How to Build a Safe FreeDOS Multi-Configuration Boot Menu

Back up FDCONFIG.SYS and FDAUTO.BAT before editing either one — a multi-configuration boot menu is genuinely useful, but it’s also the kind of change that can leave a machine unable to boot cleanly if a syntax error slips through untested.

FreeDOS’s MENU directive in FDCONFIG.SYS displays a numbered boot menu during startup; MENUDEFAULT sets which option is selected automatically if no key is pressed within a given timeout, and MENUCOLOR controls its text and background colors. The mechanism for making later CONFIG.SYS lines conditional on which menu option was chosen is a numeric prefix directly on the line itself:

[menu]
menuitem=1,Normal
menuitem=2,Games
menuitem=3,Recovery
menudefault=1,10

12?DOS=HIGH
2?DEVICE=C:\FDOS\BIN\HIMEMX.EXE
23?DEVICEHIGH=C:\FDOS\BIN\ANSI.SYS

A line prefixed 12? runs only if option 1 or 2 was selected; 23? runs for options 2 or 3. This is what actually lets one FDCONFIG.SYS serve several genuinely different boot profiles instead of needing entirely separate configuration files.

Step 2: put only universally safe directives in the common section

Anything every profile needs regardless of which one is selected — core FreeDOS kernel options, filesystem drivers, basics that no profile should ever boot without — belongs unconditionally, with no numeric prefix. Reserve the prefixed, conditional lines specifically for memory managers, optional device drivers, and anything else that’s genuinely profile-specific, so the common section stays small and easy to reason about.

Step 3: make FDAUTO.BAT branch on the same selection

FreeDOS sets an environment variable reflecting which menu option was chosen, which your startup batch file can check directly:

IF "%CONFIG%"=="2" GOTO :games
IF "%CONFIG%"=="3" GOTO :recovery
GOTO :normal

This is what keeps a CD-ROM redirector or network packet driver from being loaded in AUTOEXEC-equivalent startup when its kernel-side prerequisite from FDCONFIG.SYS wasn’t actually selected for that boot — loading a driver whose dependency never initialized is a common, avoidable source of a startup batch file hanging or erroring partway through.

Step 4: build the recovery entry to be genuinely minimal

The recovery profile should load no optional drivers, no memory managers beyond what’s strictly required, and no TSRs at all — its entire purpose is providing a config nearly guaranteed to boot even when something else in the primary profile has gone wrong. Give it a short menu timeout default only for the normal-use profile, not recovery, so an unattended reboot doesn’t default into a barebones environment when everything is actually fine.

Step 5: test every entry from a genuine cold boot

Test each menu option by actually power-cycling or cold-booting the machine and selecting it, not merely by restarting the FreeCOM shell from within an already-running session — a cold boot exercises the full driver-loading sequence in a way a shell restart doesn’t. Record free conventional memory and confirm expected devices are present for each profile, so a regression in one specific configuration doesn’t go unnoticed just because the profiles you test most often still work.

Step 6: keep an external rescue path independent of this file entirely

However carefully tested, a multi-configuration FDCONFIG.SYS is still a single file a future edit could break. Keep bootable external rescue media — a floppy or USB image with its own minimal, independent configuration — so a syntax error introduced in some future edit to the hard disk’s own configuration is never the only way back into a working system.

How this compares to MS-DOS’s own original MultiConfig

MS-DOS 6.0 introduced conceptually the same idea — combining several CONFIG.SYS/AUTOEXEC.BAT pairs into one file with a boot-time menu — but implemented it with named bracketed block headers like [MENU], [COMMON], and [CONFIG1] rather than FreeDOS’s inline numeric prefixes. Both approaches solve the identical real-world problems Microsoft’s own documentation described at the time: a dual-boot machine needing different driver sets, or a system needing to switch between conventional-memory-maximized and expanded-memory-available configurations depending on what’s about to run. If you’re translating an old MS-DOS MultiConfig setup to FreeDOS, expect to restructure the actual mechanism, not just copy the file across — the underlying goal transfers directly, but the syntax does not.

Give each menuitem a genuinely descriptive label rather than a generic “Config 1” placeholder — a menu read once at a cold boot, months after you set it up, benefits enormously from names that state their actual purpose plainly. “Recovery — no drivers” tells you immediately what you’re choosing and why it exists; a bare number forces you to remember, or go re-read FDCONFIG.SYS itself, before making a confident choice under exactly the stressful circumstances a recovery boot usually implies.

Related:

Sources: