 | This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) (Learn how and when to remove this message)
|
Aresource fork is afork of afile onApple'sclassic Mac OSoperating system that is used to store structured data. It is one of the two forks of a file, along with thedata fork, which stores data that the operating system treats as unstructured.[1]: 1-4 Resource fork capability has been carried over to the modernmacOS 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.[1]: 1-5
The concept of resources and resource forks was conceived and implemented by Apple programmerBruce Horn.[2] It was inspired bySmalltalk'sdynamic andobject-oriented programming environment, and specifically the object-orientedvirtual memory system OOZE designed byTed Kaehler.[3]
In classic Mac OS, resources and resource forks served several purposes:
Resource forks are natively supported in all of thefile systems used for system drives in theclassic Mac OS (MFS,HFS andHFS Plus), and in themacOS-onlyAPFS (but not inUFS,[5] 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 anicon 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 adatabase.
The Macintosh file systems storemetadata 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 Classic68k application, where even the executable code is contained in resources of type 'CODE'. LaterPowerPC 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 otheroperating systems. The MacBinHex andMacBinary 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 theAppleSingle and AppleDouble formats. Starting withMac OS X Tiger, AppleDouble was used to store resource forks on file systems such as WindowsSMB shares andFAT32 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.[6]
As of August 7, 2002, Apple recommended that developers should not build resources into resource forks inMach-O binaries on Mac OS X.[7]
Each resource has anOSType identifier (a four byte value), an ID (asigned 16-bitword), and an optional name. There are standardized resource types fordialog boxes (DITL), images (PICT), sounds (snd) – andexecutable binaries (CODE) which, until the advent of thePowerPCprocessor, were without exception stored in the resource fork. Subroutines for renderingwindows 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 asResEdit 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 ahandle 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.
As the resource fork can be edited with a resource editor such asResEdit, it can be used tolocalize and customizesoftware. In addition, most resource editors allow visual editing of data. InmacOS, it is possible to use resources when developing an application. However, if the application may need to be used inUFS, 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[citation needed]. Theintegrated development environments distributed for free byApple Inc., which includeMPW andApple Developer's Tools, include acompiler called Rez.[1]: 1-3 This uses a dedicated language, also called Rez, which can be used to create a resource fork by compilingsource 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.[1]: 1-8 This can be used to allowrandom 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,[1]: 1-4, 1-5 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.
Resource forks appear as theextended attribute com.apple.ResourceFork.[8]
Previously resource forks were accessed via the 'Resource Manager'API. This API is now deprecated.[9]
Under the deprecated API:
File Manager APIs such asPBOpenRF() 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."[10][1]: 1-5
From thePOSIX interface, the resource fork could be accessed asfilename/..namedfork/rsrc or asfilename/rsrc; the shorter form was deprecated inMac OS X v10.4 and removed completely inMac OS X v10.7.[11]
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 | alias | Stores an alias to another file, in a resource fork of a file whose "alias" attribute bit is set |
| ALRT | alert | Defines the shape of an application alert box |
| APPL | application | Stores application information |
| BNDL | bundle | Defines data such as a file type icon used in an application |
| cicn | color icon | Defines a color icon used in data |
| clut | color look-up table | Defines a color palette used in data |
| CNTL | control | Defines the details of a component positioned in a window |
| CODE | code resource | Stores the machine code for the program |
| CURS | cursor | Defines the shape of a monochrome cursor (8 × 8 bit square) |
| DITL | dialog item list | Defines a component of a window |
| DLOG | dialog | Defines the shape of a dialog box for an application |
| FREF | file reference | Defines a file type handled by an application |
| hfdr | icon balloon help | Defines the contents and shape of the balloon help displayed when the cursor hovers over the file in the Finder |
| icl8 | 8-bit icon list | Defines an icon displayed in the Finder |
| icns | 32-bit icon list | Defines an icon displayed in the Finder |
| ICON | icon | Defines a monochrome item used in data |
| kind | file description | Defines a description of a file type |
| MBAR | menu bar | Defines a menu and menu bar for an application |
| MDEF | menu definition | Defines a menu for an application. Can also be used to define menus with complex shapes such as color palettes. |
| MENU | menu | Defines the menu items in an application |
| MooV | movie | Stores a QuickTime movie |
| open | open | Defines a file type which the application can open |
| PICT | picture | Stores a PICT image contained in the file |
| PREF | preference | Stores the environment settings for an application |
| snd | sound | Stores a sound used in the file |
| STR | string | Stores a string or hexadecimal data used in the file |
| STR# | string list | Stores multiple strings used in the file |
| styl | style | Defines style information, such as the font, color and size of text |
| TEXT | text | Stores text |
| TMPL | template | Describes the data format of a specific resource type, to control howResEdit and other resource editors display resources of that type |
| vers | version | Defines theversion or region of use of the file |
| WDEF | window definition | Defines a window for the application. Windows of an unspecified shape can also be defined. |
| WIND | window | Defines the shape of an application window |
Because resource forks are a Mac-specific feature, they have led to compatibility problems when storing Mac files on file systems that do not support resource forks natively, such asFAT, when storing them onnetwork shares, or when otherwise transmitting them over a network, such as viaemail.
AFP natively supports resource forks. Many AFP servers internally use file systems with no resource fork support and thus store resource forks in other ways instead, such as in a special file or directory or in analternate data stream. This happens internally on the server side though, so that from the client's perspective, files on the AFP share have native resource forks.
TheSMB protocol supports a file metadata system similar to Mac forks, known asalternate data streams, which macOS uses by default sinceMac OS X 10.6 if supported by the SMB server. In previous versions of Mac OS X, including upgraded versions of 10.6,[citation needed] this feature is disabled by default, but can be enabled manually.[15]
On volumes that do not natively support resource forks,extended attributes, or alternate data streams, such as localFAT file systems orNFSv3 network shares, macOS uses a technique calledAppleDouble to store resource forks and other Mac-specific metadata. In this case, the data fork is written as a regular file, while the resource fork and metadata are written to a separate hidden file whose name is the original file name with "._" prepended. For example, "ExampleFile.psd" would contain the data fork and "._ExampleFile.psd" would contain the corresponding resource fork and metadata.
Compatibility problems can arise if Mac clients connecting to the same network share don't use the same way of storing resource forks. For example, if one client uses a protocol with native resource fork support like AFP, but another client connects via a protocol like NFSv3 that requires AppleDouble to store resource forks, the two clients may see different resource fork contents for the same file.
Another challenge is preserving resource forks when transmitting files using non-resource fork-aware applications or with certain transfer methods, including email and FTP. A number of file formats, such asMacBinary andBinHex, have been created to handle this. Command-line system toolsSplitForks andFixupResourceForks allow manual flattening and merging of resource forks.
Carbon applications compiled for theIntel architecture may havebyte order issues when working with resources, because most resource data is stored in big-endian byte order, as used by the68000 andPowerPC architectures, which does not match the Intel architecture's little-endian byte order. While the operating system automatically handles these byte order differences for the overall resource fork format and for standard resource types like 'snd' or 'moov', any resources with non-standard types must have their data byte-swapped manually to ensure consistent behavior regardless of architecture.[16]
Until the advent ofMac OS X v10.4, the standard UNIX command-line utilities in macOS (such ascp andmv) did not respect resource forks. To copy files with resource forks, one had to useditto or CpMac and MvMac.
The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on theXerox Alto in Smalltalk-76.[17] The concept is now largely universal in all modern operating systems. However, the concept of the resource fork remains peculiar to the Macintosh. 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 forWindows resources for instance, and similar solutions are used with theX Window System, although the resources are often left as a separate file.
TheWindows NTNTFS can support forks (and so can be a file server for Mac files), the native feature providing that support is called analternate data stream. Windows operating system features (such as the standard Summary tab in the Properties page for non-Office files) and Windows applications use them and Microsoft was developing anext-generation file system that has this sort of feature as basis.
Early versions of theBeOS implemented a database within the file system, which could be used in a manner analogous to a resource fork. Performance issues led to a change in later releases to a system of complex file system attributes. Under this system resources were handled in a fashion somewhat more analogous to the Mac.
AmigaOS does not use forked files. Itsexecutable files are internally divided into a modular structure of large pieces (hunk) capable of storing code, data, and additional information. Similarly, data and project files have achunk structure codified in theIFF standard. Other file types are stored similarly to other operating systems. Though not strictly a resource fork,AmigaOS stores meta data in files known as.info files..info files can be identified by the.info extension; for example, if you save a project to a disk, two files will be saved,MyProject andMyProject.info.MyProject would be the actual project data andMyProject.info would contain the project icon, information regarding which program is needed to open the project (since there is noapplication binding in AmigaOS), special project options and any user comments..info files are invisible on the Amiga's desktop (Workbench). The icon on the desktop, taken from the.info itself, is theinterface metaphor through which the user interacts both with the project itself and its associated.info file. A dialog box accessible by right-clicking the icon allows the user to see and modify the metadata present in the.info file..info files can be seen as individual files in thecommand-line interface or aFile manager. Modern AmigaOS clones (AROS,MorphOS andAOS4) inherit the structure (complete with metadata) of the.info files of older AmigaOS versions, and can also accept standardPNG graphic files as icon bitmaps in their.info files.
NeXT operating systemsNeXTSTEP andOPENSTEP, their successor,macOS, and other systems likeRISC OS implemented another solution. Under these systems the resources are left in an original format, for instance, pictures are included as completeTIFF files instead of being encoded into some sort of container. These resources are then placed in a directory along with the executable code and "raw data". The directory (called a "bundle" or "application directory") 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 to be easily manipulated by any application – a "resource editor" (likeResEdit) is not needed. From the command-line interface, the bundle appears to be a normal directory. This approach was not an option on theclassic Mac OS, since the file system (MFS) did not support separate catalog directories. When catalog file support was included in Mac OS, with the HFS filesystem, the resource fork was retained. macOS does retain the classic Resource ManagerAPI as part of itsCarbon libraries for backward compatibility. However, the resources themselves can now be stored in separate data files within the file system – the Resource Manager now hides this implementation change from the client code.
