Role of COMM.DRV in Windows 3.11 Architecture

In Microsoft Windows 3.11, COMM.DRV served as the foundational 16-bit device driver responsible for managing serial and parallel port communications across the operating environment. This article examines the architectural placement of COMM.DRV, how it translated high-level Windows communication API calls into hardware-level instructions, its interplay with virtual device drivers (VxDs) in 386 Enhanced Mode, and the performance challenges that made it a frequent target for replacement.

Architecturally, Windows 3.11 operated as a 16-bit graphical environment on top of MS-DOS, running under a cooperative multitasking model. Within this framework, COMM.DRV resided in the system layer alongside other core dynamic link libraries and drivers like USER.EXE, GDI.EXE, and KEYBOARD.DRV. It exposed the official Windows Communications API—functions such as OpenComm(), ReadComm(), WriteComm(), and CloseComm()—which allowed software developers to build terminal emulators, fax software, and modem dialers without writing direct hardware assembly routines for each vendor's serial controller.

When an application requested a read or write operation, COMM.DRV acted as the gatekeeper. It managed the low-level interrupt service routines (ISRs) for IRQ3 (COM2/COM4) and IRQ4 (COM1/COM3), as well as internal software input and output queues. Instead of allowing individual applications to directly manipulate the registers of the Universal Asynchronous Receiver-Transmitter (UART) chips—such as the National Semiconductor 8250, 16450, or 16550A—COMM.DRV standardized these controls, enforcing parity, baud rates, stop bits, and flow control (both hardware RTS/CTS and software XON/XOFF).

In 386 Enhanced Mode, the hardware abstraction became multi-layered. While COMM.DRV managed the logical interface for 16-bit Windows-based applications, the Virtual Communications Device (*VCD), a protected-mode Virtual Device Driver (VxD), handled hardware port virtualization. The *VCD intercepted I/O port trapping when multiple DOS virtual machines or the Windows system itself contended for the same physical COM port. In this configuration, COMM.DRV passed data to the underlying VxD architecture, which directly managed hardware interrupts and avoided resource collisions.

Despite its critical role, the default COMM.DRV shipped with Windows 3.11 had notable performance limitations, especially with the advent of high-speed modems (14.4 kbps and 28.8 kbps). The original Microsoft driver had minimal or unoptimized support for the 16-byte FIFO (First-In, First-Out) buffer found in 16550A UART chips. Because cooperative multitasking could introduce latency while another application held the CPU, incoming serial buffers would frequently overrun, resulting in dropped packets and transmission errors. Consequently, power users and network administrators frequently replaced the stock COMM.DRV with optimized third-party alternatives, such as TurboCom or Cybercom, to achieve stable high-speed networking and remote access in Windows for Workgroups 3.11.