On my systems that are running MS-DOS, I change the default command.com to 4DOS for more features.
How was the shell system designed and how did it with the operating system in MS-DOS that it enabled you to swap in a different one?
Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.Sign up to join this community
Traditionally, operating shells are relatively independent of the operating system’s function and the operating system can operate without a shell. Most shells have two modes of operation, interactive mode where they manage the command line and execute commands entered interactively, and batch mode where they run scripts. They’re “standard” programs which handle whatever the input and output system is, and provide their features with no extra special sauce.
In DOS, the “kernel” is provided by two files, typically
IBMDOS.COM). These are loaded at boot-up; they read
CONFIG.SYS for configuration, and once all the device drivers have loaded and initialised, they load the shell and start running it. By default the shell is
COMMAND.COM on the boot disk, but this can be overridden by the
SHELL directive in
In theory you’d expect the IO and DOS portions of the kernel to provide the “real” operating system, and then COMMAND.COM to follow the standard model of shell design on top of that, but in DOS the distinction between the three parts of the core operating system aren’t as well delineated as you might hope. Because of the way DOS works, with no protection between processes, and using fairly well-documented (or reverse-engineered) functions via the 0x21 interrupt, operating system functions could be implemented in various places, and extended by any number of programs, so the “kernel”, command interpreter and extension TSRs ended up constituting a closely-tied ecosystem... Over the course of its history, DOS ended up relying on COMMAND.COM for certain features, and some of the features DOS provided to COMMAND.COM ended up being extended in ways users expected to find; replacement DOS shells had to provide the former, and ideally respect the latter.
Some examples will hopefully help understand the kinds of issues involved better.
COPYare implemented in the command processor); replacement shells ideally need to implement this too. Some third-party programs used this to call internal commands or even add new internal commands to DOS, so replacement shells need to support the same mechanism (interrupt 0x2E — invoking this allows internal commands to be run from outside the shell, and hooking this allows internal commands to be added — and the installable command functions 0x2FAE¹).
COMSPECvariable was used to point COMMAND.COM to the right file).
Most of this was documented at the time, and what wasn’t was quickly discovered. Nowadays you can read the source code for FreeCOM or 4DOS, or even MS-DOS itself, if you’re curious to see exactly how a DOS shell works...
¹ See this PC Magazine Tutor article, “Replacing internal DOS commands”, for details.