Resource Fork - Resource Identifiers

Resource Identifiers

Each resource has an OSType identifier (a four byte value) and an ID (a signed 16-bit word), as well as an optional name. There are standardised resource types for dialog boxes (‘DITL’), images (‘PICT’), sounds (‘snd ’) — and even for executable binaries (‘CODE’) which, until the advent of the PowerPC processor, were without exception stored in the resource fork. Subroutines for rendering windows are stored in their own type of resources (‘WDEF’), subroutines for rendering menus in theirs (‘MDEF’), and if there is a type of data you think does not fit any of the standardised categories, you can just as well use a type of your own (e.g. ‘John’) — actually any four characters or 32-bit value can serve as a resource type. This arrangement enabled users to easily customise not only individual applications but also the operating system itself, using tools such as ResEdit to modify the resources of an application file or any of the system files.

Within an application or other code, resources can be loaded simply using a combination of their type, ID or name, without regard to how and where they are stored in the resource fork. The client is returned a Handle to the loaded resource which can then be accessed like any other heap-based data. The OS component that facilitates this is the Resource Manager. In addition to abstracting the details of the data storage from the data itself, the Resource Manager also arranges sets of open resource forks into a stack, with the most recently opened file on top. When trying to load a resource, it will look in the top of the stack first, (perhaps the current document's resource fork), then the next one down (the application's resource fork), then the next one (system resource forks). This arrangement is very powerful — it permits local resources to override more global ones lower down — so an application can provide its own icons or fonts in place of the standard system ones, for example. It also allows an application to load resources from the system using the same API as any other resource, without regard to where or how that resource is stored — to the application, all resources are equally available and easy to use. The system reserves resource IDs in a certain range to help avoid resource conflicts arising from this. Resource Manager APIs allow the programmer to manipulate the stack and modify the search behaviour.