How Windows 95 Handled Hot-Plugging PCMCIA Modems

When a user inserted a PCMCIA (PC Card) modem into a running Windows 95 machine, the operating system utilized its new 32-bit Plug and Play (PnP) architecture to detect, configure, and initialize the device dynamically without requiring a reboot. This process relied on specialized hardware detection pins, the PCMCIA bus driver stack, the Windows Configuration Manager, and dynamic virtual device drivers (VxDs) coordinating in real time to assign system resources and establish a usable communications port.

1. Physical and Hardware-Level Detection

The insertion process began at the physical socket interface:

  • Staggered Pin Sensing: PCMCIA connectors were engineered with card-detect pins (CD1 and CD2) that were shorter than the power and ground pins. This ensured the card received stable power before the controller detected physical seating.
  • Controller Interrupt: Once fully seated, the card grounded the card-detect pins. The host controller (typically compatible with the Intel 82365SL standard) detected this state change and fired a hardware interrupt to the system.

2. PCMCIA Bus Driver Processing

The interrupt was routed to the Windows 95 32-bit protected-mode PCMCIA bus driver stack:

  • Interrupt Servicing: The controller driver signaled Card Services, managed predominantly by PCMCIA.SYS.
  • Reading the CIS (Card Information Structure): The bus driver interrogated the card’s non-volatile attribute memory to read its "tuples"—small, structured data blocks containing the Card Information Structure.
  • Device Identification: The CIS tuples revealed critical device metadata, including the manufacturer name, device type (Serial/Modem), supported operational voltages, and specific resource requirements (I/O port ranges and interrupt requests).

3. PnP Configuration and Resource Allocation

Once the card was identified, the PCMCIA subsystem passed the device information to the Windows 95 Configuration Manager (CONFIGMG):

  • Device Tree Registration: The Configuration Manager registered the device as a dynamic node in the system's hardware tree.
  • Resource Arbitration: The Configuration Manager arbitrated system resources. Because PCMCIA modems behaved like standard 16550/8250 UART serial devices mapped over an ISA-like bus, the system had to allocate an unused IRQ and an available I/O base address (typically mapping to standard configurations like COM3 or COM4).
  • Socket Powering: Once resources were safely reserved, Card Services configured the controller's socket registers to route the allocated IRQ, apply operating voltage, and map the I/O window to the system bus.

4. Driver Initialization and COM Port Creation

With the hardware configured, Windows 95 loaded the necessary software stack into memory:

  • Serial Driver Assignment: The operating system dynamically bound the protected-mode serial communications driver (SERIAL.VXD) to the allocated I/O and IRQ range, creating a dynamic COM port.
  • Modem Subsystem Notification: The Universal Modem Driver (UNIMODEM.VXD) and Telephony API (TAPI) were notified that a new communications device was present. If the modem had been configured previously, Windows matched it against the registry; if newly discovered, the "New Hardware Found" wizard prompted the user for an .INF installation file.

5. User Notification

Finally, Windows 95 informed the user that the device was ready to use:

  • Auditory Cue: The system played the characteristic ascending two-tone sound associated with dynamic hardware insertion.
  • Visual Indicator: The PCMCIA status utility placed a card icon in the taskbar notification area (system tray), allowing the user to view the active socket or prepare the card for safe removal later.