DLL Association Paths in Windows 3.11

In Microsoft Windows 3.11, the primary file responsible for storing dynamic link library (DLL) associations and hardware driver mappings was SYSTEM.INI. While modern Windows operating systems rely on a centralized Registry to manage DLL paths and application dependencies, Windows 3.11 utilized plain-text initialization files alongside a nascent registration database (REG.DAT) to manage how libraries and system drivers were loaded into memory.

The Role of SYSTEM.INI

The SYSTEM.INI file, located in the main Windows installation directory (typically C:\WINDOWS), served as the core hardware and low-level dynamic library configuration file for Windows 3.11. Within this file, specific sections dictated which DLLs loaded at startup and how they mapped to operating system functions:

  • [boot] Section: Specified the core dynamic-link libraries and drivers required to initialize the graphical user interface. This included entries such as display.drv, sound.drv, comm.drv, and system.drv, all of which were modular DLL-based drivers.
  • [drivers] Section: Maintained aliases and file associations for installable drivers and multimedia dynamic link libraries, allowing applications to access specialized functions via standard DLL calls.
  • [386Enh] Section: Controlled dynamic libraries and virtual device drivers (.386 files, closely related in role to DLLs) when running the operating system in 386 Enhanced Mode.

Supplementary DLL and Association Handlers

While SYSTEM.INI handled the operating system's system-level dynamic library bindings, two other files worked in tandem for higher-level associations:

  • WIN.INI: Focused on the desktop environment, software settings, and file associations. It determined which executable or dynamic link library should launch when handling certain extensions or running embedded macros.
  • REG.DAT: Introduced with Windows 3.1 to support Object Linking and Embedding (OLE). It stored rudimentary class and library path associations, allowing applications to discover the dynamic link libraries required for embedding objects from other software.

Dynamic Library Search Resolution

When an application required a DLL that was not explicitly associated via a full path in SYSTEM.INI or REG.DAT, Windows 3.11 relied on a fixed search hierarchy:

  1. The current working directory from which the application was executed.
  2. The primary Windows directory (e.g., C:\WINDOWS).
  3. The Windows system directory (e.g., C:\WINDOWS\SYSTEM), where most shared DLLs were housed.
  4. The directory containing the executable file for the current task.
  5. The directories listed in the PATH environment variable defined in AUTOEXEC.BAT.
  6. Any directory mapped over the network (applicable specifically to Windows for Workgroups 3.11).