MS-DOS 6.22 AUTOEXEC.BAT Execution Loops Explained

This article explores how MS-DOS 6.22 handles system execution loops inside the AUTOEXEC.BAT startup file. It covers the internal processing mechanisms of COMMAND.COM, the behavioral differences between chaining and nested recursion, the memory and disk performance implications of uncontrolled loops, and the built-in system recovery features designed to interrupt runaway execution at boot time.

In MS-DOS 6.22, batch processing is handled by the default command interpreter, COMMAND.COM. When the operating system finishes processing CONFIG.SYS, it invokes COMMAND.COM, which automatically searches for and executes AUTOEXEC.BAT in the root directory of the boot drive. Because COMMAND.COM is a line-by-line interpreter rather than a compiler, it processes batch loops dynamically at runtime using text parsing and file pointer repositioning.

Execution loops inside AUTOEXEC.BAT are typically constructed using labels and the GOTO statement, or through recursive file calls. When a GOTO label command is executed, COMMAND.COM does not jump to a pre-indexed memory offset. Instead, it resets its file pointer and scans the batch file from the beginning until it matches the specified label string. In an infinite loop, COMMAND.COM continuously re-reads the file from storage. If disk caching software like SMARTDRV.EXE has not yet been loaded in the startup sequence, this scanning behavior causes continuous physical disk read operations, resulting in drive thrashing and noticeable hardware delays on floppy disks or slow hard drives.

The nature of an execution loop also depends on whether the script uses direct chaining or the CALL command. If AUTOEXEC.BAT invokes itself directly by name (e.g., executing AUTOEXEC as a command), COMMAND.COM terminates the current execution context and transfers control to the beginning of the newly invoked instance. This is known as batch chaining. Chaining does not consume additional conventional memory, allowing an infinite loop to run indefinitely without triggering a stack overflow.

Conversely, if AUTOEXEC.BAT calls itself using the CALL AUTOEXEC.BAT syntax, COMMAND.COM preserves the state of the caller in memory before spawning a nested subshell context. Because conventional memory (the first 640 KB) and internal shell nesting tables are strictly limited in MS-DOS 6.22, deep or infinite recursion via CALL rapidly exhausts system resources. This typically results in an out-of-memory error, an internal stack overflow error, or a total system lockup.

To break out of an active loop inside AUTOEXEC.BAT, MS-DOS relies on interrupt-driven keyboard signals. Users can send a hardware interrupt by pressing Ctrl+C or Ctrl+Break. When detected, COMMAND.COM pauses execution and displays the prompt: Terminate batch job (Y/N)?. Answering Y aborts the batch script entirely and drops the user directly into the standard DOS prompt (C:\>), leaving any commands defined after the loop unexecuted.

If an execution loop locks the system before keyboard interrupts can be processed, MS-DOS 6.22 provides pre-boot recovery options. During boot, when the message Starting MS-DOS... appears on the screen, users can press F5 to perform a clean boot, completely bypassing both CONFIG.SYS and AUTOEXEC.BAT. Alternatively, pressing F8 enables interactive step-by-step confirmation, allowing the user to selectively approve or skip individual commands in AUTOEXEC.BAT, effectively bypassing the loop without altering the file on disk.