I argued with my friend that the Command Prompt is just a GUI version of MS-DOS which works in the Windows forms environment. He totally disagrees with me.
Who is right?
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this communityThis was true once, but it isn't anymore.
From MS-DOS # Windows command-line interface - Wikipedia:
All versions of Microsoft Windows have had an MS-DOS like command-line interface (CLI). This could run many DOS and variously Win32, OS/2 1.x and Posix command line utilities in the same command-line session, allowing piping between commands. The user interface, and the icon up to Windows 2000, followed the native MS-DOS interface.
Consumer Windows (up to 3.11, Win9x, WinME) ran as a Graphical User Interface (GUI) running on top of MS-DOS. With Windows 95, 98, and ME the MS-DOS part was integrated, treating both operating systems as a complete package. The command line accessed the DOS command line (usually command.com), through a Windows module (winoldap.mod).
A new line of Windows, (Windows NT), boot through a kernel whose sole purpose is to load Windows. One can not run Win32 applications in the loader system in the manner that OS/2, UNIX or Consumer Windows can launch character mode sessions.
So no, in every Windows from the NT family (e.g., XP, Vista, 7, 8), the command prompt and MS-DOS are visually similar, but quite different.
cmd.exe
would have been command.com
, a rather small part of MSDOS.
(Unless your definition of equality does not extend past »*It is a text interface and I can run programs from it.*«)
What is run when you click Command Prompt in the Start Menu is the Windows Command Processor, a.k.a. cmd.exe
. Its built-in commands and scripting syntax (including many quirks) are based on the ancient command.com
from CP/M and later MS-DOS, but apart from that they are completely separate things. Also, command.com
is a 16-bit program while cmd.exe
is a native Windows console application.
Things were different in Windows 95, 98 and ME where command.com
would be run in a MS-DOS VM with Windows acting as the hypervisor (yes, they had that sort of thing at the time already). There you had an entire virtual machine running DOS. But on Windows NT, 2000, XP, Vista and 7 – no. DOS only lives on there in ntvdm.exe
which is the NT Virtual DOS Machine which is just a thin emulation layer capturing calls that the CPU cannot execute directly (which is why it works faster but worse than DOSBox).
In any case, even command.com
was just a shell for DOS. It wasn't the operating system.
Inside, I actually cringe each time I see people referring to a window with gray-on-black text as MS-DOS. In the vast majority of cases they don't actually know what they're referring to.
They are different things - The Command Prompt is Not MS-DOS - but as far as the user is concerned they could be the same thing as they do the same things.
So it depends on your point of view. From a technical point of view your friend it correct, but from a user perspective you are correct (sort of as there are differences that an expert would spot).
From what I understand, MS-DOS is the disk operating system that Microsoft released. The command prompt is a non-graphical interface that allows you to interact with your operating system.
Command Prompt is a command line interpreter application available in most Windows operating systems, officially called the Windows Command Processor but sometimes called the command shell. Command Prompt is a Windows program that emulates many of the command line abilities available in MS-DOS but it is not actually MS-DOS.
Command Prompt is a GUI version of command.com in MS-DOS. cmd.exe is a native Windows application usually running in a Win32 console. This allows it to take advantage of features available to native programs on the platform that are otherwise unavailable to DOS programs.
For example, since cmd.exe is a native text-mode application on OS/2, it can use real pipes in command pipelines, allowing both sides of the pipeline to run concurrently. As a result, it is possible to redirect the standard error in cmd.exe, unlike COMMAND.COM. (COMMAND.COM uses temporary files, and runs the two sides serially, one after the other.)
In reality, cmd.exe is a Windows program that acts as a DOS-like command line interpreter. It is generally compatible, but provides extensions which address some of the limitations of COMMAND.COM (above explanations are referred by Wikipedia).
Apparently lots of people don't realise that the DOS Prompt, and the Windows Command Prompt are not the same thing. They're actually two different programs - COMMAND.COM and CMD.EXE respectively.
Firstly due to differences in the platform (DOS vs Windows) and interpreter (command.com
vs cmd.exe
), there will be obvious dissimilarities like
mode con:cols=COL lines=ROW
command to resize the console, and no title
commandBut there are also major differences in the capabilities and syntax of internal commands between command.com
and cmd.exe
, as well as some external tools in the two environments. In MS-DOS there are
dir 1>out.txt
, dir 2>err.txt
, dir >out.txt 2>&1
doesn't work()
or local scopes which means
for
, if
... must be followed by a single command on the same line, no for ... (multiple lines)
or if ... (multiple lines)
no exit /b
or goto :eof
no setlocal
and endlocal
goto
can only jump to a label, call
can only start another batch file instead of calling a function or doing indirect expansion
commands can't be grouped together like
(
command1
command2
) >output.txt
call set %%var%suffix%=string
) of variables and no delayed expansion (e.g. echo !var%suffix%!
)^
. Printing special characters would be a pain, and no possibility of running multi-line commands or passing special arguments to programsif
, which means
if cmdextversion
and if defined
if [/i] string1 compare-op string2
~xxxV
variable expansion support%variable:~num1,num2%
or string replacement support %variable:str=newstr%
set
:
set
(things like set com
or set pro
won't work)set "var=value"
syntaxset /a
so you can't do arithmeticset /p
which means reading user input is a painfor /d
, for /r
or for /l
. No for /f
so reading input from files is also difficult. The only form of for
in DOS is FOR %variable IN (set) DO command [command-parameters]
%*
variable for the whole command linefindstr
, and find
doesn't support Unicode%CD% %DATE% %TIME% %RANDOM% %ERRORLEVEL% %CMDEXTVERSION% %CMDCMDLINE% %HIGHESTNUMANODENUMBER%
pushd/popd
cd /d
. Also no cd path with spaces
and cd "path with spaces"
due to the lack of long file name supportcolor
commandforfiles
which means running commands on files or getting special character is even more complexshift /N
. You can only shift a single argument at a timeassoc
or ftype
(because there are no GUI and files must be opened manually from command line, so no file association is needed)Many other internal commands are not available either: dpath
, keys
mklink
, start
. A lot of useful external commands in Windows like where
, sort
, more
(in some DOS versions), choice
... are also missing in DOS
And this is what MS' Rich Turner said
Also, Cmd != MS-DOS!
I also want to point out a common misconception perpetuated by articles like the ones above: Cmd <> MS-DOS!
In FACT:
- Microsoft last shipped a "new" version of MS-DOS (v8.0 in Windows ME), on September 16th, 2000 - 16 years ago (as of this writing)!!
- MS-DOS was an operating system (albeit a relatively simple OS by today's standards) whose primary user-interface was a command-line shell, until Windows 3.x & 9.x arrived and ran on/around MS-DOS
- MS-DOS' command-line shell's scripting language was relatively terse and moderately powerful, but lacked many of the richer, and more advanced features we enjoy in modern-day PowerShell, Bash, etc.
- While later versions of MS-DOS grew in sophistication and added/replaced some older assembly with new code written in 'C', much of MS-DOS remained written in x86 assembly for efficiency, and because it was the only way at the time to gain access to many hardware devices and peripherals. This made MS-DOS non-portable to non-x86 CPU's. If you're so inclined, you can actually download the source code for MS-DOS v1.1 and v2.0 to see just how much of the earlier versions of MS-DOS were written in x86 assembly (hint: pretty much all of it)!
https://devblogs.microsoft.com/commandline/rumors-of-cmds-death-have-been-greatly-exaggerated/
.bat
files differ from old MS DOS .bat
files?In conclusion, functionality-wise they may be a little bit similar, but otherwise hugely different
Your friend is right. MS-DOS is/was an Operating System (Microsoft Disk Operating System is what the acronym stands for.) The UI for DOS is called a (the) command prompt.
The first few versions of Windows ran on top of DOS (making them technically operating environments, though I'm not sure anybody makes that distinction anymore), but later OSes, starting with the NT Kernel, didn't - DOS was gone.
However, people still needed the functionality provided by the command prompt, and instead of command.com we got command.exe (and these days cmd.exe), which when run gives us a command prompt.
But, that's not the only (nor anywhere near the first) command prompt that people have used. Command Prompts are also called Shells, and Unix has many, and the commands are different and often very powerful. Speaking of Power, Microsoft has created a new command prompt for Windows called PowerShell which is incredibly powerful and interesting. See Wikipedia for more: http://en.wikipedia.org/wiki/Command-line_interface#Operating_System_Command-Line_Interfaces
cmd.exe
is a whole different beast from MS-DOS.