These alternatives require additional work by programs using the data, but benefit from portability to file systems that do not support forks.
The resource fork was designed to store non-compiled data that would be used by the system's graphical user interface (GUI), such as localizable text strings, a file's icon to be used by the Finder or the menus and dialog boxes associated with an application.
[2] However the feature was very flexible, so additional uses were found, such as splitting a word processing document into content and presentation, then storing each part in separate resources.
Beginning with 10.4, a partial implementation was made to support Apple's extended inline attributes.
Multiple data streams also allow Macintosh clients to attach to and use NetWare servers.
[9] ADS was originally intended to add compatibility with existing operating systems that support forks.
Service Pack 2 for Windows XP introduced the Attachment Execution Service that stores details on the origin of downloaded files in an ADS called zone identifier, in an effort to protect users from downloaded files that may present a risk.
When a file system supports different forks, the applications should be aware of them, or security risks can arise.
Allowing legacy software to access data without appropriate shims in place is the primary culprit for such problems.