Running Binary Data as a Script in MS-DOS 6.22

When MS-DOS 6.22 is instructed to run a non-executable binary file as a batch script, the command interpreter treats the raw byte stream as standard ASCII text. This article explains how the operating system processes this invalid input, detailing the parsing behavior of the command shell, the generation of recurring terminal errors, the impact of low-level control characters, and the conditions that cause the script to terminate.

Line Parsing and Buffer Limitations

In MS-DOS 6.22, batch scripts are processed directly by COMMAND.COM. The shell reads the file sequentially, looking for carriage return (0x0D) and line feed (0x0A) bytes to demarcate individual command lines.

Because binary files contain arbitrary byte arrangements rather than formatted text lines, COMMAND.COM reads through the data until it hits a line break or fills its internal command buffer. In MS-DOS, this buffer is limited to 127 characters. If binary data exceeds this length without encountering a line break, the shell truncates the line, appends a null terminator, and attempts to execute whatever arbitrary string of bytes has accumulated.

Syntax Errors and "Bad command or file name"

The primary reaction of the operating system is the rapid generation of the standard error: Bad command or file name.

As COMMAND.COM evaluates each pseudo-line, it scans the leading characters up to the first space or delimiter, checking against its internal command table (such as DIR, COPY, or TYPE) and then searching the current directory and system PATH for matching executable files (.COM, .EXE, .BAT). Because the chance of arbitrary binary bytes forming a valid command name is low, almost every chunk parsed by the shell fails validation, resulting in continuous command errors printed to the screen.

Terminal Display Corruption and Control Characters

As the command interpreter reads and echoes lines to the console (unless @ECHO OFF was somehow parsed at the start), raw binary bytes pass through the standard BIOS video routines. This triggers noticeable hardware and display behaviors:

  • Audio Beeps: Byte value 0x07 represents the ASCII Bell character. When passed to the console, it triggers the motherboard's PC speaker, causing the system to beep repeatedly during execution.
  • Visual Glitches: Control characters such as 0x08 (backspace), 0x09 (tab), and 0x0C (form feed) manipulate the cursor position and clear the screen arbitrarily.
  • Extended ASCII Characters: Bytes between 0x80 and 0xFF render as graphical symbols, accented characters, and box-drawing elements defined by Code Page 437, filling the screen with chaotic visual artifacts.
  • ANSI.SYS Interpretation: If the ANSI driver (ANSI.SYS) is loaded in CONFIG.SYS, the escape byte (0x1B) signals the start of control sequences. Binary data following an escape character can inadvertently alter text colors, reposition the cursor, or remap keyboard keys.

Stream Redirection and System Halts

Certain ASCII characters embedded in the binary data can alter how COMMAND.COM routes I/O:

  • Redirection Operators: Bytes matching < (0x3C), > (0x3E), or | (0x7C) instruct the shell to perform input redirection, output redirection, or piping. If an invalid or nonexistent filename immediately follows a redirection byte, the interpreter throws errors like File not found or Access denied.
  • Input Freezes: If the interpreter parses a redirection command that requests input from an unready device or an invalid handle, the system may hang, waiting indefinitely for user input or hardware readiness.

Termination by End-of-File Markers

MS-DOS text file parsing natively uses byte 0x1A (ASCII Substitute / Ctrl+Z) as a hard end-of-file marker.

Even if the physical file is several megabytes long, the moment COMMAND.COM encounters byte 0x1A within the binary stream, it immediately stops reading further commands. The shell closes the file handle and returns control to the prompt. Given the uniform distribution of bytes in compiled binaries or compressed archives, a 0x1A byte typically appears within the first few hundred to few thousand bytes, ensuring that execution ceases relatively quickly without external intervention.