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, could be stored in structured formats known as resources.

Resources, respectively, are stored in the resource fork of each application or other file. This is a filesystem construct paralleling the main body of a file (the data fork), in which resources are stored by type and name. Access to the data fork works like file access on any other operating system -- pick a file, pick a byte offset, read some data -- whereas access to the resource fork works more like extracting structured records from a database.

This complexity has led to historical compatibility problems with other filesystems. 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 actuall 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, although the Windows NT NTFS can support forks (for Mac file support), it does not use them. Similar solutions are used under XWindows[?], although the resources are often left as a separate file.

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, and and its successor Mac OS X. 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 in the Unix filesystem, which is hidden from view at the user level. This provides all of the same functionality as the resource fork, but adds the ability to have the resources be easily manipulated by any application – a "resource editor" is not needed. This was not an option on the original Macintosh OS, since the first release of Mac OS did not support directories.