How Windows 3.11 Handled File Associations

In Microsoft Windows 3.11, double-clicking a document to launch its parent application relied on a dual-system architecture combining the legacy WIN.INI initialization file and the 16-bit Registration Database (REG.DAT). When a user double-clicked a file in File Manager (WINFILE.EXE), the operating system evaluated the file's three-letter extension, resolved the associated binary or Dynamic Data Exchange (DDE) command string, and spawned the application with the target file passed as an argument.

The Role of WIN.INI

The simplest and most direct method for associating a file extension was the [Extensions] section inside WIN.INI. This mechanism was carried forward from earlier versions of Windows to maintain backward compatibility with 16-bit DOS-based Windows applications.

In WIN.INI, an entry followed a basic key-value format:

[Extensions]
txt=notepad.exe ^.txt
doc=write.exe ^.doc
ini=notepad.exe ^.ini

The caret symbol (^) acted as a placeholder for the file name without the extension, followed immediately by the extension. When a user double-clicked a .txt file, the Windows shell replaced ^.txt with the fully qualified path of the clicked file, resulting in an execution call equivalent to notepad.exe C:\DOCS\SAMPLE.TXT.

The Registration Database (REG.DAT)

Windows 3.1 introduced Object Linking and Embedding (OLE 1.0), which required a more sophisticated registry known as the Registration Database, stored on disk as REG.DAT. This was edited through the 16-bit Registry Editor (REGEDIT.EXE).

Instead of a simple string replacement, REG.DAT implemented a hierarchical structure:

  1. Extension Mapping: Extensions were mapped to an internal document type identifier (a programmatic identifier, or ProgID). For example, .doc was mapped to Word.Document.6 or Write.Document.
  2. Verb Definition: The document type defined explicit "verbs" (actions), primarily open and print.
  3. Execution Commands: Under each verb, a command key specified the target executable, using %1 as the variable for the clicked file path (e.g., C:\WINDOWS\WRITE.EXE %1).

The database also enabled Dynamic Data Exchange (DDE) commands. If an application was already running, Windows could instruct the running instance to open the document rather than launching a redundant instance of the executable.

Double-Click Execution Resolution

When a user double-clicked a file within File Manager, the system executed the following lookup sequence:

  1. Shell Inspection: File Manager intercepted the double-click event and extracted the file's extension.
  2. Registry Lookup: File Manager queried the Registration Database (REG.DAT) via the Shell API (specifically RegQueryValue) to see if an open verb was defined for that extension.
  3. Fallback to WIN.INI: If the extension was not defined in REG.DAT, the system fell back to the [Extensions] section in WIN.INI.
  4. Command Execution:
    • If an entry was found, File Manager substituted the file name into the target string and invoked the internal Windows API function WinExec() or ShellExecute().
    • If DDE parameters were specified, the system opened a DDE conversation with the application server to pass the open command.
  5. Association Prompt: If no entry existed in either location, File Manager halted execution and presented an "Associate" dialog box, prompting the user to manually select an application executable to register the unknown extension.