Windows Console and Terminal Ecosystem Roadmap

This document is a high-level roadmap of the Windows Console and Windows Terminal products. It covers:

How Windows Console and Windows Terminal fit into the ecosystem of command-line applications across Windows and other operating systems.

A history and future roadmap of the products, features, and strategies that are part of building the platform, as well as building for this platform.

The focus of the current console/terminal era at Microsoft is to bring a first-class terminal experience directly to developers on the Windows platform and to phase out classic Windows Console APIs, replacing them with virtual terminal sequences utilizing pseudoconsole. Windows Terminal showcases this transition into a first-class experience, inviting open source collaboration from the developer community, supporting a full spectrum of mixing and matching of client command-line and terminal hosting applications, and unifying the Windows ecosystem with all other platforms.

Definitions

Architecture

The general architecture of the system is in four parts: client, device, server, and terminal.

Client

The client is a command-line application that uses a text-based interface to enable the user to enter commands (rather than a mouse-based user interface), returning a text representation of the result. On Windows, the Console API provides a communications layer between the client and the device. (This can also be a standard console handle with device control APIs).

Device

The device is an intermediate message-handling communications layer between two processes, the client and the server. On Windows, this is the console driver. On other platforms, it is the TTY or PTY device. Other devices like files, pipes, and sockets may be used as this communication channel if the entire transaction is in plain text or contains virtual terminal sequences, but not with Windows Console APIs.

Server

The server interprets the requested API calls or messages from the client. On Windows in the classic operating mode, the server also creates a user interface to present the output to the screen. The server additionally collects input to send back in response messages to the client, via the driver, like a terminal bundled in the same module. Using pseudoconsole mode, it instead is only a translator to present this information in virtual terminal sequences to an attached terminal.

Terminal

The terminal is the final layer providing graphical display and interactivity services to the user. It is responsible for capturing input and encoding it as virtual terminal sequences, which eventually reach the client’s STDIN . It will also receive and decode the virtual terminal sequences that it receives back from the client’s STDOUT for presentation on the screen.

Further connections

As an addendum, further connections can be performed by chaining applications that serve multiple roles into one of the endpoints. For instance, an SSH session has two roles: it is a terminal for the command-line application running on one device, but it forwards all received information on to a client role on another device. This chaining can occur indefinitely across devices and contexts offering broad scenario flexibility.

On non-Windows platforms, the server and terminal roles are a single unit because there is no need for a translation compatibility layer between an API set and virtual terminal sequences.

Microsoft products

All of the Microsoft Windows command-line products are now available on GitHub in an open source repository, microsoft/terminal.

Windows Console Host

This is the traditional Windows user-interface for command-line applications. It handles all console API servicing called from any attached command-line application. Windows Console also handles the graphical user interface (GUI) representation on behalf of all of those applications. It is found in the system directory as conhost.exe , or openconsole.exe in its open source form. It comes with the Windows operating system. It can also be found in other Microsoft products built from the open source repository for a more up-to-date implementation of the pseudoconsole infrastructure. Per the definitions above, it operates in either a combined server-and-terminal role traditionally or a server-only role through the preferred pseudoconsole infrastructure.

Windows Terminal

This is the new Windows interface for command-line applications. Windows Terminal serves as a first-party example of using the pseudoconsole to separate the concerns between API servicing and text-based application interfacing, much like all non-Windows platforms.

Windows Terminal is the flagship text-mode user interface for Windows. It demonstrates the capabilities of the ecosystem and is driving Windows development toward unifying with other platforms. Windows Terminal is also an example of how to build a robust and complex modern application that spans the history and gamut of Windows APIs and frameworks. Per the definitions above, this product operates in a terminal role.

Major historical milestones

The major historical milestones for the console subsystem are broken into implementation prior to 2014 and then moves into an overview of work performed since 2014, when the renewed focus on the command-line was formed in the Windows 10 era.

Initial Implementation

[1989-1990s] The initial console host system was implemented as an emulation of the DOS environment within the Windows operating system. Its code is entangled and cooperative with the Command Prompt, cmd.exe , that is a representation of that DOS environment. The console host system code shares responsibilities and privileges with the Command Prompt interpreter/shell. It also provides a base level of services for other command-line utilities to perform services in a CMD-like manner.

