DOS 6's Multiconfig, part 3. (IBM DOS 6.0) (Hardware Clinic) (Column)
by Mark Minasi
In the August column, I suggested one way to easily combine a number of AUTOEXEC.BATs into a single MultiConfig-ready file. If you tried experimenting with your system, perhaps you learned that the configuration names get passed to AUTOEXEC.BAT in the same case that you wrote them in CONFIG.SYS. If the configuration name is interlnk, don't write the IF statement as IF %config%==INTERLNK GOTO . . . , for that'll never match. The case must match; the statement would have to be IF %config%==interlnk GOTO . . . .
If you're batch-savvy, you may know about the CALL statement. The CALL statement makes it possible for one batch job to activate another batch job without DOS's forgetting about the original batch job. For you nonbatchers, activating one batch program from inside another doesn't ordinarily cause DOS to finish the first batch job once the second has been run. For example, assume that you have a batch job called X.BAT that looks like this.
@echo off echo Message from X Y echo Last message from X
Also, assume that you have a batch program called Y.BAT that looks like this.
@echo off echo Message from Y
Running X will result in the screen's showing this.
Message from X Message from Y
There will be no Last message from X.
That's because starting one batch program from inside another batch program causes COMMAND.COM - the program that executes batch programs - to load Y.BAT in anticipation of executing it and to accidentally over-write X.BAT in COMMAND.COM's memory. As a result, when Y ends, COMMAND.COM returns to the command prompt, not to the finishing lines of X.BAT. If, on the other hand, the line Y that stands by itself in X.BAT is replaced by CALL Y, COMMAND.COM will remember X.BAT, and the output will be as follows.
Message from X Message from Y Last message from X
The CALL command will, then, provide an alternative to inserting the various AUTOEXEC.BATs physically into the master AUTOEXEC.BAT. To apply this, recall the AUTOEXEC.BAT that we ended up with in August looks like this, with three sections.
@ECHO OFF IF %config%==standard GOTO STANDARD IF %config%==maxmemory GOTO MAXMEMORY IF %config%==wingcomm GOTO WINGCOMM :STANDARD PROMPT $P$G PATH C:\DOS DOSKEY PRINT /Q SMARTDRV GOTO END :MAXMEMORY PROMPT $P$G PATH C:\DOS LH DOSKEY GOTO END :WINGCOMM CD\GAMES\WC2 WC2 GOTO END
The standard section is the stuff that you usually use, the interlnk section sets up an Interlnk server, and the wingcomm section sets up a configuration that allows Wing Commander II - a very memory-intensive game - to run. But instead of merging these files, imagine that you have batch files called STANDARD.BAT, MAXMEM.BAT, and WINGCOMM.BAT. Inside the sections you could simply insert CALL STANDARD, CALL MAXMEM, or CALL WINGCOMM. The final AUTOEXEC.BAT look like this.
@ECHO OFF IF %config%==standard GOTO STANDARD IF %config%==maxmemory GOTO MAXMEMORY IF %config%==wingcomm GOTO WINGCOMM :STANDARD CALL STANDARD GOTO END :MAXMEMORY CALL MAXMEM GOTO END :WINGCOMM CALL WINGCOMM GOTO END :END
Now, there's an even more compact way of doing this that involves just doing the CALL statements from inside the Ifs; the AUTOEXEC.BAT would look like this.
@ECHO OFF IF %config%==standard CALL STANDARD IF %config%==maxmemory CALL MAXMEM IF %config%==wingcomm CALL WINGCOMM
That's probably an acceptable alternative, and it certainly makes converting a bunch of configurations to a single AUTOEXEC.BAT easier, but it won't work if the %config% variable gets altered by one of the batch files. The chances of that happening are small, so this may be the simplest method of unifying AUTOEXEC.BATs for most people.
If you're a batch expert, a look at the amalgamated batch file above will probably lead you to notice that I could've reorganized some of the statements to make the AUTOEXEC.BAT smaller. That's certainly true, and if you want to do that for your AUTOEXEC.BAT, go ahead. I didn't because I like the clearly defined separate areas for the different configurations.
Making It Simple
Let's get back to the CONFIG.SYS part of MultiConfig. In my example, I end up it a CONFIG.SYS that looks like this.
[menu] menuitem normal, Standard setup menuitem interlnk, Setup with Interlnk driver menudefault normal,2
[normal] FILES=60 BUFFERS=30 STACKS=9,256 DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH
[interlnk] FILES=60 BUFFERS=30 STACKS=9,256 DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH DEVICE=C:\DOS\INTERLNK.EXE
You'll notice that a group of statements is common to both configurations. There are just a few statements that you can expect all configurations to have-perhaps an essential device driver, FILES/BUFFERS/ LASTDRIVE/STACKS statements, and the like. In the case of my example configuration, the commands that are common to the two configurations are as follows.
FILES=60 BUFFERS=30 STACKS=9,256 DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH
You can save yourself some typing by extracting a common group of statements and making it a block by giving it a block name and using the MultiConfig command INCLUDE. Just remove the group of statements from all configurations that use it, and precede it with a name in brackets, just like the configurations that you've been building so far.
Where the group of statements used to be in each configuration, insert the phrase INCLUDE [blockname], where blockname is whatever you've called the block of statements common to the configurations. For example, if I create a block called [shared] that contains the statements that are shared between the configurations, the CONFIG.SYS look like this.
[menu] menuitem normal, Standard setup menuitem interlnk, Setup with Intelnk driver menudefault normal, 2
[shared] FILES=60 BUFFERS=30 STACKS=9,256 DEVICE=C:\DOS\HIMEM.SYS DOS=HIGH
[normal] INCLUDE shared
[interlnk] INCLUDE shared DEVICE=C:\DOS\INTERLNK.EXE
You can have as many INCLUDE blocks as you like. For example, you might have an INCLUDE block with your memory management commands (EMM386/HIMEM/ DOS=HIGH,UMB), another with your LAN drivers, another with Interlnk commands, and so on.
If you have a bunch of statements that are common to all configurations, you can create a block containing those statements, and then include them in each block. But there's an easier way: using the [common] block.
There's a predefined block called [common], which, if included in your CONFIG.SYS, will automatically be executed at the end of every configuration. Just include [common] on a line and follow it with whatever statements you want to see executed, no matter which configuration gets selected.
I strongly recommend that you have a [common] block and that you put it at the end of your CONFIG.SYS. That way, when you install a program that inserts commands into your CONFIG.SYS statement, the new statements will usually be placed at the end.
If the last block is the [common] block, you know that the statements will be executed; if the last block isn't the [common] block, the newly inserted statements won't be executed unless the last block happens to get executed, which would probably cause the newly installed program to fail.
Speak Up!
Do you have a tough hardware problem that you would like Mark to tackle? Let him know about it by calling (900) 884-8681, extension 7010202. The call will cost 95 cents per minute, you must be 18 or older, and you must use a touch-tone phone. Sponsored by Pure Entertainment, P.O. Box 186, Hollywood, California 90078.