How CONFIG.SYS and AUTOEXEC.BAT Shape MS‑DOS Boot Configuration

The boot‑time problem

When you power on an IBM‑compatible PC running MS‑DOS, the system must transition from firmware to a usable command prompt. If the wrong drivers are loaded or essential environment variables are missing, programs fail to start or the machine hangs before you can type a command. The challenge is to get hardware initialized first, then user‑level software, using only plain‑text files that the BIOS can read.

Two‑stage initialization

MS‑DOS splits the boot process into two deterministic phases:

1. CONFIG.SYS – read before any command interpreter runs. It loads device drivers (e.g., HIMEM.SYS for extended memory) and sets low‑level directives such as DOS=UMB that enable upper memory blocks (UMBs).
2. AUTOEXEC.BAT – executed after CONFIG.SYS finishes. Here you can define the PATH, set environment variables, and launch terminate‑and‑stay‑resident programs (TSRs) like MOUSE.COM. Because hardware is already initialized, TSRs can safely interact with devices.

This ordering guarantees a predictable state: drivers are present before any user program tries to use them.

Worked example: enabling high memory and loading a mouse

Assume a fresh MS‑DOS 6.22 installation on drive C:. To make extended memory available and load the mouse driver into an UMB, you would edit the two files as follows.

CONFIG.SYS (located at C:\CONFIG.SYS)

DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH,UMB
DEVICE=C:\DOS\EMM386.EXE NOEMS

Place the file using the built‑in EDIT.COM

program from a bootable floppy or within DOSBox. You need write access to the root of C: (normally granted when you boot from the system disk).

AUTOEXEC.BAT (located at C:\AUTOEXEC.BAT)

@ECHO OFF
PATH C:\DOS;C:\UTILS
SET TEMP=C:\TMP
LH MOUSE.COM

The LH (LoadHigh) directive attempts to load MOUSE.COM into an UMB created by HIMEM.SYS and EMM386. If insufficient UMB space exists, the driver falls back to conventional memory.

Trade‑offs and limitations

The reliance on plain‑text batch files brings both simplicity and fragility:

• No syntax checking – a missing comma, stray character, or misspelled directive halts the boot process before you reach the prompt, requiring a boot disk to edit the file.
• Static configuration – there is no built‑in mechanism for conditional loading (e.g., load a driver only if a certain hardware probe succeeds). Users must resort to clever IF EXIST checks in AUTOEXEC.BAT or maintain multiple CONFIG.SYS variants.
• Memory pressure – each TSR loaded via AUTOEXEC.BAT consumes conventional memory unless successfully loaded high. Loading many TSRs can leave insufficient space for large applications like early Windows or games.

Actionable checklist for safe changes

1. Backup – copy CONFIG.SYS and AUTOEXEC.BAT to a floppy or to C:\BACKUP\ before editing.
2. Edit safely – use EDIT.COM from a bootable floppy or DOSBox; avoid editing while Windows is running.
3. Test incrementally – after each change, reboot and watch the startup messages. Successful loading of HIMEM.SYS appears as a line like HIMEM.SYS version X.Y loaded.
4. Verify memory – at the C:\> prompt run MEM. Look for:
1. Extended memory reported (e.g., Total extended memory: 6400K).
2. Upper memory blocks enabled (non‑zero Upper memory value).
3. Conventional memory sufficient for your target application.
5. Rollback if needed – if the system fails to boot, boot from a floppy, restore the backup copies, and try again.

By keeping a known‑good copy, testing changes one at a time, and using REM to comment out suspect lines, you can iterate on your MS‑DOS configuration without risking an unbootable machine.