Editing Resource fork (section)

== Other operating systems ==
The concept of a resource manager for graphics objects, to save memory, originated in the OOZE package on the [[Xerox Alto]] in Smalltalk-76.<ref>{{cite web|url=http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html |title=The Early History of Smalltalk|access-date=2008-07-24}}</ref> 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.

The [[Windows NT]] [[NTFS]] can support forks (and so can be a file server for Mac files), the native feature providing that support is called an [[Fork (file system)|alternate 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 a [[WinFS|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 file]]s are internally divided into a modular structure of large pieces ([[Amiga Hunk|hunk]]) capable of storing code, data, and additional information. Similarly, data and project files have a [[chunk (information)|chunk]] structure codified in the [[Interchange File Format|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 <code>'''.info'''</code> files. <code>.info</code> files can be identified by the <code>.info</code> extension; for example, if you save a project to a disk, two files will be saved, <code>MyProject</code> and <code>MyProject.info</code>. <code>MyProject</code> would be the actual project data and <code>MyProject.info</code> 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. <code>.info</code> files are invisible on the Amiga's desktop ([[Workbench (AmigaOS)|Workbench]]). The icon on the desktop, taken from the <code>.info</code> itself, is the [[interface metaphor]] through which the user interacts both with the project itself and its associated <code>.info</code> file. A dialog box accessible by right-clicking the icon allows the user to see and modify the metadata present in the <code>.info</code> file. <code>.info</code> files can be seen as individual files in the [[command-line interface]] or a [[File manager]]. Modern AmigaOS clones ([[AROS Research Operating System|AROS]], [[MorphOS]] and [[AmigaOS 4|AOS4]]) inherit the structure (complete with metadata) of the <code>.info</code> files of older AmigaOS versions, and can also accept standard [[Portable Network Graphics|PNG]] graphic files as icon bitmaps in their <code>.info</code> files.

[[NeXT]] operating systems [[NeXTSTEP]] and [[OPENSTEP]], their successor, [[macOS]], 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 (macOS)|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{{snd}} 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 [[classic Mac OS]], since the file system ([[Macintosh 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 Manager [[application programming interface|API]] as part of its [[Carbon (API)|Carbon]] libraries for backward compatibility. However, the resources themselves can now be stored in separate data files within the file system{{snd}} the Resource Manager now hides this implementation change from the client code.