Windows 95 Serial Communications and VCOMM Driver

Windows 95 introduced the Virtual Communications (VCOMM) driver architecture to replace the fragile, monolithic serial drivers of 16-bit Windows. By operating as a 32-bit protected-mode manager, VCOMM decoupled high-level communication APIs from direct hardware access, providing a unified, preemptive, and interrupt-driven subsystem for handling serial devices, modems, and parallel ports across both 16-bit and 32-bit applications.

Prior to Windows 95, Windows 3.x relied on COMM.DRV, a monolithic driver that tied API calls directly to standard PC serial hardware. This approach frequently failed under heavy multitasking, caused buffer overruns at speeds higher than 9600 baud, and made it difficult for hardware vendors to support non-standard serial cards or multiport adapters without breaking system compatibility.

VCOMM solved these issues by implementing a modular, layered architecture based on Virtual Device Drivers (VxDs). In this design, VCOMM.VXD acted as the central communication manager, sitting between user-mode applications and the underlying hardware. When a Win32 application initiated communication using standard Win32 API functions—such as CreateFile, ReadFile, WriteFile, and DeviceIoControl—the operating system directed these requests to VCOMM in kernel space.

VCOMM itself did not communicate directly with the serial chipsets. Instead, it delegated hardware control to specialized, modular port drivers. For standard RS-232 COM ports using 8250, 16450, or 16550 UARTs, VCOMM loaded SERIAL.VXD. If a user installed an internal modem or a third-party multiport expansion card, the hardware manufacturer provided a custom port driver that registered its own interface with VCOMM. This separation allowed multiple types of hardware interfaces to expose identical communication behaviors to the operating system.

When a port driver loaded, it registered a dispatch table of callback functions with VCOMM. This table included low-level primitives for opening the port, configuring line parameters (baud rate, parity, data bits, stop bits), asserting control lines (RTS, DTR), monitoring status lines (CTS, DSR, CD, RI), and managing internal transmit and receive buffers. VCOMM exposed these hardware capabilities upward via internal client services, enabling drivers like the Telephony API (TAPI) and Unimodem to control communication devices without knowing the underlying port architecture.

Hardware contention and virtualization were also handled through VCOMM. Because Windows 95 ran a mix of 32-bit Win32, 16-bit Win16, and MS-DOS applications, VCOMM managed port arbitration. If a legacy DOS application attempted to read directly from a UART's I/O ports or hook COM interrupts, VCOMM and the virtual serial driver intercepted the access, virtualized the hardware registers, and prevented conflicts with active Windows sessions.

Finally, VCOMM provided built-in support for asynchronous, non-blocking I/O. By fully utilizing the hardware FIFOs of 16550 UARTs and implementing interrupt-driven software ring buffers, VCOMM allowed the operating system to service serial data in the background. Applications could use Win32 overlapped I/O and event-driven notifications (WaitCommEvent) to sleep until data arrived, eliminating the polling loops that previously degraded system performance.