Windows 3.11 Serial Baud Rate Configuration

This article examines how Microsoft Windows 3.11 configured and managed serial communication baud rates through graphical utilities, system configuration files, internal communications drivers, and the Win16 API. It also addresses the underlying hardware interaction with Universal Asynchronous Receiver-Transmitter (UART) chips and the common workarounds required to sustain high-speed data transmission in a 16-bit multitasking environment.

The Graphical Interface: Ports Applet

In Windows 3.11, the primary user interface for configuring serial ports was the Ports applet located within the Control Panel.

When a user selected a communications port (COM1 through COM4) and clicked Settings, a dialog presented standard serial framing and transmission parameters:

  • Baud Rate: Predefined selections commonly included 110, 300, 600, 1200, 2400, 4800, 9600, and 19200 bits per second (bps).
  • Data Bits: 4, 5, 6, 7, or 8.
  • Parity: Even, Odd, None, Mark, or Space.
  • Stop Bits: 1, 1.5, or 2.
  • Flow Control: Xon/Xoff, Hardware (RTS/CTS), or None.

An Advanced sub-dialog allowed users to map the base I/O port address and the Interrupt Request line (IRQ), which was critical when resolving resource conflicts between COM1/COM3 (typically sharing IRQ 4) and COM2/COM4 (typically sharing IRQ 3).

Configuration Storage: WIN.INI and SYSTEM.INI

The settings chosen in the Control Panel were written directly to Windows initialization files:

  1. WIN.INI: The [ports] section stored default initialization strings used by standard applications and printing subsystems. A typical entry appeared as: 
    [ports]
COM1:=9600,n,8,1,x
COM2:=19200,e,7,1,p
  2. SYSTEM.INI: Low-level port assignments, buffer allocations, and 386 Enhanced Mode hardware virtualization parameters were stored under the [386Enh] section. Key parameters included:
    • COM1Base = 03F8h
    • COM1Irq = 4
    • COM1Buffer = 128 (size of the software receive buffer in characters)
    • COMIrqSharing = TRUE (allowed sharing of IRQ lines if supported by hardware)

Architecture: COMM.DRV and VCD

Windows 3.11 managed serial hardware through a layered driver architecture:

  • COMM.DRV: The standard 16-bit user-mode communications driver provided the software interface between Windows applications and the hardware.
  • VCD (Virtual Communications Driver): When running in 386 Enhanced Mode, *vcd intercepted hardware port accesses, virtualized interrupt requests, and prevented conflicts between multiple virtual DOS machines (VDMs) and Windows applications attempting to access the same physical serial port.

When an application requested a specific baud rate, it bypassed DOS interrupt 14h calls and used the Windows Communications API. Software initialized a DCB (Device Control Block) structure via BuildCommDCB and applied the baud rate, flow control, and byte framing using SetCommState. The COMM.DRV driver calculated the appropriate clock divisor and programmed the serial chip directly.

Hardware Limitations and High-Speed Baud Rates

The primary limitation of Windows 3.11 serial handling was its native support for contemporary UART hardware:

  • 8250 and 16450 UARTs: These older chips contained only a 1-byte buffer. At speeds exceeding 9600 or 19200 baud, the interrupt latency of Windows 3.11's cooperative multitasking environment often caused buffer overruns (dropped characters).
  • 16550A UART: This chip introduced a 16-byte FIFO (First-In, First-Out) hardware buffer. However, the default COMM.DRV shipped with Windows 3.1 and early Windows 3.11 releases had defective or disabled 16550 FIFO support, preventing the OS from taking full advantage of the hardware queue.
  • Third-Party Drivers: To operate 14.4k, 28.8k, or 56k modems at baud rates of 38400, 57600, or 115200 bps without data loss, users routinely replaced COMM.DRV in SYSTEM.INI with specialized third-party drivers such as TurboCom/Rx or CyberCom. These replacement drivers enabled the 16550 FIFO triggers and allowed the system to reliably sustain higher divisor rates.