Resource fork

The resource fork is a fork or section of a file on Apple's classic Mac OS operating system, which was also carried over to the modern macOS for compatibility, used to store structured data along with the unstructured data stored within the data fork. The resource fork is a fork or section of a file on Apple's classic Mac OS operating system, which was also carried over to the modern macOS for compatibility, used to store structured data along with the unstructured data stored within the data fork. A resource fork stores information in a specific form, containing details such as icon bitmaps, the shapes of windows, definitions of menus and their contents, and application code (machine code). For example, a word processing file might store its text in the data fork, while storing any embedded images in the same file's resource fork. The resource fork is used mostly by executables, but every file is able to have a resource fork. Originally conceived and implemented by programmer Bruce Horn, the resource fork was used for three purposes with Macintosh file system: The resource fork is implemented in all of the file systems used for system drives on the Macintosh (MFS, HFS and HFS Plus). The presence of a resource fork makes it easy to store a variety of additional information, such as allowing the system to display the correct icon for a file and open it without the need for a file extension in the file name. While access to the data fork works like file access on any other operating system — pick a file, pick a byte offset, read some data — access to the resource fork works more like extracting structured records from a database. (Microsoft Windows also has a concept of 'resources', but these are completely unrelated from resources in Mac OS.) The resource fork is sometimes used to store the metadata of a file, although it can also be used for storing the actual data, as was the case with font files in the classic Mac operating systems. Note that the Macintosh file systems also have a separate area for metadata distinct from either the data or resource fork. Being part of the catalogue entry for the file, it is much faster to access this. However, the amount of data stored here is minimal, being just the creation and modification timestamps, the file type and creator codes, fork lengths, and the file name.Some files have only a resource fork. Classic 68k applications are one example, where even the executable code is contained in resources of type 'CODE'. Later PowerPC binaries store the executable code in the data fork. As resource forks are supported only on the file systems HFS and HFS Plus, they cannot be used on operating systems which use other file systems. At present, HFS is supported only by the Macintosh operating system, which means that only machines running Mac OS can use resource forks. Even in a Mac OS system, resource forks cannot be used if the Unix File System has been installed. In the HFS Plus file system, which is currently the system most commonly used under Mac OS, settings can be made to allow other forks in addition to the data and resource forks, to create a 'multi-fork' application. However, as forks can make it difficult to exchange files with other operating systems, this feature is not in common use. Even in macOS, resource forks are seldom used anymore. Currently, macOS supports resource forks on Windows SMB shares by creating a hidden file in the same directory with the data fork file, with the characters '._' at the beginning of the file name. 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.