| Windows Console | |
|---|---|
A Windows Console withcmd.exe inWindows 10 20H2 | |
| Other names | Win32 console |
| Developer | Microsoft |
| Written in | C++ |
| Operating system | Microsoft Windows |
| Platform | IA-32,x86-64,ARM64 |
| Type | Terminal emulator |
| License | MIT License |
| Website | docs |
| Repository | github |
Windows Console is aGUI application for runningconsole applications inWindows. Windows Console is used for runningtext-basedprograms such asoperating systemshells (e.g.Command Prompt andPowerShell),utilities (e.g.Far Manager) and some, generally older,applications (e.g.Midnight Commander).
Windows Terminal was introduced inWindows 10 as a replacement for Windows Console.[1] In 2019, the console host wasopen-sourced under theMIT License, alongside Windows Terminal.[2]


Windows Console runs in either window or full-screen mode. The mode can be toggled by pressingAlt+↵ Enter.
In window mode, the console writes text in awindow and uses an operating system'sfont rendering. In this mode, an application'suser interaction is controlled by the windowing system, analogous toX Window System applications such asxterm.
InWindows XP and earlier, the full-screen console uses ahardware text mode and uploads araster font to thevideo adapter, analogous to a text-basedsystem console. This early full-screen mode only supports VGA-compatible text modes, giving it a maximum characterresolution of 80columns by 28 rows.[3] This mode was removed inWindows Vista,[4] although untilWindows 8, it was possible to circumvent this issue by installing a Windows XP display driver.[4][5]
Windows 10 features a full-screen mode once again. The implementation uses the native Windows rendering subsystem instead of the text mode, and supports rows and columns to fill the screen.[6]
A program may programmatically interact with its host console via theWindows API, which exposes both high-level functions (such asReadFile,ReadConsole,WriteFile, andWriteConsole) and low-level functions (e.g.ReadConsoleInput andWriteConsoleOutput).[7]
A user can configure the consolefont orcolor palette, either system-wide or at the application level. An instance of a console application, however, cannot change its font or color palette on the fly.
A console application is distinct from anMS-DOS application, even though on Windows (especially onWindows 9x), they may not look different. A console application has access to theWindows API and does not run on MS-DOS or compatible systems. A DOS application cannot access the Windows API and only runs on a 32-bit version of Windows with the aid ofVirtual DOS machine (VDM).
An instance of a Windows Console has ascreen buffer and aninput buffer. The input buffer is a queue where events are stored (fromkeyboard,mouse etc.). The output buffer is a rectangular grid where characters are stored, together with their attributes. A console window may have several output buffers, only one of which is active (i.e. displayed) for a given moment.
InWindows 3.1 and earlier, there is no native support for consoles. Because those version are merely a graphical interface for MS-DOS, most text programs that ran on earlier Windows versions were actually MS-DOS programs running in a window. To simplify the task of porting applications to Windows, early versions ofVisual C++ are supplied withQuickWin, a library that implements basic console functionality inside a regular window. A similar library forBorland C++ was calledEasyWin.

Windows 9x support is relatively poor compared toWindows NT, because the console window runs in the systemvirtual DOS machine and so keyboard input to a Win32 console application had to be directed to it byconagent.exe running in a DOS VM that are also used for real DOS applications by hooking the keyboard interrupt.conagent.exe then callsVcond (which is aVxD).Vcond then had to pass the keyboard input to the System VM, and then finally to the Win32 console application. Besides performance, another problem with this implementation is that drives that are local to a DOS VM are not visible to a Win32 console application. This can cause confusion.
Under Windows 9x, the screen buffer mirrors the structure ofVGA text buffer, with two bytes per character cell: one byte for character code, one byte for attributes (the character must be inOEM character set, the attribute is with high-intensity background/no blinking). This speeds up operation considerably if the actual VGA text mode is used.


Traditionally, theClient/Server Runtime Subsystem (CSRSS) has been responsible for managing console windows on theWindows NT family of operating systems.[8] InWindows 7, CSRSS spawns oneconhost.exe for each console window, to manage it. InWindows 8 and later, the console applications spawn theirconhost.exe processes directly. This change has both security and usability implications. While CSRSS runs in a highly privileged security context, eachconhost.exe runs in the same security context as the console app. In addition, in Windows 7, this change enabled console windows to have the features of theAero Glass theme.[9]
On Windows NT andWindows CE, the screen buffer uses four bytes per character cell: two bytes for character code, two bytes for attributes. The character is then encoded in a 16-bit subset ofUnicode (UCS-2).[10] For backward compatibility, the console APIs exist in two versions: Unicode and non-Unicode. The non-Unicode versions of APIs can usecode page switching to extend the range of displayed characters (but only ifTrueType fonts are used for the console window, thereby extending the range of codes available). EvenUTF-8 is available as "code page 65001"[11] (displaying only from the UCS-2 subset of full Unicode[citation needed]).
As of theWindows 10 October 2018 update, the Windows Console has full Unicode support.[12]
XDDM and VGA drivers will not compile on Windows 8 and later versions
Console: Fix for no output text being displayed in codepage 65001 (utf8)