You've come to this page because you've said something similar to the following:
- The command interpreter owns the console …
- CMD controls the console …
- CMD displays the console …
- I passed the XYZ option to the console on its command line …
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.
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.