On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type.
So why wouldn't a stand-alone font file consist of a Resource fork with a single resource of "FONT" type? Otherwise, the OS engineers have to develop two entirely different ways of reading in font data. Why duplicate the effort?
The system made perfect sense, both then and now. It bothers me that so few people know anything about Mac Classic, it really was an amazingly well-designed OS for its time.
It had a few interesting ideas. But no desktop OS based on cooperative multitasking can be called 'well-designed', almost anything could hard-lock the entire system at any time.
>On Mac Classic, if you wanted to ship a custom font with your application, you'd put it in the Resource fork in a resource of "FONT" type.
On Windows you can do the same thing with .rsrc in an .exe/.dll file.
It's possible you would ship a font as a PE .dll with a font resource, but for a single file the encapsulation is a little unnecessary (unless your application architecture already makes it easy to deal with PE encapsulation).
Except that in the windows example you gave the .rsrc section is part of the main data stream. It is counted in the file's size when doing a dir command. When the file is copied by all command line and shell tools or sent over the internet the data in the .rsrc section is copied/sent just like all the other data in the exe/dll.
None of this is true for the resource fork in the Mac case.
It does not strike me as a sane design. You already have file extensions, unique prefixes (like those used by the 'file' command to identify files). Why would you use fs forks to differentiate between file types?
There are various arbitrary restrictions in various filesystems and operating systems. The intention is to store smaller amounts of useful information with the file. Smaller means in the bytes/kilobytes range. For example you wouldn't store multi-gigabyte alternate language versions of a video file in its extended attributes. But you could store URLs of where to get them.
Or you could attach authorship, review, dates, keywords and similar metadata which would work for any file type, not just those whose format explicitly has that support.
If you want to get a handle on what filesystem design is like then I highly recommend Dominic Giampaolo's book on the design and implementation of the Be filesystem (he wrote BeFS). The book is freely available from his website as http://www.nobius.org/~dbg/practical-file-system-design.pdf and includes information about the design of other filesystems too. It isn't exhaustive, but does give a very good grounding in filesystems and does cover extended attributes.
Fonts, when part of a program, were stored in a "FONT" fork (conversely, icons went into "ICON"). It's natural that font files would have nothing in the data fork and the font definition itself would be under FONT.
Ah, good to know. My last Mac was m68k (Performa 630CD, one of the very last m68k models), so my memories include seeing plenty of CODE resources when playing around with ResEdit.
Oh they stuck around, of course, an entire other chapter of historical MacOS zaniness in which many programs and the OS itself contained and ran both 68k and PPC code at the same time, there were 'universal procedure pointers', 'accelerated' CODE resources (with PPC code in them) and on and on.
Actually, I believe OS X does this for small files in order to not burn a whole filesystem block on a sub 1k file.
"In Mac OS X Snow Leopard 10.6, HFS+ compression was added. In open source and some other areas this is referred to as AppleFSCompression. Compressed data may be stored in either an extended attribute or the resource fork.[13] When using non-Apple APIs, AppleFSCompression is not always completely transparent."
FS compression is transparent to any regular file-reading API; it only shows up in lower-level APIs, like if you want to copy the file and keep the compression.
I was responding to the comment "You wouldn't put the entire content of a file in an extended attribute, would you?" HFS+ does, although in this case, it does without leaking that detail to callers.
So why wouldn't a stand-alone font file consist of a Resource fork with a single resource of "FONT" type? Otherwise, the OS engineers have to develop two entirely different ways of reading in font data. Why duplicate the effort?
The system made perfect sense, both then and now. It bothers me that so few people know anything about Mac Classic, it really was an amazingly well-designed OS for its time.