The FreeDOS Boot Process: CONFIG.SYS and AUTOEXEC.BAT

FreeDOS’s boot process is refreshingly small compared to any modern OS — no service manager, no unit dependency graph, just a strict linear sequence: boot sector, kernel, CONFIG.SYS, COMMAND.COM, AUTOEXEC.BAT. Every step is a plain, readable file, and the entire chain can be understood in one sitting.

Stage 1: the boot sector

On a bootable FreeDOS disk, the very first 512-byte sector contains boot code whose only job is to locate and load the kernel file (KERNEL.SYS) into memory and jump to it — analogous in spirit to FreeBSD’s boot0/boot1 or a minimal MBR loader, just far simpler since there’s no filesystem abstraction layer or menu system to speak of.

FORMAT A: /S

/S copies the boot sector code plus KERNEL.SYS and COMMAND.COM onto a freshly formatted disk, making it bootable.

Stage 2: the kernel loads CONFIG.SYS

Once KERNEL.SYS has control, it initializes core data structures and then reads CONFIG.SYS from the root directory — the single file controlling nearly everything about the DOS environment before the shell ever appears: which device drivers load, how much memory management is enabled, and various kernel tunables.

DEVICE=C:\FREEDOS\HIMEM.EXE
DEVICE=C:\FREEDOS\EMM386.EXE
DOS=HIGH,UMB
FILES=40
BUFFERS=20
SHELL=C:\COMMAND.COM /P

Each DEVICE= line loads a driver — HIMEM.EXE enables access to extended memory, EMM386.EXE provides expanded memory emulation and upper memory blocks. FILES= and BUFFERS= tune how many simultaneously open file handles and disk buffers the kernel allocates — real, meaningful tunables on a system without dynamic memory allocation the way a modern OS has it.

DEVICEHIGH: loading drivers into upper memory

Because conventional memory (the first 640KB) is a scarce, fixed resource that every DOS program competes for, CONFIG.SYS supports loading drivers into upper memory blocks instead, freeing conventional memory for applications:

DEVICEHIGH=C:\FREEDOS\ANSI.SYS

This single line is a perfect example of DOS-era resource management: every driver loaded high instead of low is kilobytes of conventional memory recovered for whatever application actually needs to run.

Stage 3: COMMAND.COM

Once CONFIG.SYS has finished processing, the kernel loads the shell specified by the SHELL= line — normally COMMAND.COM, which becomes the actual interactive command interpreter (and the thing that executes batch files, including the next stage).

SHELL=C:\COMMAND.COM C:\ /E:512 /P

/E:512 sets the environment variable space size, and /P marks this shell instance as permanent — it can’t be exited back to a “parent” DOS, which matters because on a normally-booted system there is no parent to return to.

Stage 4: AUTOEXEC.BAT

COMMAND.COM’s first action, once loaded, is to look for and execute AUTOEXEC.BAT — an ordinary batch file, run exactly like any script you’d invoke manually, whose entire purpose is to set up the interactive environment: PATH, environment variables, TSRs (terminate-and-stay-resident programs), and often a mouse or sound driver that doesn’t belong in CONFIG.SYS because it’s an executable program rather than a device driver.

@ECHO OFF
SET PATH=C:\FREEDOS\BIN;C:\DOS
SET TEMP=C:\TEMP
LH C:\FREEDOS\MOUSE.EXE
PROMPT $P$G

LH (load high) is AUTOEXEC.BAT’s equivalent of DEVICEHIGH= — loading a TSR program into upper memory rather than conventional memory, for exactly the same reason.

Interactive boot: stepping through manually

FreeDOS supports pressing F5 or F8 during boot to skip or step through CONFIG.SYS line by line — the direct equivalent of FreeBSD’s -s single-user boot or interrupting a Linux boot to edit kernel parameters, giving you a way to isolate exactly which driver or setting is causing a boot problem.

Starting FreeDOS...
Press F8 for step-by-step confirmation

Why this simplicity is the whole point

There’s no dependency graph to resolve, no parallel startup, no unit files to cross-reference — CONFIG.SYS runs top to bottom, then AUTOEXEC.BAT runs top to bottom, and that’s the entire boot sequence. For a real-mode, single-tasking OS with a fixed, small memory budget, that linearity isn’t a limitation so much as the correct design for the problem: every kilobyte of memory a driver or TSR consumes is visible and attributable to one specific line in one specific file, which is exactly the kind of total system legibility that gets harder to achieve as an OS’s boot process grows more sophisticated.