Resource fork

The resource fork is a construct of the Mac OS operating system (and implemented in all of the filesystems used on the Macintosh, MFS, HFS and HFS Plus), used to store structured data in a file, alongside and tightly bound to unstructured data within the data fork. While the resource fork is probably mostly used by applications and other executables, every file is able to have a resource fork, and so its use is not limited to applications alone. 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.

Unlike most prior microcomputer systems, in which programs directly accessed hardware and were responsible for user interaction and input/output themselves, the Macintosh provided operating system services for many I/O functions, notably the graphical user interface. Many of the data structures used by these routines, including the layout of GUI elements such as menus and windows, are stored in structured formats known as resources. Resources are stored in the resource fork of each application or other file. 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.

Each resource has an OSType identifier (a four byte value) and an ID (a signed 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 were until the advent of the PowerPC processor 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 (eg. '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.

This complexity has led to compatibility problems with other filesystems in the past. In order to transmit a Macintosh file over a network or other medium, the data and resource forks must be serialized together. A number of file formats, such as MacBinary and BinHex, have been used to implement this. In addition, a file server seeking to present filesystems to Macintosh clients must accommodate the resource fork as well as the data fork of files; Unix servers usually implement this with hidden directories.

The concept of a resource is now largely universal in all modern operating systems. However, the concept of the resource fork remains a Mac-only one. Most operating systems used a binary file containing resources, which is then "tacked onto" the end of an existing program file. This solution is used on Microsoft Windows for instance, and similar solutions are used with the X Window System, although the resources are often left as a separate file.

Although the Windows NT NTFS can support forks (and so can be a file server for Mac files), the native feature providing that support, called a file stream, has never been used extensively -- certainly not as a true resource fork. However, Windows operating system features (such as the standard Summary tab in the Properties page for non-Office files) and Windows applications are using them more often now, (and Microsoft is developing a next-generation file system that has this sort of feature as basis).

Early versions of the BeOS implemented a database within the filesystem, which could be used in a manner analogous to a resource fork. Performance issues led them to change this in later releases, to a system of complex filesystem attributes. Under this system resources were handled in a fashion somewhat more analogous to the Mac.

Perhaps the best solution to the problem was implemented on the NeXT operating systems NeXTSTEP and OPENSTEP, and its successor, Mac OS X, and other systems like RISC OS. Under these systems the resources are left in an original format, for instance, pictures are included as complete TIFF files instead of being encoded into some sort of container. These resources are then placed in a directory using a Unix filesystem along with the executable code and "raw data". The directory (called a "bundle") is then presented to the user as the application itself. This solution provides all of the same functionality as the resource fork, but allows the resources be easily manipulated by any application – a "resource editor" (like ResEdit) is not needed. From the command line interface, the bundle appears to be a normal directory. This approach was not an option on the original Macintosh OS, since the file system (MFS) did not support folders/directories. Mac OS X does retain the classic Resource Manager API as part of its Carbon libraries for backward compatibility. However, the resources themselves can now be stored in separate data files within the OSX filesystem - the Resource Manager now hides this implementation change from the client code.

External links

• Apple Developer Resource Library: Resource Manager Reference (http://developer.apple.com/documentation/Carbon/Reference/Resource_Manager/index.html)
• Apple Developer Resource Library: Resource Management, Bundles (http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/index.html)ja:リソースフォーク