Windows 95 Plug and Play Device Registration

Windows 95 revolutionized PC hardware management by introducing Plug and Play (PnP) architecture, eliminating the need to manually configure jumpers, IRQs, and I/O addresses. At the core of this architecture was the dynamic integration between the PnP subsystem and the Windows Registry. This article explains how Windows 95 used the Configuration Manager, bus enumerators, and specialized dynamic registry keys to detect hardware, arbitrate system resources, and load the correct device drivers in real time without requiring system reboots.

The Role of the Configuration Manager and Bus Enumerators

Dynamic device registration began with the Configuration Manager, the central component of the Windows 95 PnP subsystem. Working alongside specific bus enumerators (drivers responsible for surveying buses such as PCI, ISA, SCSI, and PCMCIA), the system actively listened for hardware state changes.

When a peripheral was inserted or detected at boot, the relevant bus enumerator queried the device for its hardware identification string. This string uniquely identified the device's manufacturer, model, and class. The enumerator then generated a device node (devnode) and passed this information directly to the Configuration Manager.

The Registry Architecture: Static vs. Dynamic Storage

To handle device data efficiently, Windows 95 separated hardware information into static configuration data and dynamic run-time status across two primary registry branches:

  • HKEY_LOCAL_MACHINE\Enum (Static Database): This branch functioned as the central database of all hardware known to the system. Once a bus enumerator identified a device, the Configuration Manager searched HKLM\Enum for a matching device ID. If the hardware was recognized, the system read the static configuration parameters, required drivers, and acceptable resource ranges. If the device was new, Windows initiated the hardware installation process to add a new subkey under Enum.
  • HKEY_DYN_DATA (Dynamic Database): Unlike other registry branches stored permanently on the hard drive, HKEY_DYN_DATA was kept entirely in RAM. The subkey HKEY_DYN_DATA\Config Manager tracked the active status of every devnode in real time. It mirrored the live device tree, containing information such as allocation status, error codes, and dynamic handles for currently active hardware.

Resource Arbitration and Driver Loading

After retrieving the device's resource requirements from HKLM\Enum, the Configuration Manager checked for available system resources—such as Interrupt Requests (IRQs), Direct Memory Access (DMA) channels, Input/Output (I/O) port ranges, and base memory addresses.

The Configuration Manager called specific system Arbitrators to negotiate conflicts:

  1. Conflict Checking: The Arbitrators cross-referenced the device's requirements against active allocations recorded in the dynamic database.
  2. Reallocation: If an acceptable configuration was not immediately available, PnP-compliant devices already running could be asked to relocate their resources to make room for the newly attached hardware.
  3. Assignment: Once resources were determined, the Configuration Manager wrote the chosen configurations to the device's dynamic entry in HKEY_DYN_DATA.

With resources locked, the system loaded the corresponding Virtual Device Driver (VxD) identified in the device's static registry entry. The driver initialized the physical hardware using the allocated parameters.

System Notification

The final phase of dynamic registration was system-wide notification. The Configuration Manager broadcast a WM_DEVICECHANGE message across the operating system. This notified running applications and system services that a new device was registered, active, and accessible, finalizing the dynamic registration cycle. When a device was unplugged, the process executed in reverse: the driver was unloaded, allocated resources were freed, the corresponding devnode under HKEY_DYN_DATA was removed, and another WM_DEVICECHANGE message alerted the system.