Nubies' Corner

     Archives is a term used for a file that was created by encoding a file or folder of files into a different format. There are a number of uses for archives, and some formats are better than others for given tasks.

     For the Mac, StuffIt (.sit) by Aladdin is the primary archive format for compressing files for transfer over the internet. A slightly older and relatively common format is MacBinary (.bin), which is a little less compatible with some decoders. Since both of these formats have both resource and data forks, they are usually text encoded using BinHex (.hqx, binary hexadecimal). In many cases, the resource fork for StuffIt is not necessary, so the archive can be uploaded to the net for download. It is advisable to first remove the resource fork and test the archive before posting to a non-Mac server, to be sure that it can be properly opened. Usually, the dual encoding is used for Mac files, either .sit.hqx or .bin.hqx. Usually, the first extension is dropped and the file is amended with a simple .hqx.
     The PC platform, which only has the single data fork, uses Zip. Since there is no resource fork to protect, there is no need to text encode the archive, since it is already a text file by nature, as are all PC files. All the .zip encoding needs to do is save space.

     Saving space is a rather complex process. First, the files being encoded are checked for dead space, basically null entries (digital zero). These dead spaces are given a prefix and numerical value, defining the number of consecutive null spaces there are. This shortens the sequence considerably for files that are loaded with null spaces. It's less effective on files that have fewer null spaces. Next, the encoder uses a preset encoding algorithm that takes a sequence of digital values (bytes) and gives them a value with the decoder will reverse. The encryption depends on the format, as all are different by definition.
     The Self Expanding Archive (.sea) is basically a StuffIt archive with the necessary decoding code within the file. It is essentially a document and an application rolled into one. It takes up more space than the StuffIt archive, but it has the advantage of not needing a decoder application, such as StuffIt or StuffIt Expander present to decode the archive. This is the answer on how to get StuffIt Expander if you don't already have StuffIt Expander to open the archive containing it. The PC equivalent of the SEA is the Self Expanding Zip (.exe). This can be a little confusing, as there are both self expanding zips and executables available for download on the net, often without description. One can be expanded, the other is totally useless on a Mac. But for the PC to run the self contained code, it must be labeled as an executable.

     Another type of archive is the image file (.img, .smi). Instead of expanding into files, they expand into disk images, which imitate a disk (hard drive, CD, floppy, etc) on the desktop. Once expanded, the image is double clicked (can be set to open automatically on expanding), and it acts exactly like a disk. It requires a desktop just like a real disk. When dragged to the trash, the image vanishes, but the file containing the disk image remains on the hard drive. Apple loves to use Disk Copy to send out all it's software, a throwback to the days when the floppy disk was the largest portable media. On simply opened the image, dragged it to a floppy, and saved it. It allowed for a reliable means of mass copying without the means to alter the locked contents. Even though we've moved to Zip disks, CD-r, and many other types of removable media, the .smi remains the basic package for Apple.

     There are many compression formats available, such as CPT, RAR, UU, MIME, ARC, and many more, and each has served its purpose over time. Likewise, the other platforms, like Unix, Linux, Sun, etc, have their own archive formats, like Gzip, Bzip, tar, and others. To learn them takes a little time and exposure to them. Some are more efficient than others, some serve specific purposes better than others. Some were unsuccessful attempts to unseat the ruling archive formats. Knowing when to use what is the mark of someone with years of computing skills. But the basic four, .sit, .bin, .hqx, and .zip are the four to know first, as over 90% of the archives on the net for download are one of these formats. For Mac, StuffIt Expander is the most popular multi-format decoder available. It's PC counterpart, Aladdin Expander, is just as versatile for decoding a multitude of formats.

     Encoding and decoding can often be performed with the same application. However, the more popular (and less expensive) versions are separate applications. For example, StuffIt Deluxe, the commercial application from Aladdin, does just about every encoding and decoding available for the Mac, allowing files to be targeted for a number of other platforms. The less expensive DropStuff and DropZip allow encoding for the one format only. They do a great job of encoding, but many of the tools in the Deluxe version are missing, and they don't decode. The free StuffIt Expander only decodes, though it decodes most any current archive format. DropStuff, DropZip, and StuffIt expander come with the Deluxe package for the drag and drop ease, when the full range of tools is not needed and time saving is a factor.
     Note that Aladdin is the leader in the archive business on the Mac, but it's not the only application. There are a number of format specific encoders and decoders, as well as a few multiformat decoders available. And for the PC, the outdated WinZip still holds a certain loyalty, even though there are far better options today.






