Role of MOUSE.COM Driver Before Windows 3.11

Before launching Microsoft Windows 3.11, the primary role of the MOUSE.COM driver was to enable mouse input within the MS-DOS environment. Because MS-DOS lacked native hardware abstraction for pointing devices, MOUSE.COM served as a real-mode terminate-and-stay-resident (TSR) program that translated physical mouse movements and button clicks into standard software interrupts that DOS-based programs could understand.

Establishing the DOS Mouse Interface

MS-DOS was fundamentally a text-based operating system designed for keyboard input. When a user added a serial, bus, or PS/2 mouse to an IBM PC-compatible system, the operating system had no built-in mechanism to communicate with the hardware port or interpret the incoming data stream.

Running MOUSE.COM—typically through the AUTOEXEC.BAT startup script—loaded the driver into the conventional 640 KB memory space. The driver communicated directly with the communication port (such as COM1 or COM2) or the dedicated mouse port, captured hardware interrupts, and registered software Interrupt 33h (INT 33h). Any MS-DOS application that supported mouse interaction, such as file managers, word processors, or computer games, queried INT 33h to track cursor coordinates and detect button presses.

Transition to Windows 3.11

Windows 3.11 did not strictly require MOUSE.COM to control the cursor within the Windows graphical user interface itself. When a user executed the WIN command to start Windows, the operating system transitioned from real mode to 386 Enhanced Mode. In this state, Windows bypassed standard DOS drivers and utilized its own protected-mode virtual device drivers (such as VMD.386) and display/pointer drivers (such as MOUSE.DRV) specified in the SYSTEM.INI file.

Supporting DOS Prompts and Virtual Machines

Despite Windows 3.11 having its own mouse subsystem, loading MOUSE.COM prior to starting Windows remained essential for DOS compatibility. When users launched an MS-DOS prompt or executed legacy DOS applications inside a Windows virtual machine or full-screen session, Windows passed mouse events through to the underlying DOS interrupt structure. If MOUSE.COM had not been loaded prior to initiating the Windows session, the pointer would function within Windows desktop applications but cease to work when navigating non-Windows software.