Windows Info 第123回

Windows 3.1時代のファイルマネージャーを見てWindowsを振り返る

Windows 3.0／3.1時代のファイルマネージャーで思い出す
Windowsの歴史

　Windows 3.0／3.1時代に使われていたファイルマネージャーがオープンソースになったという。ファイルマネージャーは、現在のWindowsエクスプローラーの祖先みたいなファイル管理ツールである。Windows 3.0／3.1では、今のスタートメニューに相当するものとしてアプリケーションのアイコンを登録できる「プログラムマネージャー」がシェルとして使われていた（設定でファイルマネージャに切り替えることもできた）。

オープンソース化され、Windows 10でも動作するようになったファイルマネージャー。28年前に作られたWindows 3.0に標準搭載されていた、現在のエクスプローラーのご先祖様である

　さらに言えば、Windows 3.0以前のWindows 2.11までは、MS-DOSエグゼクティブというファイル管理ソフトウェアがシェルになっていて、その後継として登場したのがファイルマネージャーとなる。

　そもそもWindows 3.0／3.1は、Win16環境のWindowsだ。Windows 3.0の発表は1990年5月。いまから28年も前の話である。若い読者にとっては、石器時代の話にも等しい昔の話だろう。そもそも、PC自体が一般にはあまり普及しておらず、使っていたとしてもMS-DOSユーザーのほうが多かった時代だ。筆者はこの頃、家電メーカーでPCやワークステーション関係の仕事をしており、こうした動きのまっただ中にいた。

　現在のWin32環境とは違い、Windows 1.01で作られた16bit CPU向けの「オペレーティングエンバイロンメント」では、最初にMS-DOSが起動しており、デバイスやファイルシステムのアクセスは、MS-DOSやBIOS経由で行なわれていた。当時の最新CPUはi386DX／SXだったが、Windows 3.0では16bitのリアルモードのみしかない8086でも動作するようになっていた。このため起動時にCPUやハードウェアに合わせて3つの起動モードがあった。

・リアルモード：8086の16bitリアルモードで動作
・プロテクトモード：80286の16bitプロテクトモードで動作
・エンハンスドモード：i386DX/SXの拡張プロテクトモード（32bitモード）で動作

　このうちリアルモードは、Windows 3.1では廃止された。

　Windows 3.0が出たとき、マイクロソフトとIBMは、次世代の標準プラットフォームをかけて競争の真っ最中だった。話は1985年にまでさかのぼる。マイクロソフトとIBMは、次世代OSの開発で提携する。

　今にしてみれば、なぜIBMとマイクロソフトが提携してOSを開発することになったのかはよくわからないが、当時の記憶では、IBMが1984年に発表したMS-DOSのマルチタスク環境であるTopViewを極度に警戒していた。マイクロソフトは1983年にWindowsを発表していたが、出荷されるのは1985年になってから。IBMのTopViewは、テキスト表示ながらMS-DOSアプリをウィンドウ内に表示できるマルチタスク環境だった。

　このIBMとマイクロソフトの提携の成果として作られたのがOS/2である。OS/2は1987年にPS/2とともに出荷されるが、この時点ではGUIはなく、80286のプロテクトモードにしか対応していなかった。その後、マイクロソフトはOS/2を自社の製品ラインとはせず、OS/2 1.2（1989年）を最後にOS/2の開発から手を引き、OS/2 Ver.3として開発中だったOSをWindows NTとする。

　当時のマイクロソフトは、MIPSのR3000上でWindows NTを動かしており、PCのOEMメーカーにR3000ベースでのコンピュータ開発を打診していたことがある（ACEプロジェクト）。

　その裏でマイクロソフトが開発を進めていたのがWindows 3.0（1990年）だ。Windows 3.0は、本来はOS/2とAPI的に互換性を持たせる予定で、GUIのスタイルに関してはOS/2のプレゼンテーションマネージャーと同じになるように開発が進んでいた。しかし、Windows 3.0は、OS/2互換のAPIは採用せず、Windows 2.11（1989年）の上位互換であるWin16を継承している。

