Windows 95 Modem Initialization via AT Commands

During the dial-up era, Windows 95 transformed how personal computers interacted with modems by shifting hardware control away from fragmented DOS applications into a centralized operating system framework. Through its Universal Modem Driver (Unimodem) and Telephony Application Programming Interface (TAPI), Windows 95 automated the configuration, initialization, and execution of standard and proprietary Hayes "AT" (Attention) command strings. By mapping hardware specifications stored in driver information files to dynamic user settings, the operating system ensured reliable handshakes, standardized data compression, and unified hardware control across thousands of distinct modem models.

The Role of Unimodem and TAPI

Prior to Windows 95, DOS communication programs required individual configuration for specific modem chipsets. Windows 95 resolved this by introducing Unimodem, a layered driver architecture residing between communication applications and the serial port driver (SERIAL.VXD).

Applications made standardized function calls via TAPI (such as dialing a number or hanging up), and Unimodem translated these high-level requests into the low-level AT command strings required by the attached hardware. This abstraction layer allowed developers to write communication software without needing to know whether the user had a generic 14.4k modem, an external USRobotics Courier, or a high-end Rockwell-based device.

Driver Configuration via INF Files

The translation mechanism relied heavily on Windows 95 Modem Information Files (.INF), located in the C:\WINDOWS\INF directory. When a user installed a modem, Windows matched the device's plug-and-play ID or diagnostic response to a specific INF file entry.

These INF files contained predefined registry sections that specified the exact command strings the hardware expected:

  • Init Sections: Defined the base configuration strings, commonly specifying commands such as ATZ (software reset) or AT&F (load factory defaults).
  • Settings Sections: Mapped operating states to specific hardware flags, such as enabling hardware flow control (&K3 on some modems, \Q3 on others).
  • Response Sections: Translated modem responses (like CONNECT 28800, BUSY, or NO CARRIER) into system messages that Windows could act upon.

The Dynamic Initialization Sequence

When a program initiated a connection, Windows 95 did not simply send a single static string. Instead, Unimodem assembled a dynamic initialization sequence based on both the INF parameters and the user's active configuration in the Control Panel.

The initialization procedure typically followed this structured flow:

  1. Hardware Reset: Unimodem sent a reset sequence, such as ATZ or AT&F0, to clear existing registers and restore known factory defaults.
  2. Echo and Verbose Settings: The system sent ATE0V1 to disable local command echoing (preventing the PC from interpreting its own instructions as responses) and enable verbose (text-based) result codes rather than numeric codes.
  3. Feature Configuration: Windows evaluated user settings in the Modem Properties panel and appended the necessary commands. This included speaker volume (L0 to L3), speaker control (M0 for off, M1 for on until carrier detect), error correction protocols (V.42/MNP), and data compression options (V.42bis).
  4. Flow Control Setup: Because interface speeds between the PC and modem (DTE speed) were often higher than the physical telephone line speed (DCE speed), Windows explicitly configured RTS/CTS hardware flow control to prevent buffer overflows.

Custom Initialization and Extra Settings

Because firmware implementations of the Hayes command set varied significantly between manufacturers, edge cases were common. Windows 95 accommodated this via the "Advanced Connection Settings" dialog in the Control Panel.

This interface featured an "Extra settings" text field where users could manually enter supplementary AT commands. Windows appended these user-defined strings to the end of the standard initialization sequence immediately before issuing the dial command (ATDT for tone dialing or ATDP for pulse dialing). This allowed power users to force specific connection protocols, alter register delays (such as S7 wait time), or override problematic factory defaults without modifying the underlying driver INF files.