How Windows 98 Managed Serial COM Ports

Microsoft Windows 98 managed peripheral connections over serial ports (COM ports) through a hybrid 16-bit/32-bit communications architecture that integrated legacy RS-232 hardware with modern Plug and Play standards. By combining direct hardware control via UART controllers, a centralized driver stack led by the VCOMM virtual device driver, and user-configurable settings in the Device Manager, the operating system enabled stable data transmission for essential peripherals like external modems, serial mice, and data acquisition tools.

The Hardware Layer and UART Controllers

Serial communications in Windows 98 relied on the Universal Asynchronous Receiver-Transmitter (UART) chips embedded on motherboards or expansion cards. Standard PC architecture allocated four primary COM ports mapped to specific standard I/O base addresses and Interrupt Requests (IRQs):

  • COM1: I/O port 0x3F8, IRQ 4
  • COM2: I/O port 0x2F8, IRQ 3
  • COM3: I/O port 0x3E8, IRQ 4
  • COM4: I/O port 0x2E8, IRQ 3

Because COM1 and COM3 shared IRQ 4, and COM2 and COM4 shared IRQ 3, Windows 98 had to prevent simultaneous use of paired ports to avoid hardware interrupt conflicts, unless the underlying expansion hardware specifically supported shared interrupts.

Windows 98 fully utilized the 16550A UART chip's built-in 16-byte FIFO (First-In, First-Out) buffer. The operating system configured buffer thresholds to allow data to accumulate temporarily in hardware before generating an interrupt, significantly reducing the CPU overhead and preventing data loss (buffer overruns) at transfer speeds up to 115,200 bps.

The Driver Architecture: VCOMM and Port Drivers

Windows 98 handled serial I/O via a modular communications subsystem rather than allowing applications to access hardware ports directly:

  1. Win32 Communications API: User-mode applications accessed serial devices using standard Windows file operations (CreateFile, ReadFile, WriteFile, SetCommState) targeting port names such as COM1 or COM2.
  2. VCOMM.VXD: The core 32-bit protected-mode communications manager. VCOMM acted as an intermediary between the Win32 API and hardware-specific port drivers, managing port access requests, event notifications, and port contention between applications.
  3. SERIAL.VXD: The default port driver for standard RS-232 hardware. SERIAL.VXD interfaced directly with the UART registers, managing the physical transmission of data bits, handling interrupts, and executing flow control.
  4. UNIMODEM (Universal Modem Driver): For serial modems, Windows 98 layered UNIMODEM.VXD over VCOMM. This abstraction converted standard AT command strings into uniform API calls, allowing third-party communication software to operate without requiring modem-specific driver code.

Plug and Play and Device Enumeration

Windows 98 incorporated the external Serial Plug and Play specification to identify attached hardware automatically. During system startup or manual hardware scans, the serial port driver toggled control lines (Data Terminal Ready / Request to Send) to trigger an identification response from attached peripherals.

If a Plug and Play-compliant device (such as an external PnP modem) was connected, it returned a standardized identification string containing vendor and product codes. Windows 98 matched this string against its INF driver files, dynamically assigned resources, and configured the communications parameters.

For non-PnP legacy peripherals—such as older serial mice, barcode readers, or weather station loggers—users installed devices using the "Add New Hardware" wizard, which manually bound the peripheral to a fixed COM port.

Port Configuration and Flow Control

Users and administrators managed COM port properties through the Windows 98 Device Manager. The system supported granular configuration of port performance and signaling parameters:

  • Baud Rate: Transmission speeds typically ranged from 110 bps up to 115,200 bps.
  • Framing Parameters: Configuration of Data bits (usually 7 or 8), Parity (None, Odd, Even, Mark, Space), and Stop bits (1 or 2).
  • Flow Control: Support for both hardware flow control (RTS/CTS lines) to prevent buffer overflows during high-speed transfers, and software flow control (XON/XOFF control characters) for text-only terminal connections.
  • Advanced Buffer Controls: Sliders within the Device Manager allowed users to manually decrease the receive and transmit FIFO buffers to troubleshoot connection instability or increase them for maximum throughput.