Technique

     Cross-platform conversion is one of the most perplexing processes in the digital world today. At the same time, there is a definite demand for it. It is a skill that is highly desirable, and one that takes a basic understanding of platform protocols to get right. If you can convert between Mac and PC, you're no novice, and you will gain friends quickly by offering your services to those in need of them.

     Before I begin dealing with the process, let me clarify that only document files can be carried across platform lines without some form of emulation (Virtual PC, RealMac, etc) or a cross-platform transfer application (Dave, etc).
     The reason for the major differences in the Macintosh and PC platforms dates back to the time when Bill Gates was fired by Apple and the grudge he held and carried over into his Microsoft designs. Many of the differences were designed to prevent cross-platform compatibility in an attempt to destroy Apple. Hence the art of cross-platform conversion requires the undoing of the differences that Bill Gates insisted upon in the early PC designs.

     And a warning for anyone who wants to convert files between platforms. No one ever buys an inferior platform. The ego couldn't bear the thought of being on the losing end with that kind of sticker shock. The platform purchased is always superior, end of argument. Always take platform bashing with a grain of salt if you're going to be a converter. Mac does some things better, PC does others better. (I chose Mac because it fits what I do better. And I know a lot of Microsoft jokes. But still, I create files for both PC and Mac users, and I do my best for both sides, because the users on both sides are people trying to do their best with what they can afford. My goal is to mend the rift as best I can.)



     To be able to convert cross-platform, one must know the parameters that differ in operating systems. Four play the largest part in converting an average document file.
Name size allocation (address bus)
File forks
File ID coding
Text encoding

Name size:
     DOS is the shortest, and most obsolete, with seven characters plus extension, giving eleven characters ((3X4 bit)-1). It still shows up occasionally on CD's, mostly out of habit. Except for a few die hard hold outs, DOS is a dead platform.
     Even though Macintosh has gone to 128 bit addressing in the G4, it still retains the 31 character name address ((4X8 bit)&endash;1) to maintain consistency in its operating platforms, from OS 6.x through OS 9.1 and OS X. Many have complained that the names could be longer, yet Apple has clung to the 31 character format so that all Macs share the common format regardless of OS. For the internet, the 31 characters translates to 27 characters plus extension, which is needed for the MIME system to properly identify file type. If there is no extension, it is assumed to be plain text. This can be fixed manually, but it is easier to perform the conversion automatically (via browser MIME assignment, MacLinkPlus, OS 9 File Exchange, etc.) by using the extension on the net. Files to be transferred from Mac to PC must bear the file type extension.
     Windows went with a 39 character address ((5X8 bit)-1), which results in a 35 character plus extension maximum name size. If a PC file is meant to be shared with a Mac, the 27 plus extension rule should be observed. File names longer than 27 characters will force the extension to be sheared from the file upon receiving, and the file type must be manually established.
     The reason for extension on PC and DOS is that the file type lies within the name of the file. On the Mac, it lies in the first few bytes of the file, along with the parent application code. On the PC, this parent code also lies within the first few bytes of the file. More on this below.

File forks
     DOS and Windows have the single fork protocol. Mac has dual fork protocol. The difference was intentionally designed to prevent Mac files from being able to run on a PC. (The reason for this dates back to the time when Bill Gates was fired by Apple and the grudge he held. Many of the differences were designed to prevent cross-platform compatibility. Hence the art of cross-platform conversion requires the undoing of what Bill Gates insisted upon.)
     PC uses many files to accomplish what Mac is capable of accomplishing with a single file. Mac has a dual fork protocol, resource/data. Some Mac files have both forks, some have only resource fork, and some have only the data fork. The data fork holds information, be it text, image, audio, support data, whatever the digital process needs to fuel the process. The resource fork holds the items needed to make the function within the system. In applications, it holds the executable code. It can also holds icons, image previews, version numbers, Finder data, interface graphics, window style, encryption keys, and much more. In the PC, these functions are far more fragmented. Mac users point to all the files PC users must have, while the PC users talk about the bloated size of Mac files. (Most of this talk is usually wrapped in an ego bolstering brag about the superior platform that the user purchased, as I explained above.) In the end, Mac dual forks allow more flexibility in the interface while consuming more drive space.
     In the end, Mac users can take most any PC document for which there is support on the Mac and use it as is. If that is not the case, most likely, there is a converter available for easily making the file usable. This is especially the case for applications that have been designed across platforms. (Photoshop, Bryce, Netscape, etc) PC generated graphics, audio, video, 3D, and database files with common formats can easily be opened and used as is by the Mac. The Mac from OS 7 to the present has been designed for ease of PC file use.
     To take a Mac file on a PC, it must be stripped of its resource fork. This means that no Mac file which requires the present of its resource fork to operate can be converted to a PC file without special processing by an application designed to do a proper conversion. But for files that do not have a resource fork or require the resource fork information to run on a PC, the resource fork (if any) can be removed with a resource fork stripper. (BoxTop software has one that is freeware called GIF Prep. There are others.) This process must take place on the Mac, since a PC can not recognize a dual fork file. Note that any Mac file that is uploaded to a PC or Unix server is automatically stripped of the resource fork by the transfer mechanism, such as the FTP client.

