Command vs. Cmd
Posted on:: September 2nd, 2003
TIP: In Windows, typing “command” into the Run box brings up a DOS window. Typing “cmd” also brings up a DOS window, but with “cmd” you can use the arrow keys to cycle through previous command lines, etc.
Why “command” even exists beats me. If it’s for backwards compatibility, then why not add the basic set of user interface facilities in “cmd”?
Oh well. Some things we just aren’t meant to understand.
Categories: Uncategorized dw
Command and Cmd are really pretty different.
On NT-based systems, command.com launches a DOS window – an encapsulated instance of Microsoft’s DOS command interpreter running in a window. 640k base memory + extended, no long filenames (dir shows them but you can’t cd into them or use them), all that jazz. Single thread. Allows DOS programs to run that expect to be able to write to memory with impunity (but is limited by the virtual machine to the 640k+extended that it can see). If you want command history, you run doskey.exe, as you would in DOS. Yes, only really useful for backward compatibility. I never use it.
cmd.exe launches a windows NT command shell. NT’s capabilities without the GUI (well as long as there’s a program available for what you want to do or if you write one yourself). Long filenames, vastly extended batch language (try /? against each of pushd,popd,for,set,if for a start), command history, access to NT services and security model that aren’t available with command.exe. multi-threaded. Disallows messing with memory owned by other processes.
cmd.exe is absolutely essential to any system administrator as a commandline scripting environment. I can’t do without it.
Hope that helps.
you can get into long-named files and dirs under command.com with their tilde-ified short names.
ie
cd progra~1
rather than
cd program files
Helps??? It’s perfect! Thanks.
cmd does more things, one of my fav being the tab based auto complete, similar to that of Unix shells.
Random Tip time. Did you know that you can drag and drop a file on the CMD window and it’s filename will appear as if it was typed in at the prompt.
Where is this stuff documented???
I very much like what You are doing here on this forum – Thanks! Please also take a look at our sites about the Okanagan Valley in B.C., (British Columbia) Canada – Some useful real estate and accommodation Links.
Lake Okanagan ResortOsoyoos B.C., South Okanagan, real estate and area information.Osoyoos B.C.Kelowna information.Kelowna
great read
Never using command again. Thanks for the tip.
I had a problem with command.com on an XP system and found you can set the system to use cmd.exe as a default by including “ntcmdprompt” in the config.nt file in Win2000 or XP.
With cmd you can use the tab key to complete statements like in UNIX and you can put long file names in quotes instead of having to type progra~1. None of this is possible in command.
CMD.exe is more compatible and portable between different platforms. COMMAND is included for backwards compatibility. It is recommended to use COMMAND when MS-DOS programs may not be able to be ran in Windows NT.
The old command.com honors ANSI escape sequences like any decent vt100 terminal or emulator since the 1980s. But cmd.exe has no ANSI support that I can figure out. So much for nice color/bold highlighting in log files and error outputs.
Actually cmd can create ANSI output by using the /a switch with the CMD command.
Why “command” even exists beats me. If it’s for backwards compatibility, then why not add the basic set of user interface facilities in “cmd”?
To aid your understanding, cmd.exe is a 32-bit binary executable, possibly 64-bit if you run a 64-bit version of windows. COMMAND.COM is a 8/16 bit DOS 1 compatible binary with no executive wrappings. This is the compatibility which must be maintained.
.EXE files were a late arrival to DOS, allowing for programs larger than 64K. A .COM file has no header, so does not require relocation in memory. The CS and DS pointers point to the same 64K conventional memory page, all addresses are 16-bit so you cannot address any memory outside you programs 64K page. EXEcutables allow you to set a different DS (Data Segment) and CS (Code Segment) page, taking your programs to 128K and you can add a seperate SS (Stack Segment) and ES (Extra Segment) all witout using any Memory manager.
The Executive Kernel of DOS 3+ (And some extended versions of DOS 2) will allocate these memory pages for you according to the EXE Header. .COM files have no header. EXE defines an MZ header, but when the 386 came along with Protected and Extended modes for 32-bit processing, we aquired true 16-bit LE headers in .EXE files for Windows 3.1.
The PE header was added for true 32-bit executables in Windows NT2, as taken from Microsoft OS/2 before that became IBM OS/2 v2. PE was ported to DOS based windows Kernels with the Win32s extension to Windows for Workgroups 3.2, optionally, you can add this to Windows 3.1. It was finally the standard executable format on Windows 95 and up.
The fact of the matter is that the APIs provided by cmd.exe are true 32/64 bit windows APIs and are far to complex for any DOS based system.
It’s not a matter of adding backwards compatibility to cmd.exe, it’s a case of what you could not do with cmd.exe if it had to be run under the 16-bit VDM (Virtual DOS Machine) or WOW (Windows On Windows, that’s 16-bit Windows applications on a 32-bit Windows Kernel) as COMMAND.COM does.
For many 16-bit applications to work under VDM or WOW, the standard COMMAND.COM has to be accessible to them. 64K page frames don’t exist once the processor is bumped into 32-bit Extended / Protected mode, so it is not possible to run .COM files without the VDM virtualisation that emulates those CPU features to the application. However, 16-bit applications will expect COMMAND.COM to be in a certain 64K page frame. Once in that Virtual Machine you have no access to the 32-bit APIs of Windows.
Many extension, for long file names and Workgroup LAN access and such have been added to more recent Windows versions after 3rd party developers made their money from them in the bad old days of Windows 3.1. Essentially using a copy and paste, system between 16Bit virtual code and 32Bit native code applications. But this is very slow. Windows NT and OS/2 have always had a cmd.exe native to them. Adding back COMMAND.COM is only so that 16Bit applications designed for DOS or 16/32 hybrid Windows versions can call “COMMAND.COM” and load it in the same 16Bit Virtual Machine as they are running.
I hope this makes things clearer.
FYI this traditional trend of physical architectural change to PCs and the havoc it wreaks on backward compatibility while taking advantage of the much needed technological improvements of those architecture changes, is probably Microsofts real reason for wanting developers to switch to producing .Net code, which is not compiled to a native Binary form, but rather interpreted or JIT compiled (compiled as the executable is loaded from disk, into memory).
Despite the fact that this makes programs load up slower from disk, and execute slower on the PC it leaves iNTEL, Motorola and AMD free to change their CPUs as much as they want, and leave the OS to handle how the executable is actually run. Meaning they all make more money, and we (the users) stop winging that our applications don’t work on our new PC, and they don’t need to add 15 layers of virtualisation for backward compatibility. (See VDM, WOW, WOW64 etc or Apples Fat Binaries, Universal Binaries and Classic compatibility layers and X-Windows Server) Open Source Applications and Operating systems hold a distinct advantage in this field. Especially the Unicies, (Unix, Linux, BSD, HP-UX and Solaris) because they traditionally expect the user to modify the source files, headers etc. and compile the source for their platform as part of the installation process. Programs which depend on other programs will therefore never make assumptions about what hardware they are running on, and never modify code in memory as many DOS and 16-bit Windows applications did.
It also means you can install the exact same program on your ARM based palmtop PC as your desktop Intel/AMD PC, without there being two different binary code files to do the same job on the different platforms. The reason why PowerPC and DEC Alpha versions of Windows NT 4 and 2000 failed to make a dent in any market at all. There’s more Apple and NeXT software for PPC and more Sun/Solaris and HP-UX software for DEC Alpha than there is Windows Software compiled for either processor.