A command interpreter is not a console.

You've come to this page because you've said something similar to the following:

This is the Frequently Given Answer to such erroneous statements. Of course, it applies to platforms that have "consoles" in the first place. A similarly common error is to erroneously conflate consoles and terminals, which are two quite different paradigms for operating systems. Don't erroneously conflate command interpreters and terminals, either.

CMD (and COMMAND and indeed 4NT, sh, ksh, and csh) are command interpreters, not consoles. They aren't in charge of displaying consoles, and they don't even own consoles.

Command interpreters are ordinary application programs that run on top of the operating system. They are just Textual User Interface programs that use consoles (when they are in interactive mode) for their user interfaces. They have open handles to the consoles that they use, just like they have open handles to the files that they use. They no more "own" or "display" the consoles because of this than they "own" or "store" the files that they have open handles to.

Like many other kernel objects in the system, consoles are just non-persistent system objects that stick around until the last handle to them is closed. (There's some slight complexity to this. Console programs on Windows NT and TAU have a hidden reference to their primary consoles, so even if they close all application-visible handles to consoles, this hidden reference, from the process object itself to the console object, keeps the console around. The process is "attached" to the console object. There's a slightly different situation with IBM OS/2, but the same overall effect.) There's no special "owner" of a console object via these open handles, and no process that has a handle to a console — or to its input and output buffer sub-objects — is distinguished as special in some way. The console object sticks around until the last one of the references to it, attachments from processes and open handles to the object, is gone.

TUI programs that use consoles either inherit these open handles from their parent processes or explicitly open handles to a console (using the "CON" device file) or to its current input or output buffer (using the "CONIN$" and "CONOUT$"device files). To such processes, handles to console objects are little different to handles to open files. They're inherited from parents, opened, closed, and used.

How console windows are displayed on the GUI and who owns them

Sometimes consoles are displayed not with a true Textual User Interface, with the display adapter hardware in text mode. Rather, they are displayed as windows that are part of a Graphical User Interface, with the display adapter hardware in graphics mode. (It's easy to tell when the actual display adapter hardware is in graphics mode. There are certain things that it is impossible to do in text mode, such as have more than 16 colours at once. It's sometimes quite difficult to tell when the actual display adapter hardware is in text mode. It is possible to provide quite a convincing emulation of MDA/CGA/EGA/VGA text modes in graphics mode. Indeed, some systems, most notably Microsoft Windows NT's Blue Screen of Death, are actually in graphics mode even though they appear to be text mode.)

There is another process, a server process, that displays and owns the console window(s) that display(s) the contents of the console output buffer(s). On TAU, it's a PM Console Daemon, for example.

On Microsoft Windows NT versions up to version 6.0, that server process was the Client-Server Runtime SubSystem process. This process used to be the server process for most Win32 API functions made by Win32 applications programs. They were implemented as remote procedure calls, made by passing messages over a dedicated "local RPC" connection between the Win32 application the CSRSS process. (In the original Windows NT 3.0 design, everything related to the user interface, GUI or TUI, in Win32 was a remote procedure call to CSRSS, and display drivers and the like were user-space DLLs loaded within that process.) The procedure calls for consoles in CSRSS were implemented by code in a WINSRV.DLL library that CSRSS was dynamically linked to.

By the time of Windows NT 4, much of the Win32 GUI API functionality had moved out of CSRSS into the kernel, to a WIN32K driver that set up a whole new set of system calls, which applications invoked instead of passing messages to a server program over an LRPC connection. But the client-server remote procedure calls for consoles remained in CSRSS. It wasn't until Windows NT 6.1 that they moved out of the CSRSS process into a process of their own, CONHOST, which CSRSS started. (The reasons for this are discussed by Raymond Chen in detail and relate to the security problems of allowing untrustable "theming" code to run in a process that runs under the aegis of the "Local System" account rather than under the aegis of the account of the logged in user.) So on Windows NT 6.1 and later, it is CONHOST that owns and paints the windows within which console output buffers are displayed.

Even on IBM OS/2, which (it being the first system to which second system effect was applied for Windows NT) has a rather ad hoc approach to this sort of thing, the console windows are owned by the "Session Manager" process, not by the various TUI programs (such as the command interpreter, CMD) that simply use consoles.

© Copyright 2011 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.