BATCH FILE TIPS AND UTILITIES The First in a Series by Mitchell A. Hoselton SERIES INTRODUCTION This is a tutorial series about techniques for writing efficient, powerful and, possibly, elegant batch files. It is not a series subtitled "The Joy of Batch File Programming" or "Zen and the Art of Batch File Programming." It is an introduction to practical tips and utilities that make writing batch files more useful, interesting, and rewarding. Too most PC users the term "batch file" means AUTOEXEC.BAT, period. Some think that utilities are only for other people. Unfortunately, they are missing some golden opportunities to make their computing lives a lot easier. There is more to using batch files than AUTOEXEC.BAT and more to AUTOEXEC.BAT than setting the DATE, TIME, PATH, and PROMPT. If you let them, batch files will help you manage all your DOS computing chores. On my C: drive I have about 100 batch files occupying 110 Kbytes. The largest are several Kbytes in size. I've written most of them myself. The DOS prompt hardly ever appears, and then only when I request it. Most of the batch files are inter-linked so each one can be selected from a menu created by another batch file. Many of them print menus on the screen; all the menus respond to single letter keyboard selections. These batch files launch all my important applications and most of the minor ones. There is one overriding reason for writing so many batch files. They save time. Every time I use one, I recoup a little of the time spent writing it. By now I'm certain to have saved more time than I ever spent writing all those batch files. Once an application is successfully launched with a batch file, its name, its drive and directory, its command line switches and all the set up details can usually be forgotten. From then on the batch file name is all you need to remember. Since one batch file can launch many others, and since AUTOEXEC.BAT can launch the first one for you, there may not be too many batch file names to remember either. The batch file control language (BFCL, for short) built into DOS provides only a few simple programming tools. The key to writing useful batch files is, therefore, largely a matter of hard work and good luck. It takes work to learn the intricacies of the BFCL. It takes even more time to develop your own library of tips, tricks and techniques to get the most out of the BFCL. It takes luck to find the utilities that fill in the programming gaps DOS created. The idea behind this series is to take some of the work out of writing batch files and most of the luck out of finding the utilities you need to supplement the BFCL. It will be your introduction to and your resource for the most useful programming tips and utility routines available. The focus in this series is on enhancing batch file programming options, flow control features and programming sophistication. No batch file related topic will be excluded. This series will, over time, provide beginning level coverage for all the batch file programming commands. It will also cover tips and suggestions that experienced programmers can use and appreciate. It will even include tips that push the BFCL to the limits of its capability. Anyone who has written a batch file will know something about the limitations of the BFCL. Using all the tricks in the book will not make it a great programming language. To get a quantum leap in batch file performance requires adding new features to the BFCL. This is where the batch file utilities come in. Microsoft won't provide them, but batch file programmers can still turn to third party utility routines to expand their programming options. These articles should help programmers at all levels overcome some of the worst limitations of the BFCL. Everyone should find a new tip, trick or utility to use in their batch files. The various articles will demonstrate to beginners the full range of options that batch files can provide for them. The series should motivate them to start writing batch files. The series will help experienced programmers improve their batch files and introduce them to utilities they may not have seen before. THE SOURCES So where does all this information come from? Some tips and ideas are rediscovered by batch file programmers of every generation. Some of the tips come from books. The best ones come from computer magazines; PC Magazine and PC/Computing are the two best sources. Anyone who wants to develop a personal library of batch file tips and utilities should scour these and other computer magazines for a steady supply of good ideas. Many utility routines are public domain or shareware and are often available from bulletin boards or discount software houses. Many are available in libraries of programs accessible on CompuServe and from other on-line database services. PC Magazine operates the service called PC MagNet. I've been clipping and saving items from every source at my disposal since before I bought my first PC. Some of the utilities mentioned in my files are shareware, some are public domain and some are commercial programs sold by software vendors. Some of them are available on Disk-of-the-Month diskettes sold by the North Texas PC User's Group. The important criterion for inclusion in this series is not the source. What really counts is, "How can this utility help me write better batch files?" THE SERIES STANDARD PC SYSTEM Unless otherwise specified, articles in this series assume a standard PC system consisting of a 386 compatible PC with at least 2 megabytes of memory, two floppy disk drives and one physical hard disk. The hard disk has two or more partitions. The DOS partition (C:) has DOS 5.0 installed and it is the active partition. A printer, if required, will be a parallel device connected to PRN. A modem, if required, is on COM1. DOS batch files work on all PCs with all modern versions of DOS. The details change with each DOS version, however. This series is primarily, but not exclusively, limited to covering DOS 5.0. Unless otherwise specified, DOS means DOS 5.0. BOOTING UP THE SYSTEM This story starts at the beginning; in fact, it starts at the point where you turn on the PC's power switch. That is the first step of the PC boot cycle. The remainder of this article covers all the other steps that occur before the DOS prompt finally appears on the screen. That may not sound like much territory to cover. However, a lot happens in the first few seconds after the computer powers-on or reboots. Every programmer should have an appreciation and a general understanding of what happens inside the computer during all phases of its operation. That is even true for batch file programmers. Understanding how the PC and DOS interact during the boot process makes it easier to understand some of what happens while batch files are executing. It takes only a few seconds between power-on and the execution of the first line in CONFIG.SYS. Nevertheless, all the important actions undertaken by the hardware without the benefit of operating system control occur in those first few seconds. DOS takes its first critical steps in those few seconds. There is even time for the most unusual utility I've ever used to take control of the PC during those few seconds. I'll introduce you to MBOOT a little later. The boot process was described in the May 1991 edition of PC/Computing, more or less, along the following lines: 1) Turn on the PC. At power-on, the CPU clears its data registers and resets the program counter register to F000h. The "h" means it is a hexadecimal number. The first megabyte of PC memory consists of the segment addresses from 0000h to FFFFh, inclusive. F000h is the permanent memory address of the first few instructions of the boot program stored on the ROM BIOS chips. (In hexadecimal notation the numbers 0 to 9 and the letters A to F are used to represent the digits zero to fifteen. The Digits in different positions are multiplied by integer powers of sixteen instead of the integer powers of ten used in decimal notation. Here is a translation of the number 3AFh to its decimal equivalent. 3AFh = (3*16^2) + (10*16) + 15 = 943 Hexadecimal notation is convenient because it provides a compact form for expressing the binary numbers that the computer uses internally.) 2) The CPU starts processing the ROM BIOS boot program which in turn runs the Power-On-Self-Test (POST for short). The POST begins by testing for memory malfunctions. The POST was described in some detail in the February 13, 1990 edition of PC Magazine. 3) The POST checks that the input/output devices are working properly. These tests look at such devices as the keyboard, the video card and the hard and floppy disk drives. The POST tells the CPU to read the CMOS memory area and then determines if the devices are where the CMOS says they should be. (CMOS memory is maintained by a battery after the computer is turned off. CMOS memory contains data about the amount of memory, the clock, the diskette and hard disk drives, the display type and the keyboard.) The POST beeps one time after it finishes. 4) The ROM BIOS boot program checks for a formatted diskette in drive A:. On a series standard PC system the diskette drive is usually empty. The ROM BIOS boot program checks next for an active formatted partition on the hard disk. If neither a formatted diskette nor an active formatted partition exists, then the ROM BIOS boot program displays an error message and stops. 5) The ROM BIOS boot program loads a special program called the boot sector or the boot record from the diskette or the active hard disk partition into memory and executes it. This is called bootstrapping. The boot sector resides in the first physical disk sector of every diskette and hard disk partition formatted by the DOS operating system. 6a) After the boot sector loads into memory, it takes over from the ROM BIOS boot program. As soon as the ROM BIOS boot program initiates execution of the boot sector, DOS gets its first opportunity to control the boot process. Whoever writes the boot sector, controls the boot process from this point forward. From now on, everything is software controlled. The hardware is available as a tool for the software to use, nothing more. The user can change the boot sector, for example, by changing the PC disk operating system. Changing from one DOS version to another, from MS-DOS to DR DOS, from DOS to OS/2 or XENIX usually changes the boot sector, if only slightly. Most of us should leave writing new boot sectors to Microsoft or Digital Research or IBM. Making the slightest change to the boot sector is always dangerous. Douglas Boling may be one of those rare individuals who can get away with a major rewrite of the boot sector. What he did is amazing. What follows is definitely not for novice users or the idly curious. Unless the hard disk has a current complete back up, even the desperately needy should not attempt to install or use the following utility. MULTIBOOT - USING FOUR OPERATING SYSTEMS FROM ONE HARD DISK Another way that users can change the boot sector is by installing the utility known as MBOOT (short for MultiBOOT). Douglas Boling wrote MBOOT. He described it in the February 26, 1991 edition of PC Magazine. A copy of the program can be downloaded from PC MagNet. (See any issue of PC Magazine for instructions on accessing PC MagNet.) The Programmers Shop sells copies of MBOOT at (800) 421-8006 for $60. Bolt Systems publishes MBOOT. It requires DOS versions 3.0 or higher and claims it is compatible with OS/2. A copy of the PC Magazine article or the MBOOT manual and careful attention to all the instructions are essential prerequisites for safely installing and using MBOOT. MBOOT first saves a copy and then rewrites the boot sector on the C: drive. It modifies the boot record so that when booting from C:, the boot sector loads and executes additional non-DOS code stored in a new MBOOT file. The new MBOOT code pops up a menu of installed operating systems. The user can install up to four operating systems in MBOOT. The user selects one of the four from the MBOOT menu, or accepts the default operating system, each time the computer boots-up. During the DOS 5 Beta test program, I used MBOOT to ease the chore of moving between DOS 3.3 and a sometimes unreliable beta version of DOS 5. Actually, MBOOT kept two installed versions of DOS 5. One version loaded DOS 5 HIGH and the other loaded DOS 5 LOW. The system was easy to reboot after a crash by selecting the DOS 3.3 version from the MBOOT menu. It never was necessary to use the bootable floppy disks I kept available for emergencies (I know they're around here somewhere). I did not even have to decide, until after the MBOOT menu appeared, which operating system to select. MBOOT reserves enough clusters at the beginning of the data area on the active DOS partition to hold the DOS system files. After the user chooses an operating system from the menu, MBOOT loads the correct system files into that first group of clusters. (Note: Before the appearance of DOS 5.0, the two system files were always located in consecutive clusters at the beginning of the data storage area. MBOOT handles the delicate task of swapping the system files for each installed operating system into and out of these reserved clusters. Starting with DOS 5.0, Microsoft no longer cares if the system files are in consecutive clusters. MBOOT does care, however. It will crash if the DOS 5.0 system files get broken into non-consecutive clusters.) The current system files may be small enough that they do not occupy all the clusters that MBOOT is reserving. If so, MBOOT marks any extra clusters in its reserved pool as bad. Other programs will not try to store data in any cluster marked bad. The current system files might be larger than the system files of the prior operating system. In that case, MBOOT will mark a few more clusters from its reserved pool as good. That makes room for the larger system files of the incoming DOS version. To form this pool of reserved clusters, MBOOT looks at the installed operating system it finds when it first rewrites the boot record. Clusters used by the current operating system must be good otherwise the PC would not boot up. MBOOT reserves only as many clusters as that operating system is using to store its system files. It is essential to install the DOS version that has the largest system files onto the hard disk before installing MBOOT. To switch between DOS and OS/2, users must install OS/2 before installing MBOOT. MBOOT also swaps the CONFIG.SYS and AUTOEXEC.BAT files for the incoming and outgoing operating systems. It does not swap the different versions of COMMAND.COM, but CONFIG.SYS or AUTOEXEC.BAT can handle that easily enough. After loading the selected operating system files, MBOOT executes the program code it saved from the original boot record. The normal boot process should continue unaffected by this little excursion. This technique worked for several months without a single MBOOT related problem during the DOS 5 beta test. Nevertheless, as soon as the final DOS 5.0 version was released, I removed MBOOT. There was no reason to tempt fate further than I already had. However, where access to multiple operating systems is essential, MBOOT seems to be the only option. Actually, OS/2 will provide the option to boot OS/2 or DOS, but it will only manage one DOS version. Install and use MBOOT with care. In principle, it is possible to keep working versions of OS/2, DOS 5.0, DOS 4.01 and DOS 3.x on one hard disk at the same time. Even better, the DOS version is selectable from a menu without resorting to boot floppies. A known problem with MBOOT is that Peter Norton's SAFE FORMAT program will not work properly after MBOOT modifies the boot record on the hard disk. DOS's own FORMAT program works fine, however. BOOTING UP THE SYSTEM - CONTINUED 6b) Under MS-DOS operating systems, the main job of the boot record is to search for another program called IO.SYS. IO.SYS is the first of the two system files stored at the beginning of the active DOS partition. If the boot record cannot find IO.SYS, it puts an error message on the screen and stops. Usually, the boot record finds IO.SYS, loads it into memory and executes it. IO.SYS includes a subroutine called SYSINIT that handles the rest of the boot process. IO.SYS resides in memory at all times. 7) SYSINIT loads MSDOS.SYS into memory. MSDOS.SYS is the second system file stored at the beginning of the active DOS partition. It does not start executing immediately. Like IO.SYS, MSDOS.SYS resides in memory at all times. Other system modules use them to handle various tasks. During day to day operation of the PC, IO.SYS and MSDOS.SYS may be called upon to execute programs, manage files and respond to hardware interrupts. 8) SYSINIT searches the root directory on the active DOS partition for a file named CONFIG.SYS and tells MSDOS.SYS to process the commands in that file. The list of commands in CONFIG.SYS can include loading instructions for specialized programs called device drivers. (IO.SYS and MSDOS.SYS are device drivers themselves. The next installment of this series will discuss a very useful device driver called BOOTCON.) The list in CONFIG.SYS can also include other commands that specify system configuration options. These include the BREAK status, the number of DOS BUFFERS, the DOS command, the number of FCBS, the number of FILES, the letter of the LASTDRIVE, the number of STACKS and the keyboard SWITCHES status. CONFIG.SYS can also include a SHELL command. The SHELL command will load COMMAND.COM, or an alternative command processor, and use it to adjust the size of the DOS environment, set the COMSPEC variable and/or specify an input/output device other than the console (console = CON = keyboard + monitor). 9) SYSINIT tells MSDOS.SYS to load COMMAND.COM into memory and execute it. If the SHELL command in CONFIG.SYS has already loaded a primary command processor, SYSINIT just tells MSDOS.SYS to execute the one loaded earlier. The primary command processor is COMMAND.COM by default. It searches the root directory of the active DOS partition for a file named AUTOEXEC.BAT and processes any commands contained in that file. Eventually, COMMAND.COM displays the DOS prompt on the console or on the input/output device specified by the SHELL or CTTY commands. A portion of COMMAND.COM stays resident in memory at all times. After it finishes processing AUTOEXEC.BAT. COMMAND.COM splits itself into resident and transient parts to make more memory available for applications. All user access to DOS, whether from the keyboard or from a batch file, is funneled through the command processor. When COMMAND.COM finds the name of an executable file (*.COM or *.EXE) at the command prompt or in a batch file, it tells MSDOS.SYS to load and execute the program. When a program exits back to DOS, COMMAND.COM takes control again. Then it either resupplies the DOS prompt or reads the next line of the batch file. HOW BATCH FILES WORK There is a distinction between "executable programs," like IO.SYS or COMMAND.COM, which are resident in or loaded into and then executed from memory, and "configuration files" like CONFIG.SYS or "batch files" like AUTOEXEC.BAT, which remain resident on the disk, are not executable and merely contain lists of commands for other system modules to carry out (they are interpreted files). Batch files are more like scripts than programs. MSDOS.SYS and/or COMMAND.COM read the commands in these files one line at a time. They load and execute the requested programs or system modules. When control returns to MSDOS.SYS or COMMAND.COM, the process repeats itself at the next line in the file. Processing continues one line at a time until it reaches the end of the configuration or batch file. COMMAND.COM activates the DOS prompt whenever it finishes processing a batch file. Writing a batch file may not seem like programming at all. However, some of the lines in batch files are calls to internal modules of COMMAND.COM. These are the batch file control commands that constitute the BFCL. The eight primary batch commands are CALL, ECHO, FOR IN DO, GOTO, IF, PAUSE, REM and SHIFT. For some purposes the EXIT command is considered part of the BFCL. These commands can customize the batch file, change the order of execution and perform various tests. They include some primitive branching and looping capability that can change the execution order. The BFCL, as it turns out, is a fairly primitive interpreted programming language. It is the one programming language that almost everyone needs to know something about. Batch files can handle a wide variety of tasks. They range in size from two or three lines up to files with hundreds of lines. Large or small, most batch files are quite useful. It is simpler to write a batch file than to remember all the command line switches on many applications. Complex batch files can present entire menus full of choices. All batch files save time because they only require users to type each line correctly one time. They only require a determination about the correct order of execution one time. Users are free to concentrate on using application programs rather than worrying about the details associated with finding and executing those applications. Unfortunately, the BFCL complicates the process of writing all but the simplest batch files. It offers only a few flow control options and no interactive input options at all. Batch file utilities alleviate some of the inadequacies of DOS's native BFCL by providing more programming options than DOS alone provides. Batch file tips help programmers exploit all the power that is available within the limited capabilities provided by DOS in the BFCL. Tips and utilities are the two major themes this series will address in the coming months. Part 2 of this series makes a first pass through the CONFIG.SYS file and introduces a useful routine for managing multiple PC configurations. It is called BOOTCON and it is a little easier and a lot safer to use than MBOOT for controlling the configuration at boot-up. BOOTCON cannot swap operating systems, however. Only MBOOT can change operating systems on the fly. BOOTCON incorporates different configuration choices into a single file and lets the user choose one from a menu at boot-up. Part 3 takes a first look at batch files by examining the DOS environment and introducing a utility that can check for installed device drivers. KEY WORDS 386 (PC with Intel 80386 CPU and supporting chip set) AUTOEXEC.BAT Batch File Batch File Control Language (BFCL) BFCL (Batch File Control Language) Boling, Douglas Bolt Systems Boot Process Boot Record Boot Sector BOOTCON Booting Bootstrapping Boot-Up BREAK BUFFERS CALL Cluster (minimum sized section of hard disk addressed by DOS) CMOS (Charge-coupled Metal Oxide Semiconductor) Command Processor COMMAND.COM CompuServe COMSPEC CON (Console) CONFIG.SYS CPU (Central Processing Unit) CTTY C: (C-Colon - 1st Hard Disk Partition Name on a PC) Digital Research [Incorporated] (DRI) Disk Operating System Disk Sector DOS 5.0 Operating System (Microsoft Corporation) DOS= DR-DOS (by Digital Research) ECHO Executable Program EXIT FCBS FILES Floppy Diskette [Drive] Flow Control (Looping, Branching, User Input) FOR IN DO FORMAT GOTO Hard Disk [Drive] [Partition] Hardware Hardware Interrupt Hexadecimal Notation IBM (International Business Machines) IF Interpreted File IO.SYS (MS-DOS System File) LASTDRIVE MBOOT (MultiBOOT, by Bolt Systems) Microsoft [Corporation] MSDOS.SYS (MS-DOS System File) MS-DOS (by Microsoft) North Texas PC Users Group Operating System OS/2 (by IBM) PAUSE PC Magazine; February 13, 1991; February 26, 1991 PC Magnet PC (Personal Computer) PC/Computing; May 1991 POST (Power-On-Self-Test) Programmers Shop, The REM ROM BIOS (Read-Only Memory, Basic Input/Output System) SAFE FORMAT, Peter Norton's Script File SHELL SHIFT Software STACKS SYSINIT