A resource fork is a fork of a file on Apple's classic Mac OS operating system that is used to store structured data. It is one of the two forks of a file, along with the data fork, which stores data that the operating system treats as unstructured. Resource fork capability has been carried over to the modern macOS for compatibility.
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). Any file can have a resource fork, not just applications - for example, the screen position of a document window might be stored as a resource in the document's resource fork, separate from the document's contents stored in the data fork.
Design The concept of resources and resource forks was conceived and implemented by Apple programmer Bruce Horn. It was inspired by Smalltalk's dynamic and object-oriented programming environment, and specifically the object-oriented virtual memory system OOZE designed by Ted Kaehler.
In classic Mac OS, resources and resource forks served several purposes: Reducing the RAM usage of large data, such as bitmaps, by implementing a form of virtual memory: resources can be loaded from disk into memory on demand and unloaded when no longer needed. Providing a way for non-programmers to perform internationalization and localization or to change an application's graphical elements, without needing access to the source code. Storing the Finder's Desktop Database, which stored file type associations and icons as resources. Allowing applications to distribute nearly all of their components in a single file, reducing clutter and simplifying application installation and removal.
File system support Resource forks are natively supported in all of the file systems used for system drives in the classic Mac OS (MFS, HFS and HFS Plus), and in the macOS-only APFS (but not in UFS, a supported choice for system drives in early Mac OS X versions). The presence of a resource fork makes it easy to store a variety of additional information, such as an icon that the desktop should display for that file. While the data fork allows random access to any offset within it, access to the resource fork works like extracting structured records from a database.
The Macintosh file systems store metadata distinct from either the data or resource fork, such as the creation and modification timestamps, the file type and creator codes, and fork lengths.
Some files have only a resource fork. One example is a font file in the classic Mac OS. Another example is a Classic 68k application, where even the executable code is contained in resources of type 'CODE'. Later PowerPC binaries stored the executable code in the data fork.
Since resource forks were supported only on Macintosh file systems including MFS, HFS, HFS Plus, and APFS, they could not be copied to the file systems of other operating systems. The Mac BinHex and MacBinary formats were invented to encode resource and data forks into one file, for transfer between systems. A/UX supported resource forks on Unix file systems via the AppleSingle and AppleDouble formats. Starting with Mac OS X Tiger, AppleDouble was used to store resource forks on file systems such as Windows SMB shares and FAT32 volumes.
In the HFS Plus file system, settings can be made to allow other forks in addition to the data and resource forks, to create a "multi-fork" application.
As of August 7, 2002, Apple recommended that developers should not build resources into resource forks in Mach-O binaries on Mac OS X.
Resource identifiers Each resource has an OSType identifier (a four byte value), an ID (a signed 16-bit word), and an optional name. There are standardized resource types for dialog boxes (DITL), images (PICT), sounds (snd ) and 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), and subroutines for rendering menus in theirs (MDEF). This arrangement enabled users to easily customize 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, 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.
Editing
As the resource fork can be edited with a resource editor such as ResEdit, it can be used to localize and customize software. In addition, most resource editors allow visual editing of data. In macOS, it is possible to use resources when developing an application. However, if the application may need to be used in UFS, it is also possible to configure it so that the entire resource fork is moved to the data fork, using the Raw Resource File setting. The integrated development environments distributed for free by Apple Inc., which include MPW and Apple Developer's Tools, include a compiler called Rez. This uses a dedicated language, also called Rez, which can be used to create a resource fork by compiling source code. A decompiler, DeRez, which can be used to change a resource fork back into Rez code is also included.
In the structure of the resource fork, there is a piece of data called a "resource map" which stores the positions of resource data items. This can be used to allow random access to resource data based on the defined IDs and names. The resource fork can be thought of as consisting of essentially three objects, the resource header, the resource map, and the resource data itself, but in fact each data type is a hierarchical structure which stores multiple items of data. The format in which the information in the resource data is stored is defined based on the types of information, which are known as "resource types." Resource data often makes references to other types of data.
Accessing Resource forks appear as the extended attribute com.apple.ResourceFork.
Previously resource forks were accessed via the 'Resource Manager' API. This API is now deprecated.
Under the deprecated API: When a resource fork is accessed, data including the start position and length of the resource data and resource map is read in from the header. If a resource type to read in has been specified, a check is performed to make sure that type is present in the resource list, and the number of items of data containing that type and their offsets in the resource reference list from the start position of the resource map is found. The resource ID, the offset of the resource name, the resource properties, and the offset of the data from the start position of the resource data is found. If resource data with the specified ID or name is present in the resource data, the offset obtained above is accessed, the data length is found, and all the data stored there is read in, and returned as the return value.
File Manager APIs such as PBOpenRF() also allowed access to the raw resource fork; however, they should be used only for applications such as copying a file Apple strongly warns against using the resource fork as a "second data fork."
From the POSIX interface, the resource fork could be accessed as filename/..namedfork/rsrc or as filename/rsrc; the shorter form was deprecated in Mac OS X v10.4 and removed completely in Mac OS X v10.7.
Types The type codes below, like the above datatypes, are used as type identifiers for more than resource forks themselves: they are used to identify files themselves, to describe data in the clipboard, and much more.
Types must be 4 bytes long, so types like snd and STR actually have a space (0x20) at the end. Name of resource type actual name Description alis aliasStores an alias to another file, in a resource fork of a file whose "alias" attribute bit is set ALRT alertDefines the shape of an application alert box APPL applicationStores application information BNDL bundleDefines data such as a file type icon used in an application cicn color iconDefines a color icon used in data clut color look-up tableDefines a color palette used in data CNTL controlDefines the details of a component positioned in a window CODE code resourceStores the machine code for the program CURS cursorDefines the shape of a monochrome cursor (8 × 8 bit square) DITL dialog item listDefines a component of a window DLOG dialogDefines the shape of a dialog box for an application FREF file referenceDefines a file type handled by an application hfdr icon balloon helpDefines the contents and shape of the balloon help displayed when the cursor hovers over the file in the Finder icl8 8-bit icon listDefines an icon displayed in the Finder icns 32-bit icon listDefines an icon displayed in the Finder ICON iconDefines a monochrome item used in data kind file descriptionDefines a description of a file type MBAR menu barDefines a menu and menu bar for an application MDEF menu definitionDefines a menu for an application. Can also be used to define menus with complex shapes such as color palettes. MENU menuDefines the menu items in an application MooV movieStores a QuickTime movie open openDefines a file type which the application can open PICT pictureStores a PICT image contained in the file PREF preferenceStores the environment settings for an application snd soundStores a sound used in the file STR stringStores a string or hexadecimal data used in the file STR# string listStores multiple strings used in the file styl styleDefines style information, such as the font, color and size of text TEXT textStores text TMPL templateDescribes the data format of a specific resource type, to control how ResEdit and other resource editors display resources of that type vers versionDefines the version or region of use of the file WDEF window definitionDefines a window for the application. Windows of an unspecified shape can also be defined. WIND windowDefines the shape of an application window
Editors ResEdit Distributed free of charge by Apple. Can be used for visual editing of resource data. If the structure of data is known, it can display a range of different types of data in a visual format. Does not run on modern macOS. Resorcerer Expensive, but popular, as it can be used for visual editing of many more types of data than ResEdit. HexEdit A binary editor, which in fact is normally used more for editing the data fork rather than the resource fork. ResKnife Open-source editor for Mac OS X; no longer maintained.