How MS-DOS 6.22 Executes AUTOEXEC.BAT Commands

This article explains the internal mechanics of how MS-DOS 6.22 processes and executes the commands stored within the AUTOEXEC.BAT file during startup. Upon booting, the operating system's primary shell, COMMAND.COM, reads this batch script line by line, utilizing a single-tasking execution model that runs internal routines, calls external binaries synchronously via DOS interrupts, and maintains state until the final instruction completes and hands control to the interactive command prompt.

The Boot Hand-off to COMMAND.COM

The execution of AUTOEXEC.BAT occurs at the final stage of the MS-DOS 6.22 bootstrap sequence. First, the ROM BIOS loads the master boot record, which transfers control to IO.SYS and MSDOS.SYS. These system files initialize hardware, configure internal device drivers, and parse CONFIG.SYS to establish memory structures (such as HIMEM.SYS and EMM388.EXE) and system buffers.

Once CONFIG.SYS processing finishes, MSDOS.SYS launches the default command interpreter specified by the SHELL= directive (or defaults to C:\COMMAND.COM). Upon initialization, the transient portion of COMMAND.COM automatically looks for a file named AUTOEXEC.BAT located in the root directory of the boot drive. If found, COMMAND.COM opens the file to execute its instructions sequentially.

The Line-by-Line Parsing Mechanism

COMMAND.COM interprets AUTOEXEC.BAT strictly sequentially using a text parsing loop:

  1. File Read: COMMAND.COM opens AUTOEXEC.BAT using standard DOS file-handling interrupts (INT 21h). It reads a single line of text up to the carriage return and line feed (CRLF) characters into an internal 128-byte command buffer.
  2. File Pointer Tracking: Because MS-DOS operates with limited memory footprints, COMMAND.COM stores the current file seek offset before processing the line. In many circumstances, it closes the file handle during program execution and reopens it using the stored offset to fetch the next line.
  3. Parsing and Expansion: The interpreter strips leading whitespace, parses environment variables (expanding %VARIABLE% tokens), handles redirection operators (<, >, |), and checks for suppression flags (such as the @ symbol, which hides command echoing).

Synchronous Execution via Single-Tasking Architecture

MS-DOS 6.22 is a single-tasking, 16-bit real-mode operating system. It cannot execute multiple processes concurrently. As a result, sequential execution is enforced by the hardware and the architecture of DOS execution calls:

  • Internal Commands: Commands built directly into COMMAND.COM (such as PATH, PROMPT, SET, or ECHO) are handled immediately by the command interpreter's code routines in RAM. Once the memory variables are updated or text is printed, COMMAND.COM immediately reads the next line of AUTOEXEC.BAT.
  • External Executables (.COM and .EXE): When COMMAND.COM encounters an external command (such as SMARTDRV.EXE or MSCDEX.EXE), it issues an INT 21h, Function 4Bh (EXEC) system call. This call loads the target program into the largest available conventional or upper memory block (UMB). Control of the CPU is entirely transferred to the child program. COMMAND.COM remains dormant in memory until the child process terminates by calling INT 21h, Function 4Ch. Only after the child program exits and returns an exit code does COMMAND.COM regain control of the CPU to fetch the next line from AUTOEXEC.BAT.

Terminate and Stay Resident (TSR) Programs

Many commands in AUTOEXEC.BAT load TSR utilities, such as mouse drivers (MOUSE.COM) or keyboard utilities (DOSKEY). These programs do not execute continuously in the foreground. Instead, they hook specific hardware or software interrupt vectors, reserve their required memory block, and exit back to the operating system using INT 21h, Function 31h (Keep Process / TSR). Because the TSR exits immediately after setting up its hooks, control returns to COMMAND.COM in milliseconds, allowing the sequential execution of subsequent AUTOEXEC.BAT lines to proceed without delay.

Sub-Batch Files and the CALL Command

Sequential execution behavior in MS-DOS 6.22 changes when invoking another batch file (.BAT) from within AUTOEXEC.BAT:

  • Direct Invocation: If a secondary batch file is called directly by name (e.g., NETSTART.BAT), COMMAND.COM closes AUTOEXEC.BAT and permanently transfers the batch execution context to the new file. Any lines remaining in AUTOEXEC.BAT below that call are never executed.
  • Using CALL: If invoked using the CALL command (e.g., CALL NETSTART.BAT), COMMAND.COM saves the state, file handle, and read offset of AUTOEXEC.BAT onto an internal stack. It sequentially executes the secondary batch file to completion, pops the saved state off the stack, and resumes execution of AUTOEXEC.BAT at the exact line following the CALL statement.

Completion and Transition to the Prompt

COMMAND.COM continues this read-parse-execute cycle until it encounters an End-of-File (EOF) marker (ASCII 26 / Ctrl+Z) or reaches the physical end of AUTOEXEC.BAT. Once the final command finishes and returns control, COMMAND.COM unloads the batch-processing state from its transient memory area, displays the system prompt (as configured by the PROMPT command), and enters an idle polling loop awaiting user keyboard input via INT 16h.