Purpose of MS-DOS MOUSE and CTMOUSE Drivers

This article explains the function and significance of the MOUSE and CTMOUSE drivers in MS-DOS 6.22, detailing how they bridge the gap between pointing hardware and DOS applications. It explores the technical role of Interrupt 33h, the use of mice within text-based and command-line interfaces, and the practical differences between Microsoft's original mouse driver and the community-favorite CuteMouse alternative.

The Need for a DOS Mouse Driver

Unlike modern operating systems, MS-DOS does not include built-in, native background handling for pointing devices. The operating system kernel only manages essential input and output routines, such as keyboard interaction and disk access via basic BIOS interrupts.

For MS-DOS to detect and interpret input from a serial, PS/2, or bus mouse, a dedicated terminate-and-stay-resident (TSR) program or device driver must be loaded into memory via AUTOEXEC.BAT or CONFIG.SYS. Without this driver running in the background, mouse hardware remains completely non-functional in the DOS environment.

The Role of Interrupt 33h

Mouse drivers function primarily by establishing and servicing Interrupt 33h (INT 33h). This interrupt acts as the standardized Application Programming Interface (API) for DOS mouse operations:

  1. Hardware Polling and Translation: The driver listens to the serial or PS/2 port hardware, tracking physical movement pulses and button presses.
  2. Coordinate Mapping: It translates relative hardware movements into screen-space coordinates, tailored to the current display mode (text or graphics).
  3. API Exposure: When an application queries INT 33h, the driver returns the current position of the pointer and the status of the left, right, and middle buttons. It also handles drawing the default mouse cursor on the screen.

Mouse Usage in Command-Line and Text-Mode Applications

While the primary DOS command prompt (C:\>) relies exclusively on keyboard commands, many command-line utilities and Text User Interface (TUI) environments take full advantage of the mouse driver.

Applications that benefit directly include:

  • Text Editors: The native MS-DOS EDIT.COM utilizes the mouse for placing the text cursor, highlighting blocks of text, navigating drop-down menus, and clicking dialog boxes.
  • Development Environments: Tools like QBASIC.EXE and Borland Turbo Pascal rely on mouse input for navigating integrated development environments (IDEs).
  • File Managers: Utilities such as Norton Commander, Volkov Commander, and XTreeGold allow users to select, drag, and manage directory trees and files using mouse clicks.
  • Setup and Configuration Utilities: Many installation scripts and system configuration tools implement clickable buttons and scrollable lists within standard text-mode displays.

In these environments, the driver draws a distinct block cursor over text cells, allowing rapid navigation without requiring extensive keyboard shortcuts.

Microsoft MOUSE vs. CTMOUSE

Users of MS-DOS 6.22 typically choose between the standard Microsoft driver and the third-party CuteMouse alternative:

  • Microsoft MOUSE.COM / MOUSE.SYS: The official driver distributed with DOS and Windows. While offering near-universal hardware compatibility and stability, it consumes a relatively large portion of conventional memory (typically 15 KB to 25 KB), which can limit the memory available to run demanding DOS games or utilities.
  • CTMOUSE.EXE (CuteMouse): An open-source, highly optimized mouse driver popular in the DOS community. It performs the same duties as the official driver and provides full INT 33h compatibility, but uses a fraction of the memory—often as little as 3 KB to 4 KB. It can easily load into the Upper Memory Block (UMB), includes automatic port detection, and supports wheel-mouse scrolling in compatible software.

Ultimately, loading either MOUSE or CTMOUSE transforms the MS-DOS text environment from a purely keyboard-driven interface into a more efficient, interactive workspace.