How Windows 98 Managed Modem Setup and AT Commands

In the late 1990s, dial-up internet access was standard, and Microsoft Windows 98 handled connectivity through an automated blend of Plug and Play hardware detection, the Universal Modem Driver (Unimodem) architecture, and the Telephony Application Programming Interface (TAPI). Rather than requiring software to communicate directly with hardware ports using raw Hayes AT commands, Windows 98 standardized modem configuration through centralized INF driver files and Control Panel applets. This article explains how the operating system installed modem hardware, abstracted communication through driver layers, issued automated AT command sequences, and provided users with manual diagnostic and override controls.

Plug and Play and Port Assignment

Modem configuration in Windows 98 began at the hardware layer via the "Modems" applet in the Control Panel or the Add New Hardware Wizard. When an internal ISA or PCI modem card or an external RS-232 serial modem was connected, Windows 98 used Plug and Play (PnP) specifications to detect the device. For non-PnP legacy modems, the operating system probed serial communication ports (COM1 through COM4) and mapped them to specific I/O addresses and Interrupt Requests (IRQs).

Once detected, the setup routine matched the hardware ID against standard .INF files stored in the C:\Windows\Inf directory. These INF files contained the exact specifications of the modem, including supported baud rates, data compression protocols (such as V.42bis or V.90), and the exact Hayes-compatible AT commands required to operate the chipset.

The Unimodem Driver and TAPI Architecture

To prevent software from conflicting over serial ports, Windows 98 relied on the Universal Modem (Unimodem) driver architecture, specifically Unimodem V. This system acted as an abstraction layer between dial-up applications (such as Dial-Up Networking or HyperTerminal) and the modem hardware.

Applications communicated using Windows TAPI rather than sending raw text strings directly to COM ports. When a connection request was initiated, TAPI passed high-level commands (such as "dial" or "hang up") to the Unimodem driver. Unimodem then translated these requests into the appropriate sequence of AT commands designated in the modem's INF file, ensuring compatibility across hundreds of different modem models and chipsets (such as Rockwell, USRobotics, or Conexant).

AT Command Generation and Initialization Sequences

During operation, Windows 98 executed a structured sequence of AT commands to establish and maintain a connection:

  1. Reset and Echo Control: The driver sent reset and setup commands (commonly ATZ or AT&F for factory defaults, followed by ATE0 to disable command echoing and ATV1 for verbose responses).
  2. Configuration Strings: Settings for hardware flow control (&K3 or &F1), speaker volume (L and M commands), and compression negotiation were applied.
  3. Dialing: The driver issued the dial command, appending either T for tone dialing or P for pulse dialing along with the target phone number (e.g., ATDT555-0123).
  4. Monitoring: Windows monitored the modem's return codes, listening for responses such as CONNECT, BUSY, NO CARRIER, or NO DIALTONE.

Manual Overrides and Diagnostic Tools

While Windows 98 automated AT commands, it also provided advanced settings for edge cases, noisy telephone lines, or specialized hardware. Inside the modem’s properties dialog under the "Connection" tab, users could open the "Advanced" menu to access an "Extra settings" text field. This field allowed power users to append custom initialization strings (such as disabling 56K negotiation via specific +MS commands or forcing software flow control) directly to the end of the standard setup sequence.

For troubleshooting, Windows 98 included built-in diagnostic tools. In the "Diagnostics" tab of the Modems control panel, clicking "More Info" prompted Windows to send a series of standard identification commands (ATI1 through ATI7) directly to the device to report the firmware revision and chipset capabilities. Additionally, users could enable an appendable log file (MODEMLOG.TXT), which recorded every raw AT command sent and received during a connection attempt to diagnose failed handshakes or line drops.