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

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

[Guest PD43]

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

 

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

 

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

[Guest Bill in Co.]

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

 

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

 

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.

[Guest Pegasus \(MVP\)]

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

 

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

 

 

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

[Guest PD43]

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

 

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

 

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

>

[Guest Bill in Co.]

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

 

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

 

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

[Guest Bill in Co.]

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

 

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

 

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.

[Guest Pegasus \(MVP\)]

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

 

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

 

 

"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

[Guest Bill in Co.]

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

 

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

 

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.

[Guest John John (MVP)]

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

 

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

 

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

[Guest Colon Terminus]

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

 

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

 

"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

[Guest Bill in Co.]

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

 

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

 

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.

[Guest Bill in Co.]

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

 

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

 

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.

[Guest John John (MVP)]

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

 

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

 

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

[Guest John John (MVP)]

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

 

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

 

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