Storing Application Preferences in Mac OS 9

In classic Mac OS, specifically Mac OS 9, application settings were managed through a dedicated directory located within the central System Folder. Rather than scattering configuration files across various user directories or using a unified registry, applications saved their state in the "Preferences" folder. System software provided specialized APIs to locate this directory, while the underlying file architecture utilized metadata, unique creator codes, and resource forks to structure and link preference files to their respective applications.

The Preferences Folder

The primary location for configuration data in Mac OS 9 was the System Folder:Preferences directory. When an application launched for the first time, it checked this folder for an existing configuration file. If none was found, the application generated a new preference file with default settings upon exit or when the user modified preferences. Because Mac OS 9 was primarily a single-user operating system (with limited multi-user capabilities introduced via the Multiple Users control panel), all applications shared this central location unless separate user environments were explicitly configured.

The Folder Manager API

Developers did not hardcode the file path to the Preferences folder, as the System Folder could be renamed or reside on different volumes. Instead, Mac OS 9 utilized the Folder Manager API. Programmers called the FindFolder function using the kPreferencesFolderType constant:

FindFolder(kOnSystemDisk, kPreferencesFolderType, kCreateFolder, &vRefNum, &dirID);

This call returned the volume reference number (vRefNum) and directory ID (dirID) of the Preferences folder, automatically creating the folder if it did not already exist. The application then used the File Manager API to read from or write to that specific directory ID.

File Types and Creator Codes

Mac OS 9 relied on a four-character metadata system embedded in the HFS (Hierarchical File System) catalog rather than filename extensions. Application preference files were typically assigned a specific File Type and Creator Code:

  • File Type: Most preference files were given the type 'pref', identifying the file format to the system.
  • Creator Code: The creator code matched the four-character signature of the parent application (for example, 'MSWD' for Microsoft Word or 'ttxt' for SimpleText).

This system ensured that the Finder recognized the file as a preference document associated with a specific program, displaying the appropriate document icon even without an explicit extension like .plist or .ini.

Storage Architecture: Resource Forks vs. Data Forks

Classic Mac OS files consisted of two forks: the data fork and the resource fork. Developers chose between two primary methods to store preference data:

  1. Resource Forks: Many programs stored preferences as structured resources (such as 'STR#' for strings, 'RECT' for window coordinates, or custom application-defined types). The Resource Manager allowed developers to read and update specific settings without parsing an entire text file.
  2. Data Forks: Other programs saved raw C structs or binary dumps directly into the data fork. This method allowed the application to read the entire configuration block directly into memory with a single read operation.

By combining the Folder Manager API, the HFS metadata system, and fork-based storage, Mac OS 9 maintained a standardized, self-contained method for managing application configurations directly inside the System Folder.