AppleScript Recordable Actions in Mac OS 9

In classic Mac OS, culminating in Mac OS 9, AppleScript featured a powerful recording capability that allowed users to generate automation scripts simply by interacting with graphical interfaces. Rather than requiring users to write code manually, the system intercepted user-driven actions within supported applications and translated them into human-readable AppleScript syntax in real time. This process relied on the Open Scripting Architecture (OSA), a rigorous software design pattern known as application factoring, and the interprocess communication framework of Apple Events.

The Role of Apple Events

At the core of Mac OS 9 automation was the Apple Event Manager. Apple Events were high-level, semantic messages passed between applications or within an application itself. While standard "scriptable" applications could only receive and execute Apple Events sent from an external controller (such as the Script Editor), "recordable" applications had to support a bidirectional flow of these events.

Application Factoring

To make an application recordable, developers had to adhere to an architecture called "factoring." In an unfactored application, a user action (such as clicking a menu item or dragging a shape) directly modified the application’s internal data structures.

In a factored, recordable application, the user interface was strictly decoupled from the core application logic:

  1. When a user performed an action via the mouse or keyboard, the interface code did not directly modify the document.
  2. Instead, the UI layer constructed an Apple Event representing the action (for example, set bounds of window 1 to... or make new document).
  3. The application sent this Apple Event to itself through the Apple Event Manager.
  4. The application’s event-handling routines received the event and finally carried out the requested change on the internal data.

The Recording Process

When a user opened the Script Editor in Mac OS 9 and clicked the "Record" button, the system entered a global recording state. The recording mechanism functioned through the following steps:

  1. System Notification: The AppleScript component registered with the Apple Event Manager to receive notifications whenever recordable events were dispatched.
  2. Event Interception: When a factored application sent an Apple Event to itself in response to a user action, the Apple Event Manager sent a copy of this event to the active recording process.
  3. Decompilation and the 'aete' Resource: Upon receiving the raw event codes (typically four-character codes such as core or getd), AppleScript referenced the target application's 'aete' (Apple Event Terminology Extension) resource. The 'aete' resource acted as a dictionary, mapping internal four-character tokens to English-like terms.
  4. Code Generation: AppleScript converted the tokenized event into readable source code lines according to AppleScript language syntax.
  5. Real-Time Display: The resulting script statement was sent to the Script Editor, where it appeared immediately in the open script window. When the user clicked "Stop," the Apple Event Manager stopped routing event copies to AppleScript, leaving behind an editable, executable automation script.

Challenges and Limitations

Although recording was visually impressive, widespread adoption was hindered by technical hurdles. Factoring an entire application required significant architectural overhead and careful performance optimization. If an operation produced excessive intermediate events (such as tracking cursor coordinates during a drag operation), the resulting recorded script could become bloated and inefficient. Consequently, while flagship software like the Mac OS 9 Finder, FileMaker Pro, and parts of the AppleWorks suite supported varying degrees of recording, many third-party developers implemented basic scriptability without full recordability.