Windows 3.11 Serial Mouse COM Port Detection

Microsoft Windows 3.11 operated in a pre-Plug and Play computing era, requiring low-level hardware polling and static configuration files to identify and communicate with pointing devices. To detect a serial mouse on an RS-232 communication (COM) port, the operating system and its underlying drivers relied on toggling hardware control lines on the serial interface to trigger a specific identification byte from the mouse microcontroller, coordinating this physical handshake through configuration entries in SYSTEM.INI.

The Hardware Handshake Routine

Serial mice did not possess independent power supplies; they drew power directly from the serial port lines controlled by the Universal Asynchronous Receiver-Transmitter (UART) chip. Detection relied on a standardized electronic handshake:

  1. Pin Toggling: The driver manipulated the Data Terminal Ready (DTR) and Request to Send (RTS) lines. By dropping both lines low (cutting power/signal) and then pulling them high again, the computer forced a cold reset of the microcontroller inside the connected mouse.
  2. The Identification Byte: Upon receiving this reset pulse, a standard Microsoft-compatible serial mouse was engineered to immediately transmit an identification packet across the Transmit Data (TxD) line at 1200 baud, using 7 data bits, no parity, and 1 stop bit (1200 7N1).
  3. Signature Recognition: A genuine Microsoft Serial Mouse transmitted the uppercase ASCII character 'M' (hexadecimal 0x4D). If the UART received an 'M' within a brief timeout window (typically around 100 to 200 milliseconds), the driver confirmed the presence of a Microsoft-compatible pointing device. Variations existed for other vendors; for instance, some Logitech mice responded with additional characters or specific byte sequences to signal a third button.

Driver Architecture and SYSTEM.INI

Windows 3.11 did not handle serial mouse polling dynamically at runtime. Instead, mouse management was split between setup-time detection and static system initialization:

  • Windows Setup Detection: During the installation of Windows 3.11 (or via the SETUP.EXE utility in DOS), the installer probed the standard UART base addresses (COM1 at 0x3F8, COM2 at 0x2F8, COM3 at 0x3E8, and COM4 at 0x2E8). It executed the DTR/RTS pulse on each port sequentially to locate an answering device.
  • SYSTEM.INI Configuration: Once verified, Windows recorded the driver mappings inside SYSTEM.INI. The [boot] section defined the user-mode driver (typically mouse.drv=mouse.drv), while the [386Enh] section loaded the Virtual Mouse Driver (mouse=*vmd) responsible for arbitrating COM port access between Windows applications and DOS virtual machines.

DOS Handoff and IRQ Sharing Limits

In many installations, Windows 3.11 bypassed raw serial probing entirely by inheriting the state of the real-mode DOS driver (MOUSE.COM or MOUSE.SYS) loaded in AUTOEXEC.BAT or CONFIG.SYS. If the DOS driver had already initialized the port, the Windows virtual mouse driver hooked into the existing mouse interrupt vector (Interrupt 33h).

Because standard PC architecture shared interrupts between ports (COM1 and COM3 shared IRQ 4; COM2 and COM4 shared IRQ 3), active serial detection had to be strictly managed. If a modem resided on COM3 and a mouse was probed on COM1, conflicting IRQ lines could hang the machine. Consequently, Windows 3.11 relied heavily on the user manually designating the correct COM port if the hardware configuration deviated from standard defaults.