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

A normal FreeDOS BIOS boot crosses several distinct layers: firmware chooses a disk, hard-disk MBR code chooses an active partition, that partition’s volume boot record loads KERNEL.SYS, the kernel processes FDCONFIG.SYS or CONFIG.SYS, and the selected shell—normally FreeCOM—runs FDAUTO.BAT or AUTOEXEC.BAT. Separating those layers makes a failed boot diagnosable instead of turning every blank screen into a “CONFIG.SYS problem.”

Firmware and partition boot code come before FreeDOS

On a traditional BIOS PC, firmware reads boot code from the selected device. A floppy has no MBR partition-selection stage: its volume boot record is directly bootable. A partitioned hard disk normally begins with an MBR whose code selects an active partition and loads that partition’s volume boot record.

FreeDOS’s volume boot code then locates the configured kernel filename, normally KERNEL.SYS, loads it, and transfers control. The volume’s BIOS Parameter Block also describes sector size, cluster size, FAT layout, and other geometry the boot code needs.

This means the “first 512-byte sector loads the kernel” description is incomplete for hard disks. Sector zero usually contains MBR code and a partition table; the active partition has another boot sector. Damage to either layer can stop startup before the kernel ever reads a configuration file.

FreeDOS SYS installs boot code and copies the kernel and shell. Its simplest documented form is SYS dest:, but it overwrites a boot sector and must never be used speculatively on a valuable disk. Current SYS provides /DUMPBS and /BACKUPBS options that can preserve the existing sector. Practice on a copied image and verify source and destination drive letters first.

KERNEL.SYS initializes DOS services

After the volume boot code succeeds, KERNEL.SYS initializes memory structures, built-in devices, drive information, system tables, and the DOS API. The kernel includes default console, clock, disk, and other core handlers; later configuration can add external drivers and adjust resource limits.

A kernel filename can be changed in boot code using advanced SYS options, but a normal installation expects KERNEL.SYS. Renaming or replacing it without corresponding boot-sector configuration can produce a failure earlier than any visible FreeCOM message.

Kernel and shell versions are independent. KERNEL.SYS provides DOS services; COMMAND.COM provides the command interpreter, batch processing, and prompt. Updating one does not prove the other was updated or remains compatible with every extension.

FDCONFIG.SYS takes precedence over CONFIG.SYS

The FreeDOS kernel first looks for FDCONFIG.SYS. If it exists, the kernel uses it instead of CONFIG.SYS. This FreeDOS-specific filename allows one volume to keep different configuration for another DOS kernel. Articles that say FreeDOS always reads only CONFIG.SYS miss that documented precedence.

Configuration is processed during kernel initialization. Typical directives include:

DEVICE=C:\FDOS\BIN\HIMEM.SYS
DOS=HIGH,UMB
FILES=40
BUFFERS=20
SHELL=C:\FDOS\BIN\COMMAND.COM C:\FDOS\BIN /E:1024 /P=C:\FDAUTO.BAT

Paths and driver filenames differ across installations. Copy settings from the installed release and the driver’s documentation rather than assuming this illustrative layout exists.

FILES reserves system file-table capacity within documented limits. BUFFERS selects a minimum number of disk buffers; FreeDOS may use available High Memory Area space for more, and its secondary-buffer argument is accepted for compatibility but ignored. They are not simply static relics of a kernel incapable of dynamic allocation.

DEVICE and DEVICEHIGH load kernel extensions

DEVICE=path options loads an installable device driver into conventional memory. DEVICEHIGH attempts upper-memory placement and falls back to conventional memory. Upper-memory loading depends on suitable memory-manager setup, and order can change whether a sufficiently large block remains available.

DEVICEHIGH=C:\FDOS\BIN\XCDROM.SYS /D:FDCD0001

That CD-ROM driver name is then matched by a redirector loaded later; the identifier must agree on both sides. A driver option copied from another implementation may be rejected or, worse, change hardware access unexpectedly. Use the exact driver’s help.

