Master 512
Forum by Robin Burton
Beebug Vol. 10 No. 3 July 1991
Some possible Forum topics tend to be ignored because I think of them as obvious, or basic facts everyone probably already knows.
Perhaps they're not. I guess from the response to a Forum a couple of months ago that some subjects are perhaps worth covering in more detail after all.
COMMAND.COM REVISITED
You'll recall that recently I mentioned loading a second copy of COMMAND.COM as a fix for some programs that normally won't run in the 512. It's not a new discovery, quite the opposite in fact, and it was explained in one of the first Forums nearly three years ago. Obviously some of you had forgotten it, or perhaps hadn't even heard of it, so it turned out to be well worth covering again. It also prompted a letter which provides the subject for this month's Forum.
First, thanks to Doug Blyth from Epsom for writing to tell me that TAXCALC, a PC program from Which? magazine responds to this fix and now runs in his 512. I should mention that Doug had written to me quite some time ago asking if I knew if this program could be made to work in the 512, but at the time I wasn't able to help. The reason was simply that Doug didn't send a copy of the program with his query, while I (incorrectly as is now obvious) had assumed he'd tried reloading COMMAND.COM because it's the first thing I try if a program fails to run. It just shows that we can all forget basics and that the cure for a problem might be so simple we overlook it.
I'm also indebted to another member, David Harper, first for confirming that this fix also works for version 4.00 of the shareware spreadsheet As-Easy-As, and for reminding me about another point I haven't covered in the Forum.
There wasn't enough space in the last issue to cover COMMAND.COM, but in any case the point that David raises deserves a separate article of its own to do it justice. Here it is, with some extra detail and explanation added for the benefit of newer 512 users, plus some example files in case you want to try things for yourself.
COMMAND LINE SWITCHES
A useful feature of DOS Plus which almost everyone uses from time to time is the command line switch. The most frequently used are probably '/P' after a 'TYPE' or a 'DIR' command to output the display in paged mode, a '/W' for a wide directory display, or '/S', which enables access to system files which otherwise would be ignored in operations such as 'DIR' or 'COPY'.
What DOS Plus users might not realise however, is that these switches are not a DOS standard, by which I mean they aren't provided by PC-DOS or MS-DOS. One illustration is something referred to in BEEBUG Vol.9 No.7, the MS-DOS utility MORE. MS-DOS users are obliged to employ piping through an extra program to produce exactly the same effect as the much more convenient '/P' used in DOS Plus. In fact command line switches are common to all Digital Research operating systems, from the 8-bit CP/M of ten years ago up to and including the latest version of DR-DOS.
What does this have to do with reloading COMMAND.COM? Well, you'll remember that 'EXIT', terminates a second copy of COMMAND and returns you to a single DOS command shell, freeing 30K of memory as it does so. David points out that if you use the '/C' switch when the extra copy of COMMAND is loaded the 'EXIT' is automatic, saving you the need to (remember to) do it. Here's how it works.
Suppose we want to run a program which requires a second copy of COMMAND.COM to be loaded and we want this second copy to be terminated automatically at the end of the program run. First let's point out that it doesn't matter whether the program in question is just a utility that does a single job and then terminates, or is a more substantial application such as As-Easy-As, which you might use for hours before returning to DOS. In all cases the method is exactly the same.
For illustration we'll use a text editor, and with the usual flair and imagination for which the Forum is well known we'll call the program EDIT. The file to be edited? What else but 'TEXT.DOC'! Assuming drive A: as the current drive, doing things manually (i.e. the long way) the sequence of commands would be:
A>COMMAND
A>EDIT TEXT.DOC
at which point the application would load, followed by the file and we'd then proceed to edit it. When we finished the job we'd save the file again then exit the editor back to the DOS command line. Next we must enter:
A>EXIT
to remove the second copy of COMMAND.COM and free its 30K of memory. David points out that there's a much more direct method which reduces the above three commands to just one entry, like this:
A>COMMAND /C EDIT TEXT.DOC
If you didn't know that COMMAND.COM could take command line parameters just like many other DOS programs, you do now. In fact, it's virtually the same technique as that used by DOS itself when the system first starts up. The major difference when you boot the system is that you never get to see the command line, but if you did, it would be 'COMMAND AUTOEXEC'.
Of course, in this case DOS has first made sure that there is an AUTOEXEC.BAT file, and if there isn't then COMMAND.COM is simply loaded without a command tail. You might have noticed when the system starts up (though you'll only be aware of it using floppies) that after the initial XIOS copyright display the system very clearly scans the disc again, and there's a distinct delay while it finds out whether or not there's an AUTOEXEC file to load. Of course this is just information for interest, it's not directly useful, so now back to our example.
To understand how the '/C' switch works we'll take the command entry apart and see what happens to it. The first point is that one copy of COMMAND.COM is already resident of course, and this permanent copy processes all manual or batch file command input, so the command is initially treated just like any other that calls a program from disc.
As usual, the first item on the line (up to the first space) is the name of the executable file which is to be loaded, in this case COMMAND. As normal DOS looks for and loads a file with that filename and a 'COM, 'CMD', 'EXE' or 'BAT' extension. When the second copy of COMMAND.COM is loaded the remainder of the original line, consisting of:
/C EDIT TEXT.DOC
is passed to the newly loaded program as its own command tail. The second COMMAND.COM therefore potentially has three parameters to process. The first one is the part we're most interested in here, the '/C'. That tells COMMAND that when the next action or operation ends, the program should remove itself from memory.
The remainder of the original command line is then processed by (the second) COMMAND.COM in the same way as it would be if it had been entered directly from the keyboard. The next parameter is again the name of a program, which in turn is loaded in the normal manner and according to the usual rules. The final parameter, the filename, is then passed to this new program as its command tail.
You can see that; although the command line is entered in one, in fact it is processed piecemeal so that each parameter is treated almost like a separate command. It is therefore important to remember that the position of the '/C' is critical. It must immediately follow COMMAND, otherwise it might be passed to the application as one of its parameters, with numerous potential results, none of which would be the right one.
Naturally all this is transparent to the user sitting at the machine, so when editing is complete and we finally leave the editor, the extra copy of COMMAND.COM then actions the original '/C' parameter, which it has remembered throughout. The extra copy of COMMAND.COM therefore terminates immediately with no further user input and all the previously occupied RAM is freed.
Another point which you'll notice if you use this technique is that the usual copyright display seen when a second copy of COMMAND is loaded, which appears as:
DOS Plus Version 2.1
Copyright Digital Research (c) 1985,1986
isn't displayed when the '/C' switch is used. This is obviously of little importance during manual entry, but it clearly points the way to other possibilities offered by the '/C' switch.
BATCH FILES AGAIN
A potential problem in batch files in the 512 is the fact that some programs will only work if a second COMMAND.COM is loaded. Without the '/C' switch the need for a second COMMAND shell appears to restrict the use of such programs in batch files unless you load COMMAND manually before you start the batch file. You can prove this yourself if you don't see why by creating and running the example file I'll explain in a moment.
Before you start, however, issue a 'BACKG' command and note how much free RAM you have in your machine if you're not sure. In a standard 512 this should be 358K, in an expanded machine, 614K. Obviously, if you use TSRs as in your 512 these will reduce the free memory figures slightly.
Having done this, from the command line type:
COPY CON DEMO.BAT
followed by Return. This will open the file 'DEMO.BAT' for output to the current directory on the current drive. Next, type in the lines shown below, following each line with a Return.
COMMAND
ECHO Hello Mum
EXIT
On or after the end of the last line press Ctrl-Z and another Return, which will close the file and return you to the DOS prompt. Make sure that COMMAND.COM is in a current path, then run the file by entering 'DEMO'.
You'll see that a second COMMAND.COM loads by the fact that it announces itself with the copyright message shown above. However, that's all you'll see for the moment, because execution of the batch file is then immediately suspended and you're presented with a normal DOS prompt (from which you can execute programs as normal).
The reason for this effect is that the initial call to the batch file was made through the original, permanent copy of COMMAND.COM. However, as soon as the second copy is loaded and for as long as it remains active the original COMMAND.COM is no longer in control, hence it cannot continue with execution of the batch file.
To prove this, next enter BACKG' again and you'll see from the reduction in free memory (30K less than before) that the second copy of COMMAND is in RAM. 'BACKG' is of course a transient program, so running it clearly demonstrates that you're using a normal command line, but the rest of this test will also show that you're doing so from within a batch file.
You can at this stage execute any command you'd normally use on the command line, including execution of yet more batch files. What's more, one of those batch files could be 'DEMO' (again) if you like. This you can also prove, but before trying this, read the rest of the article, for reasons which will become clear later.
For now just type 'EXIT', followed by Return and you'll see that immediately following your entry the line 'Hello mum' appears, followed by the echoed display then yet another 'EXIT', this one being the one in the batch file. You can see that the 'EXIT' in the batch file, which you might have expected to remove the second copy of COMMAND.COM, serves no useful purpose in fact, because it's too late by the time it is processed!
Given the explanation of what happened when the file began execution, you can probably guess what's now happened. As soon as the 'EXIT' is entered manually the second copy of COMMAND terminates. After this control returns to the original, permanent copy, which then resumes processing of the batch file from the point it had reached when control was taken away from it.
Now create another batch file called, say 'DEMO2', but this time include a '/C' and a 'BACKG' on the COMMAND line, like this:
COMMAND /C BACKG
ECHO Hello Mum
EXIT
When you run it you'll immediately see the difference. 'BACKG' is run from the second COMMAND.COM as the free RAM display will prove, but that copy then terminates immediately and execution of the batch file will resume automatically.
The benefits of this are obvious, you can after all run programs that need a second copy of COMMAND.COM from batch files successfully without manual intervention. Secondly, and as a side effect of the '/C' parameter, you will avoid cluttering the screen with the DOS Plus copyright display in the middle of the execution of a batch file.
LIMITATIONS
To round off this month I'll return to the point about running batch files from a second shell, itself created within a batch file. Given normal (that is, sensible) use there's no problem at all, apart from that of the reduction in free RAM in unexpanded machines. However, as an experiment I tried running 'DEMO.BAT' repeatedly and on the 21st run I received the message:
Internal error 08
Not enough memory to load command.com
Not surprising really! 19 'EXIT's later I was nearly back to where I'd started, each 'EXIT' producing the expected effect, but I should warn you that making DOS tie itself in knots like this is almost certain to crash the system sooner or later. Sure enough, on the 20th 'EXIT' it did crash, quite gently really, with a permanent display of:
Not enough memory to load command.com
At this point nothing had any further effect, except that repeated Ctrl-Cs caused the message to be repeated. The system was obviously quite prepared to continue like this ad infinitum.
The only surprise to me was that the system proved to be far more tolerant of this type of abuse than I'd expected. I'd anticipated a crash at any moment after the fourth nested 'DEMO' run. I didn't bother to find out how many I could actually get away with safely, it's certainly more than three and quite enough for any sensible purpose, so I'll leave it to you to investigate the limit if you're interested.
Obviously what happens ultimately is that somewhere in DOS a data store overflows (probably one of the system stacks) with the result that the system loses its way and finally can't remember how to get out again.