How Windows 95 Handled Plug and Play Events

Windows 95 transformed personal computing by introducing Plug and Play (PnP), a coordinated architecture designed to automate the detection, resource allocation, and configuration of hardware devices. At the heart of this framework was the Configuration Manager (CONFIGMG.VXD), a central operating system component that orchestrated hardware events in real time. By communicating between bus enumerators, resource arbitrators, device drivers, and the system registry, the Configuration Manager eliminated the need for manual jumper settings and system reboots when adding or removing hardware.

The Plug and Play Architecture

The Windows 95 Plug and Play subsystem relied on several interacting components:

  • The Configuration Manager (CONFIGMG.VXD): The central engine that received hardware event notifications, built the system hardware topology, and coordinated resource assignments.
  • Bus Enumerators: Specialized drivers responsible for discovering devices on specific buses (such as PCI, ISA, PCMCIA, and SCSI) and identifying their resource requirements.
  • Resource Arbitrators: Modules that managed pools of system resources, including Interrupt Requests (IRQs), Direct Memory Access (DMA) channels, I/O port addresses, and memory ranges.
  • Device Loaders and Drivers: Virtual Device Drivers (VxDs) that directly controlled the configured hardware once resources were assigned.
  • The Hardware Tree: A dynamic, in-memory hierarchical database representing every active device node (devnode) currently recognized by the system.

Processing an Insertion Event

When a user plugged in a device—such as a PCMCIA network card—or booted the machine with new hardware installed, the system followed a structured sequence to process the event:

  1. Hardware Event Detection: The bus controller detected a physical state change (via a hardware interrupt or bus polling) and signaled the corresponding bus enumerator.
  2. Device Identification: The bus enumerator queried the new device to extract its unique Plug and Play identifier and its resource requirements (acceptable IRQ, DMA, I/O, and memory ranges).
  3. Notification to Configuration Manager: The bus enumerator created a new device node (devnode) and alerted the Configuration Manager that a hardware arrival event had occurred.
  4. Resource Arbitration: The Configuration Manager queried the system registry to identify known configurations and passed the device's resource requirements to the Resource Arbitrators. If primary resources conflicted with an existing device, the Configuration Manager attempted to rebalance resources dynamically by shifting relocatable devices to alternate settings.
  5. Driver Loading and Initialization: Once conflict-free resources were locked, the Configuration Manager invoked the appropriate Device Loader to load the hardware’s VxD into memory.
  6. Device Start: The Configuration Manager sent a CONFIG_START message to the device driver containing the finalized resource allocations. The driver programmed the hardware registers accordingly, bringing the device online.

Processing a Removal Event

Handling hardware removals followed a reverse sequence to preserve system stability:

  1. Removal Notification: When a device was ejected, the bus enumerator notified the Configuration Manager of a hardware removal event. In cases of "orderly" removal (such as software-initiated ejection), the Configuration Manager first sent a CONFIG_TEST_STOP query to ensure no active processes were reading or writing to the device.
  2. Stopping the Driver: The Configuration Manager dispatched a CONFIG_STOP message to the device driver, instructing it to halt operations and flush any pending I/O buffers.
  3. Resource Reallocation: The Configuration Manager signaled the Resource Arbitrators to release the assigned IRQ, DMA, and memory resources back into the global availability pool.
  4. Driver Unloading and Tree Pruning: The device driver was unloaded from memory if no other devices required it, and the Configuration Manager removed the corresponding devnode from the active Hardware Tree.