MS-DOS 6.22 Extended ASCII Batch Labels

MS-DOS 6.22 processes batch file labels containing extended ASCII characters (character codes 128 through 255) by treating them as raw, single-byte identifiers subject to specific truncation, byte-comparison, and code page constraints. When the command interpreter (COMMAND.COM) encounters a label prefixed with a colon (:), it processes extended ASCII bytes directly from the file stream. Understanding this behavior requires examining how COMMAND.COM manages byte tokenization, the eight-character evaluation limit, case-folding mechanisms, and code page dependencies.

Byte Tokenization and Delimiters

In MS-DOS 6.22, batch file labels begin with a colon (:) as the first non-whitespace character on a line. When COMMAND.COM parses a label name, it reads sequential bytes until it encounters a standard delimiter, such as a space, tab, comma, semicolon, equal sign, or newline.

Extended ASCII characters (hexadecimal values 0x80 to 0xFF) are not recognized as delimiters. COMMAND.COM treats them as valid constituent bytes of the label name. Consequently, symbols, accented characters, box-drawing elements, and foreign alphabet characters falling within this range are read directly into the internal label buffer.

The Eight-Character Truncation Limit

COMMAND.COM enforces a strict eight-character limit on batch labels. While a label in a batch file can visually exceed eight characters, MS-DOS only reads and evaluates the first eight bytes following the colon. Any subsequent characters—standard or extended ASCII—are discarded during internal evaluation.

For example, if an extended character appears within the first eight bytes, it directly influences label resolution:

  • :TESTé123A and :TESTé123B are identical to MS-DOS because both truncate to the exact same eight-byte sequence (TESTé123).
  • A GOTO command searching for :TESTé123B will jump to the first :TESTé123A it finds in the file.

Case Folding and NLS Handling

Standard ASCII letters (a–z) are automatically converted to uppercase (A–Z) by COMMAND.COM to ensure case-insensitive label matching. However, extended ASCII characters behave differently depending on whether National Language Support (NLS) is active:

  1. Default Configuration (No NLS): Without COUNTRY.SYS and NLSFUNC loaded, COMMAND.COM applies basic ASCII uppercase mapping (0x61 to 0x7A mapped to 0x41 to 0x5A). Extended ASCII bytes (0x80 to 0xFF) bypass this conversion and are stored as literal, raw byte values. In this state, extended ASCII labels become effectively case-sensitive. A GOTO referencing an uppercase accented character will not match a label defined with the lowercase counterpart.
  2. Active NLS Configuration: If extended country support is initialized, COMMAND.COM uses the active DOS country casing table (via INT 21h, Function 65h) to convert lowercase extended characters to their uppercase equivalents. In this scenario, case-insensitivity extends to supported foreign characters defined within that specific country table.

Code Page and Binary Matching

MS-DOS does not have native support for Unicode or modern multi-byte encodings (such as UTF-8). It interprets files purely as sequences of single-byte values according to the currently active hardware or prepared code page (such as Code Page 437 or Code Page 850).

During a GOTO operation, COMMAND.COM resets the file pointer to the beginning of the batch file and performs a byte-by-byte comparison between the target label argument and the labels defined in the file. Because matching occurs at the raw byte level:

  • A batch file written in an external editor using Windows-1252 (ANSI) encoding will fail if MS-DOS executes it under Code Page 437, whenever the intended character maps to different byte values between the two encodings.
  • The visual glyph displayed on the screen via the console font does not dictate execution; only the exact numerical byte value (0x80–0xFF) saved on the disk determines whether COMMAND.COM resolves the label successfully or halts with a Label not found error.