Mark Levy and Gordon Thomas
Every semester, our computer writing lab has several hundred new users; most of these users first-year students with no previous computer experience. Few of those who have had experience know much about the DOS operating system; consequently, they have little idea of what it means to boot the system, change the logged disk drive, load a program, and so forth. We asked ourselves whether we were in the business of teaching writing or of teaching students about microcomputers or both. It is true that this last answer is certainly a reasonable one: "computer literacy" has begun to seem almost as important as more conventional literacy. But, because our students learn about computers during their freshman writing course, we decided that a better answer to this question was the first one: the teaching of writing was our primary purpose, and any learning about computers for their own sake should be as unobtrusive as possible.
With this starting point, we were faced with the simple problem of making our computers accessible to hundreds of new users.
p. 56
We were not using user-friendly Macintoshes; instead, we had 50 DEC Rainbows, which use MS-DOS as an operating system. From the user's point of view, there are virtually no differences between MS-DOS and PC-DOS; in this respect, the Rainbows are very similar to IBM-PCs. Using batch files and other commands that DOS (Versions 2.1 and higher) offers any user, we devised a menu system that provides a virtually fool-proof method for novice users to access the word-processing program, run a style analysis program, back up their files, and perform routine disk maintenance. We would like to describe here how such a menu system can be constructed by anyone who has any version of DOS higher than 2.1. (1) In this article, we are assuming that you know many DOS resident commands, but are unfamiliar with making your own batch files, aside from a short AUTOEXEC.BAT file.
DOS allows you to build any menu system you wish because of several features: you can send any text file you wish to the screen, and you can change the prompt in DOS to say anything you wish. The cryptic prompts, "A>" and "B>", are not much help to a first-time user. Furthermore, DOS allows you to run a long series of commands automatically without displaying the commands themselves on the screen, and these series of commands can be linked to other series of commands so that novice users can easily perform sophisticated tasks.
Files that contain such a series of commands are called batch files, which are simply ASCII text files (i.e., they must not contain any special control characters that word-processing programs often use to format text on the screen) that you can create with your word processor. (2) Each command occupies a separate line in the batch file. The batch file enters the commands in the same way that the users would enter them from the keyboard. For example, suppose you wanted your computer to set the path command in a useful way (3), ask you for the time and date, switch to the B Drive, and load your word processor. The short file shown in Figure 1 would accomplish all of the following objectives:
p. 57
Commands Explanation of What Command Does path a:\:b:\ Sets the "path" (see Note 3.). date Prompts you to enter the current date. time Prompts you to enter the current time. b: Switches you to the B Drive. wp Loads the word-processing program (Word Perfect in this case). Figure 1: Batch File for Setting Path Command
Batch files always have .BAT as their file type (the three-letter suffix on the end). If the name of the above file was START.BAT, you could invoke it by typing START and pressing RETURN. A better name for such a file, though, would be AUTOEXEC.BAT because giving a batch file this special name causes it to run automatically when the computer is turned on. The menu system that we describe here is composed of a series of batch files that interact with each other.
Before you start constructing such a system, it is wise to draw up a list of what you want the students to be able to accomplish. Then, you should consider what you want the whole system to look like from the students' points of view. Ideally, the tasks should have easy-to-understand names that may have little to do with the actual DOS commands needed to accomplish these tasks.
For example, in our first system, we wanted the students to be able to do three main things: load the word-processing program, run the style analysis program, and make back-up copies of their disks. Consequently, we decided that the first thing a student would see was a menu with these three choices. To make the computer seem more polite, and at the same time somewhat reserved (after all, it's not a friend of the student), we settled on the phrase "What would you like to do?" as a prompt. This phrase seemed better than an abrupt "Command:" or the cryptic "B>".
p. 58
We also wanted the students' disks to reflect accurate dates and times of their papers, but we did not want them to have to enter the date and time because, in our experience, this task was unnecessarily confusing to novice users. Furthermore, the constant starting and restarting that would take place during the day in the lab seemed like an unnecessary strain on the Rainbows' rather delicate disk drives. For these reasons, we decided to keep the computers on all the time; in fact, now we never turn them off except during semester break. The only danger in leaving the computer on is that letters can become etched in the screen. To alleviate this problem, the Rainbows have a feature that automatically turns off the screen when there has been no keyboard activity for 30 minutes; on an IBM-PC, the students could be taught to turn down the contrast when they were finished working. Leaving the computers on seemed wasteful to us, until we remembered that a refrigerator runs all the time, and it has more moving parts than a computer. A better example is a stereo receiver or VCR which can run all the time without damage.
The first screen (see Figure 2) that the students would see is brought up by using an elaborate AUTOEXEC.BAT file (more on this later).
University of Idaho Department of English Microcomputer Laboratory MAIN MENU 1) Go to the Word Processor 2) Do a Style Analysis 3) Make a Back Up Copy of Your File DIRECTIONS: Press the number corresponding to your choice and then RETURN. What Would You Like to Do? _ Figure 2: Appearance of the Main Menu
p. 59
The cursor is located two spaces after the question. This screen actually consists of two parts: everything but the last question is an ordinary text file that we created using a word processor; the text file has been sent to the screen using the DOS TYPE command. The question is actually a modified version of the prompt; instead of "A>" or "B>", we changed the prompt to the question you see above. Of course the students see this text and the prompt underneath as being the same screen. Even those who have some familiarity with DOS do not realize that they are really in DOS at this point.
When students enter "1" to load the word processor, they actually run a batch file, which is named 1.BAT. The contents of that file are listed below (Figure 3).
Command Explanation of What Command Does echo off Prevents commands from being displayed on the screen. cls Clears the screen. b: Switches over to B drive. echo Shows which operation is running while the word processor is loading fw %l Loads the word processor. cls Clears the screen when the student has finished word processing. e: Switches over to the memory drive (more on this later). type main.scr Sends the MAIN.SCR to the screen displaying the main menu Figure 3: 1.BAT
p. 60
These commands (Figure 3) require some explanation. "Echo off" is a DOS command that is useful only in a batch file. This command prevents subsequent batch-file commands from being displayed on the screen as they are executed; from the student's point of view, this keeps most cryptic messages from appearing as the program works. "CLS" clears the screen; when used with the "echo off" command, this pair of commands almost instantly clears the screen and prevents odd things from being written as the batch file progresses.
This batch file then switches the user to the B Drive (in case they are not there already) and puts the message "Loading the Word Processor . . ." at the top of the screen. This message remains there for the few seconds it takes the program to load. The next command loads FINALWORD II, the particular word processor we were using at that time; any command could occur right here.
When the student exits from the program, the batch file resumes and switches them over to the E Drive, which is a memory disk (more on this later). The batch file then "types" the file MAIN.SCR to the screen; MAIN.SCR is the text file that was displayed in Figure 1. Thus, for a normal word-processing session the student begins and ends with the same screen.
We used a more elaborate technique in getting the students to back up their disks. If students choose Option 3 from the Main Menu by pressing "3" and then RETURN, they cause the following series of commands to be given automatically (see Figure 4):
echo off cls e: type e: copy.scr Figure 4: 3.BAT
p. 61
This file would clear the screen and display the following message (Figure 5):
TO MAKE A BACK-UP
1) Replace the System Disk in Drive A with your Back-Up Disk.
2) Type Backup, a space, the name of the file you want to back-up
and press <Return>
Example: What Would You Like to Do? BACKUP filename <Return>
If you got here by mistake type OUT and press the Return key.
What Would You Like to Do?
Figure 5: COPY.SCR
The next screen shows a somewhat different method of making the menu. It allows the student to run batch files called BACKUP.BAT and OUT.BAT. OUT.BAT is the simplest of these two files (see Figure 6):
echo off
cls
e:
type main.scr
Figure 6: OUT.BAT
p. 62
The OUT command simply returns the student to the MAIN MENU. BACKUP.BAT is more complex (see Figure 7).
echo off cls IF NOT EXIST b:%1 goto error copy b:%1 a: cls echo The file % 1 has been copied to the diskette in DRIVE A:. echo Please remove your BACK-UP disk and place the SYSTEM disk in DRIVE A: echo pause goto end :error cls e: type e:error.scr dir b:/w echo echo echo off :end b: echo off cls e: type e:main.scr Figure 7: BACKUP.BAT
BACKUP.BAT first looks for the file that the student has asked to copy. After checking to be sure that the file really exists, BACKUP.BAT copies the file to the disk in Drive A and displays the message in Figure 8.
p. 63
The file FILENAME has been copied to the diskette in DRIVE A: Please remove your BACK-UP disk and place the SYSTEM disk in DRIVE A: Figure 8: Response Message from BACKUP.BAT
The system then pauses, which causes the message "Strike a key when ready . . ." to display. When the student presses a key to continue, the batch file causes the MAIN.SCR file to be displayed (see Figure 2).
This batch file has a refinement built into it: if it can't find the student's file (probably because the student did not type in the file name correctly), the commands jump down to the ":error" line, and the batch file continues from there. The following screen is then displayed (see Figure 9):
Sorry, I can't seem to find the file you wanted. Are you sure you typed it correctly? Maybe you never saved it to disk. If you don't see it on the following list you should go back to FinalWord and save it to your working disk by pressing the SAVE FILE key and giving the file name you want. Here are the files you have saved to disk so far: Figure 9: ERROR.SCR
Under this message will be displayed a directory of the student's disk followed by the directory of the B Drive and the message "Strike a key when ready ...." When the students press any key, they are immediately returned to the Main Menu (MAIN.SCR). The DOS command "copy b:filename a:" would of course accomplish the same thing more efficiently, but the process that we
p. 64
outline here significantly reduces the errors that inexperienced users tend to make, errors such as copying the backup file onto the newer version, instead of the other way around. This process also eliminates the need to teach the students how to use the COPY command.
When starting the computers, the MAIN MENU can be displayed by including those commands as part of the AUTOEXEC.BAT file. Figure 10 shows a simple version of that file.
echo off path a:\;b:\ cls date time cls type e:main.scr prompt What Would You Like To Do? Figure 10: AUTOEXEC.BAT
AUTOEXEC.BAT prompts the user (who at this point is usually a lab monitor) for the date and time; it then clears the screen and displays the file MAIN.SCR. Finally, it changes the prompt from "A>" or "B>" to "What Would You Like To Do?"
One final refinement you can make to this whole system is to change the speed at which it operates. You can put all these batch files on the students' disks, but they cause delays of a few seconds as the computer searches for the file every time it tries to do a different task. The solution to this problem is to create a "virtual disk" or memory drive by reserving a portion of your computer's memory so that it can operate as a third disk drive. This drive is "virtual" because it only exists electronically; from your point of view, though, it functions exactly like a third drive which you get to by entering "c:" or "e:" and pressing Return. You can copy and save files to this disk; the main advantage of the virtual drive is that programs which have been copied to the memory drive run much
p. 65
faster than they do when you use a normal floppy disk drive or even a hard disk (4). If you copy all the batch files you'll be using onto this drive, they will run so fast that the commands a student gives using a menu system will be executed as quickly as commands sent directly to the operating system.
With a memory drive, you can put the batch files for the menu system on the students' disks and then have them copied over to the memory disk when the first student boots up in the morning. AUTOEXEC.BAT, which is listed below (see Figure 11), would accomplish such a task:
echo off path c:\;a:\:b:\ cls date time cls echo Place your disk in drive B and close the door to the drive. pause copy b:*.* c: cls type c:main.scr prompt What Would You Like To Do? Figure 11: AUTOEXEC.BAT Second Version
AUTOEXEC.BAT assumes that the batch files are on the students' disks (Drive B) and that the memory disk is called C (as it is with most IBM compatibles), rather than E (as it is with DEC Rainbows).
Creating a menu system for your students to access your available software should not require sophisticated programming skills, or the purchase of additional software. With the exception of a RAM driver, DOS has all the commands that you need built right in; it is only necessary to write the appropriate batch files and short text files that will serve as screen displays. Although a menu system does not encourage the students to learn the DOS operating
p. 66
system commands, it does make it possible for novice users to perform computer tasks that are ordinarily beyond their skills.
We have only described three uses that such a menu system might have. Usually, our menu systems have included a total of about 30 files--text files that show what the various screens do and batch files that actually carry out the commands and change the various screens. With such a menu system in operation, it is a relatively simple matter, after the first week of classes, for a single undergraduate student working as a lab monitor to oversee as many as thirty or forty novice users who are performing fairly sophisticated computer tasks. More importantly, we have made our system accessible to students. Instead of teaching relatively esoteric computer concepts, we can concentrate on teaching writing.
(1) For a more elaborate (and more general) explanation of the techniques we describe here, see Wolverton, especially Chapters 13,14, and 15. For a more abbreviated version of some of these same techniques, see Koelling. (2) You can produce ASCII files by using WORDSTAR in the non-document mode, by saving word perfect files with the "Text In/ Out" key, or by creating the file with a line editor, such as EDLIN (or even, for short files, COPY). (3) Simply put, the "path" is the list of disk drives that DOS searches to locate command files. When you have set the path to search on both the A and B Drives, you can give the command to load or run a program from, say, the B Drive: when the DOS does not find that program on the disk in the B drive, it will automatically look for it on the disk in the A drive.
p. 67
(4) Creating a memory drive is not difficult, but it does require a fair amount of memory (at least 256 K) and a piece of software usually called a "ram driver." DOS 2.10 does not come with a ram driver, but DOS 2.11 (for the DEC Rainbow) does, as does DOS 3.0 or higher. You can get a RAM driver from public domain software sources. There are many kinds of RAM drivers; they usually have names like RAMDRIVE.SYS, MEMDISK.SYS, MDRIVE.SYS, or VDISK.SYS (in DOS 3.2).
RAM drivers usually have instructions for how to set them up; they generally work as follows: you need another small ASCII file that you can create using a word processor called CONFIG.SYS. This file is needed to tell your operating system the name of the ram driver. Usually, this file needs to consist of only one line:
"device=RAMDRIVE.SYS 32."
You would substitute the name of your ram driver for "RAMDRIVE.SYS." The "32," which could be any number, tells the operating system how large a memory disk to make. When the DOS boots up, it looks for the file CONFIG.SYS and then automatically sets up your system according to what you have specified there (setting up memory drives is only one of the ways you can configure your system using CONFIG.SYS; see your DOS manual for other things it can do).
The larger a memory drive, the less memory your computer will have for other programs. For example, some of our computers have only 256 K of memory. The largest memory disk we can make on these computers and still have enough memory to run the word processor is 32 K.
Koelling, R. (1987, January-February-March). Customizing IBM's Disk Operating System for writing labs. ACE Newsletter, pp. 6-7.
Wolverton, V. ( 1984). Running MS DOS. Bellevue, WA: Microsoft Press.