The differences between cmd.exe and command.com, in practice, for running DOS apps

[Bill in Co.]

Has anyone played around with this extensively to know just what DOS
applications "command.com" (16 bit shell) will run successfully, that
"cmd.exe" (32 bit shell) cannot (under XP)?

Note: "cmd.exe" is newer and more "featured", of course (and also handles
long filenames), but isn't quite as compatible for running some DOS apps.

Just wondering if anyone has any personal experiences they can share on
this. I seem to have noticed a few already, but was curious.

 

[Bill in Co.]

Google (it's your friend) "XP command line commands"

First reference listed:

http://www.ss64.com/nt/

Did you READ what I wrote? I have already *read* plenty about it, know
the differences, and have worked with both of them, but I wanted to hear
some case histories (as I WROTE) of what some had found they had incidents
with (i.e., not running well on CMD.EXE, but running well under
COMMAND.COM).

Reading 101.

 

[Pegasus \(MVP\)]

Has anyone played around with this extensively to know just what DOS
applications "command.com" (16 bit shell) will run successfully, that
"cmd.exe" (32 bit shell) cannot (under XP)?

Note: "cmd.exe" is newer and more "featured", of course (and also handles
long filenames), but isn't quite as compatible for running some DOS apps.

Just wondering if anyone has any personal experiences they can share on
this. I seem to have noticed a few already, but was curious.

Cmd.exe is the Windows XP command processor. Command.com
is a legacy processor that you should only use for 16-bit applications
that won't run properly under cmd.exe. Avoid it if you can!

 

[Bill in Co.]

Cmd.exe is the Windows XP command processor. Command.com
is a legacy processor that you should only use for 16-bit applications
that won't run properly under cmd.exe. Avoid it if you can!

I know that, but I was curious as to which apps someone had problems with
(that worked fine under "command.com" under XP, but not under "cmd.exe")

There are plenty of apps that won't work with either, however (and HAVE to
run under REAL DOS).

 

[Bill in Co.]

Bite me you fool.

OK, I give up. You apparently can't really comprehend what I said, and
I'll just have to accept that.

Still, it is a bit disappointing. But maybe it's just (yet another) sign
of the newage times, though.

 

[Pegasus \(MVP\)]

I know that, but I was curious as to which apps someone had problems with
(that worked fine under "command.com" under XP, but not under "cmd.exe")

There are plenty of apps that won't work with either, however (and HAVE to
run under REAL DOS).

Consider installing DOS in a Virtual PC. It's free.
http://www.microsoft.com/windows/virtualpc/default.mspx

 

[Bill in Co.]