DBCS for CJK

1999 Around this time, DBCS support («Double-byte character set») is introduced to support CJK (Chinese, Japanese, and Korean) markets. This effort results in a bifurcation of many of the writing and reading methods inside the console to provide both «western» versions to deal with single-byte characters as well as an alternative representation for «eastern» versions where two bytes are required to represent the vast array of characters. This bifurcation included the expanding representation of a cell in the console environment to be either 1 or 2 cells wide, where 1 cell is narrow (taller than it is wide) and 2 cells is wide, full-width, or otherwise a square in which typical Chinese, Japanese, and Korean ideographs can be inscribed.

Security/Isolation

2007 With the console subsystem experience running inside the critical system process, csrss.exe , connecting assorted client applications, at varying access levels, to a single super-critical and privileged process was noticed as particularly dangerous. In this era, the console subsystem was split into client, driver, and server applications. Each application could run in their own context, reducing the responsibilities and privilege in each. This isolation increased the general robustness of the system, as any failure in the console subsystem no longer affected other critical process functionality.

User Experience Improvements

2016 After a long time of generally scattered maintenance of the console subsystem by assorted teams across the organization, a new developer-focused team was formed to own and drive improvements in the console. Improvements during this time included: line selection, smooth window resizing, reflowing text, copy and paste, high DPI support, and a focus on Unicode, including the convergence of the split between «western» and «eastern» storage and stream manipulation algorithms.

Virtual Terminal client

2017 With the arrival of the Windows Subsystem for Linux, Microsoft efforts to improve the experience of Docker on Windows, and the adoption of OpenSSH as the premier command-line remote execution technology, the initial implementations of virtual terminal sequences were introduced into the console host. This allowed the existing console to act as the terminal, attached directly to those Linux-native applications in their respective environments, rendering graphical and text attributes to the display and returning user input in the appropriate dialect.

Virtual Terminal server

[2018] Over the past twenty years, third-party alternatives for the inbox console host were created to offer additional developer productivity, prominently centered in rich customizations and tabbed interfaces. These applications still needed to run and hide the console host window. They attach as a secondary «client» application to scrape out buffer information in polling loops as the primary command-line client application operated. Their goal was to be a terminal, like on other platforms, but in the Windows world where terminals were not replaceable.

In this time period, the pseudoconsole infrastructure was introduced. Pseudoconsole permits any application to launch the console host in a non-interactive mode and become the final terminal interface for the user. The main limitation in this effort was the continued compatibility promise of Windows in servicing all published Windows Console APIs for the indefinite future, while providing a replacement server-hosting interface that matched what is expected on all other platforms: virtual terminal sequences. As such, this effort performed the mirror image of the client phase: the pseudoconsole projects what would be displayed onto the screen as virtual terminal sequences for a delegated host and interprets replies into Windows-format input sequences for client application consumption.

Roadmap for the future

Terminal applications

[2019-Now] This is the open source era for the console subsystem, focusing on the new Windows Terminal. Announced during the Microsoft Build conference in May 2019, Windows Terminal is entirely on GitHub at microsoft/terminal. Building the Windows Terminal application on top of the refined platform for pseudoconsole will be the focus of this era, bringing a first-class terminal experience directly to developers on the Windows platform.

Windows Terminal intends not only to showcase the platform — including the WinUI interface technology, the MSIX packaging model, and the C++/WinRT component architecture — but also as a validation of the platform itself. Windows Terminal is driving the Windows organization to open and evolve the app platform as necessary to continue to lift the productivity of developers. The Windows Terminal unique set of power user and developer requirements drive the modern Windows platform requirements for what those markets truly need from Windows.

Inside the Windows operating system, this includes retiring the classic console host user interface from its default position in favor of Windows Terminal, ConPTY, and virtual terminal sequences.

Lastly, this era intends to offer full choice over the default experience, whether it is the Windows Terminal product or any alternative terminals.

Client support library

