Everybody knows that. Put a MS-DOS floppy or cartridge in a Macintosh computer and, most of the time, you don't see the difference with a Macintosh volume. Apple engineers did a really good job integrating this file system. It is even possible to copy a difficult Macintosh file, say a font file, to the MS-DOS disk and back without loosing anything, be it the full name (including characters unallowed in a classical MS-DOS filename), the data fork, the resource fork or the icon.
To manage this, the system creates in each folder two hidden items, a file named "finder.dat" and a subfolder named "resource.frk". The file contains a table with the short and long names of files and folders, plus the signature of the files. The data fork is stored in the normal folder, under the main name of the file (short name beginning with a !, for whatever reason, under system 7.x, long name under system 8.x). The resource fork is stored in the resource folder under a truncated name (without suffix). When the file has a null data fork, the main file in the visible folder is empty. Depending on the versions of Apple utility, there may be a empty resource fork in the subfolder, or not.
When you load the MS-DOS medium on a PC, it behaves quite normally. The innocent
user may note that the files don't have the descriptive icons he is now accustomed
to get under Windows. For an example, the Word file announced by the sender had
the Windows generic icon and a double click on it doesn't open Word, but an error
window with a cryptic message about registration of suffixes.
Gurus will say that the Macintosh user should have named his file with a specific
extension, to alleviate the problems of the receiver. Well, those gurus should
go and tell them...
Things are manageable if you get only one file. And what about a whole DTP job
under Xpress, with numerous included pictures?...
Font files are a good illustration of the problem of Macintosh files being not
of a monolithic nature. Fonts are namely stored in the resource fork, and not in
the data fork. And those resource forks are not in the main file (the one with
a really cute long name) but in the hidden subfolder under a cryptic truncated
name.
How could the user know all that? He copied his fonts in a folder adequately
named "Fonts" on the Macintosh, he tries to copy the same files from
the same folder. And he gets empty files. And he gets puzzled.
This kind of problems isn't really dramatic when you're exchanging little text
files with a buddy or when you just have to type a text page again. If you're
a professional computer user, your time is money and you have deadlines to meet.
Transferring files is not a game and you should use real tools.
Even if things can eventually be ironed out, even if the customer was happy at
the end, did you (or your boss) take the time to estimate the real costs of all
those incidents? How much for the operator who spent half a day sorting the files
without extensions, just to know which file was the Xpress files and which ones
the pictures? How much for checking the reflow problems because you had to use
another font, even if the sender swore he had put the correct font on the Zip
cartridge...
From release 5, our Mac-PC transfer program MacDisk also manages this kind of MS-DOS media storing Macintosh files, to allow you to get on the PC correctly suffixed files and even to convert font files. We developped those features to answer the need expressed by numerous actual and potential users and think that they can be really useful tools for real professional users. The cost of the software can be set off most of the time on a single job.
Maybe you still have some MS-DOS disk with such files lying around on your desk. Just download a copy to check yourself the difference and see how MacDisk can help you with those disks.