How MS-DOS 6.22 CTTY Redirects Input and Output

The MS-DOS 6.22 CTTY (Change TTY) command allows users to change the default terminal device assigned to standard input and standard output. By substituting the default console (CON) with an alternative character device, such as a serial communication port, CTTY enables remote terminal access, automated batch scripting through external hardware, or headless system operation. This article explains the underlying mechanism of how CTTY alters the operating system's device associations, how it handles data flow at the driver level, and the technical limitations inherent to DOS-based I/O redirection.

The Default I/O Architecture in MS-DOS

In MS-DOS, input and output operations default to the CON device, a built-in character device driver representing the physical keyboard (standard input) and the video display adapter (standard output and error). When the system initializes, the primary command interpreter, COMMAND.COM, opens the standard handles—Handle 0 (STDIN), Handle 1 (STDOUT), and Handle 2 (STDERR)—and binds them directly to the CON device.

Programs interacting through standard DOS API calls (Interrupt 21h) read keystrokes from and write text buffers to this device driver without needing to manage the hardware directly.

How the CTTY Command Redirects Standard Handles

When you execute CTTY [device], such as CTTY COM1 or CTTY AUX, MS-DOS modifies the assignment of the standard input and output streams. The command operates through the following steps:

  1. Device Validation: MS-DOS scans its internal device driver chain to locate the specified device header. The target must be an installed character device that supports both input and output functions. Block devices (such as disk drives C: or A:) are rejected.
  2. Handle Reassignment: Once the device is validated, MS-DOS closes the active association of the standard handles (Handles 0, 1, and 2) with CON and re-attaches them to the newly designated character device driver.
  3. Interpreter Binding: COMMAND.COM redirects its prompt, command parsing loop, and output messages to the new stream. For instance, redirecting to COM1 causes COMMAND.COM to read incoming ASCII characters from the serial UART interface as if they were typed on the local keyboard, and it writes text responses out to the serial transmitter.

To restore standard operations, a command must be issued through the active stream to reset the console back to the physical monitor and keyboard:

CTTY CON

Driver-Level Interaction and Interrupts

At the driver level, character devices implement a standardized header containing a strategy routine and an interrupt routine. When CTTY shifts control to a port like COM1, DOS invokes the character device driver's read and write functions instead of the BIOS-backed keyboard and screen routines:

  • Read Requests: DOS calls the driver's input routine, which polls the serial hardware FIFO or buffer register until a character is ready.
  • Write Requests: DOS passes data bytes to the driver's output routine, which serializes the data across the transmission line.

Because MS-DOS operates in real mode with cooperative execution, standard I/O redirection through CTTY relies strictly on synchronous polling unless the specific device driver uses hardware interrupts (such as IRQ 4 for COM1 or IRQ 3 for COM2) to populate an internal ring buffer.

Technical Limitations of CTTY Redirection

While CTTY successfully redirects commands processed through DOS, it does not provide true hardware-level terminal virtualization:

  • Direct Hardware Access: Many MS-DOS programs bypass DOS Interrupt 21h for performance reasons, writing directly to video memory addresses (0xB800 for CGA/VGA text mode) or reading directly from the keyboard controller via port 0x60h or BIOS Interrupt 16h. Programs that do this ignore CTTY redirection completely; their output continues to appear on the local monitor, and they will not accept input from the remote device.
  • Lack of Flow Control: Built-in DOS serial drivers have minimal flow control handling. If CTTY is pointed to a serial port without proper hardware handshaking (RTS/CTS) configured externally, buffer overruns can easily cause dropped characters or command lockups.
  • No Authentication: CTTY passes full, unrestricted administrative control of COMMAND.COM to the connected port. Any device sending ASCII text to the port can execute disk operations, format drives, or delete files without credentials.