[Future] With the support and documentation of virtual terminal sequences on the client side, we strongly encourage Windows command-line utility developers to use virtual terminal sequences first over the classic Windows APIs to gain the benefit of a unified ecosystem with all platforms. However, one significant missing piece is that other platforms have a wide array of client-side helper libraries for handling input like readline and graphical display like ncurses. This particular future road map element represents the exploration of what the ecosystem offers and how we can accelerate the adoption of virtual terminal sequences in Windows command-line applications over the classic Console API.

Sequence Passthrough

[Future] The combination of virtual terminal client and server implementations allows the full mixing and matching of client command-line and terminal hosting applications. This combination can speak to either the classic Windows Console APIs or virtual terminal sequences, however, there is an overhead cost to translating this into the classic compatible Windows method and then back into the more universal virtual terminal method.

Once the market sufficiently adopts virtual terminal sequences and UTF-8 on Windows, the conversion/interpretation job of the console host can be optionally disabled. The console host would then become a simple API call servicer and relay from device calls to the hosting application via the pseudoconsole. This change will increase performance and maximize the dialect of sequences that can be spoken between the client application and the terminal. Through this change additional interactivity scenarios would be enabled and (finally) bring the Windows world into alignment with the family of all other platforms in the command-line application space.

Общие сведения о программировании на C++ в Windows Overview of Windows Programming in C++

Существует несколько обширных категорий приложений Windows, которые можно создать с помощью C++. There are several broad categories of Windows applications that you can create with C++. Каждый из них имеет собственную модель программирования и набор библиотек для Windows, но в любом из них можно использовать стандартную библиотеку C++ и сторонние библиотеки C++. Each has its own programming model and set of Windows-specific libraries, but the C++ standard library and third-party C++ libraries can be used in any of them.

В этом разделе описывается, как использовать Visual Studio и библиотеки оболочек MFC/ATL для создания программ Windows. This section discusses how to use Visual Studio and the MFC/ATL wrapper libraries to create Windows programs. Документацию по самой платформе Windows см. в документации по Windows. For documentation on the Windows platform itself, see Windows documentation.

Приложения командной строки (консоль) Command line (console) applications

Консольные приложения C++ запускаются из командной строки в окне консоли и могут отображать только текстовые выходные данные. C++ console applications run from the command line in a console window and can display text output only. Дополнительные сведения см. в разделе Создание калькулятора консоли в C++. For more information, see Create a console calculator in C++.

Собственные клиентские приложения для настольных систем Native desktop client applications

Собственное клиентское приложение для настольных систем — это оконное приложение c или C++, которое использует исходные интерфейсы API для Windows c или COM для доступа к операционной системе. A native desktop client application is a C or C++ windowed application that uses the original native Windows C APIs or Component Object Model (COM) APIs to access the operating system. Эти интерфейсы API написаны в основном на языке C. Существует несколько способов создания собственного классического приложения: вы можете программировать напрямую с помощью API-интерфейсов Win32, используя цикл сообщений в стиле C, который обрабатывает события операционной системы. Those APIs are themselves written mostly in C. There’s more than one way to create a native desktop app: You can program using the Win32 APIs directly, using a C-style message loop that processes operating system events. Или можно программировать с помощью Microsoft Foundation Classes (MFC), объектно-ориентированной библиотеки C++, которая заключает в оболочку Win32. Or, you can program using Microsoft Foundation Classes (MFC), a lightly object-oriented C++ library that wraps Win32. Ни один из подходов не считается «современным» по сравнению с универсальная платформа Windows (UWP), но оба они все еще полностью поддерживаются и миллионы строк кода работают в мире уже сегодня. Neither approach is considered «modern» compared to the Universal Windows Platform (UWP), but both are still fully supported and have millions of lines of code running in the world today. Приложение Win32, выполняемое в окне, требует, чтобы разработчик работал явно с сообщениями Windows внутри функции процедуры Windows. A Win32 application that runs in a window requires the developer to work explicitly with Windows messages inside a Windows procedure function. Несмотря на имя, приложение Win32 можно скомпилировать 32 как 64-разрядный (x86) или 64-разрядный (x64) двоичный файл. Despite the name, a Win32 application can be compiled as a 32-bit (x86) or 64-bit (x64) binary. В интегрированной среде разработки Visual Studio термины x86 и Win32 являются синонимами. In the Visual Studio IDE, the terms x86 and Win32 are synonymous.

