Resource Fork - Other Operating Systems

Other Operating Systems

The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on the Alto in Smalltalk-76. 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 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 an alternate data stream, (introduced for this very reason) 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 was developing a next-generation file system that has this sort of feature as basis.

Early versions of the BeOS 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. Its executable 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 a chunk structure codified in the IFF 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 and MyProject.info. MyProject would be the actual project data and MyProject.info would contain the project icon, information regarding which program is needed to open the project (since there is no application 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 the interface 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 the Command line interface or a File manager. Modern AmigaOS clones (AROS, MorphOS and AOS4) inherit the structure (complete with metadata) of the .info files of older AmigaOS versions, and can also accept standard PNG graphic files as icon bitmaps in their .info files.

NeXT operating systems NeXTSTEP and OPENSTEP, and its successor, OS X, and other systems like RISC OS implemented another solution. 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 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” (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 Mac OS, since the file system (MFS) did not support folders/directories. When directory supoort was included in Mac OS, with the HFS filesystem, the resource fork was retained. 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 file system — the Resource Manager now hides this implementation change from the client code.