　この頃のWindowsは、MS-DOSの上に乗っており、仮想記憶も特権モードもなく、メモリ空間が最大でも1MBしかない8086で動作させるため、大変“無理”のある作りになっていた。マルチウィンドウを実現するためにマルチタスクが必要だったが、採用されたのは「協調的マルチタスク」であった。

　これは、アプリケーションが明示的に制御を戻したり、APIを呼び出したタイミングでタスクを切り替えるもの。アプリケーションが制御を返さなければ、ずっと他ののタスクは止まったままになる。こうしたさまざまな制限とMS-DOSとの互換性を保つために、Windowsのアプリケーションは特殊な構造になっていた。

今のWindowsアプリではありえない部分が
ソースコードから見られる

　たとえば、Windowsアプリケーションは、C言語で開発するときには、WinMainという関数から起動するのである。

Win16アプリでは、メインプログラムはWinMain関数から開始する

　これは、公開されたファイルマネージャーにも残ったままだ。多少C言語を使った方なら、C言語の起動は、main関数であることはご存じだろう。いくつかの理由から、Windows 1.01が作られた当時、main関数からWindowsアプリケーションを起動させることはできなかった。

　1つには、当時は、MS-DOSが主流で、MS-DOSとWindows両対応のアプリを開発するという目的があったと思われる。WindowsのアプリもDOSのアプリも同じ拡張子「exe」を使っており、Windowsアプリケーションは、先頭部分にMS-DOS互換のプログラムを置くことができるようになっている。

　実際に当時のWindowsプログラムをMS-DOS上で起動すると、「このプログラムはWindows用」とメッセージを表示して終了することが多かったが、原理的には両方で動作するプログラムの開発が可能だった。そうなると、C言語のランタイム部分は、MS-DOS用にそのまま残さねばならない。その場合、MS-DOSでmain関数を使ってしまうため、WindowsはWinMain関数を呼び出してアプリを動作させるように作られた。

　当時のMS-Cは、Lattice-CのOEM版であり、ランタイムや起動コード部分に手を入れることは難しかったのだと思われる。そもそも、Windows自体がOEM版のMS-Cで開発されていた。

　ファイルマネージャーのソースコードをみると、WinMainがそのまま残っている。WindowsもWin32からは、普通にmain関数から起動できるのだが、このとき互換性のためWinMainも残された。しかし、現在でもこの名残が残っているようで、WindowsアプリケーションのランタイムがちゃんとWinMainを呼び出してくれるようだ。

　また、このソースコードでは、現在では「ご禁制」ともいえる、ハンガリアン記法が見られる。

今ではあまり見かけなくなったハンガリアン記法が残るソースコード

　このハンガリアン記法とは、当時マイクロソフトが推奨していた変数の命名方法だ。たとえば、ロングポインターを格納する変数であれば「lp」、ハンドルなら「h」、整数ならば「i」や「n」といったデータの「型」を変数名の頭に付ける方法である。こうしておけば、たとえばlpで始まる変数にhで始まる変数を間違って代入しないだろうと言われていた。当時マイクロソフトは秘密にしていたが、Win32APIなどがデータ構造をアクセスさせるために返すハンドルは、実はポインターだった。

　現在では、あまり意味がないとして、.NETなどでは非推奨となっていて、使う人をほとんど見ない。そもそも、ハンガリアン記法とは、数式を「演算子」と「引数」の順に表記する「ポーランド記法」に由来する命名。この記法を考えた論理学者の出身国から取られた。

　もともとは論理学の表記なのだが、コンピューターで数式を処理する際にはこの形式に変換することで処理しやすくできるため、ソフトウェア開発者には、比較的知られた名称だった。同様にハンガリアン記法は、考案者（チャールズ・シモニー）の出身国から取られた。

　というわけで、ファイルマネージャーのソースコードを見ると、今では見ることはほとんどないハンガリー記法のソースコードが含まれている。だが、このハンガリアン記法、マイクロソフトがWindowsの開発者にも推奨していたが、.NET Frameworkでは利用を禁止している。

.NET Frameworkの「一般的な名付け規則」（General Naming Conventions）では、「DO NOT use Hungarian notation.」とハンガリアン記法を禁止している

　このため、最近のコードサンプルなどではまず見ないのだが、筆者など、ついつい「lp〜」で始まる変数を作ってしまうことが今でもある。