Чтобы приступить к работе с традиционным программированием на языке Windows C++, см. статью Начало работы с Win32 и C++. To get started with traditional Windows C++ programming, see Get Started with Win32 and C++. Когда вы получите представление об использовании Win32, будет проще изучить классическое приложение MFC. After you gain some understanding of Win32, it will be easier to learn about MFC Desktop Applications. Пример традиционного классического приложения C++, использующего сложную графику, см. в разделе Hilo: Разработка приложений c++ для Windows. For an example of a traditional C++ desktop application that uses sophisticated graphics, see Hilo: Developing C++ Applications for Windows.

C++ или .NET? C++ or .NET?

Как правило, программирование .NET в C# менее сложное, менее подверженное ошибкам и имеет более современный объектно-ориентированный API, чем Win32 или MFC. In general, .NET programming in C# is less complex, less error-prone, and has a more modern object-oriented API than Win32 or MFC. В большинстве случаев его производительность больше, чем достаточно. In most cases, its performance is more than adequate. .NET использует Windows Presentation Foundation (WPF) для расширенной графики, и вы можете использовать как Win32, так и современный среда выполнения Windows API. .NET features the Windows Presentation Foundation (WPF) for rich graphics, and you can consume both Win32 and the modern Windows Runtime API. В качестве общего правила рекомендуется использовать C++ для классических приложений, когда требуется: As a general rule, we recommend using C++ for desktop applications when you require:

• точный контроль использования памяти precise control over memory usage
• важнейшим приоритетом экономичность при потреблении энергии the utmost economy in power consumption
• Использование GPU для общих вычислений usage of the GPU for general computing
• доступ к DirectX access to DirectX
• интенсивное использование стандартных библиотек C++ heavy usage of standard C++ libraries

Также можно сочетать мощь и эффективность C++ с программированием на .NET. It’s also possible to combine the power and efficiency of C++ with .NET programming. Вы можете создать пользовательский интерфейс на C# и использовать C++/CLI, чтобы позволить приложению использовать собственные библиотеки C++. You can create a user interface in C# and use C++/CLI to enable the application to consume native C++ libraries. Дополнительные сведения см. в разделе программирование .NET с помощью C++/CLI. For more information, see .NET Programming with C++/CLI.

COM-компоненты COM Components

Модель COM — это спецификация, которая позволяет программам, написанным на разных языках, взаимодействовать друг с другом. The Component Object Model (COM) is a specification that enables programs written in different languages to communicate with one another. Многие компоненты Windows реализуются как COM-объекты и следуют стандартным правилам COM для создания объектов, обнаружения интерфейсов и уничтожения объектов. Many Windows components are implemented as COM objects and follow standard COM rules for object creation, interface discovery, and object destruction. Использование объектов COM из классических приложений C++ относительно просто, но написание собственного COM-объекта является более сложным. Using COM objects from C++ desktop applications is relatively straightforward, but writing your own COM object is more advanced. Библиотека активных шаблонов (ATL) предоставляет макросы и вспомогательные функции, УПРОЩАЮЩИЕ разработку com. The Active Template Library (ATL) provides macros and helper functions that simplify COM development. Дополнительные сведения см. в разделе компоненты ATL com Desktop. For more information, see ATL COM desktop components.

Приложения универсальной платформы Windows Universal Windows Platform apps

Универсальная платформа Windows (UWP) — это современный API Windows. The Universal Windows Platform (UWP) is the modern Windows API. Приложения UWP работают на любом устройстве Windows 10, используют XAML для пользовательского интерфейса и полностью поддерживают касание. UWP apps run on any Windows 10 device, use XAML for the user-interface, and are fully touch-enabled. Дополнительные сведения об универсальномконтроллере платформы Windows см. в статье что такое приложение универсальная платформа Windows (UWP) . For more information about UWP, see What’s a Universal Windows Platform (UWP) app? and Guide to Windows Universal Apps.

