REBOOT.C

A Turbo C Programming Project

by Bob Miller

Part I

I'll bet this has happened to you. Over time, you develop a
cozy working environment on your computer, based on your favorite
memory-resident programs and needed device drivers. You find it
convenient or necessary to have them loaded into your system when
you you boot up, by invoking them in your CONFIG.SYS and
AUTOEXEC.BAT files on your hard disk. (From here on out, I'll
refer to these two files collectively as the "autoexec files,"
for convenience.)
Now, this works fine as long as you use your computer for
the same sort of work. Sooner or later, though, you find that
you have to run some program which is incompatible with the cozy
environment you have been using. At the very least, the new
program may need some of the memory that you have tied up in
memory-resident programs. So, what do you do now?
Obviously you need to remove some of the memory resident
stuff. This means rebooting, but first you have to change the
autoexec files to prevent the stuff from being loaded in again.
If you are running a floppy-based system, or only need to do
this rebooting once, you can just put the modified autoexec files
on a floppy disk, and then reboot off the floppy. If you have a
hard disk and find that you're going to have to run the new
program a fair amount, there are a lot of reasons why booting off
of a number of different floppies will turn out to be a nuisance.
I kept running into this problem on a system at work which is
used by several people. After some experimentation, I hit on a
simple approach.
I have found it convenient to keep several sets of autoexec
files in the boot directory: each one represents a different
working environment, a different set of drivers and memory-
resident programs. To change from one working environment to
another, I simply recopy the autoexec files and reboot.
Let's take an example. On the computer at work, we often
write FORTRAN-77 programs to calculate and plot some curves.
This requires that some graphics drivers be loaded in at boot
time by CONFIG.SYS and initialized by running a program using
AUTOEXEC.BAT. At other times, we have to run a big microwave
circuit simulation program called Touchstone, which is so large
that it needs absolutely every scrap of our 640K of memory. If
the graphics drivers used by the FORTRAN-77 setup are in memory,
there's not enough free memory to run Touchstone.
My solution is to have several different sets of autoexec
files. The FORTRAN-77 files are called CONFIG.F77 and
AUTOEXEC.F77; these load and initialize the graphics drivers when
I boot up the FORTRAN working environment. The Touchstone files
are called CONFIG.TCH and AUTOEXEC.TCH; these only load in a
mouse driver needed by Touchstone, and then set up a directory
path.
To change to the FORTRAN-77 environment, I simply copy
CONFIG.F77 over CONFIG.SYS, then copy AUTOEXEC.F77 over
AUTOEXEC.BAT, then reboot. (Note that I still have CONFIG.F77 et
al for future use.) If I later want to run Touchstone, I copy
CONFIG.TCH over the present CONFIG.SYS, AUTOEXEC.TCH over
AUTOEXEC.BAT, and reboot again. If for some reason I don't know
or remember just which environment is loaded in at the moment, I
can just look at the present autoexec files in the root directory
of the hard disk to find out.
Now, recopying these autoexec files may still sound like
work to you, but I've written a program to do it automatically:
REBOOT.C, the subject of this series of articles. To run it, I
first go to the root directory of the hard disk. Then if I type
something like
C:\>REBOOT F77
it copies CONFIG.F77 over CONFIG.SYS, AUTOEXEC.F77 over
AUTOEXEC.BAT, then causes the computer to reboot. When the
computer does, the new autoexec files set up the FORTRAN-77
working environment properly.
If I can't remember the extensions of all the different
autoexec file sets I have, I can run REBOOT with no command line
arguments. It will then present me with a sorted list of
autoexec files, and allow me to pick the one I want:

C:\>reboot

REBOOT ver. TC2.20, 12/14/87 R. L. Miller

Copies \CONFIG.ext -> \CONFIG.SYS, \AUTOEXEC.ext -> \AUTOEXEC.BAT,
then reboots computer.
CONFIG files AUTOEXEC files
============ ==============

CONFIG.F77 AUTOEXEC.F77
CONFIG.PCL AUTOEXEC.PCL
CONFIG.TCH AUTOEXEC.TCH


Enter the file extension 'ext' of the CONFIG and AUTOEXEC files
to copy over CONFIG.SYS & AUTOEXEC.BAT: f77

In function reboot()...

