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

Question

In Linux I have shells (for instance bash, csh etc.) and terminal emulators (for instance xterm). Shells execude commands and terminal emulators display black window with white letters.

And how is it in Windows? I know I have cmd.exe there, but what is it? Is it a shell, or is a terminal emulator, or is it both?

And how is called the interpreter that executes bat files? Are they executed by cmd.exe or by something else?

Answer 1

A little history on the terms: Back in the days when computers were huge and complicated, there were consoles to operate them. This was not seldom just a set of buttons to manipulate the internal state of the computer and some lamps on the computer displayed the state. More complex commands were entered via paper tape or punch cards.

Newer computers used small printers or teletypewriters (TTY) to print output. And the typewriters could also be used to type in command lines, that were executed by the computer. This was basically a more direct (and much slower) alternative to the tapes or cards - but allowed some kind of dialogue between the programmer and the computer. These so-called terminals were a more advanced end-point for the programmers, than the original consoles were, but they served the same purpose. That's why these two terms are often used interchangeably.

Now it gets a little complicated: when computers were connected with each other, one could access another computer from the terminal they were sitting in front of, without having to walk to the terminal of the other computer. This was not an easy task, because the first computer had to act, as if it were the terminal of the second computer by sending the same signals over the cable, that the real terminal would send. So they wrote programs to do that, that were called terminal emulator.

On modern computers, the internals of the operating system are encapsulated so that the user does not have access. There is also no need for that, because there are programs making life easier for you. These programs are called shell. They can be graphically, like the Windows Explorer, that e.g. allows you to copy files from A to B without having to worry about where on the memory or even hard drive the file is actually written to. In this case the commands can be entered with mouse and keyboard.

A shell can also be text-based, like the cmd.exe. It asks for a command by displaying a command prompt like C:\> and you type in a command line, that will be interpreted. So the cmd.exe is a special kind of shell: a command interpreter.

If you are using a graphical user interface, the window where you enter text is like a terminal emulator to the text-based interface. What's why I prefer calling it terminal window or just terminal.

What you see when you open the cmd.exe (e.g. by clicking on it from the explorer) is actually the terminal window conhost.exe. There are also others like ConEmu or the new Windows Terminal.

---

tl;dr: cmd.exe is a command interpreter (a type of shell), that is often executed in a terminal window like conhost.exe.

---

And to the last question: a *.bat file is also called batch file. It contains multiple commands, like a batch (or stack) of punch cards. Each of these commands is interpreted by cmd.exe.

Answer 2

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.

Answer 3

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.

Answer 4

The history of CMD.EXE goes back to the time when IBM needed command line interface for it's x86 based IBM PC computers - Microsoft made MS-DOS (Disk Operating System) which was the first interface and it was indirectly influenced by Unix -style shell interface in that it had possibility to navigate subdirectories, execute commands in PATH and also create .BAT files which run several commands in sequel.

After graphical UI became commodity, the CMD.EXE was created as a DOS-emulator which could run older MS-DOS based programs capable of emulating the old EGA/VGA based display, mostly in the text mode. It was also possible to emulate to some extend the graphics modes in full screen mode. Later, the support for older graphics modes was removed from the the CMD.EXE and the purpose of it's existence was geared towards text based interface for power users.

However the CMD.EXE was legacy interface and remained inferior when compared to Unix systems. Furthermore, it lacked access to many features to administrate important Windows operating system tasks properly - something that Unix users take for granted. In the early 2000's Microsoft begun developing alternative way of running power-user administrative tasks using command line interface, the PowerShell.

Answer 5

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.