Исходная поддержка C++ для UWP состояла из (1) C++/CX, диалекта C++ с расширениями синтаксиса или (2) библиотеки среда выполнения Windows (WRL), основанной на стандартном C++ и COM. The original C++ support for UWP consisted of (1) C++/CX, a dialect of C++ with syntax extensions, or (2) the Windows Runtime Library (WRL), which is based on standard C++ and COM. C++/CX и WRL по-прежнему поддерживаются. Both C++/CX and WRL are still supported. Для новых проектов рекомендуется использовать c++/WinRT, который полностью основан на стандартном c++ и обеспечивает более высокую производительность. For new projects, we recommend C++/WinRT, which is entirely based on standard C++ and provides faster performance.

Мост для классических приложений Desktop Bridge

В Windows 10 можно упаковать существующее классическое приложение или COM-объект в качестве приложения UWP и добавить функции UWP, такие как сенсорный ввод, или вызвать API из современного набора API Windows. In Windows 10, you can package your existing desktop application or COM object as a UWP app, and add UWP features such as touch, or call APIs from the modern Windows API set. Можно также добавить приложение UWP в решение для настольных систем в Visual Studio и упаковать их в один пакет и использовать интерфейсы API Windows для обмена данными между ними. You can also add a UWP app to a desktop solution in Visual Studio, and package them together in a single package and use Windows APIs to communicate between them.

Visual Studio 2017 версии 15,4 и более поздних версий позволяет создать проект пакета приложений Windows, чтобы значительно упростить работу по упаковке существующего настольного приложения. Visual Studio 2017 version 15.4 and later lets you create a Windows Application Package Project to greatly simplify the work of packaging your existing desktop application. К вызовам реестра или API-интерфейсам, которые может использовать настольное приложение, применяются некоторые ограничения. A few restrictions apply to the registry calls or APIs your desktop application can use. Однако во многих случаях можно создать альтернативные пути кода для обеспечения аналогичной функциональности при выполнении в пакете приложения. However, in many cases you can create alternate code paths to achieve similar functionality while running in an app package. Дополнительные сведения см. в статье Мост для классических приложений. For more information, see Desktop Bridge.

Игры Games

Игры DirectX могут работать на компьютере или Xbox. DirectX games can run on the PC or Xbox. Дополнительные сведения см. в статье DirectX Graphics и игровыеустройства. For more information, see DirectX Graphics and Gaming.

Клиенты базы данных SQL Server SQL Server database clients

Для доступа к базам данных SQL Server из машинного кода используйте ODBC или OLE DB. To access SQL Server databases from native code, use ODBC or OLE DB. Дополнительные сведения см. в разделе SQL Server Native Client. For more information, see SQL Server Native Client.

Драйверы устройств Windows Windows device drivers

Драйверы — это низкоуровневые компоненты, которые делают данные из аппаратных устройств доступными для приложений и других компонентов операционной системы. Drivers are low-level components that make data from hardware devices accessible to applications and other operating system components. Дополнительные сведения см. в разделе Windows Driver Kit (WDK). For more information, see Windows Driver Kit (WDK).

Службы Windows Windows services

Служба Windows — это программа, которая может выполняться в фоновом режиме с небольшим или без участия пользователя. A Windows service is a program that can run in the background with little or no user interaction. Эти программы называются демоны на системах UNIX. These programs are called daemons on UNIX systems. Дополнительные сведения см. в разделе Службы. For more information, see Services.

Пакеты SDK, библиотеки и файлы заголовков SDKs, libraries, and header files

Visual Studio включает в себя библиотеку времени выполнения C (CRT), стандартную библиотеку C++ и другие библиотеки, относящиеся к Microsoft. Visual Studio includes the C Runtime Library (CRT), the C++ Standard Library, and other Microsoft-specific libraries. Большинство папок включения, содержащих файлы заголовков для этих библиотек, находятся в каталоге установки Visual Studio в папке \ВК Most of the include folders that contain header files for these libraries are located in the Visual Studio installation directory under the \VC\ folder. Файлы заголовков Windows и CRT находятся в папке установки Windows SDK. The Windows and CRT header files are found in the Windows SDK installation folder.