I give it the extension I want by typing "f77". It then recopies
the autoexec files as described above.

How it Works

REBOOT.C turned out to be a good vehicle for showing the
strengths and weaknesses of Turbo C. These became immediately
apparent to me as I translated the program from an earlier
version I had written in MIX C.
We'll begin analyzing the program this month, then hopefully
explain the rest next month and present a complete source
listing. Along the way, we'll get a chance to talk about lots of
C concepts, like pointers, arrays, structures, and so forth.
Figure 1 shows the main program. Note that it starts with
some global variable declarations. By defining these variables
here in the lisitng, outside of the main procedure or any
function, we guarantee these variables to be accessable to any
part of the program.
The line
#define FILEMAX 20
really doesn't define a variable, but a kind of constant.
FILEMAX is the maximum number of CONFIG or AUTOEXEC files that
our program can handle. Using the name FILEMAX instead of the
number 20 at various places in the program, such as in the
declaration of the character arrays cfig and aexec a few lines
down makes the program a bit easier to understand. These two
dimensional arrays have room for FILEMAX (=20) strings, each 13
characters long. The 13 characters in each string leaves enough
room for the 12 (count em!) characters in a filename like
AUTOEXEC.BAT, plus one more character for the null (=00H)
character that C requires to be the terminator for any string.
All character arrays in C have to be dimensioned 1 character
larger than the expected maximum string length, to leave room for
the terminator.
The main() function has two arguments, which have to do with
command line arguments. The integer variable argc tells us how
many arguments (words) appeared on the DOS command line that
called up this program. If we had typed "REBOOT F77", argc would
be 2.
The character array argv deals with the actual command line
arguments themselves. In the above example, the first array
element argv[0] would contain the word "REBOOT", while argv[1]
would contain "F77", the file extension we want. We have
declared argv as
char **argv;
that is, "a pointer to a pointer to a character." This is a
convenient way of declaring that argv is an array of strings
whose size we don't know yet, nor do we even know how many
strings there are until we actually run the program. For an
explanation of that, see any good textbook on C.
Inside the curly brackets that define the code for main(),
we have a few more declarations: these are local to main().
Since C expects any function to return an integer value unless
you declare otherwise, the four functions catalog(), select(),
copyem(), and reboot() have to be declared as "void" because they
don't return any value at all.
The main() program starts by printing a small signon message
explaining what it is and what it does. This is one of my pet
peeves: there is nothing more frustrating than finding a program
with no documentation that doesn't even tell you what it's going
to do when you try to run it. Even if you write a program for
your own use, you'll find that 6 months or more later, you will
have forgotten a lot about it. Every program should have a
signon message of some sort.
The rest of the code of main() is the picture of top-down
structured simplicity, because all of the real work is done by
the 4 functions mentioned above, and the names of these pretty
well describe what they do.
If argc is less than 2, it means that we had just typed
"REBOOT" on the DOS prompt. In this case, function catalog() is
called, which looks at the disk directory and finds all the
CONFIG.* and AUTOEXEC.* files. It stores these names in the
arrays cfig and aexec, then prints them on the screen in sorted
order. Next, the select() function asks for and gets the
extension (like "F77") of the ones we want to use. The copyem()
function then copies these files over CONFIG.SYS and
AUTOEXEC.BAT. Finally, the reboot() function actually reboots
the computer. Unlike most C function, reboot() never really
returns control.
If argc is equal to 2, that means we must have supplied an
extension by typing something like "REBOOT F77", so we just need
to copy the second word "F77", contained in argv[1], to the
global string variable ext. Then we call copyem() and reboot()
in turn.
If for some reason there are more than 2 command line
arguments, the user must be really confused, so we just print out
a polite message indicating what he should have typed. In this
case, we do not reboot or copy any files, we just return to the
operating system and let the user try again.


UPDATE FOR VERSION TC2.20:
=========================

The above documentation appeared in the August, 1987 issue
of the CACHE REGISTER, the newsletter of the Chicago Area
Computer Hobbyist's Exchange. The current version of REBOOT,
Version TC2.20, no longer requires you to log into the root
directory: you may operate it from any subdirectory, and the
program will look up the autoexec files of the logged in drive,
copy them as directed, and do a warm boot.