Windows 95 Legacy Serial Mouse Auto-Detection

When Windows 95 launched, it promised seamless Plug and Play hardware configuration, yet it still had to support millions of legacy RS-232 serial devices that predated plug-and-play standards. To detect whether a mouse was plugged into a standard COM port at boot, Windows 95 implemented an active hardware probing routine managed by its serial port enumerator. By toggling specific pin voltages and monitoring the port for signature response bytes, the operating system was able to reliably identify legacy pointing devices without requiring manual user configuration.

The primary challenge Windows 95 faced was that standard RS-232 serial ports provided no built-in mechanism for connected peripherals to announce their presence. To overcome this limitation, Windows 95 relied on a low-level driver called the Serial Enumerator (SERENUM.VXD). During the operating system's boot phase, this enumerator systematically queried the system's serial ports (typically COM1 through COM4).

The detection process relied on standard hardware behaviors established by Microsoft and Logitech serial mice. When probing a COM port, the serial enumerator lowered and then raised the voltage on the Data Terminal Ready (DTR) and Request to Send (RTS) control lines. In serial mouse design, these lines were not just control signals; they also provided the direct electrical power required to operate the mouse's internal microcontroller. Toggling these lines effectively power-cycled the mouse, triggering its internal firmware reset routine.

Upon completing its reset sequence, a standard Microsoft-compatible serial mouse was hardwired to transmit an identification byte over the Receive Data (RX) line at 1200 baud. For a standard two-button Microsoft mouse, this response was the ASCII character 'M' (hexadecimal 0x4D). If the serial enumerator detected this character within a brief timing window, it registered a mouse on that COM port and loaded the appropriate mouse driver.

Variations in the received byte sequence allowed Windows 95 to differentiate between hardware types:

• A bare 'M' indicated a standard Microsoft two-button serial mouse.
• A sequence including 'B' or distinct subsequent bytes identified three-button mice, such as those made by Logitech or the Microsoft BallPoint trackball.
• Extended multi-byte handshakes were used later to detect devices like the Microsoft IntelliMouse with a scroll wheel.

If no response was received within the allocated timeout, the system concluded that no mouse was present on that COM port. The enumerator would then either test the port for modems using standard Hayes AT commands or leave the port unassigned for general-purpose applications.

This active polling method had one infamous side effect known as the "crazy mouse" problem. Because Windows 95 interpreted any incoming serial data matching specific timing parameters during boot as a mouse handshake, other hardware transmitting continuous data—such as GPS receivers, uninterruptible power supplies (UPS), or data loggers—would be falsely detected as a pointing device. This caused the operating system to interpret incoming data streams as mouse coordinates, sending the on-screen cursor darting wildly across the screen and registering erratic clicks. Despite this occasional drawback, serial probing was a vital bridge technology that made legacy hardware functional within Windows 95's automated setup architecture.