File ID coding
     As I stated above, the extension is an integral part of the file function for PC, while it is superfluous to the Mac, other than in the internet downloading/MIME ID process. While a .jpg files opens as a JPEG on a Mac, even if the extension is not there, a PC can not identify the file for what it is without it. Both platforms have codes that identify the file type and the parent application. Mac has both nestled internally, while the PC has one internal, one external (extension). This gives PC a slight advantage in that it doesn't have to ready any of the internal file to identify what type of file it is handling. But to identify which executable it needs to open it, it must check within the file. At today's computing speeds, the advantage is negligible.
     To explain these ID codes better, it is best to look at a document creation. Say I open up Photoshop and create a new file. I paste some preexisting images and apply a few filters. Then I select the Save function, and I choose JPEG format from the pop-up menu. In the process of writing the file, Photoshop will identify the parent application as Photoshop and the type as JPEG. Then I perform a SaveAs, saving the file as a BMP. The first file has the internal code JPEG/8BIM and the second has BMPf/8BIM. Now after closing the files, I launch JPEGView, a tried and true mac image viewer, and open the JPEG version from within the application. I use the SaveAs function and save the file. Instead of being a Photoshop JPEG, it is now a JPEGView JPEG and bears the code JPEG/JVWR.
     There are many utilities and system enhancements for dealing with the type/creator code on a Mac. The MIME codes translate automatically when downloading files from the net. The long list of Helpers in Netscape preferences are the translators that give the incoming files their Type/Creator codes. OS 9 File Exchange picks up where Netscape leaves off, and is user programmable. FileBuddy, ResEdit, Snitch, and many many more utilities/system enhancements are available for dealing with changing these codes independent of the parent applications.
     Now for Mac > PC, it's simple. The type code should be set to TEXT, and the creator code is moot, as the PC will skip over it. I usually set the creator to Simple Text (ttxt, text reader native to the Mac system) in case I need to inspect the interior of the file in a text editor. The alternative is ????, which means that the parent application is unspecified. Then the proper extension is added to the name of the file. The PC will read the extension and assign it according to the application set by the user for the system.

Text encoding
     Text is different on a Mac and a PC. If you ever open a PC text document on a Mac, you see a lot of squares, especially following line returns. StuffIt Expander has an option to automatically convert PC text to Mac, and Aladdin Expander has the converse option available. But there are plenty of others that can be used, since in some cases, one doesn't want to convert the text format, since it can cause system problems in some cases where the purpose of the file is other than for reading. For the Mac, my favorite is TextSpresso, which can convert many formats of text to another (Mac, PC, tab delineated, html....... long list). There is also MacLinkPlus, whose XTND system excels in converting various word processor formats to another. (AppleWorks > text > MS Works > Word > WordPerfect > html......... another long list) If you operate a Mac, then you should target the text format for the audience, because it is much easier to convert text on the Mac than than it is on the PC. Mac just has many more tools for it.
     All ReadMe's and other text documents should be converted, but not any of the data files (anything other than text). Converting the format of the data files will corrupt them.


     In conclusion, converting the files manually can be a bit tedious, but it can pay off handsomely. And with a little familiarity and the proper utilities, it's actually not that much of a bother. And offering both Mac and PC copies of the files you generate and post on the net is much more rewarding than answering e-mails, explaining why you don't offer the file in the "other" platform. Wherever possible, my download pages contain both versions. And I've yet to have to answer why I don't make a copy for the "other" platform (PC). Consequently, I have friends on both sides of the rift, some of which who don't mind too terribly much that I don't use a PC.