(well, that's a bit "dramatic".
(I've used both, and don't mind (too much) the limitations of each, and it
keeps me from getting too rusty - with DOS.

Consider installing DOS in a Virtual PC. It's free.
http://www.microsoft.com/windows/virtualpc/default.mspx

I've thought of that. Or "VirtualBox" (also free), which I hear (at least
from some reviews) is even better, in many respects. But I haven't really
found the need to go quite that far just yet! (I'm thinking using a VPC
would be more appropos for another windows operating system, or Linux, but
not so much for just using DOS, on occasion) A bit overkill, IOW.

Right now I also have a 1 GB Flash USB stick with DOS, which I can boot up
on, if needbe.

And - in case anybody's interested, there is also a good DOS emulator (free)
called DOSBox, which works well for some of the older DOS games.

 

[John John (MVP)]

Did you READ what I wrote? I have already *read* plenty about it, know
the differences, and have worked with both of them, but I wanted to hear
some case histories (as I WROTE) of what some had found they had incidents
with (i.e., not running well on CMD.EXE, but running well under
COMMAND.COM).

You need to do more reading. The version of Command.com that ships with
NT versions is not the same thing at all as the MS-DOS/Windows 9x
version. The NT version of Command.com only runs inside the NT Virtual
Dos Machine (NTVDM) and only has a few internal commands, these internal
commands are used to configure the DOS subsystem from the Config.nt or
Autoexec.nt files, or they are only accepted for compatibility with
files from MS-DOS. The Config.nt and Autoexec.nt files are processed
when Command.com is launched. The Command.com internal configuration
commands are:

BUFFERS, COUNTRY, DEVICE, DEVICEHIGH, DOS, DOSONLY, DRIVEPARM,
ECHOCONFIG, FCBS, FILES, INSTALL, LOADHIGH, LASTDRIVE, NTCMDPROMT,
SHELL, STACKS, and SWITCHES

Any other commands run by Commmand.com are actually run by Cmd.exe. The
NT version of Command.com prepares and passes all of the commands it
receives to Cmd.exe for execution, that is why the two CLI's appear
seemingly to be able to run the same commands, they are because Cmd.exe
runs the commands for Command.com so in fact Command.com can take
advantage of the commands available with Cmd.exe.

If you want to observe the use of Cmd.exe by Command.com start the the
Task Manager and then launch Command.com and you will see the NTVDM
start in the Task Manager, you will not see Command.com. Now, give a
bit of work to the Command.com 16-bit processor and keep an eye on the
Task Manager and you will see Cmd.exe appear and then disappear when it
executes the command it received from Command.com. If the amount of
work to do is too little you won't see CMD.EXE appear in the Task
Manager, the work will be over before Task Manager responds. A good
command to run to see this would be the DIR /s command from the root folder:

cd\
dir /s

The dir/s command will list all the files on the volume, to stop the
output of the dir /s command press Ctrl+Break.

John

 

[Colon Terminus]

You need to do more reading. The version of Command.com that ships with
NT versions is not the same thing at all as the MS-DOS/Windows 9x version.
The NT version of Command.com only runs inside the NT Virtual Dos Machine
(NTVDM) and only has a few internal commands, these internal commands are
used to configure the DOS subsystem from the Config.nt or Autoexec.nt
files, or they are only accepted for compatibility with files from MS-DOS.
The Config.nt and Autoexec.nt files are processed when Command.com is
launched. The Command.com internal configuration commands are:

BUFFERS, COUNTRY, DEVICE, DEVICEHIGH, DOS, DOSONLY, DRIVEPARM, ECHOCONFIG,
FCBS, FILES, INSTALL, LOADHIGH, LASTDRIVE, NTCMDPROMT, SHELL, STACKS, and
SWITCHES

Any other commands run by Commmand.com are actually run by Cmd.exe. The
NT version of Command.com prepares and passes all of the commands it
receives to Cmd.exe for execution, that is why the two CLI's appear
seemingly to be able to run the same commands, they are because Cmd.exe
runs the commands for Command.com so in fact Command.com can take
advantage of the commands available with Cmd.exe.

If you want to observe the use of Cmd.exe by Command.com start the the
Task Manager and then launch Command.com and you will see the NTVDM start
in the Task Manager, you will not see Command.com. Now, give a bit of
work to the Command.com 16-bit processor and keep an eye on the Task
Manager and you will see Cmd.exe appear and then disappear when it
executes the command it received from Command.com. If the amount of work
to do is too little you won't see CMD.EXE appear in the Task Manager, the
work will be over before Task Manager responds. A good command to run to
see this would be the DIR /s command from the root folder:

cd\
dir /s

The dir/s command will list all the files on the volume, to stop the
output of the dir /s command press Ctrl+Break.

John

Finally an intelligent, understandable answer to the OP's query.
Thank you John John.

 

[Bill in Co.]

You need to do more reading.

Probably true. One can never learn too much....

The version of Command.com that ships with
NT versions is not the same thing at all as the MS-DOS/Windows 9x
version. The NT version of Command.com only runs inside the NT Virtual
Dos Machine (NTVDM) and only has a few internal commands, these internal
commands are used to configure the DOS subsystem from the Config.nt or
Autoexec.nt files, or they are only accepted for compatibility with
files from MS-DOS.

The Config.nt and Autoexec.nt files are processed when Command.com is
launched.

Yes, I am aware of that.

The Command.com internal configuration commands are:

BUFFERS, COUNTRY, DEVICE, DEVICEHIGH, DOS, DOSONLY, DRIVEPARM,
ECHOCONFIG, FCBS, FILES, INSTALL, LOADHIGH, LASTDRIVE, NTCMDPROMT,
SHELL, STACKS, and SWITCHES

I didn't know it was that limited.

Any other commands run by Command.com are actually run by Cmd.exe.

Now THAT is interesting to know. Thanks.

The NT version of Command.com prepares and passes all of the commands it
receives to Cmd.exe for execution, that is why the two CLI's appear
seemingly to be able to run the same commands, they are because Cmd.exe
runs the commands for Command.com, so, in fact, Command.com can take
advantage of the commands available with Cmd.exe.

If you want to observe the use of Cmd.exe by Command.com start the the
Task Manager and then launch Command.com and you will see the NTVDM
start in the Task Manager, you will not see Command.com. Now, give a
bit of work to the Command.com 16-bit processor and keep an eye on the
Task Manager and you will see Cmd.exe appear and then disappear when it
executes the command it received from Command.com. If the amount of
work to do is too little you won't see CMD.EXE appear in the Task
Manager, the work will be over before Task Manager responds. A good
command to run to see this would be the DIR /s command from the root
folder:

cd\
dir /s

The dir/s command will list all the files on the volume, to stop the
output of the dir /s command press Ctrl+Break.

John

Thanks for all this additional info, John. That's quite a bit to think
about, too.

But, interestingly enough, when I tried running some old DOS games under a
shortcut or PIF to "command.com", I occasionally got better results than I
did when I tried running it under a shortcut to "cmd.exe" (even though the
two are so well linked together, per what you wrote above). Maybe I'm
misrembering this, but I don't think so.

So - that part surprises me, in view of what you have written (which, if I
can paraphrase it, basically seems to say that "cmd.exe" can handle it more
completely (and by invoking "command.com", when needed) much better than
running anything "directly" under a "command.com" shortcut. But what I
found seemed to contradict that: that in some instances, running some old
DOS game directly under a shortcut to "command.com" worked better. (Hmmm.
maybe that has more to do with the "configuration options" I chose (or
didn't use), however).

Many (if not most) of these old 16 bit DOS games (etc) generally don't work
well down here either, and usually require something like DOSBox, to work
properly.

 

[Bill in Co.]

Finally an intelligent, understandable answer to the OP's query.
Thank you John John.

Indeed, and I thank him again.

 

[John John (MVP)]

Probably true. One can never learn too much....




Yes, I am aware of that.




I didn't know it was that limited.




Now THAT is interesting to know. Thanks.




Thanks for all this additional info, John. That's quite a bit to think
about, too.

But, interestingly enough, when I tried running some old DOS games under a
shortcut or PIF to "command.com", I occasionally got better results than I
did when I tried running it under a shortcut to "cmd.exe" (even though the
two are so well linked together, per what you wrote above). Maybe I'm
misrembering this, but I don't think so.

Cmd.exe is exclusively 32-bit, Command.com is exclusively 16-bit. All
MS-DOS programs are 16-bit and when run on NT operating systems they are
run in the NTVDM, cmd.exe does not interact directly with the Virtual
Dos Machine, command.com does. 16-bit application do not run in the
32-bit environment.

So - that part surprises me, in view of what you have written (which, if I
can paraphrase it, basically seems to say that "cmd.exe" can handle it more
completely (and by invoking "command.com", when needed) much better than
running anything "directly" under a "command.com" shortcut. But what I
found seemed to contradict that: that in some instances, running some old
DOS game directly under a shortcut to "command.com" worked better. (Hmmm.
maybe that has more to do with the "configuration options" I chose (or
didn't use), however).

As I said earlier, Cmd.exe is not designed to run 16-bit programs, it
only runs in a 32-bit environment. Also, the Command.com internal
MS-DOS configuration commands are not available under Cmd.exe, these DOS
commands are arcane relics and they are not used in the NT 32-bit
environment.

Many (if not most) of these old 16 bit DOS games (etc) generally don't work
well down here either, and usually require something like DOSBox, to work
properly.

Many will run fine as long as they don't insist on having direct access
to the hardware, that is why many DOS programs fail to run on NT
systems, NT does not permit direct access to the hardware. I agree with
you that DOSBox can be a useful solution for some DOS applications.

John

 

[John John (MVP)]

Indeed, and I thank him again.

You are both welcome.

John