How Windows 3.11 Recorder Processed Macro Keystrokes

In Microsoft Windows 3.11, the Recorder accessory (recorder.exe) captured and reproduced user actions by interfacing directly with the operating system's internal message-handling pipeline. Rather than interacting with individual application windows, Recorder utilized low-level global system hooks—specifically WH_JOURNALRECORD and WH_JOURNALPLAYBACK—to intercept raw keyboard hardware events from the system queue during recording and reinject synthesized messages back into the message stream during playback.

The Role of Windows Journal Hooks

Windows 3.11 was built upon a 16-bit cooperative multitasking architecture governed by a central system message queue. To enable system-wide automation, the Windows API provided specialized hooks accessed via the SetWindowsHook function. These journal hooks sat between the low-level hardware keyboard driver and the application message queues, giving the Recorder utility the ability to monitor and simulate hardware-level interactions globally.

Capturing Keystrokes: WH_JOURNALRECORD

When a user started recording a macro, Recorder installed a WH_JOURNALRECORD hook.

  1. Hardware Interception: Whenever a key was pressed or released, the keyboard driver generated hardware scan codes and sent them to the system message queue.
  2. Hook Notification: Before dispatching these events to the active application, Windows redirected the event to Recorder’s hook callback procedure.
  3. Data Extraction: The callback received an EVENTMSG structure containing critical input parameters:
    • The message identifier (such as WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, or WM_SYSKEYUP).
    • The virtual key code and hardware scan code.
    • A timestamp (in milliseconds) indicating when the event occurred.
  4. Storage: Recorder serialized these EVENTMSG records sequentially in memory. When saving, it compiled these entries into a .REC binary file alongside configuration settings like playback speed, shortcut triggers, and target window behavior.

Replaying Keystrokes: WH_JOURNALPLAYBACK

When a macro was triggered via a designated hotkey, Recorder took over input routing by installing a WH_JOURNALPLAYBACK hook.

  1. Feeding the Queue: When the operating system checked for user input, the presence of the playback hook instructed Windows to query Recorder rather than the physical keyboard driver.
  2. Emulating Input: Windows called the playback hook repeatedly with specific hook codes:
    • HC_GETNEXT: Recorder populated the provided EVENTMSG buffer with the next sequential keystroke event and calculated delay times relative to the previous event (if "Fast" mode was disabled).
    • HC_SKIP: Windows notified Recorder that the current message had been read, advancing the playback pointer to the next event in the macro queue.
  3. Dispatch to Focus: Windows treated the synthetic EVENTMSG as genuine user input, converting it into standard window messages and placing them directly into the message queue of the currently focused window.

System Control and Limitations

Because Windows 3.11 lacked preemptive multitasking and process isolation, the WH_JOURNALPLAYBACK hook effectively monopolized the input pipeline during execution. If a macro replayed keystrokes faster than the target application could process them, or if the active window changed unexpectedly during playback, keystrokes would be sent to the wrong control or dropped entirely. To provide an emergency exit, the operating system monitored for the Break key (Ctrl+Break), which immediately unhooked WH_JOURNALPLAYBACK and restored normal input processing.