What Were AUTOEXEC.BAT and CONFIG.SYS? (And How They Worked) | Comuniq

This site requires Javascript to work properly. Please enable Javascript in your browser.

/Technology

Gadgets, apps, inventions and everything that involves the world of technology. Share your links here and see what the guys have to say in the comments.

Members: 15 Join

Moderated by: mozzapp

What Were AUTOEXEC.BAT and CONFIG.SYS? (And How They Worked)

Manon_code<br>1781640192<br>[Technology]<br>2 comments

## What did autoexec.bat and config.sys actually do when your computer turned on?

They were two plain text startup files that MS-DOS read automatically on every boot. `config.sys` ran first and told the operating system how to configure itself at a low level: memory layout, device drivers, file limits. Then `autoexec.bat` ran as a regular batch script, setting environment variables, loading resident programs, and preparing the user session. Between the two of them, they handled everything the system needed before you could actually use it.

## How It Was at the Time

In the MS-DOS era, roughly from the early 1980s through the mid-1990s, personal computers running DOS depended on these two files to be usable at all. They lived in the root of the C: drive and the system looked for them automatically during startup. If they didn't exist, DOS would still start, but in a minimal state that wasn't good for much. If they had errors, the results ranged from a missing mouse driver to a machine that refused to boot.

There was no graphical configuration panel, no wizard to walk you through it. You opened the files in a text editor, made your changes, rebooted, and saw what happened. It was manual in the most direct sense.

`config.sys` was processed by DOS before any user-facing code ran. It wasn't really a script. You couldn't write loops or conditionals in it (not until DOS 6.0 added multi-boot support, which we'll get to). It was a list of directives, each one telling the kernel to do something specific before handing control over to the rest of the boot process.

The central problem it existed to solve was memory. The original IBM PC architecture had a hard ceiling of 640 kilobytes of conventional memory, the space where programs actually ran. DOS itself consumed part of that. Device drivers consumed more. TSR programs (Terminate and Stay Resident, things like mouse drivers, disk caches, network clients) consumed more still. By the time a user tried to launch a demanding application, they might have only 560 or 580KB free, and plenty of software required more than that just to start.

The industry's response was a layered set of workarounds: Extended Memory (XMS), Expanded Memory (EMS), and the Upper Memory Area, a 384KB region between 640KB and 1MB that was nominally reserved for hardware but could sometimes be reclaimed for software use. DOS 5.0 added tools to exploit this, and tuning `config.sys` became largely about pushing drivers and resident software out of conventional memory and into these upper regions.

A reasonably typical `config.sys` from the early 1990s looked something like this:

```<br>DEVICE=C:\DOS\HIMEM.SYS<br>DEVICE=C:\DOS\EMM386.EXE NOEMS<br>DOS=HIGH,UMB<br>DEVICEHIGH=C:\DOS\ANSI.SYS<br>DEVICEHIGH=C:\MOUSE\MOUSE.SYS<br>FILES=40<br>BUFFERS=15<br>STACKS=9,256<br>SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:512 /P<br>```

`HIMEM.SYS` was the extended memory manager. Without it, nothing above 1MB was accessible to anything. `EMM386.EXE` with `NOEMS` enabled the Upper Memory Blocks without setting up expanded memory emulation, which would have wasted space if you didn't need it. `DOS=HIGH,UMB` moved part of DOS itself into the High Memory Area (the first 64KB above 1MB), freeing conventional memory for programs. `DEVICEHIGH` loaded drivers into Upper Memory instead of conventional memory, so every kilobyte you moved out of that 640KB space was a kilobyte a program could use instead.

`FILES` set how many files DOS could have open at once across all running programs. Set it too low and certain applications threw cryptic errors. Set it too high and it wasted memory on file control blocks that would never be used. `BUFFERS` allocated disk read-ahead buffers, which helped performance but also had a memory cost. `STACKS` controlled how many hardware interrupt stacks DOS maintained, usually left at the default unless something crashed under heavy interrupt load. The `SHELL` directive pointed to the command interpreter and let you set its environment size, which determined how much space was available for environment variables later.

Beyond memory management, `config.sys` was where device drivers loaded. DOS had no built-in CD-ROM support, for instance. If you had a CD-ROM drive, you needed a driver specific to that drive's manufacturer, loaded via `DEVICE=`, and then a separate program called `MSCDEX` in `autoexec.bat` to assign the drive a letter. If either piece was missing or misconfigured, the drive simply didn't exist as far as the system was concerned. Same...