Use FreeDOS to learn about computers

When I got my start in working with computers, “computers” were a very simple thing. The “personal computer” was still quite new: the Commodore PET, TRS-80, and Apple II had just come out in 1977. The IBM PC 5150 and DOS came out a few years later in 1981. My first computer was an Apple II clone, then the IBM PC. So my start with “computers” was loading a floppy into a drive and turning it on.

These days, “computers” are much more complicated. And because of that extra complexity, it’s more difficult to see what’s happening behind the scenes for basic activities like booting the computer. I think it’s easier to go back to a simpler system, learn how that works, and use that as a starting point to learn how more modern computers do their thing.

DOS boot-up

Let’s look at how the FreeDOS kernel boots up on a computer. There’s a bit more detail happening here, but I’ll stick to the high points so we can focus on the major steps:

First, the computer goes through a power-on self test, called a POST and it’s done through firmware. The POST tests the memory and checks if certain peripherals are attached to it. On some classic computers, you might see the computer “count up” the memory and display it on the screen—that’s the POST reporting the memory.

Then, the firmware needs to “hand off” the computer start-up process to the operating system. It can’t immediately jump to the operating system, because you can run lots of things on a PC. So instead, it looks for the next step in the process.

The POST checks for a small executable program called the master boot record, usually on the hard disk. The master boot record (called the MBR) is what actually loads the operating system. In the 1990s, you might have more than one operating system running on your computer, and a way to select which operating system to boot was done through a little menu when the computer started up. That menu program was stored in the master boot record.

The MBR has enough intelligence to figure out how to find the operating system for the computer. The MBR that loads FreeDOS knows to look for the KERNEL.SYS file, which is the FreeDOS kernel, and runs that.

The FreeDOS kernel has certain defaults built into it, so it can boot on its own from there. But users can customize those values and add other actions such as loading system drivers (usually a CD-ROM driver) by writing a configuration file called CONFIG.SYS in the root directory of the boot drive.

The FreeDOS kernel actually first looks for a file called FDCONFIG.SYS and if it’s not there, then it looks for CONFIG.SYS. The MS-DOS kernel only looks for CONFIG.SYS. We do it that way with the FreeDOS kernel so you can boot both MS-DOS and FreeDOS on the same hard drive: use CONFIG.SYS for your MS-DOS settings, and FDCONFIG.SYS for your FreeDOS configuration.

After the kernel starts up, it needs to let the user do things with the operating system. To do this, the kernel needs to load a shell program. By default, DOS systems like FreeDOS and MS-DOS use a program called COMMAND.COM, also in the root directory of the boot drive. But you can instead specify another shell program with the SHELL= line in your CONFIG.SYS or FDCONFIG.SYS file.

It can be helpful to have the shell start up with certain settings and run any programs that set up the system, such as setting a PATH variable to tell the shell where to look for other programs. You could type these commands in yourself, but it’s easier if the system can do that by itself. So at start-up, the shell reads a file called AUTOEXEC.BAT that contains a bunch of commands.

A neat feature in the FreeDOS COMMAND.COM is that you can tell it to look for a different file, using the SHELL= line in the CONFIG.SYS file. This makes it possible to use a different start-up file for FreeDOS than MS-DOS. For example, for the last several releases, we’ve used FDAUTO.BAT as the shell’s start-up file; you can see that setting in the CONFIG.SYS file. That way, MS-DOS only looks for AUTOEXEC.BAT but FreeDOS uses FDAUTO.BAT instead.

And that’s it! After the shell reads its start-up file, you will see the friendly > prompt, usually with a path like C:\>, so you can start typing commands.

Start simple, go from there

I like to use DOS as an example when teaching others about how computers work, because DOS is small enough and simple enough that you can see all of the “moving parts” and understand what they do. And once you understand how DOS works, you can start to understand more complex systems.

For example, Linux systems have more steps during the boot-up process, but essentially they follow the same general process: the computer powers on, it runs a firmware program (these days, that’s UEFI) that loads the next part of the operating system. The Linux kernel starts up, and loads a bunch of drivers (as kernel modules) and other things.

Linux is a multi-user system that has a lot of other things going on, so it’s hard to see the details if you don’t know what you’re seeing—but early in the start-up process, Linux runs a program that loads everything else. In earlier times, this program was called init and it used scripts to start any background processes (called daemons). Most modern Linux distributions instead use SystemD, which does things differently than init, but it still does the job of loading other programs.

Eventually, your Linux system boots to a login prompt. After typing your username and password, you get some kind of user interface. This is usually a graphical desktop like GNOME or KDE or Xfce, or another one. If you’re on a server, that’s probably just a command line prompt. For a command line prompt, you’re in a shell, and you can control what commands set up your initial environment by writing a file. If you use the Bash shell, that file is .bash_profile in your home directory. For non-login shells, the start-up file is called .bashrc.

So the process is more complicated with Linux, because there’s a lot more going on. But the basic steps are still there. And if you understand how a simple system like DOS starts up, you can understand more complex systems like Linux.