MicrosoftのRaymond Chen氏が、ブログ「The Old New Thing」で、Windowsに存在した「winstart.bat」の役割について解説した。これは読者からの質問への回答で、現在では使われない仕組みだが、その役割からMS-DOSを基盤としていたWindows 3.x～Windows 95時代の起動構造が見えてくる。
MS-DOS時代のWindowsを支えた「TSR」
Chen氏によると、このバッチファイルはWindows 3.1または3.0で登場した新機能とされる。Windows 3.xはMS-DOSを基盤として動作しており、起動時にもMS-DOSを利用する構成だった。
前提知識として、MS-DOSの重要な機能「Terminate and Stay Resident（TSR）」がある。TSRは、プログラムの実行終了後もその一部をメモリ上に常駐させておく仕組みで、当時はドライバーの常駐などに広く利用されていた。主にドライバーのインストールや疑似的なマルチタスク環境の実現に利用され、winstart.batでもWindows向けドライバーのインストールなどに利用された。なお、この機能はWindows 95や98でも利用可能とされる。
winstart.batはWindows起動のどこで実行されたのか
Windows 3.1またはWindows 95を基準にすると、PCの電源を入れるとMS-DOSが読み込まれ、基本的な初期化処理を実行し、その過程でTSRを利用するプロセス（ドライバーなど）を保持する。次にWindowsカーネルへと処理が遷移し、仮想マシンマネージャー（VMM）と呼ばれるコンポーネントが読み込まれ、MS-DOSの制御を引き継ぐ。MS-DOSの管理領域（割り込みベクターやTSRプロセスなど）は「仮想86モード」と呼ばれる仮想マシンとして管理される。
次に仮想マシンマネージャーはシステム仮想マシンを初期化し、この段階で「winstart.bat」が実行される。このバッチファイル内部でもTSRを利用でき、任意のプロセスを仮想86モードのMS-DOS管理領域に保持できる。バッチファイルの実行を終えると、初期化済みのシステム仮想マシンを使用してWindowsアプリを制御するユーザーモードカーネルを実行する。このユーザーモードカーネルがWindows本体となる。つまり、winstart.batはMS-DOSの初期化後、Windowsのシステム仮想マシンが初期化される段階で実行される。
なぜwinstart.batが必要だったのか
winstart.batが必要だった理由は、Windowsアプリ向けの基盤環境にWindows専用のTSRプロセスをインストールし、コマンドプロンプトから隠すことにある。Windows起動後に実行されるコマンドプロンプトは、仮想86モードのコピー環境が使用される。このコピー環境は、winstart.batの実行時にTSRを利用して保持したプロセスを含まないように構成される。
その結果、基盤として存在する仮想86モードにはMS-DOS初期化時のTSRプロセスと、winstart.bat実行時に保持したTSRプロセスが存在する。一方で、新たに起動したコマンドプロンプトには、MS-DOS初期化時のTSRプロセスのみが存在する。Windowsアプリの多くはネットワーク機能を利用するため、ネットワークドライバーを必要とするが、コマンドプロンプト上で動作する古いアプリはネットワーク機能を必要としない。この条件を満たすドライバーの提供方式として、winstart.batが利用できるとの説明だ。
最後に、Chen氏は「Windows起動後に実行されるコマンドプロンプトは、仮想86モードのコピー環境が使用される」という表現は正確ではなく、むしろシステム仮想マシンのコピーに近いと補足した。しかし、この仕組みは複雑すぎるとして説明を割愛し、別の機会があれば説明したいと話を締めくくっている。