Диспетчер пакетов Vcpkg позволяет легко устанавливать сотни сторонних библиотек с открытым исходным кодом для Windows. The Vcpkg package manager lets you conveniently install hundreds of third-party open-source libraries for Windows.

К библиотекам Майкрософт относятся: The Microsoft libraries include:

Microsoft Foundation Classes (MFC): объектно-ориентированная платформа для создания традиционных программ Windows (в частности, корпоративных приложений), со сложным пользовательским интерфейсом, включающим кнопки, поля списков, древовидные структуры и другие элементы управления. Microsoft Foundation Classes (MFC): An object-oriented framework for creating traditional Windows programs—especially enterprise applications—that have rich user interfaces that feature buttons, list boxes, tree views, and other controls. Дополнительные сведения см. в разделе MFC Desktop Applications. For more information, see MFC Desktop Applications.

Active Template Library (ATL): многофункциональная вспомогательная библиотека для создания компонентов COM. Active Template Library (ATL): A powerful helper library for creating COM components. Для получения дополнительной информации см. ATL COM Desktop Components. For more information, see ATL COM Desktop Components.

C++ AMP (C++ Accelerated Massive Parallelism): библиотека, предоставляющая возможность выполнять высокопроизводительные вычислительные задачи общего характера в графическом процессоре. C++ AMP (C++ Accelerated Massive Parallelism): A library that enables high-performance general computational work on the GPU. Для получения дополнительной информации см. C++ AMP (C++ Accelerated Massive Parallelism). For more information, see C++ AMP (C++ Accelerated Massive Parallelism).

Среда выполнения с параллелизмом: библиотека, упрощающая параллельное и асинхронное программирование для мультиядерных и многоядерных устройств. Concurrency Runtime: A library that simplifies the work of parallel and asynchronous programming for multicore and many-core devices. Для получения дополнительной информации см. Concurrency Runtime. For more information, see Concurrency Runtime.

Для многих сценариев программирования Windows также требуется пакет Windows SDK, в который входят файлы заголовков, обеспечивающие доступ к компонентам операционной системы Windows. Many Windows programming scenarios also require the Windows SDK, which includes the header files that enable access to the Windows operating system components. По умолчанию Visual Studio устанавливает Windows SDK как компонент рабочей нагрузки C++ для настольных систем, который позволяет разрабатывать универсальные приложения для Windows. By default, Visual Studio installs the Windows SDK as a component of the C++ Desktop workload, which enables development of Universal Windows apps. Для разработки приложений UWP требуется версия Windows 10 Windows SDK. To develop UWP apps, you need the Windows 10 version of the Windows SDK. Дополнительные сведения см. в разделе пакет SDK для Windows 10. For information, see Windows 10 SDK. (Дополнительные сведения о пакетах Windows SDK для более ранних версий Windows см. в Windows SDK архиве). (For more information about the Windows SDKs for earlier versions of Windows, see the Windows SDK archive).

Программные файлы (x86) \Windows Kit — это расположение по умолчанию для всех версий Windows SDK, которые вы установили. Program Files (x86)\Windows Kits is the default location for all versions of the Windows SDK that you’ve installed.

Другие платформы, например Xbox и Azure, обладают собственными пакетами SDK, которые вам, возможно, потребуется установить. Other platforms such as Xbox and Azure have their own SDKs that you may have to install. Дополнительные сведения см. в Центре разработчика DirectX и в Центре разработчика Azure. For more information, see the DirectX Developer Center and the Azure Developer Center.

средства разработки: Development Tools

Visual Studio включает многофункциональный отладчик для машинного кода, средства статического анализа, графические средства отладки, полнофункциональный редактор кода, поддержку модульных тестов, а также множество других средств и служебных программ. Visual Studio includes a powerful debugger for native code, static analysis tools, graphics debugging tools, a full-featured code editor, support for unit tests, and many other tools and utilities. Дополнительные сведения см. в статьях Приступая к разработке с помощью Visual Studioи Общие сведения о разработке C++ в Visual Studio. For more information, see Get started developing with Visual Studio, and Overview of C++ development in Visual Studio.