How MS-DOS 6.22 EDIT Provides a Full-Screen Editor

The MS-DOS 6.22 EDIT command delivers a full-screen text editing environment by utilizing the runtime engine of Microsoft QBasic to render a text-based user interface (TUI). Unlike earlier line-oriented editors such as EDLIN, EDIT provides a visual workspace featuring pull-down menus, mouse navigation, dialog boxes, and cursor-based text manipulation. This article explains the technical mechanics behind how EDIT interfaces with MS-DOS system resources, hardware video modes, and the QBasic interpreter to generate this interface.

The QBasic Architecture Dependency

In MS-DOS 6.22, EDIT.COM is not an independent, self-contained application. Instead, it serves as a lightweight stub loader (approximately 413 bytes) that invokes QBASIC.EXE using a specialized, undocumented switch: QBASIC /EDITOR.

When a user executes EDIT filename.txt, the stub checks for the presence of QBASIC.EXE in the current working directory or along the system PATH. If located, QBASIC.EXE launches directly into its embedded text editing subsystem while suppressing the standard BASIC programming environment and interpreter prompts. If QBASIC.EXE is absent or corrupted, the command fails with an error indicating that the editor cannot run without it.

Text-Mode Video Memory Management

Rather than using graphical pixel modes, the EDIT interface operates strictly within the standard PC text display mode (VGA/EGA Mode 03h), which consists of an 80-column by 25-row character grid.

To achieve high rendering speeds on legacy hardware, the underlying engine bypasses standard MS-DOS character output routines and writes directly to video display memory located at physical memory segment B800h (for color displays) or B000h (for monochrome displays). Each screen cell requires two bytes in video memory:

  1. Character Byte: The ASCII code of the character to display.
  2. Attribute Byte: Defines the foreground color, background color, and blink/intensity status.

By manipulating these attribute and character bytes directly, the editor instantly updates the entire screen without perceptible flicker during typing, scrolling, or menu navigation.

Visual Elements via Extended ASCII

The full-screen interface creates the illusion of overlapping windows, drop-down menus, borders, and buttons using standard IBM Extended ASCII (Code Page 437) characters:

  • Borders and Frames: Single-line and double-line box-drawing characters (ASCII values 179 to 218) form the boundaries of the main editing window, status bars, and pop-up dialogs.
  • Scroll Bars: Vertical and horizontal scroll tracks are rendered using light and dark shade blocks (ASCII 176 and 178), while directional arrows are indicated by standard arrow symbols (ASCII 24 to 27).
  • Drop Shadows: Pop-up menus and dialog windows simulate depth by changing the background attribute byte of neighboring cells to a darker color (typically black on dark gray) rather than shifting character positions.

Input Handling and Mouse Support

The editor abstracts input control through two primary mechanisms:

  • Keyboard Navigation: The interface captures raw keystrokes via BIOS Interrupt 16h. Holding down the Alt key combined with underlined hotkeys immediately highlights and opens the corresponding top-level menus (File, Edit, Search, Options, Help). Standard keyboard arrow keys, Page Up, Page Down, Home, and End adjust the internal buffer pointers and move the visible hardware cursor using BIOS Interrupt 10h.
  • Mouse Driver Integration: If a mouse driver such as MOUSE.COM or MOUSE.SYS is loaded into memory, the editor queries mouse services through software Interrupt 33h. The driver provides cursor position coordinates and click states. In response, the editor alters the attribute byte of the character cell beneath the pointer, creating a distinctive inverted block cursor that moves across the screen to select text, position the insertion point, or activate menu options.

Memory Buffering and File Handling

When opening a document, EDIT loads the file into conventional memory (the first 640 KB of system RAM). The internal buffer manages text as dynamically allocated lines in memory. As the user navigates, the engine calculates which segment of the text buffer aligns with the current 80x25 viewing window, applies syntax or selection highlight attributes, and transfers the corresponding text matrix to video RAM. Because operations take place directly in RAM, navigation remains responsive until changes are written back to storage via MS-DOS File I/O (Interrupt 21h).