John John (MVP) wrote:
> Bill in Co. wrote:
>> PD43 wrote:
>>
>>> "Bill in Co." <not_really_here@earthlink.net> wrote:
>>>
>>>
>>>> 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.
>>>>
>>>
>>> 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* aa bit 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.

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.