is cmd.exe a shell, a terminal emulator or both?

The architecture of Linux and Windows is different. That's really it - you should not look for similarities when there are none.

Linux is based on UNIX, which goes back to the days of dumb terminals. Graphics devices were highly specialised (and expensive), and uncommon. Most UNIX access was through character driven terminals (asynchronous at that).

There were many manufacturers of terminal devices. One of the most successful at that time was DEC (since taken-over by HP) who had a series of terminals used on their VAX computers: vt52 was the most basic, vt100, vt220, vt320 gave increasing functionality. Terminal emulators like putty emulate those. IBM, HP, and others all had their own devices as well.

The problem is that all these terminals were different, and had to be driven differently. So a database of terminal instructions was created, first called termcap and then terminfo. The database was accessed depending on the setting of the TERM environment variable, which is still used.

In comes graphics, specifically Xterm, and a terminal window. The database has control information for xterm, and the TERM variable is set accordingly.

Of course Microsoft's Windows is a totally alien operating system so far as UNIX is concerned, so it has to pretend to be a UNIX terminal. That is what a terminal emulator like putty is. It will be pretending to be one of those ancient terminals that are nowadays only found in museums.

So, cmd.exe is not a terminal emulator because it is a Windows application running on a Windows machine. There is no need to emulate anything.

It is a shell, depending on your definition of what a shell is. Microsoft consider Windows Explorer to be a shell. In other words a shell is just a program that runs other programs. Most UNIX/Linux people would not call a GUI a shell, but that's just semantics.

cmd.exe is a console program, and there are lots of those. For example telnet and python are both console programs. It means they have a console window, that's the monochrome rectangle you see. Some people think that is the same as cmd.exe (and even worse call it a "DOS box"), but it is not, it just uses the same console APIs. A Windows graphics program has a "Main Window" associated with it, but it can if it wishes create a console as well! They don't usually, but they can.

cmd.exe scripts have .bat (or less common now .cmd) file extensions by default. But this file extension association is just a set of lookups in the Windows registry (HKEY_CLASSES_ROOT). There is no magic here, it is just like associating .doc with Microsoft Office Word, instead .bat is associated with cmd.exe.

One of the clever features of UNIX is the #! line on scripts. This can be used to run bash, ksh, sed, awk, perl, python, ruby, etc, etc. If you have more than one version of, say, python installed, then you just change the #! line to pickup the right one. No such flexibility on Windows, you can only associate one program at a time with a file extension.

Agreeing that cmd is not a terminal emulator, whether it is a shell depends upon your expectations. Microsoft refers to it as a command interpreter. As a command interpreter (including a variety of built-in features — see Command-line reference A-Z), it is able to interpret scripts. A terminal emulator is concerned with display, and input/output — something entirely different.

However, the part of the answer given regarding console windows is less helpful than it could have been.

Console windows are a special case of Windows application: they emulate the behavior of MS-DOS, etc., but applications running in them (or using them) are not limited to the MS-DOS behavior because the console window is after all a Windows application.

The documentation for AllocConsole says:

This function is primarily used by graphical user interface (GUI) application to create a console window. GUI applications are initialized without a console. Console applications are initialized with a console, unless they are created as detached processes (by calling the CreateProcess function with the DETACHED_PROCESS flag).

Here are a few links which discuss this further:

• Adding Console I/O to a Win32 GUI App
• Adding GUI to c++ win32 console
• How to create a Windows program that works both as a GUI and console application
• Determine Whether a Program Is a Console or GUI Application

Regarding OP's final question: cmd.exe is the default command interpreter on Windows, and is associated with the ".bat" file suffix. (That is, it is the program invoked by default when Windows is told to "open" a file suffixed with ".bat".) File associations are (mostly) a feature used in the Windows File Explorer. An analogous feature in Unix would be the mailcap configuration.

In Windows convention, you can "open" a file with an alternative application by using it as a parameter to the application. Windows' cmd.exe has a special command start which can be used to open a file using the default application (see for example Open a file in the default application using the Windows command line (without JDIC)).

Like Unix shell interpreters, cmd has an option (/c) for allowing you to run it explicitly with a given command string. There are third-party command interpreters for Windows; some extend cmd.exe, while others are ports of Unix programs.

CMD.exe is a Win32 console program and there is nothing special about it from a window perspective. Type in Start - Run (Winkey + R) while looking in Task Manager (Ctrl + Shift + Escape).

cmd.exe

close then

ftp.exe ftp.microsoft.com

All console programs have a console and work differently to GUI programs (what's a GUI program - one that doesn't have a console). Usually, but not always, we start cmd then ask cmd to start another console program. But CMD is not required as you can see from ftp program example above.

From Help

Character-Mode Applications

Consoles manage input and output (I/O) for character-mode applications (applications that do not provide their own graphical user interface).

The console functions enable different levels of access to a console. The high-level console I/O functions enable an application to read from standard input to retrieve keyboard input stored in a console's input buffer. The functions also enable an application to write to standard output or standard error to display text in the console's screen buffer. The high-level functions also support redirection of standard handles and control of console modes for different I/O functionality. The low-level console I/O functions enable applications to receive detailed input about keyboard and mouse events, as well as events involving user interactions with the console window. The low-level functions also enable greater control of output to the screen.

This overview describes support for character-mode applications.

Send comments about this topic to Microsoft

Build date: 10/2/2006

CMD is also the Telnet interface.