When Apple’s engineers were designing the Mac’s file system, they did something very unusual. At that time, in the early 1980s, and now, the great majority of file systems use a single fork: one file, one block of data for that file’s contents.
The Mac was going to be different. Each file would consist of two forks, one a regular data fork as in normal file systems, the other a structured database of resources, the resource fork. This enabled an app to keep different localisations of its menus and other text contents in resources. Resource forks were allowed for any file, so an app could store a document’s window settings in the document’s resource fork.
Resources were used to store a lot of standard structured data, such as the specifications for and contents of alerts and dialogs, menus, collections of text strings, keyboard definitions and layouts, icons, windows, fonts, and chunks of code to be used by apps. You could extend the types of resource supported by means of a template, itself stored as a resource, so developers could define new resource types appropriate to their own apps.
Apple developed a resource editor which quickly became one of the best-known apps on the Mac: ResEdit, last seen in version 2.1.3 way back in 1994. ResEdit was the Mac power user’s quintessential tool: if you didn’t like a particular dialog in an app, ResEdit could be used to change it; if you wanted to create your own custom keyboard layout, it was the first choice for that too. If you wanted to mess someone’s Mac up, you could go into their system files and change things around when they were out at lunch. Not that we ever did that, of course.
Each resource type had a four-character name, such as ALRT for an alert definition, DLOG for dialogs, KCHR for keyboard layouts, and so on.
You could have many different KCHR resources, each numbered, so that changing your keyboard layout was a matter of switching from KCHR number 2, the standard British layout, to number 26, which was Dutch, for example. Adding your own custom keyboard layout was then merely a matter of defining a new KCHR resource with a unique ID number, here 128, and editing it to do what you wanted.
Many resource types had custom editors: here that for KCHR has a simple keyboard layout and tabular form. The highlighted (black) keys indicate that the Euro character € being shown would be generated by holding the Opt (Alt) modifier key and pressing the 2 key on the top row of the main keyboard, but not the 2 on the numeric keypad.
Mac OS X still supports multiple forks for files, including resource forks, but they can cause problems with tools derived from Unix, which were not designed to deal with such additional forks. Apple has, from the outset of OS X, discouraged developers from using resource and other forks, and they have gradually died away.
Resource forks and the thinking behind them are ingenious and empowering, but open up all sorts of security issues. In the days when there was Classic Mac OS malware, it almost invariably lived in resource forks, and took great advantage of their features. Although it was possible to lock and protect individual resources, armed with a copy of ResEdit you could soon change that, and almost anything else that you wished to – just as malware could and did.
Instead, we now have app bundles, folders containing standard structures of files and more folders, made to look like an app, library, or whatever. Within those, the data structures which would have gone into resources are now folders full of files, with standard data forks. In many cases, structured data are set out in XML, which is much less efficient than the old resources, and less suitable for power users to tamper with.
Instead of the limitless customisations to Mac OS, apps, and almost everything on your Mac, which could be accomplised using ResEdit, we are now constrained to tweaking the few settings offered in property lists (.plist files). While they lasted, resources and ResEdit were exciting and satisfying, but horribly insecure.