David Hayward reflects on the two most important files used in DOS
When we recall the DOS days, it’s often with a rose-tinted hue. However, while it was less complicated than a modern operating system, it wasn’t quite as straight forward as we often give it credit for. For one, getting a game to work often meant having to play around with the two most important files on a DOS-driven PC: Autoexec.bat and Config.sys. These files defined how the environment started up, what drivers were loaded, what the temp directory was, the Path statement and where other commands could be accessed.
Autoexec.bat loaded the drivers, set things like the Sound Blaster card IRQ and DMA values and offered the ability to load certain drivers into the high memory area and the UMB (Upper Memory Block) to free up valuable conventional memory (the first 640KB) for running of games and programs.
Config.sys was the main configuration file for DOS, and allowed you to assign certain values to device and memory parameters. You could specify disk buffers (loading them high with BUFFERSHIGH=), and load up drivers for HIMEM, EMM386, and ANSI.sys.
Compared to today, it sounds terribly complicated, but we got the hang of it – and in the end we could either own a selection of DOS boot floppy disks that served a certain purpose, such as high memory loading, more 640KB for a game, loading up the CD-Drive driver, and so on. Or we could create a long and elaborate set of files that loaded stuff up depending on what menu options we defined within the Autoexec.bat file.
The History
The Autoexec.bat and Config.sys files appeared around the DOS 2.0 stage, when the need for loading peripheral drivers became the norm. The PC was beginning to grow, as were the number of different uses for it.
It no longer belonged exclusively to the office; home users also had PCs and, as a result, peripheral makers started to expand their catalogue of products. The PC was also starting to become a formidable gaming platform, and with that came devices such as soundcards, joysticks, ever more powerful graphics cards, and so on.
With more devices now available, the conventional memory limit was starting to get a little tight. Soon, third party memory managers such as QEMM became available, which offered more available conventional memory by auto-analysing your Autoexec and Config files and creating its own version of each.
The Autoexec and Config files lasted all the way up to DOS version 7, for Windows 95, 98 and Windows ME. Although by then they were rapidly losing their ability to make any significant change to the way the system was defined at startup.
The Good
You could have a collection of boot states, that gave you more conventional memory, loaded up certain drivers, even some that auto-ran virus scanners and connected to a network for installing DOS and Windows 3.11 onto a client PC.
The Bad
They could get quite confusing, and you’d often end up wasting many hours trying to free up that extra 1KB of memory to get Star Trek: 25th Anniversary running.
Conclusion
Autoexec.bat and Config.sys once ruled the PC in a way that no other two files have ever managed since. They were the most powerful text files, and if you could master them then the operating system and the hardware within the PC was yours to command.
Did You Know?
• If you installed Windows 95 over DOS and Windows 3.11, then the Autoexec and Config files were auto renamed to allow dual booting into both environments.
• The Toshiba CD driver was smaller and used less memory than the Oakcdrom.sys driver loaded in Config.sys
• Smartdrv was one of the main issues with loading games. Although it worked well for disk caching for optical drives, and for loading up games quickly, it often conflicted with the game later on and chewed up a lot of conventional memory.
• CTMouse often worked better, and with less memory used when loaded high in Config.sys