BATCH FILE TIPS AND UTILITIES The Sixth in a series by Mitchell A. Hoselton The focus this month returns to CONFIG.SYS. We'll look at DOS configuration commands, non-DOS memory managers and DOS's own supplementary device drivers. This article also examines some alternatives to BOOTCON for managing multiple DOS configurations. The classic way to change the PC configuration is to edit CONFIG.SYS and reboot. The modern approach is to tune highly specialized configurations for specific tasks and then switch among them. BOOTCON is a classy option for juggling multiple configurations. Even so, there are other alternatives worth considering. ORDERING AND ORGANIZING CONFIG.SYS COMMANDS DOS is not fussy about the order in which you list the various commands in the CONFIG.SYS file. There are three units to a well organized CONFIG.SYS file. They are the configuration commands, the device driver installation commands and the SHELL command. It is convenient though by no means necessary to keep these sub-units separated from each other. Furthermore, it is handy to keep the sub-units in a consistent relative order to improve readability. A consistent order makes it easier to work with numerous configuration files. Furthermore, it makes it easier to incorporate CONFIG.SYS enhancements. The order of configuration commands within their sub-unit is arbitrary. The order of device drivers within their own sub-unit is sometimes critical. Device drivers for memory cards, speed-up cards, memory managers and some other devices want to load first from CONFIG.SYS. They can't all be first, however. You may have to work out the correct order by trial and error. fortunately, most device drivers do not care about the order. The simple rule is that device drivers providing services to other device drivers must load ahead of their clients. CONFIG.SYS can also contain any number of blank lines. These make it easier to read the file and to find errors. Blank lines also make the organization readily apparent. ADDING COMMENTS TO CONFIG.SYS DOS versions 4.0 and 5.0 support the use of REM (short for Remarks) in CONFIG.SYS. REM can document the file and improve its readability. Also, the REM command can be used to deactivate commands in CONFIG.SYS. Adding REM at the beginning of any line will force DOS to ignore everything else on that line. This obviates the need to erase and reenter commands while testing new configurations. In most DOS versions a colon (:) at the beginning of any line in CONFIG.SYS produces almost the same effect as using REM. The only disadvantage of the colon is that it generates the following error message, or one like it. Unrecognized command in CONFIG.SYS Error in CONFIG.SYS line xx This error message has no effect on the other commands in CONFIG.SYS or on the remainder of the boot-up process. Ignore the message if you know that REM is causing it to appear. See page 288 of the January 28, 1992 edition of PC Magazine. THE CONFIG.SYS CONFIGURATION COMMANDS Chapter 11 of the MS-DOS 5.0 "User's Guide and Reference" describes the DOS configuration commands. The most important ones are BREAK, BUFFERS, DOS, FCBS, FILES, LASTDRIVE, STACKS, and SWITCHES. Put these together at the beginning of the CONFIG.SYS file. DOS has a default value for each one, but the DOS defaults do not configure most PC systems optimally. Think of the list at the beginning of CONFIG.SYS as the new default values for these configurations commands. If any of these commands appears again in CONFIG.SYS, the latter command will take precedence over this first one. A) The BREAK works in CONFIG.SYS, in batch files and from the DOS prompt. Using the BREAK command changes the way that DOS responds to the use of [CTRL]-[C] and [CTRL]-[BREAK] keystroke combinations. Normally, DOS only checks for [CTRL]-[C] or [CTRL]-[BREAK] while reading the keyboard, writing to the screen or writing to the printer. With BREAK=on, it checks for these keystrokes while reading from the disk or the keyboard and while writing to the disk, the printer or the screen. Most CONFIG.SYS files routinely include the BREAK=on command to increase the frequency with which DOS checks for these keystroke combinations. Enable BREAK with the BREAK=on command. Reset it to its default setting using the BREAK=off command. Enabling the BREAK=on, slows the PC slightly. Some application programs may intercept the [CTRL]-[C] and [CTRL]-[BREAK] keystrokes. Such applications will circumvent DOS's ability to respond to these keystrokes while the application is executing. B) The BUFFERS command controls the amount of memory set aside for handling disk transfers. DOS divides this section of memory into areas called buffers. Each buffer is the same size as a disk sector, 512 bytes. Under DOS 5.0 the buffers reside in low memory (below the 640K boundary) whenever DOS loads low. When DOS 5.0 loads into the high memory area (the HMA occupies the first 64K above the 1 Megabyte boundary) it loads the buffers into the HMA, too. If there is not enough room in the HMA to hold DOS and all the buffers, DOS loads the buffers low and keeps DOS in the HMA. DOS 5.0 leaves enough room in the HMA to load about 50 buffers. The default value on most systems is BUFFERS=15. The DOS buffers act as a very simple disk cache. The DOS buffers are so simple that the level of incremental improvement after the first five or six buffers is usually not very impressive. Still, for every hardware configuration there is a BUFFER setting that makes disk transfers optimally fast; at least some of us would like to think so. The right number of buffers will depend on the hardware configuration. Too many or too few buffers can choke the entire system down to a crawl. Without worrying about optimization, BUFFERS=20 to BUFFERS=35 is a good range to start with. See page 111 of the December 1989 edition of Personal Computing for a discussion of the BUFFERS command and its relationship to disk caching. Disk caching device drivers like DOS's SMARTDRV.SYS and Qualitas' QCACHE.EXE (QCACHE comes with 386MAX by Qualitas, but it is actually a version of Super PC-Kwik by Multisoft Corp.) may impose additional restrictions on your use of the BUFFERS command. With some versions of SMARTDRV.SYS, for example, DOS recommends using less than 20 buffers. QCACHE.EXE is optimized to use 8 buffers. These disk caching programs do everything that the buffers can do and they do it better. It is no sacrifice to use the number of buffers recommended for these disk caching device drivers. Using fewer buffers also preserves low memory for use by your applications. C) The DOS command should appear once and only once in the CONFIG.SYS file. The DOS=high command forces DOS to load into the HMA if there is an extended memory manager present. The DOS=high command can appear anywhere in CONFIG.SYS because it is the last command that DOS processes before it finishes with CONFIG.SYS. If an extended memory manager is not present, DOS loads itself low and the rest of the boot process continues normally. A message appears saying that DOS did not load high. (When DOS loads high, it loads into the HMA. When device drivers and TSRs load high, they load into high RAM. High RAM and the HMA are not the same thing. High RAM, also called the upper memory blocks, is in the address area between 640K and one megabyte. The HMA is the first 64K above the one megabyte boundary. Also, see the discussion below.) The DOS command also accepts a UMB parameter. The UMB parameter enables DOS 5.0's ability to load programs into upper memory blocks. Using the upper memory block manager provided by DOS is not nearly as efficient as using either QEMM386 from Quarterdeck Office Systems or 386MAX from Qualitas. These non-DOS memory managers do not need the UMB parameter though some will recognize and respond to it. D) Application programs that use file control blocks sometimes fail to run on systems where CONFIG.SYS does not include an FCBS command . The default value is 4. That is enough for most programs that require file control blocks. The FCBS command can be set to any value from 1 to 255. E) The FILES command specifies the size of the System File Table (SFT). Each open file requires an entry in the SFT. Many applications recommend FILES=20 to FILES=35. This is a good range in which to experiment. Systems running Microsoft WINDOWS may require a larger number. The default value is only FILES=8. Each file after the first 8 takes up 59 bytes of low memory. See page 469 of the November 12, 1991 edition of PC Magazine for a discussion of the FILES command. F) The LASTDRIVE command indicates the letter of the last drive that DOS will recognize. There is some confusion about its default value. It is not, as the DOS 5.0 manual seems to say, one letter above the last drive installed on the system. On a system with two floppy drives and 10 logical partitions on a single physical hard disk, the default value matches the actaul number of drives and partitions present, namely 12 or LASTDRIVE=L. It is not possible to set the LASTDRIVE to recognize fewer drives than actually exist on the system, including all the logical or physical drives installed by CONFIG.SYS. Use the LASTDRIVE command is only required when you need to reserve room for other logical drives (for example when using the SUBST command) not created or installed during boot-up. Each drive recognized by DOS 5.0 requires 100 bytes of low memory. G) Most PC systems do not require STACKS. Therefore, adding a STACKS=0,0 command to CONFIG.SYS will usually save some low memory. The default value depends on the hardware. Most non-IBM PCs have a default value of STACKS=9,128. Nine stacks of 128 bytes apiece should consume just over 1K of low memory. Actually, it consumes 1.8K because of extra overhead. Some hardware systems use stacks for processing certain hardware interrupts. On systems that occasionally crash for no apparent reason, using REM to disable the STACKS=0,0 statement reestablishes the default value. It may also eliminate those unexplained crashes. H) The SWITCHES command is only useful to those using WINDOWS (the /w switch) or to those using a small number of finicky utility programs (the /k switch). The /k switch is for programs that do not support the extended ROM BIOS on 101/102 key keyboards. These include Lotus METRO, Lotus EXPRESS, IBM DISPLAYWRITE III, Borland's TURBO-LIGHTNING, and Micro Logic's TORNADO 1.8. Adding the SWITCHES=/k command to CONFIG.SYS will fix the keyboard errors that these programs otherwise generate. The DOS 5.0 manual recommends adding the /k switch to the ANSI.SYS driver when using the SWITCHES=/k command. LOADING DEVICE DRIVERS FROM CONFIG.SYS Loading device drivers from CONFIG.SYS requires entering the DEVICE command followed by the device driver file name, including its extension. DOS supports the use of a path before the device driver filename.ext. It also supports the use of parameters after the filename.ext, if the device driver uses parameters. The standard syntax appears on the following line. DEVICE=[drv:\][path\]filename.ext [dd-parameters] Once CONFIG.SYS loads a device driver there is frequently no way to remove it, except by editing the CONFIG.SYS file to remove or disable the DEVICE command that loadsthe device driver, and rebooting the system. These installable device drivers supplement the device handling tools built into DOS. Installable device drivers can add new capabilities to the operating system so that it can manage new external devices, like speed up cards or video boards. Device drivers can also manage old devices in new ways. Memory managers, for example, use memory in ways that DOS, at least until DOS 5.0, could not imitate. DOS communicates with hardware devices using messages called interrupts. Device drivers can intercept these interrupt messages. Microsoft provided the software "hooks" that make it possible for device drivers to perform this feat. Microsoft wanted hardware vendors to provide device drivers to integrate their hardware with the standard PC hardware and the DOS operating system. Now, however, there are a lot of device drivers on the market that fall into the category that I would call system enhancements. This goes well beyond the original aim of integrating new devices into the system. The next few sections discuss two classes of system enhancement device drivers. These are Memory Managers, and DOS's own supplementary device drivers. Memory managers are definitely in the system enhancement category. DOS's supplementary device drivers provide features Microsoft probably should have built into the operating system in the first place. On a proprietary hardware platform Microsoft probably would have done so. In the world of PC clones installable device drivers offer the user a choice among competing device drivers, flexibility across a wide variety of hardware platforms, and loading options in the form of command line switches. These device drivers and others like them also qualify as system enhancements. MEMORY MANAGERS What follows applies only to Intel 80386 equipped PCs. By far, the most popular and most powerful memory managers available today are QEMM386 and 386MAX. DOS 5.0 provides memory management services, too, but they are pitiful by comparison. Memory management is an area that is blossoming with new entries. See the December 1991 edition of PC/Computing for a recent review. The last word on memory management and memory managers is not in yet. Both QEMM386 and 386MAX, in their latest incarnations, work very well. Other and better choices may eventually become available, but the best choice right now is between these two. Memory managers concern themselves with managing the extended memory area on a PC. Low memory is the 640K memory area available on most PCs. Low memory is memory with addresses between zero and 640K (segment addresses 0000h to 9FFFh). It is also known as conventional memory. DOS itself has always managed low memory. This is where application programs reside while executing in memory. Memory managers convert, manage, and manipulate extended memory. The converted versions of extended memory have a variety of names. A) First of all, Extended Memory is all the memory that starts at boot-up with addresses above 1 Mbyte. In a PC world without any history behind it, extended memory would remain extended memory. It would be just like conventional memory and all applications programs would use it "as is." Due to the accidents of history, however, DOS cannot address extended memory directly. The PC world has evolved four methods (and still counting) of accessing extended memory. The memory managers available today automatically support all four uses of extended memory. That is, they support the software that requires memory management services to access extended memory. Microsoft wrote DOS to support the Intel 8088 CPU chip in the original IBM PC. That CPU could handle 20 bit addresses. That means it could address 2^20 (two to the twentieth power) memory locations. That is 1,048,576 unique addresses, or 1Meg of memory. It seemed like a lot at the time. Now that PCs supporting 16, 32 and 64 Mbytes of RAM are becoming more common, the limitations imposed by that original design are starting to chafe. Access to extended memory is provided by an XMS (Extended Memory Specification) manager. The XMS manager is a device driver that adds enhanced memory addressing features to DOS. It provides the services required by applications that indirectly access extended memory. It also manages the HMA (see below) and keeps track of which applications are using which parts of extended memory. The XMS manager assigns a handle (a name) to each discrete data set stored in extended memory. XMS compliant applications pass these handles back to the XMS manager when calling for the data. B) The High Memory Area (HMA) occupies the first 64K of extended memory above the 1 Mbyte boundary. When requested, the XMS manager, will set this block of extended memory aside and prevent most applications from using it to store data. The HMA is actually 16 bytes less than 64K in size, but that is quibbling. The segment address for the HMA is FFFFh. That is less than 1Meg. That means it is within DOS's own addressing capability. Using any segment address, DOS can address 64K of memory. The HMA is where DOS 5.0 loads itself and the DOS buffers whenever the DOS=high command and an XMS memory manager are included in CONFIG.SYS. Only one program can occupy the HMA at any given time. If DOS loaded itself high, it is using the HMA and no other HMA compliant application programs can use it. C) High RAM (Microsoft calls it the Upper Memory Area) is the area of memory with addresses between 640K and 1Meg (1Meg=one megabyte=1 Mbyte; segment addresses A000h to FFFFh). System ROMs, hardware ROMs, video ROMs and video RAM all use addresses in this range. High RAM refers to RAM that has been remapped to an unused addresses in this range. Unused addresses in this range are known as the Upper Memory Blocks (UMBs). Collectively, they constitute the upper memory area (UMA). Some device drivers and Terminate-and-Stay- Resident (TSR) programs can load into high RAM. A memory manager must remap unused memory into the gaps in this address range before any device drivers or TSRs can be accessed there, however. Loading device drivers and TSRs into high RAM conserves conventional memory for use by application programs. Do not confuse the HMA and High RAM. Microsoft calls high RAM the upper memory blocks (UMB) or upper memory area (UMA) to clearly differentiate them. D) Remapping memory into the UMBs consumes some of the available extended memory. The HMA consumes another 64K of extended memory. Some or all of the remaining extended memory can emulate Expanded Memory. An EMS (Expanded Memory Specification) device driver must be in charge of expanded memory. Expanded memory is like memory that has no addresses of its own. It is off to the side all by itself, somewhere. It used to reside on its own memory board. In a 386 PC, the EMS manager uses extended memory to mimic the behavior of those old expanded memory boards. The EMS manager uses a 64K section of the high RAM address space, called the Page Frame, to make data in expanded memory available to applications. The page frame reduces the amount of high RAM available for loading device drivers and TSRs high. The page frame is a range of addresses that the EMS manager can freely assign to different sections of the expanded memory pool. The expanded memory manager temporarily assigns addresses from the page frame to the requested parts of expanded memory. It moves the page frame addresses around to make different parts of the total expanded memory pool available at different times. Data stored in expanded memory is available 64K at a time. All the page frame addresses are below 1 Mbyte. Therefore, DOS is able to access those parts of expanded memory that currently have addresses assigned to them from the page frame. The process of moving all these addresses around is clearly less efficient (slower) than just using the real addresses that the extended memory had originally. Software developers adopted the expanded memory specification to solve a hardware problem that no longer exists; at least not since the advent of Intel 80386 chip. Software written to comply with that specification still exists and gets used everyday, however. Millions of PC users will need to provide expanded memory for some of their applications for several years to come. DOS programs cannot directly access expanded memory. The EMS manager provides the services required by applications that must access expanded memory, keeps track of the addresses in the page frame and the parts of the expanded memory pool which are in use. Each discrete data set stored in a block of expanded memory receives a handle. The application programs pass the handles back to the EMS manager when calling for the data. CHOOSING A MEMORY MANAGER Whichever memory manager you chose, its device driver(s) must load ahead of any device driver that requires memory management services. Whenever possible, the memory manager should be the first device driver loaded from CONFIG.SYS. When using BOOTCON, however, BOOTCON has to come first. Using BOOTCON and QEMM386 requires installing another device driver called HOOKROM.SYS before either of them. Fortunately, HOOKROM.SYS, BOOTCON, QEMM386, 386MAX and DOS's memory management device drivers can all reside in a single BOOTCON managed CONFIG.SYS file without conflicts. QEMM386 and 386MAX provide all the capabilities for handling the various extended memory areas, and other services as well. The other services include remapping slow ROMs into faster RAM. That speeds up video and hard disk operations. They can move ROM addresses to make room inside the high RAM area for device drivers and TSRs. Both memory managers provide automatic installation and optimization routines. On my 386 clone QEMM386 and 386MAX, respectively, presented a series of installation choices and then installed the lines shown below. These lines install the DEVICE drivers that provide the memory management services. Neither installation routine is able to work with the BOOTCON managed version of CONFIG.SYS. They just get confused. I used specially prepared versions of CONFIG.SYS that each installation routine was free to modify. I manually moved the final versions of the device driver commands into my BOOTCON managed multi-configuration CONFIG.SYS file. QEMM386's OPTIMIZE program created the following line. DEVICE=C:\QEMM\QEMM386.SYS R:1 ON DB=1 RAM ROM ST:M 386MAX's MAXIMIZE program installed the following line. DEVICE=C:\386MAX\386MAX.SYS PRO=C:\386MAX\386MAX.PRO I installed the earlier versions of both memory managers by hand because I did not trust their automatic installation routines. The new installation routines work very well, however. I still took the precaution of making full back-ups of my hard disk partitions before installing either of them. My one firm suggestion is to read everything and proceed with caution. Only one of these memory managers can be active at any one time. I use BOOTCON to keep both QEMM386 and 386MAX memory managers available and ready for use. I also keep DOS's memory manger available in CONFIG.SYS, but I hardly ever use it anymore. QEMM386 is clearly a better choice than 386MAX on my system. It creates more high RAM for storing device drivers and TSRs (223K vs 148K, not including the 64K reserved for the page frame that each creates). It is somewhat easier to install. The commands it uses to load device drivers and TSRs into high RAM are shorter, easier to read and easier to understand. Finally, it comes with Manifest (MFT). Manifest is a memory probe and configuration analysis tool. The comparable program from Qualitas, MAX/ASQ, is much improved since the early version but it is still not as good as Manifest. 386MAX seemed, at one point, to have a slight edge. That is because it comes with an excellent disk cache called QCACHE. It turns out that QCACHE works just as well with QEMM386 as it does with 386MAX. QCACHE is really just the Super PC-Kwik disk cache. Both memory managers dynamically allocate extended and expanded memory. That means they can repartition extended memory in response to the requests they receive from the currently active programs in memory. The DOS 5.0 memory manager uses switches on the command line in CONFIG.SYS to create a fixed allocation between extended and expanded memory at boot-up . Changing that allocation requires editing CONFIG.SYS and rebooting. According to Barry Simon's article in the February 11, 1992 edition of PC Magazine, QEMM386, 386MAX, Netroom and QMAPS are the only memory managers than can dynamically allocate memory. As applications that use expanded memory become less common, this dynamic allocation scheme will become even more important. The eventual aim is to eliminate the use of expanded memory altogether. That is not going to happen over night. In the normal course of memory management evolution, I expect the other memory managers to adopt similar features in future releases. 386MAX's only other advantage over QEMM386 is that it works with DOS 5.0's own DEVICEHIGH command (see below). Both QEMM386 and 386MAX are rock solid memory managers. Since installing the DOS 5.0 compatible upgrades of each, there has not been a single mysterious crash on my 386 clone. That was not true of the earlier versions of either memory manager. At least not without a lot of experimentation and many hard crashes. Anyone determined to use DOS's memory management utilities can get some help by consulting page 268 of the September 1991 edition of PC/Computing, pages 223 and 427 of the September 24, 1991 edition of PC Magazine, and page 507 of the November 12, 1991 edition of PC Magazine (although this last one has some misstatements in it). DOS DEVICE DRIVERS Among the installable device drivers available with DOS, the most important ones for an American audience are ANSI.SYS, DRIVER.SYS, RAMDRIVE.SYS, SETVER.EXE and SMARTDRV.SYS. A) ANSI.SYS is a device driver that provides screen and keyboard control. It, or an equivalent device driver, is an essential tool on most modern PCs. A number of projects discussed later in this series require ANSI.SYS. B) DRIVER.SYS creates a logical drive that refers to a physical drive. It can define an external physical floppy disk drive. It can also add a second drive letter to an existing floppy disk drive. By giving one drive two names, it enables COPYing and XCOPYing on a single floppy drive in a system that has two non-identical floppy drives installed. This is the job that DOS always performed automatically on PCs with one floppy drive. The following command will not ordinarily work on such a system. COPY a:\*.* a:\ Use DRIVER.SYS to assign a second drive letter to A:, let's assume the new drive letter is N:. Now the following command will work and it will prompt the user to swap the floppy disks at the appropriate times. COPY a:\*.* n:\ C) RAMDRIVE.SYS is DOS's RAM disk driver. It uses conventional, extended or expanded memory. It can create single or multiple RAM drives up to 4096K in size. It is as good a RAM disk as most of us really need. D) SETVER.EXE loads the MS-DOS version table. This is new in DOS 5.0. It will trick older applications that check the DOS version before running. The appearance of an error message, telling you that you're using the wrong DOS version, is the first clue that your application may need SETVER. DOS provides a large list of application names and DOS version numbers. It appears in the version table printed below (except for BASIC and BASICA). DOS provides the tools to add and delete entries in the version table. Just adding a misbehaving application to the version table does not automatically guarantee that the application will work under DOS 5.0. It may be using some DOS feature no longer available in DOS 5.0. Despite that, as this list indicates, many applications that read the DOS version will run under DOS 5.0, but only after including them in the version table. BAN.COM 4.00 IBMCACHE.SYS 3.40 REDIR.EXE 4.00 BAN.EXE 4.00 LL3.EXE 4.01 SSTDRIVE.SYS 4.00 BASICA.COM 3.11 METRO.EXE 3.31 SYQ55.SYS 4.00 BASICA.EXE 3.11 MSCDEX.EXE 4.00 TOPSRDR.EXE 4.00 BASIC.COM 3.11 MSREDIR.EXE 4.00 WIN100.BIN 3.40 DD.BIN 4.01 NETWKSTA.EXE 4.00 WIN200.BIN 3.40 DD.EXE 4.01 NET.COM 3.30 WINWORD.EXE 4.10 DXMA0MOD.SYS 3.30 NET.EXE 4.00 ZDRV.SYS 4.01 EXCEL.EXE 4.10 REDIR40.EXE 4.00 ZFMT.SYS 4.01 HITACHI.SYS 4.00 REDIR4.EXE 4.00 E) SMARTDRV.SYS is DOS's disk cache. It can use either extended or expanded memory. SMARTDRV, QCACHE, Super PC-Kwik and a whole host of other disk caching programs are available. On systems with extended or expanded memory to spare for the purpose, a disk cache makes a noticeable difference in disk access operations. Only a single disk cache can be active at any one time. Both QCACHE and Super PC-Kwik are faster than SMARTDRV.SYS. PUTTING IT ALL TOGETHER IN CONFIG.SYS LISTING 1 and LISTING 2 show the versions of a CONFIG.SYS that install QEMM386 and 386MAX, respectively, and then install various DOS device drivers into high RAM. The commands shown are from actual working files on one particular 386 PC system. These are not blanket recommendations for all PC systems. The DEVICE commands in these two listings load two device drivers not previously mentioned. These are LOADHI.SYS and 386LOAD.SYS. These are the QEMM386 and 386MAX loaders, respectively. The loaders are device drivers whose only purpose is loading other device drivers into high RAM. That's right; device drivers to load device drivers. The name of the device driver being loaded high appears as one of the parameters after the loader's filename. The specific syntax used by each loader is best understood after reading the appropriate memory manager's manual. Please note that some of the lines in LISTING 1 and 2 are too long to fit on a single line in this article and have been continued on a second line. In the actual CONFIG.SYS file, however, these commands occupy only one line apiece. ============================================================================ LISTING 1 - CONFIG.SYS with QEMM386 loading device drivers high. BREAK=on BUFFERS=8 DOS=high FCBS=4 FILES=35 LASTDRIVE=L STACKS=0,0 SWITCHES=/k DEVICE=c:\qemm\qemm386.sys r:1 on db=1 ram rom st:m DEVICE=c:\qemm\loadhi.sys /r:2 c:\dos_500\ramdrive.sys 400 /a DEVICE=c:\qemm\loadhi.sys /r:2 c:\dos_500\ramdrive.sys 304 /a DEVICE=c:\qemm\loadhi.sys /r:2 c:\dos_500\setver.exe DEVICE=c:\qemm\loadhi.sys /r:1 c:\dos_500\ansi.sys /k SHELL=c:\dos_500\command.com c:\dos_500\ /e:992 /p =========================================================================== ============================================================================ LISTING 2 - CONFIG.SYS with 386MAX loading device drivers high. BREAK=on BUFFERS=8 DOS=high FCBS=4 FILES=35 LASTDRIVE=L STACKS=0,0 SWITCHES=/k DEVICE=c:\386max\386max.sys pro=c:\386max\386max.pro DEVICE=c:\386max\386load.sys size=5888 prgreg=2 flexframe prog=c:\dos_500\ramdrive.sys 400 /a DEVICE=c:\386max\386load.sys size=5888 prgreg=2 flexframe prog=c:\dos_500\ramdrive.sys 304 /a DEVICE=c:\386max\386load.sys size=11504 prgreg=2 flexframe prog=c:\dos_500\setver.exe DEVICE=c:\386max\386load.sys size=2000 prgreg=2 flexframe prog=c:\dos_500\ansi.sys /k SHELL=c:\dos_500\command.com c:\dos_500\ /e:992 /p ============================================================================ DOS 5.0 accomplishes the same task by replacing the DEVICE command with the DEVICEHIGH command. This should make DOS 5.0 somewhat easier to use, because it avoids the use of a separate loader. Unfortunately, DOS 5.0's other capabilities are so inferior to either QEMM386 or 386MAX, that using DOS 5.0, by itself, is hardly worth considering. 386MAX, however, also understands the DEVICEHIGH command and can use it to load device drivers high. This simplifies using 386MAX and avoids any need to use 386LOAD.SYS and its complex syntax. LISTING 3 shows how DEVICEHIGH and 386MAX can work together. Note that using 386MAX and DEVICEHIGH together does not require adding the UMB parameter to the DOS=high command. The 386MAX manual says that the UMB parameter should be used, but the manual is wrong. ============================================================================ LISTING 3 - CONFIG.SYS with 386MAX and DOS 5.0 loading device drivers high. BREAK=on BUFFERS=8 DOS=high FCBS=4 FILES=35 LASTDRIVE=L STACKS=0,0 SWITCHES=/k DEVICE=c:\386max\386max.sys pro=c:\386max\386max.pro DEVICEHIGH=c:\dos_500\ramdrive.sys 400 /a DEVICEHIGH=c:\dos_500\ramdrive.sys 304 /a DEVICEHIGH=C:\DOS_500\SETVER.EXE DEVICEHIGH=c:\dos_500\ansi.sys /k SHELL=c:\dos_500\command.com c:\dos_500\ /e:992 /p ============================================================================ The examples shown in LISTING 1, LISTING 2, and LISTING 3 were tested on a system that installs QCACHE from AUTOEXEC.BAT. That's why BUFFERS=8 appears rather than a normal value, like BUFFERS=25. The SWITCHES=/k was added to CONFIG.SYS because AUTOEXEC.BAT installs both Borland's Turbo LIGHTNING and Micro Logic's TORNADO 1.8. Both require the SWITCHES=/k command before they will work properly. This explains the use of the /k switch with ANSI.SYS as well. LASTDRIVE=L is not required. I keep it merely as a reminder that the system has two floppy drives and currently has ten hard disk partitions. Sometimes CONFIG.SYS installs two RAM disks and/or two DRIVER.SYS disks. In those cases the correct value for LASTDRIVE would seem to be LASTDRIVE=n or p. These drives are not installed every time the system boots. I refuse to waste 200 or 400 bytes of low memory by saving room for these occasional disks. As it turns out, I don't have to waste any memory. DOS finds the correct default value when it installs the extra drives at boot-up. In fact, the system works fine without the LASTDRIVE command. The LASTDRIVE command is only essential when you plan to use the SUBST command. The 992 byte DOS environment size is larger than actually required most of the time. Some batch files make extensive, though temporary, use of the DOS environment and for them the larger environment size is just right. The FCBS=4 command is not necessary. FCBS=4 is the normal default. I keep it there only as a reminder. INSTALLING MULTIPLE CONFIGURATIONS With a little bit of effort, all three of these configurations could be (and have been) put into one CONFIG.SYS file and managed with BOOTCON. Each one of them is selectable from the BOOTCON Start-up menu. There are other tools, beside BOOTCON, that manage multiple configurations. You can obtain more detailed information about the utilities mentioned in this section from Ronny Richardson's book, "MS-DOS Batch File Utilities." His book is my exclusive source for the information in this section. Each configuration in a multi-configuration environment has to be tuned and tested separately. Multiple configuration managers can only provide limited help with that chore. What they can do is ease the process of debugging a new configuration and/or simplify the process of switching from one configuration to another. Only a few do both. It is possible to manage multiple configurations with batch files, too. The problem with the batch file approach is that it offers no protection against fatal errors that occur after creating or editing one of the configurations. A new configuration must be chosen before a reboot begins. Recovering from one of these crashes requires a boot floppy. Don't underestimate the power of the batch file approach, though. Most of these utilities can not provide any better protection. One way to judge the value of these and related utilities is by their ability to recover the system even if a fatal error occurs while booting with a newly edited CONFIG.SYS file. A) BOOT.SYS version 1.27 is a $39.00 shareware program by Hans Salvisberg Froeschmattstr and it is available on many bulletin boards. BOOT.SYS allows 25 different configurations in one CONFIG.SYS file. The available configurations appear on a menu. BOOT.SYS has an interactive mode that can present the user with a series of questions at boot-up and install only the device drivers specified by the answers. In this mode it is possible to avoid selecting a misbehaving device driver during a reboot following a crash. BOOT.SYS can pass data to AUTOEXEC.BAT by invoking a utility that generates exit codes. BOOT.SYS includes extensions that allow users to EDIT the configuration during boot-up, change the menu colors, and pause the CONFIG.SYS if messages are flying by too quickly. It is the best alternative to BOOTCON that I've run across. B) CHENV version 1.0 (Change Environment) by Pedro P. Polakoff III is a free, public domain program available on many bulletin board systems. CHENV manages a configuration library of user created CFS.xxx and AEB.xxx files, where the xxx can be any extension. The xxx for each pair must match. Issuing the command CHENV xxx copies CFS.xxx to CONFIG.SYS and AEB.xxx to AUTOEXEC.BAT and then reboots the PC. All these files must be stored in the root directory. This is basically the same job that a well written batch file based configuration manager could accomplish. CHENV does not copy the CONFIG.SYS and AUTOEXEC.BAT back to their original CFS and AEB files when changing configurations. Any editing changes made to CONFIG.SYS and AUTOEXEC.BAT are destroyed. CHENV only saves the changes made to the CFS and AEB files. This scheme has one drawback; making simple system changes requires editing many individual files. Periodically, you will have to edit every CFS file to change the environment size or the number of BUFFERS, or something. Additionally, all these CFS and AEB files clutter up the root directory. C) CONFIG.CTL by Michael J. Mefford is a free, copyrighted program available from PC MagNet. See any edition of PC Magazine for information on accessing PC MagNet by modem. See the November 29, 1988 issue of PC Magazine for a presentation of CONFIG.CTL and the October 17, 1989 issue of PC Magazine for some additional instructions about using it. Version 3.0 is the current release as of October 29, 1991. CONFIG.CTL allows users to edit CONFIG.SYS while the computer is booting. It is valuable when used with other programs like CHENV, DynBoot, or RESET, which manage a library of CONFIG.SYS and AUTOEXEC.BAT files. It provides the feature that CHENV and the others most sorely lack. It allows configuration selection and modification after the boot process has already begun. It still requires keeping multiple CONFIG.SYS files because it will not accept totally new lines, it cannot make lines that are longer than the original, and it cannot edit the section of any line before the equal (=) sign. Changes made while booting are only temporary. On the next boot-up, the lines will reappear in their original form. This makes CONFIG.CTL a great debugging and testing tool. Mistakes do not come back to haunt you. Make permanent changes with a text editor after testing the new configuration thoroughly. D) DynaBoot version 1.1 by Matthew J. Palcic is a $15 shareware program available from the author at MJP Enterprises, 1030 Dayton-Yellow Springs Road, Xenia, Ohio 45385. It will boot up to 100 different configurations. Each configuration has its own CONFIG.SYS file and has its own matching AUTOEXEC.BAT file. It will only work with files stored in the root directory. In its basic operation it is similar to CHENV. You must select the new configuration from the command line before booting the system. All programs of this type could be used with CONFIG.CTL. After fine tuning a new configuration with CONFIG.CTL, include its final form among the files managed by any one of these utilities. E) EZ-EXEC version 1.0 by T.H.E. SoftWareHouse is $10 shareware program available at PO Box 34246, Omaha, Nebraska 68134 and from many bulletin boards. EZ-EXEC concentrates on managing only the AUTOEXEC.BAT file. The registered version allows up to 19 options. F) RESET version 1.2 by Bruce Travers is a free public domain program available on many bulletin boards. It manages a library of CONFIG.SYS and AUTOEXEC.BAT files. It will only work with files stored in the C:\BOOT directory. RESET includes switches that will pause the reboot process after copying the new files (to wait while a disk cache flushes its buffer, for example), reset an All Charge Card, and select a warm boot or a cold reboot. Ronny Richardson reports that the warm boot option did not work on his PS/2 system. G) SYSCFG version 3.0 by Masterware is a $19.95 shareware program available from the author at 2442 Tilghman Street #1, Allentown, Pennsylvania 18104. SYSCFG manages a database that incorporates matched pairs of CONFIG.SYS and AUTOEXEC.BAT files. This is better than keeping a library of little files that clutter up the hard disk's root directory. It will import existing files into the database and includes a feature to edit or create more files inside the database. While more clever than most other configuration library managers, new configurations must still be selected before the reboot starts. Also, since the individual files are tucked away in a database, they are unavailable to normal editors and CONFIG.CTL. CONFIG.CTL can still fine tune the files before putting the final version into the database, however. CLOSING COMMENTS With the advent of WINDOWS, more memory managers, OS/2 and who knows what else, the need to manage multiple configurations and possibly multiple operating systems is more likely to grow than to diminish with time. The best alternatives are BOOTCON, CONFIG.CTL in combination with one of the configuration library managers, and BOOT.SYS, not necessarily in that order. CONFIG.CTL can be useful all by itself just for experimenting with command line switches. Next month's article will cover batch file subroutines, and "nesting" FOR IN DO commands. KEY WORDS 1 Mbyte 1 Meg Boundary 20 Bit Address 386LOAD.SYS 386MAX 640K Boundary ANSI.SYS AUTOEXEC.BAT BASIC BASICA Blank Lines in CONFIG.SYS Boot Floppy BOOTCON BOOT.SYS (Hans Salvisberg Froeschmattstr) Borland's TURBO-LIGHTNING BREAK BUFFERS CHENV (Pedro P. Polakoff III) Colon (:) Configuration Commands CONFIG.CTL (Michael J. Mefford) CONFIG.SYS Conventional Memory COPY Deactivate Commands (REM, Colon) DEVICE Device Driver DEVICEHIGH Disk Cache Disk Sector (512 bytes) DOS 5.0 DOS command DOS Device Drivers DOS Environment DRIVER.SYS DynaBoot (Matthew J. Palcic) Dynamic Allocation EMS (Expanded Memory Specification) Exit Code Expanded Memory Extended Memory External Floppy Drive EZ-EXEC (T.H.E. SoftWareHouse) FCBS File Control Blocks (FCBS) FILES FOR IN DO Hard Disk Partition Hardware ROM High Memory Area (HMA) High RAM HMA (High Memory Area) HOOKROM.SYS IBM DISPLAYWRITE III Intel 80386 Chip Intel 8088 CPU Key-Capture Utility LASTDRIVE Loader (for Device Drivers) LOADHI.SYS Logical Drive Lotus EXPRESS Lotus METRO Low Memory MANIFEST (MFT) MAXIMIZE MAX/ASQ Memory Card Memory Manager Micro Logic's TORNADO Microsoft Corporation MS-DOS Batch File Utilities by Ronny Richardson Multiple Configurations Multisoft Corp. Nesting OPTIMIZE OS/2 Page Frame PC PC Magazine - September 24, 1991 PC Magazine - November 12, 1991 PC Magazine - January 28, 1992 PC Magazine - February 11, 1992 PC/Computing - December 1991 PC/Computing - September 1991 Personal Computing - December 1989 Physical Drive POST (Power-On-Self-Test) QCACHE QEMM386 Qualitas Corporation Quarterdeck Office Systems RAM Disk RAMDRIVE.SYS Reboot Reconfiguration Catastrophe REM (Remarks) Remapped Memory Remapping Memory RESET (Bruce Travers) SCSI (Small Computer System Interface) Segment Address SETVER.EXE SHELL command SMARTDRV.SYS Speed-up Card STACKS SUBST Super PC Kwik SWITCHES SYSCFG (Masterware) System Configuration System File Table (SFT) System ROM Terminate and Stay Resident (TSR) TSR (Terminate and Stay Resident) UMA (Upper Memory Area) UMB (Upper Memory Blocks) Upper Memory Blocks (UMB) Version Table Video RAM WINDOWS (by Microsoft) XCOPY XMS (Extended Memory Specification) [CTRL]-[BREAK] [CTRL]-[C]