 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Windows Forum / Windows XP / General Topics 1 / May 2008The differences between cmd.exe and command.com, in practice, for running DOS apps
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. >Has anyone played around with this extensively to know just what DOS >applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 5 lines] >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/ >> Has anyone played around with this extensively to know just what DOS >> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 12 lines] > > 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. >>> Has anyone played around with this extensively to know just what DOS >>> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 18 lines] >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. >>>> Has anyone played around with this extensively to know just what DOS >>>> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 24 lines] > > 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. >>>Has anyone played around with this extensively to know just what DOS >>>applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 18 lines] > 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 >>>>Has anyone played around with this extensively to know just what DOS >>>>applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 57 lines] > > John Finally an intelligent, understandable answer to the OP's query. Thank you John John. >>>>> Has anyone played around with this extensively to know just what DOS >>>>> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 65 lines] > Finally an intelligent, understandable answer to the OP's query. > Thank you John John. Indeed, and I thank him again. >>>>>>Has anyone played around with this extensively to know just what DOS >>>>>>applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 67 lines] > > Indeed, and I thank him again. You are both welcome. John >>>> Has anyone played around with this extensively to know just what DOS >>>> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 22 lines] > > 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 [quoted text clipped - 3 lines] > 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 [quoted text clipped - 20 lines] > > 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. >>>>>Has anyone played around with this extensively to know just what DOS >>>>>applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 83 lines] > 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 [quoted text clipped - 4 lines] > 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 > Has anyone played around with this extensively to know just what DOS > applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 5 lines] > 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! >> Has anyone played around with this extensively to know just what DOS >> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 10 lines] > 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). >>> Has anyone played around with this extensively to know just what DOS >>> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 17 lines] > 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 >>>> Has anyone played around with this extensively to know just what DOS >>>> applications "command.com" (16 bit shell) will run successfully, that [quoted text clipped - 11 lines] >>> 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") [quoted text clipped - 5 lines] > 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. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.