Windows Info 第135回

Windows 10までほとんど手が入れられてこなかったWindowsのコンソール機能

64bit版Windowsでは16bitのDOSアプリは動かなくなったが
32bitのコンソールアプリは動作可能

　「コマンドプロンプト」や「WSL」（Windows Susbsytem for Linux）を使う場合に利用するのが「コンソール」ウィンドウだ。このコンソールウィンドウは、テキスト主体のアプリケーションを実行する環境である。

　Windowsでは、その祖先にあたるMS-DOSのアプリケーションをサポートするためにコンソールウィンドウが作られ、Windows XPまでは、16bitアプリケーションとしてMS-DOSアプリを動作できた。64bit版のVistaからは16bitアプリケーションのサポートはなくなったが、32bitのコンソールアプリケーションは実行できる。

　もともとコンソールとは、ハードウェアとして、テキストの表示とキーボードからの入力をサポートしたもので、OSの支援などがなくても入出力を可能にするものとしてコンピューターに組み込まれていた。

　現在では、こうしたコンソールは逆に「ハードウェアコンソール」として区別するのが普通になったように、Windowsなどの「コンソールウィンドウ」はOSが実行環境を作り、他のアプリケーションと共存できるようにウィンドウ内で入出力を行うための仕組みになっている。なお、Windows 10 RS4（Spring Update）からは、UWPアプリでもコンソールアプリケーションを開発することが可能になった。

　コンソールウィンドウとアプリケーションは、単一のソフトウェアのように見えるが、実際には、アプリケーションとConhost.exeという2つのプログラムに分かれていて、Win32APIを介してConDrvというカーネル内のデバイスドライバーで接続されて動作している。コンソールアプリケーションとConHost.exeの間にConDrvを挟むのは、1つのコンソールアプリケーションから複数の子プロセスが起動され、同じコンソールを利用することになる場合があるからだ。

　たとえば、コマンドプロンプトウィンドウ（cmd.exe）は、起動するとコンソールウィンドウを表示するが、その中でさらにcmd.exeを起動することができる。このとき、最初に起動したコンソールを2つのcmd.exeが共有している状態となる。なお、Windowsでは、コンソールアプリケーション（プロセス）が接続できるコンソールウィンドウは1つだけに制限されている。

　ConHost.exeが導入されたのはWindows 7からで、これ以前では、コンソール表示は「Client Server Runtime SubSystem（CSRSS）」というサブシステムで行なっていた。もともと、これは、Windows NTで仮想DOSマシンのサポートやコンソールウィンドウの管理などのために作られたもの。

　GUIで起動するWindows NTは、当初はGUIなしのOSとして動作していたこともあり、システムとしてGUIを使わないコマンドなどが多数用意されていたのだ。また、従来のMS-DOSとの互換性も必要であり、これはMS-DOSの上で動いていた、当時のWindowsとの互換性からも必要なことだった。

　コマンドライン用アプリケーションは、バックグラウンド処理として画面入出力を止めた状態で動作し続けることが要求される可能性があった。実際、マイクロソフトが手本としたUnix系では、コマンドをバックグラウンドで起動したり、デーモンとして動作させるという技法が使われている。Windows NTでもこうした挙動を可能にするため、CSRSSがWindowsの機能で導入された。

セキュリティ問題への対応でWindows 7で若干の手が加わる

　Windows Vista以前、コンソールはCSRSS.EXEというシステムコンポーネントが使われていた。しかし、ユーザーモードで動作するソフトウェアでありながら、GDIやウィンドウの制御にカーネルモードドライバーを直接呼び出すなど、セキュリティ的な問題があった。

　このため、Windows 7では、CSRSS.EXEから、コンソール関連の機能を分離し、conhost.exeとした。

アプリケーションがコンソールを使う場合、ConHost.exeが子プロセスとして起動され、これがコンソールウィンドウの制御をする

　コンソール機能は、アプリケーションの子プロセスとして実行されるようになった。このようにすることで、conhost.exe側に問題が生じたとしても、アプリケーション環境の中の問題として処理することが可能になる。

　Unix系などのコンソールアプリケーションとの違いとして、本来Windowsのコンソールアプリケーションは、コンソールAPIを介して、コンソールウィンドウ内の表示を細かく制御することを想定している。これに対して、Unix系のコマンドでは、コマンドは、「標準入力」「標準出力」「標準エラー出力」といった仮想的な入出力デバイスを前提に作られている（そもそも開発された時代が違う）。

　Unixコマンドプログラムは、これらの入出力デバイスを使って、入力を受け取り、結果出力を行なう。さらに言えば、Unix系では、これらを「ファイルの読み書き」のように扱うようになっている。入力デバイスをファイルのように読み出せば、ユーザーがタイプした文字などが入力データとして得られ、結果などをテキストとして、出力デバイスに書き込めば、勝手に画面に表示される。

　MS-DOS時代には、Unixを手本としていたため、同じような標準入出力が用意された。WindowsのコンソールAPIにも、同様のことを実現する高レベルAPIが用意された。しかし、コンソール上で動作するアプリケーションのサポートが完成の域にあったUnixとは違い、MS-DOSでのサポートは、初期の16bit CPU向けの簡易な機能のみで、その後、マイクロソフトはWindowsとGUIプログラムへと移行したため、コンソールプログラムのサポートは中途半端なまま残されることになる。

　実際、Windowsのコンソール機能は、Windows 10にWSLが導入されるまで、ほとんど手がつけられていない。前述のConHost.exeの分離なども、CSRSS.EXEが攻撃対象となったからであり、あくまでセキュリティ対策だったのであり、当時は、コンソール機能を強化するという意図はなかったようだ。

　また、WSLとともに復活したDEC VT100のエスケープシーケンスのサポートも、MS-DOSや初期の16bit版Windowsでは、デバイスドライバーとして実現されていたのだが、WindowsとMS-DOSが分離されたために廃止された機能だった。

30年以上の前のコードがベース
Unicode対応に問題が生じている

　ConHost.exeは、コンソールアプリケーションに対して、子プロセスとして起動され、ウィンドウの管理や表示、入力などをする。このコードは、古いものを改良して使い続けられていると考えられる。というのは、いまだにフォントとして古いラスターフォント（TrueType導入以前のWindowsフォント形式）を扱えるなど、GDI経由で出力されているからだ。マイクロソフトのブログによれば、30年以上前のコードがベースになっているという。

　ただし、まったく手が入っていないわけではなく、たとえば、WSL導入時に組み込まれたVT100エスケープシーケンスなどは、このConHost.exe内で処理されている。MS-DOSやWindowsが複数の文字コードセットに対応していたことから、コンソールは文字コードセットの切り替え機能を持つ。

　また、日本語など2バイトコード文字への対応は、現在では拡張されてUnicodeによるものとなった。ただし、前述のようにコンソールはGDIベースであるため、Unicodeの処理については完全ではなく、複数の文字を組みあわせて1つにするような表示ができない。今後、改良されるとすれば、こうした表示関係の機能を最新のものに合わせていくことになるかと思われるが、逆に過去に作られたコンソールAPIを利用するデスクトップアプリケーションとの互換性などが足かせとなる。

　しかし、Unicodeの完全な表示は、たとえばLinuxのコンソールアプリケーションなどでも問題になることがあり、対応が急がれるところ。互換性をとるのか、捨てるのか、対応が非常に気になる部分でもある。個人的にはそろそろGDIは捨ててDirectWriteベースに移行してくれると、文字表示がきれいになるので期待したいところだ。