/Technology

## 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: ``` DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE NOEMS DOS=HIGH,UMB DEVICEHIGH=C:\DOS\ANSI.SYS DEVICEHIGH=C:\MOUSE\MOUSE.SYS FILES=40 BUFFERS=15 STACKS=9,256 SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:512 /P ``` `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 story for sound cards, network adapters, and various other peripherals. Anything that needed to intercept hardware interrupts had to register itself during this early boot phase. `autoexec.bat` came after. It was a standard DOS batch file that happened to run automatically after `config.sys` finished. A fairly typical one: ```batch @ECHO OFF PROMPT $P$G PATH C:\DOS;C:\WINDOWS;C:\UTILS;C:\MOUSE SET TEMP=C:\TEMP SET TMP=C:\TEMP LH C:\DOS\MSCDEX.EXE /D:MSCD001 /L:D LH C:\MOUSE\MOUSE.COM LH C:\DOS\SMARTDRV.EXE 2048 512 C:\DOS\DOSKEY ``` `@ECHO OFF` stopped DOS from printing each command as it ran, so the boot output looked cleaner. `PROMPT $P$G` changed the default prompt from `A>` to `C:\>`, showing you which directory you were actually in, which sounds trivial until you've navigated DOS without it. `PATH` told DOS where to look for executables, so you could type a program name from anywhere instead of having to navigate to its exact directory first. `SET TEMP` and `SET TMP` pointed applications to a directory for temporary files. Ignore this and some programs would write temp files to the root of C:, or just fail. `LH` (LoadHigh) attempted to place the following program into Upper Memory rather than conventional memory, which was the same goal as `DEVICEHIGH` in `config.sys`, just applied to executable programs instead of drivers. `SMARTDRV` was a disk cache that kept frequently accessed data in memory, which made a noticeable difference on the slower drives of the time. `DOSKEY` loaded command history so you could recall previous commands with the arrow keys. Some `autoexec.bat` files launched programs directly: a menu system, a BBS client, or in shared household machines, something that bypassed the prompt entirely and put a friendlier interface in front of whoever was using the computer. --- ## The Memory Problem in Practice Gaming is where the 640KB constraint became most visible. Games in the early 1990s pushed hardware hard, and they needed as much conventional memory as possible. Different titles had different requirements. Some needed expanded memory, some needed extended, some needed a specific combination. If you had the wrong setup, the game either crashed on launch or showed an error message. The solution many people used was the multi-boot menu introduced in DOS 6.0, which let `config.sys` branch based on a keypress at startup: ``` [MENU] MENUITEM=GAME, Load for games MENUITEM=NORMAL, Normal startup [GAME] DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE 2048 RAM [NORMAL] DEVICE=C:\DOS\HIMEM.SYS DEVICE=C:\DOS\EMM386.EXE NOEMS ``` You pressed a number when the machine started, and it loaded a different configuration depending on what you planned to do. It worked, though calling it elegant would be generous. Third-party tools like QEMM and 386MAX went further. They'd scan the system during boot, figure out where drivers could be placed in upper memory, and optimize load order automatically to maximize free conventional memory. People compared notes on how many KB they'd managed to free up, which in retrospect sounds almost comically narrow, but at the time those kilobytes genuinely determined whether software ran or didn't. --- ## Why It Was Important, and Where It Fell Short The most useful thing about this system was its transparency. Every driver that loaded, every environment variable that was set, every resident program: all of it was visible in two plain text files. There was no registry, no background service list, no hidden startup folder that you had to know to look for. If something unexpected was happening on your system, you had two files to check and they told you most of what you needed to know. It was also lightweight in a way that's hard to appreciate now. A DOS machine with a reasonable `config.sys` booted in a few seconds. There were no background processes running that you hadn't put there yourself. In most cases, the system did exactly what those files said, nothing more. The downside was the fragility. A typo in a driver path meant that driver didn't load, sometimes silently, or with an error that didn't obviously point to the problem. Missing a semicolon or getting a parameter wrong could produce behavior that took a while to trace back to its source. And if `config.sys` had a serious enough error, the machine wouldn't finish booting, which meant you needed either a boot floppy or enough familiarity with DOS to intervene at the command prompt. Most home users didn't have either option ready. The 640KB ceiling was the deeper problem, and no amount of configuration could actually eliminate it. You could only manage around its edges. The energy that went into memory optimization was real and sometimes impressive, but it was fundamentally effort spent working around an architectural limitation rather than solving anything. That ceiling was also why Windows 95 moving to a model that didn't rely on DOS for memory management was such a significant shift, even if it took years for the full transition to play out. Hardware conflicts were another constant. IRQ and DMA assignments were manual. Installing a new sound card might conflict with an existing network card at the hardware level, and the only way to resolve it was to understand what interrupts each device was using and configure them not to overlap. `config.sys` sometimes played a role here, but the issue was as much about physical hardware settings as software configuration. --- ## What Survives Today `config.sys` effectively became irrelevant with Windows 95. Windows managed driver loading differently and gradually took over the entire boot process. By the time Windows XP came along, DOS wasn't the foundation of the OS anymore and neither file served any meaningful function. On modern Windows, `autoexec.bat` is still technically read at startup for legacy compatibility, but almost nothing it contains has any effect. You're unlikely to find either file at all on a current machine. The underlying concepts, though, didn't go anywhere. Environment variables still work the same way. `PATH` still tells the OS where to find executables, it's just set through system settings or shell profiles rather than a batch file. Device drivers are still separate software components that mediate between the OS and hardware; they're installed through signed packages now and managed by the kernel, but the role is the same. On Linux, `.bashrc` and `.bash_profile` serve almost exactly the same purpose as `autoexec.bat`: setting environment variables, configuring the shell prompt, loading extensions, running startup scripts. Anyone who spent time tuning `autoexec.bat` usually finds Linux shell initialization files immediately recognizable, which makes sense because they're solving the same problem. The place where these files are still actively used is in DOS emulation. DOSBox reads both files from its virtual drive during the emulated boot sequence. Running an old game through DOSBox often means writing a short `autoexec.bat` to mount the right directories, set up the sound configuration, and launch the executable. The syntax is the same as it was thirty years ago. --- ## Looking Back at It These files mattered because they were the entire interface between you and a machine that would do nothing useful without explicit instruction. Getting them right meant the system ran well. Getting them wrong had immediate consequences. There wasn't much abstraction in between. That directness had costs. It demanded a level of technical knowledge from users that most people reasonably didn't have, and errors were easy to make and sometimes hard to recover from. But it also meant that people who learned it understood something concrete about how their system actually worked. Not as an abstract principle, but in the specific, practical sense of knowing which lines in which files controlled which behavior. Modern systems handle most of this automatically and that's generally the right trade. But it does mean that the mental model most people have of their computer is now much further removed from what the machine is actually doing. Whether that matters depends on what you're trying to do with it.