INSTALL and INSTALLHIGH run programs, commonly TSRs, during configuration with a small environment. They are not interchangeable with DEVICE: an executable TSR and a DOS device driver enter the system through different interfaces even if both remain resident.

DOS=HIGH,UMB changes memory placement

DOS=HIGH asks the kernel to place eligible code in the High Memory Area, while UMB links available Upper Memory Blocks into DOS’s allocation chain. A suitable XMS/upper-memory configuration must be loaded first. DOS=LOW,NOUMB keeps the kernel low and avoids UMB linkage.

DEVICEHIGH and later LH commands are optimization attempts, not proofs of success. A driver can fall back low, and loading a small driver first can fragment upper memory so a larger one no longer fits. Record MEM output before and after changes instead of assuming every “HIGH” keyword frees conventional memory.

Memory configuration is a frequent boot-failure source. Keep a minimal menu option without optional managers and drivers, then add one layer at a time. Do not edit the only working configuration without a bootable rescue image.

SHELL selects FreeCOM and the startup script

The SHELL directive chooses the command interpreter and passes its options. FreeCOM’s /P creates a primary, permanent instance that cannot exit to a nonexistent parent. It also runs AUTOEXEC.BAT; /P:filename selects an alternate startup script such as FDAUTO.BAT.

/E:1024 requests an environment segment size, while the path argument helps FreeCOM establish its location and COMSPEC. A shell path on a RAM disk is unsafe at this point because the RAM disk and copy operation normally do not exist until later startup.

If no valid shell can be loaded, the kernel may not reach an interactive prompt. Check the file’s presence, spelling, drive assignment, and command-line options from rescue media before changing boot sectors.

FDAUTO.BAT configures the interactive environment

The startup batch executes after the kernel has processed configuration and loaded FreeCOM. It usually sets paths and variables, initializes console or locale tools, loads executable TSRs, and sets the prompt.

@ECHO OFF
SET PATH=C:\FDOS\BIN
SET TEMP=C:\TEMP
IF NOT EXIST C:\TEMP\NUL MD C:\TEMP
LH C:\FDOS\BIN\CTMOUSE.EXE
PROMPT $P$G

LH asks DOS to place a program in upper memory. It differs from DEVICEHIGH, which loads a device driver during kernel configuration. A mouse driver such as CTMOUSE is commonly an executable resident program, so presenting MOUSE.SYS as the universal FreeDOS path is misleading.

Every command should be tested interactively before entering startup. An invalid TSR option can hang the machine on every boot; a wrong PATH can make later recovery commands appear missing.

F5 and F8 provide different recovery behavior

FreeCOM and the kernel support boot-key handling when compiled with the relevant feature. F5 bypasses configuration and causes the shell to skip the automatic startup script. F8 enables step-by-step tracing so the user can confirm lines. Timing and firmware keyboard handling can vary, so a configured boot menu is a more reproducible long-term recovery mechanism.

FreeDOS also supports MENU, MENUDEFAULT, and numeric conditional prefixes in FDCONFIG.SYS. A safe configuration can offer minimal, normal, networking, and diagnostic choices. That is more robust than commenting and uncommenting driver lines under pressure.

Diagnose the last layer that proved alive

No FreeDOS message and no kernel banner suggests firmware, media, MBR, partition selection, volume boot code, or kernel loading. Kernel output followed by a hang during a named driver points to FDCONFIG.SYS. A prompt with missing paths or TSRs points to FDAUTO.BAT. A shell-not-found message points to SHELL or COMMAND.COM.

Capture exact text and the last successful line. Boot from trusted media, mount the affected volume read-only where possible, and copy configuration files before editing. Avoid FDISK, FORMAT, and SYS until evidence identifies a partition or boot-code problem; all three can make recovery harder when used at the wrong layer.

The boot chain is linear, but not trivial. Its strength is auditability: each transition has a specific artifact and responsibility. Diagnosing BIOS/MBR/VBR, kernel configuration, shell selection, and startup batch as separate stages is safer than treating all startup failures as one file.

Related:

Sources: