Windows コンソールとターミナル エコシステムのロードマップ

このドキュメントは、Windows コンソールおよび Windows ターミナル製品の概要のロードマップです。 次の内容について説明します。

• Windows コンソールと Windows ターミナルが、Windows やその他のオペレーティング システム全体のコマンドライン アプリケーションのエコシステムとどのように適合するか。

• プラットフォームの構築、このプラットフォームの構築の一部である製品、機能、および戦略の履歴と今後のロードマップ。

Microsoft の現在のコンソールおよびターミナル時代の焦点は、Windows プラットフォームの開発者に最上級のターミナル エクスペリエンスを直接提供し、従来の Windows コンソール API の使用を段階的に停止し、疑似コンソールを利用して仮想ターミナル シーケンスに置き換えることにあります。 Windows ターミナルは、この最上級のエクスペリエンスへの移行を示すものであり、開発者コミュニティからオープンソース コラボレーションを招待し、クライアント コマンドラインとターミナル ホスティング アプリケーションのあらゆる組み合わせとマッチングをサポートし、Windows エコシステムを他のすべてのプラットフォームと統合しています。

定義

先に進む前に、この領域で使用される一般的な用語の定義について理解しておくことをお勧めします。 一般的な用語には次のものが含まれています：コマンドライン (またはコンソール) アプリケーション、標準ハンドル (STDIN、STDOUT、STDERR)、TTY および PTY デバイス、クライアントとサーバー、コンソール サブシステム、コンソール ホスト、疑似コンソール、およびターミナル。

Architecture

システムの一般的なアーキテクチャは、クライアント、デバイス、サーバー、およびターミナルの 4 つの部分に分かれています。

クライアント

クライアントは、ユーザーが (マウスベースのユーザー インターフェイスではなく) テキストベースのインターフェイスを使用してコマンドを入力し、結果のテキスト表現が返されるコマンドライン アプリケーションです。 Windows 上のコンソール API には、クライアントとデバイス間の通信レイヤーが用意されています (これは、デバイス制御 API を備えた標準のコンソール ハンドルの場合もあります)。

Device

デバイスは、クライアントとサーバーの 2 つのプロセス間の中間メッセージ処理通信レイヤーです。 Windows 上では、これはコンソール ドライバーです。 他のプラットフォームでは、TTY または PTY デバイスです。 トランザクション全体がプレーン テキストであるか、仮想ターミナル シーケンスが含まれているが Windows コンソール API が含まれていない場合は、ファイル、パイプ、ソケットなどの他のデバイスをこの通信チャネルとして使用できます。

[サーバー]

要求された API 呼び出しまたはクライアントからのメッセージは、サーバーにより解釈されます。 クラシック動作モードの Windows の場合、サーバーにより、出力を画面に表示するユーザー インターフェイスも作成されます。 さらに、サーバーによって入力が収集され、ドライバーを介して、同じモジュールにバンドルされているターミナルなどのクライアントに応答メッセージが返送されます。 疑似コンソール モードを使用する場合、これは、アタッチされているターミナルに仮想ターミナル シーケンスのこの情報を表示する単なる変換ツールになります。

ターミナル

ターミナルは、ユーザーにグラフィカルな表示と対話機能のサービスを提供する最後のレイヤーです。 これには、入力をキャプチャし、それを仮想ターミナル シーケンスとしてエンコードする役割があります。これは、最終的にクライアントの STDIN に到達します。 また、これにより、画面に表示するためにクライアントの STDOUT から受信した仮想ターミナル シーケンスの受信とデコードも行われます。

追加の接続

補足として、複数の役割を持つアプリケーションをいずれかのエンドポイントとチェーンすることにより、追加の接続を実行できます。 たとえば、SSH セッションには 2 つの役割があります。これは 1 台のデバイスで実行されているコマンドライン アプリケーションのターミナルですが、受信したすべての情報を別のデバイス上のクライアントへの転送も行われます。 このチェーンは、デバイスやコンテキスト間で無期限に発生させることができるので、さまざまなシナリオに柔軟に対応できます。

Windows 以外のプラットフォームでは、API セットと仮想ターミナル シーケンスの間に変換互換性レイヤーが必要ないため、サーバーとターミナルの役割は 1 つのユニットです。

Microsoft 製品

すべての Microsoft Windows コマンドライン製品は、GitHub のオープン ソース リポジトリ microsoft/terminal で入手できるようになりました。

Windows コンソール ホスト

これは、コマンドライン アプリケーション用の従来の Windows ユーザー インターフェイスです。 これにより、アタッチされているコマンドライン アプリケーションから呼び出されたすべてのコンソール API サービスが処理されます。 Windows コンソールにより、これらすべてのアプリケーションに代わって、グラフィカル ユーザー インターフェイス (GUI) 表現も処理されます。 これは、conhost.exe またはオープンソース形式の openconsole.exe としてシステム ディレクトリに存在します。 Windows オペレーティング システムに付属しています。 また、疑似コンソール インフラストラクチャのより新しい実装については、オープンソース リポジトリから構築された他の Microsoft 製品にも含まれています。 前述の定義に従うと、選択した疑似コンソール インフラストラクチャを介して、従来のサーバーとターミナルを組み合わせた役割、またはサーバーのみの役割のいずれかで動作します。

Windows ターミナル

これは、コマンドライン アプリケーション用の新しい Windows インターフェイスです。 Windows ターミナルは、Windows 以外のすべてのプラットフォームと同様に、疑似コンソール を使用して、API サービスとテキストベースのアプリケーション インターフェイスの間の関係を分離するファーストパーティの例として機能します。

Windows ターミナルは、Windows 用の主要なテキストモード ユーザー インターフェイスです。 エコシステムの機能を紹介し、他のプラットフォームとの統合に向けて Windows 開発を推進するためのものです。 Windows ターミナルは、Windows API とフレームワークの履歴と全域にわたる堅牢で複雑なモダン アプリケーションを構築する方法を示す例でもあります。 前述の定義に従うと、この製品はターミナルの役割で動作します。

主要な履歴のマイルストーン

コンソール サブシステムの主要な履歴のマイルストーンは、2014 年より前の実装と、その後、Windows 10 時代のコマンドラインへの新たな焦点が形成された、2014 年以降に実行された作業の概要への移行とに分けられます。

初期実装

[1989-1990 年代] 初期のコンソール ホスト システムは、Windows オペレーティング システム内の DOS 環境のエミュレーションとして実装されました。 そのコードは、DOS 環境の表現であるコマンド プロンプト (cmd.exe) と関係があり、連携しています。 コンソール ホスト システム コードは、コマンド プロンプト インタープリターおよびシェルと役割と特権を共有しています。 また、他のコマンドライン ユーティリティが CMD のような方法でサービスを実行するための基本レベルのサービスも提供されています。

CJK 向け DBCS

[1997-1999 年] この頃、CJK (中国語、日本語、韓国語) 市場をサポートするために DBCS サポート ("2 バイト文字セット") が導入されました。 この取り組みの結果、1 バイト文字を処理する "西部" バージョンと、膨大な数の文字を表すために 2 バイトが必要な "東部" バージョン用の代替表現の両方を扱うために、コンソール内の多くの書き込みメソッドと読み取りメソッドが分岐しました。 この分岐には、コンソール環境での 1 セルまたは 2 セルの幅のセルの拡張表現が含まれていました。1 セルは幅が狭く (幅よりも高さの方が大きい)、2 セルは幅が広く、全角、または四角形であり、一般的な中国語、日本語、韓国語の表意文字を表記できます。

セキュリティと分離

[2005-2009 年] 重要なシステム プロセス csrss.exe 内で実行されているコンソール サブシステムの経験により、さまざまなアクセス レベルでさまざまなクライアント アプリケーションを 1 つの非常に重要な特権プロセスに接続することは、特に危険であることがわかりました。 この時代に、コンソール サブシステムはクライアント、ドライバー、サーバー アプリケーションに分割されました。 各アプリケーションはそれぞれのコンテキストで実行されるので、個々の役割と特権が軽減されます。 この分離により、システムの全体的な堅牢性が向上しました。コンソール サブシステムでの障害が他の重要なプロセス機能に影響しなくなったためです。

ユーザー エクスペリエンスの向上

[2014-2016 年] 長い間、組織全体でさまざまなチームによってさまざまな場所でメンテナンスが行われた後で、新しい開発者中心のチームが結成され、コンソールの機能強化を担当し、推進するようになりました。 この期間の改善には、行の選択、ウィンドウのスムーズなサイズ変更、テキストのリフロー、コピーと貼り付け、高 DPI のサポート、Unicode への集中 ("西部" と "東部" のストレージとストリーム操作アルゴリズム間の分割の収束を含みます) などがあります。

仮想ターミナル クライアント

[2015-2017 年]Linux 用 Windows サブシステムの登場に伴い、Microsoft は Windows 上の Docker のエクスペリエンスの向上に取り組み、最上級のコマンドライン リモート実行テクノロジとして OpenSSH を採用し、仮想ターミナル シーケンスの初期実装をコンソール ホストに導入しました。 これにより、既存のコンソールがターミナルとして機能し、それぞれの環境で Linux ネイティブのアプリケーションに直接接続され、グラフィカル属性とテキスト属性がディスプレイに表示され、適切な言語でユーザー入力が返されるようになりました。

仮想ターミナル サーバー

[2018 年] 過去 20 年間に、受信トレイ コンソール ホスト用のサードパーティの代替品が作成され、開発者の生産性が向上し、豊富なカスタマイズとタブ付きインターフェイスが中心になりました。 このようなアプリケーションを使用するには、コンソール ホスト ウィンドウを実行し、非表示にする必要がありました。 これらはセカンダリ "クライアント" アプリケーションとしてアタッチされ、プライマリ コマンドライン クライアント アプリケーションが動作しているときにポーリング ループ内のバッファー情報が取得されます。 その目標は、他のプラットフォーム上と同様にターミナルになることでしたが、Windows 環境ではターミナルを置き換えることができません。

この期間に、疑似コンソール インフラストラクチャが導入されました。 疑似コンソールを使用すると、すべてのアプリケーションが非対話型モードでコンソール ホストを起動し、ユーザーの最終的なターミナルインターフェイスになることができるようになります。 この取り組みの主な制限事項は、公開されているすべての Windows コンソール API を無期限に提供するという Windows の継続的な互換性を保証すると同時に、他のすべてのプラットフォームで想定されるものと一致する代替サーバーホスト インターフェイス (つまり、仮想ターミナル シーケンス) を提供することです。 そのため、この取り組みではクライアント フェーズのミラー イメージを実行しました。疑似コンソールには、委任されたホストの仮想ターミナル シーケンスとして画面に表示されるものが投影され、クライアント アプリケーションから使用できるように、応答が Windows 形式の入力シーケンスに解釈されます。

今後のロードマップ

ターミナル アプリケーション

[2019年 - 現在] これは新しい Windows ターミナルに焦点を当てたコンソール サブシステムのオープン ソース時代です。 2019 年 5 月の Microsoft Build カンファレンスで発表された Windows ターミナルは、すべて GitHub の microsoft/terminal にあります。 この時代では、疑似コンソール用の洗練されたプラットフォーム上に Windows ターミナル アプリケーションを構築し、Windows プラットフォーム上の開発者が最上級のターミナル エクスペリエンスを体感できるようにすることに焦点を当てています。

Windows ターミナルは、WinUI インターフェイス テクノロジ、MSIX パッケージ モデル、C++/WinRT コンポーネント アーキテクチャなど、プラットフォームを紹介するためだけのものではありません。プラットフォーム自体の検証にも使用できます。 Windows 組織は Windows ターミナルを使用して、開発者の生産性が継続的に向上するように、必要に応じてアプリ プラットフォームを公開し、進化させています。 Windows ターミナル独自の一連のパワー ユーザーと開発者の要件によって、これらの市場が Windows に本当に必要としているものに対する最新の Windows プラットフォームの要件が決まります。

Windows オペレーティング システム内では、これにはクラシック コンソール ホストのユーザー インターフェイスを既定の位置から外し、Windows ターミナル、ConPTY、仮想ターミナル シーケンスに置き換えることも含まれています。

最後に、この時代は、Windows ターミナル製品であろうと代替ターミナルであろうと、既定のエクスペリエンスではなく自由に選択できるようにすることを目的としています。

クライアント サポート ライブラリ

[今後] Windows コマンドライン ユーティリティの開発者は、クライアント側の仮想ターミナル シーケンスのサポートとドキュメントを利用し、すべてのプラットフォームで統合されたエコシステムを活用できるように、従来の Windows API ではなく、まず仮想ターミナル シーケンスを使用することを強くお勧めします。 ただし、1 つの重要な点が欠落しています。他のプラットフォームには、readline のような入力や ncurses のようなグラフィカル表示を処理するためのさまざまなクライアント側ヘルパー ライブラリがあることです。 この点に関する今後のロードマップ要素は、エコシステムによって提供されるものと、Windows コマンドライン アプリケーションで従来のコンソール API ではなく仮想ターミナル シーケンスの導入を加速させる方法の調査を示しています。

シーケンス パススルー

[今後] 仮想ターミナル クライアントとサーバーの実装を組み合わせることで、クライアントのコマンドライン アプリケーションとターミナル ホスト アプリケーションを完全に組み合わせ、マッチングすることができます。 この組み合わせにより、従来の Windows コンソール API または仮想ターミナル シーケンスのいずれかと通信できますが、これを従来の互換性のある Windows メソッドに変換してから、より汎用的な仮想ターミナル メソッドに戻すにはオーバーヘッド コストがかかります。

市場の Windows 上に仮想ターミナル シーケンスと UTF-8 が十分に導入されれば、コンソール ホストの変換および解釈ジョブをオプションで無効にすることができます。 その後、コンソール ホストは単純な API 呼び出しのサービス提供元になり、デバイス呼び出しから疑似コンソールを介してホスト アプリケーションに中継するために使用されるようになります。 この変更により、パフォーマンスが向上し、クライアント アプリケーションとターミナルの間に使用できるシーケンスの言語数が最大限に増えます。 この変更により、追加の対話型シナリオが有効になり、("最終的に") コマンドライン アプリケーション領域で、Windows 環境は他のあらゆるプラットフォームのファミリと同様になります。