How Windows 98 Managed Drivers in the Registry

Microsoft Windows 98 managed device drivers through a hierarchical, centralized database within the Registry, primarily coordinating hardware detection, driver assignment, and system resources via the HKEY_LOCAL_MACHINE hive. By combining the Windows Driver Model (WDM) with legacy Virtual Device Driver (VxD) architecture and an active Plug and Play (PnP) subsystem, Windows 98 used specialized registry branches—predominantly Enum and System\CurrentControlSet—to identify physical hardware, associate it with corresponding driver files, and dynamically load the necessary software layers upon boot or connection.

The Enumeration Branch: HKLM\Enum

The foundation of hardware management in Windows 98 resided in HKEY_LOCAL_MACHINE\Enum. This branch acted as the master hardware tree, populated by "bus enumerators" during startup or whenever new devices were detected.

The branch was organized hierarchically by bus type:

  • PCI: Captured devices attached to the PCI bus.
  • ISAPNP: Handled legacy ISA Plug and Play devices.
  • USB: Logged Universal Serial Bus peripherals.
  • Root: Contained non-PnP legacy devices and internal system components.
  • BIOS: Maintained PnP BIOS motherboard devices.

Under each bus, the operating system created subkeys for the device identifier (e.g., vendor and device ID) followed by a unique instance identifier. Each instance subkey contained critical parameters, including DeviceDesc (a human-readable name), HardwareID, and a pointer called Driver. The Driver value linked the hardware instance directly to its driver configuration located in the Class tree.

The Class Branch: Driver Association and Configuration

While the Enum key recorded physical hardware detected by the system, driver configuration files and installation details were stored in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class.

Windows 98 organized this key by device categories defined by Microsoft, such as:

  • Display for graphics cards
  • Net for network interfaces
  • MEDIA for sound cards and capture devices
  • Modem for communications hardware

Inside each class key, devices were sequentially assigned four-digit numeric subkeys starting at 0000, followed by 0001, 0002, and so forth. The Driver string in HKLM\Enum referenced this exact location (for example, Class\Net\0000). Within these numbered subkeys, the registry stored the path to the installed .sys, .vxd, or .inf files, provider information, driver version details, and hardware-specific runtime settings.

Dual Architecture Support: VxD and WDM

Windows 98 represented a transition period between legacy Windows 95 32-bit systems and the modern Windows NT architecture. Consequently, the Registry managed two distinct driver paradigms:

  1. Virtual Device Drivers (VxDs): Static VxDs were registered under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD or referenced through StaticVxD values. These low-level drivers had direct access to hardware and kernel memory, requiring registry values to map interrupts (IRQs) and I/O addresses manually if non-PnP.
  2. Windows Driver Model (WDM): Windows 98 introduced WDM to allow source-level compatibility with Windows NT/2000. WDM drivers were loaded via standard Class entries, utilizing a PnP helper system. The registry tracked these cross-platform drivers by specifying NTMPDriver (NT-style MiniPort Driver) values in the device's class entry, instructing the Windows 98 Virtual Machine Manager to route calls through the NTKERN.VXD abstraction layer.

Resource Allocation and Hardware Profiles

The Registry also mediated resource conflicts and multiple hardware states.

The HKEY_LOCAL_MACHINE\Config key contained hardware profiles, which were aliased dynamically at runtime to HKEY_CURRENT_CONFIG. If a user docked or undocked a laptop, Windows 98 consulted this section to check which drivers should be disabled or enabled for that specific profile without deleting the master device tree in the Enum branch.

Resource arbitration data—including Direct Memory Access (DMA) channels, Input/Output (I/O) ranges, and Interrupt Requests (IRQs)—was dynamically cached under HKEY_DYN_DATA. Although technically held in RAM, HKEY_DYN_DATA presented a registry interface that allowed the Configuration Manager to track device status codes, conflict states, and active memory mappings in real time.