How Windows 95 Setup Detected Hardware Devices

During installation, Windows 95 faced the complex challenge of identifying both modern Plug and Play hardware and legacy ISA peripherals without standardized identifiers. This article explains the multi-tiered hardware detection process used during the Windows 95 setup phase, detailing how the installer performed safe software queries, executed low-level port probing, and utilized a specialized crash-recovery mechanism to prevent system-halting lockups.

The Two-Phase Detection Architecture

Windows 95 divided device detection into two primary phases: Safe Detection and Interactive (or Active) Probing. Because the operating system bridged the gap between legacy DOS-era architecture and modern hardware standards, it could not rely on a single discovery mechanism.

Safe Detection ran first to minimize the risk of system crashes. During this phase, Setup queried standard system interfaces that were guaranteed not to hang the machine. It inspected:

  • System BIOS and Plug and Play BIOS: To gather core motherboard capabilities, memory maps, and registered PnP device nodes.
  • Bus Architectures: Querying PCI, MCA, and EISA configuration spaces, which inherently supported device identification codes.
  • Existing Configuration Files: Setup scanned CONFIG.SYS, AUTOEXEC.BAT, and Windows 3.x .INI files for loaded real-mode drivers. If a driver for an obscure CD-ROM drive or sound card was already present in DOS, Setup used those signatures to identify the hardware safely.

Active Probing for Legacy (ISA) Hardware

Once safe detection finished, Windows 95 had to identify legacy Industry Standard Architecture (ISA) devices, such as network adapters, sound cards, and internal modems. Unlike PCI or PnP devices, legacy ISA cards possessed no built-in vendor identification registers and could not announce their presence.

To detect these devices, the Setup program loaded detection modules that sent explicit read and write commands to well-known I/O port addresses, Interrupt Request (IRQ) lines, and Direct Memory Access (DMA) channels. If a device responded with the expected bit pattern at a particular port, Setup registered that device as present.

Active probing was divided into distinct device classes (such as Network Cards, Sound Cards, and SCSI controllers) to avoid unnecessary tests. Setup only probed for hardware classes that the user had explicitly selected or that were deemed essential for base system operation.

The Risk of Probing and the Recovery System

Active port probing was inherently dangerous. Because ISA devices shared the same unmanaged I/O space, writing test data to an address meant for a sound card might unintentionally trigger an unrecoverable freeze on an adjacent network adapter or drive controller.

To ensure the installation could survive a system hang, Windows 95 utilized a crash-recovery mechanism powered by two log files: SETUPLOG.TXT and DETLOG.TXT.

  1. Before Probing: Setup wrote a record to DETLOG.TXT immediately before sending data to an I/O port or memory address.
  2. After Probing: If the device responded successfully without hanging, Setup marked the test as complete in the log.
  3. Recovery on Crash: If a probe caused the computer to lock up, the user was forced to power-cycle the machine. Upon rebooting, the installer read DETLOG.TXT, identified the exact probe that triggered the freeze, skipped that specific hardware test, and continued probing the remaining devices.

Resource Allocation and Registry Enrollment

Once detection concluded, the Windows 95 Configuration Manager gathered the identified resources (IRQs, DMAs, I/O ranges, and memory windows) and evaluated them for conflicts. If legacy devices occupied non-negotiable resources, the Configuration Manager dynamically configured any flexible Plug and Play devices around them. Finally, the installer registered the verified hardware configurations directly into the Windows Registry, binding the appropriate 32-bit virtual device drivers (VxDs) for the subsequent first boot.