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." <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/

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* 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.

"Bill in Co." <not_really_here@earthlink.net> wrote in message
news:OV%237Jl8tIHA.2292@TK2MSFTNGP03.phx.gbl...
> 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." <not_really_here@earthlink.net> 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* 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.

Bite me you fool. Back into the boob bin you go.
>

Pegasus (MVP) wrote:
> "Bill in Co." <not_really_here@earthlink.net> wrote in message
> news:OV%237Jl8tIHA.2292@TK2MSFTNGP03.phx.gbl...
>> 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!

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).

PD43 wrote:
> "Bill in Co." <not_really_here@earthlink.net> 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* 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.
>
> 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.

"Bill in Co." <not_really_here@earthlink.net> wrote in message
news:%23QTkwV%23tIHA.2188@TK2MSFTNGP04.phx.gbl...
> Pegasus (MVP) wrote:
>> "Bill in Co." <not_really_here@earthlink.net> wrote in message
>> news:OV%237Jl8tIHA.2292@TK2MSFTNGP03.phx.gbl...
>>> 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!
>
> 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

Pegasus (MVP) wrote:
> "Bill in Co." <not_really_here@earthlink.net> wrote in message
> news:%23QTkwV%23tIHA.2188@TK2MSFTNGP04.phx.gbl...
>> Pegasus (MVP) wrote:
>>> "Bill in Co." <not_really_here@earthlink.net> wrote in message
>>> news:OV%237Jl8tIHA.2292@TK2MSFTNGP03.phx.gbl...
>>>> 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!

(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. :-)

>> 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

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.

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* 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

"John John (MVP)" <audetweld@nbnet.nb.ca> wrote in message
news:O6TfJvcuIHA.3792@TK2MSFTNGP02.phx.gbl...
> 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* 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
>


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



--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access

Colon Terminus wrote:
> "John John (MVP)" <audetweld@nbnet.nb.ca> wrote in message
> news:O6TfJvcuIHA.3792@TK2MSFTNGP02.phx.gbl...
>> 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* a 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. 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.

Indeed, and I thank him again.

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.

Bill in Co. wrote:

> 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.

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

Bill in Co. wrote:

> Colon Terminus wrote:
>
>>"John John (MVP)" <audetweld@nbnet.nb.ca> wrote in message
>>news:O6TfJvcuIHA.3792@TK2MSFTNGP02.phx.gbl...
>>
>>>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* a 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. 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.
>
>
> Indeed, and I thank him again.

You are both welcome.

John