Mac OS was severely resource constrained. Applications typically had less memory to run in than the screen and audio buffers together used (32 kB)<p>Also, the CPU Mac OS ran on did not support virtual memory.<p>To make such a system run, applications were split into several code segments. For example, no sane program would load its printing code into memory before the user actually tried to print, and individual MacPaint commands might be located in independently loaded pieces of code, too. Resource forks and their standardized format allowed that.<p>Once that code was in place, using it for all kinds of other data that wasn&#x27;t always needed such as fonts, drivers, or desk accessories became the logical thing to do.<p>It just was easier, and put less of a constraint on memory to access a font as a set of resources than to write a similar, but separate piece of code for handling the reading of fonts from regular files.<p>See <a href="http:&#x2F;&#x2F;www.folklore.org&#x2F;StoryView.py?project=Macintosh&amp;story=Font_Manager.txt" rel="nofollow">http:&#x2F;&#x2F;www.folklore.org&#x2F;StoryView.py?project=Macintosh&amp;story...</a> for a description by someone who worked on this.<p>For me, the only weird thing is that they chose to use alternate forks. They could just as well have stored the resource fork data in the only data stream in a file. My guess would be that they did that so that they had the freedom to also write portable file formats to files that also contained resources (it certainly wasn&#x27;t so that they could write secret messages in the System file. That happened way later, with system 7)