FreeDOS Code Pages and NLS: How Keyboard, Console, and Application Text Align

Correct text on FreeDOS requires three different things to agree: keys must produce the intended byte values, the active code page must map those bytes to expected characters, and the display hardware/font must contain the matching glyphs. Changing only the keyboard layout can make typed bytes correct while the screen shows the wrong symbols.

DOS code pages map bytes, not Unicode characters

Most DOS text applications work with one-byte character values. A code page assigns glyphs and character meaning to values 0x80–0xFF while ASCII occupies the lower range. Code page 437, 850, 852, 858, and others differ; the same byte can display as a different accented letter or line-drawing symbol.

There is no filename-wide Unicode normalization layer comparable to a modern operating system. Applications, archives, printers, remote terminals, and host conversions must agree on encoding explicitly.

COUNTRY supplies locale conventions

The COUNTRY directive in FDCONFIG.SYS/CONFIG.SYS selects country data such as date, time, currency, and case-conversion tables and can identify a code page and COUNTRY.SYS file:

COUNTRY=054,850,C:\FREEDOS\BIN\COUNTRY.SYS

That example represents Argentina with code page 850 only as an illustration; confirm country and code-page support in the installed files. COUNTRY does not itself install a keyboard driver or upload a screen font.

KEYB controls input translation

KEYB loads a keyboard layout and uses layout data appropriate to the selected language/code page. Place it after required code-page support in the boot sequence. Test letters, shifted characters, AltGr combinations, dead keys, and command-shell metacharacters—not only alphabetic keys.

A mismatched layout can make \, |, @, brackets, or colon difficult to type, which then looks like a shell or PATH problem. Keep a boot-menu option with the known US/default layout for recovery.

DISPLAY and MODE manage console code pages

DISPLAY provides console code-page management. MODE CON CP PREP prepares a code page from a .CPI/.CPX font resource, and MODE CON CP SELECT activates it. CHCP queries or changes the active prepared page according to available support.

MODE CON CP PREP=((850) C:\FREEDOS\CPI\EGA.CPX)
MODE CON CP SELECT=850
CHCP

Paths and syntax depend on the distribution layout and display driver. Preparing a page without selecting it changes nothing visible; selecting a page that was not prepared fails. Some video hardware, virtual machines, and accessibility drivers use different display paths.

Applications may bypass the console

A program can write through DOS CON, BIOS video services, or directly to video memory. Direct-writing applications may ignore console-driver translation and ship their own fonts. Graphical DOS programs can implement another encoding entirely.

Printer output is another device path. A glyph visible on VGA does not prove the printer interprets the same byte as that character. Configure the printer’s code page or have the application emit the required printer language.

Filenames preserve bytes and compatibility hazards

Short filenames store byte values with DOS case rules. Moving a disk between code pages can make the same bytes display differently. Long-filename extensions add their own Unicode or conversion rules depending on driver and host. Archive tools can preserve raw names, translate them, or lose characters.

Before bulk renaming or extraction, image the disk and test representative names on every target environment. For interchange, restrict critical boot and tool paths to portable ASCII 8.3 names even when applications support more.

Build a diagnostic matrix

Record COUNTRY, active CHCP, keyboard layout, loaded DISPLAY, font file/hash, video environment, application, and output device. Create a test file containing known byte values and compare display, editor read/write, archive round-trip, printer, serial transfer, and host conversion.

Fix the layer that disagrees. If keystrokes produce the wrong byte, inspect KEYB; if the byte is right but the glyph is wrong, inspect display code page/font; if only one program fails, inspect its I/O and encoding. NLS works when input, bytes, glyphs, and locale conventions are aligned—not when one command reports the desired country number.

Related:

Sources: