MicrosoftのRaymond Chen氏が、「The little-known winstart.bat batch file - 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が読み込まれ、MS-DOSは基本的な初期化処理を実行し、その過程でTSRを利用するプロセス(ドライバーなど)を保持する。

次にWindowsカーネルへと処理が遷移する。仮想マシンマネージャー(VMM: Virtual Machine Manager)と呼ばれるコンポーネントが読み込まれ、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モードのコピー環境が使用される」とした部分について補足説明をしている。これは正確な表現ではなく、むしろシステム仮想マシンのコピーに近いという。しかし、この仕組みは複雑すぎるとして説明を割愛した。別の機会があれば、説明したいと話を締めくくっている。