1997年当時のようにQuakeをコンパイルする：レトロ開発への旅

現代のデベロッパーにとって、「コンパイル」という行為は、通常、洗練されたIDEでの数回のクリックや、ターミナルでの単一のコマンド、そしてパッケージマネージャーによる依存関係の自動処理を伴うものです。しかし1997年当時、Quakeのような最先端のタイトルを構築することは、特定のハードウェア、脆弱なツールチェーン、そして手動設定が絡み合う危ういダンスのようなものでした。

この環境を再現することは、単なるノスタルジー旅行ではありません。それはソフトウェアエンジニアリングの進化と、初期3D時代を定義した実用的な転換点についての研究です。このガイドでは、当時のツールとオペレーティングシステムを使用して、QuakeのWin32バイナリを再構築するプロセスを探ります。

Quakeスタックの進化

Quakeの開発は、単一の環境で行われたわけではありません。初期の実行ファイルであるquake.exeとvquake.exeは、NeXTを実行するHP 712-60ワークステーション上でプログラミングされ、DEC Alphaサーバー2100A上でDJGPPを使用してクロスコンパイルされました。しかし、NeXTが停滞するにつれ、id Softwareは1996年6月に極めて重要な転換を行いました。

John Carmackが指摘したように、チームはQuakeのリリース直後にWindows NTを実行するIntergraphハードウェアへと移行しました。この移行が、winquake.exe、glquake.exe、そしてQuakeWorld（qwcl.exeとqwsv.exe）への道を開きました。これらはすべて、Windows NT上でVisual C++ 4.Xを使用して開発およびコンパイルされました。

1997年の環境を再現する

歴史的な正確さを期すためには、ターゲットとなる環境を選択しなければなりません。「純粋主義者」のルートは、Intergraph RealizM Dual P6-200MHzワークステーションやデュアルPentium Proマシンを探し出すことですが、よりアクセスしやすいアプローチは、90年代後半のPC、あるいはWindows 98SEやWindows NT 4.0を実行するVirtualBox VMを使用することです。

Windows NT 4の設定

Windows NT 4のインストールは単純なプロセスですが、その時代特有のミニマリズムを浮き彫りにします。Windows 95/98とは異なり、NT 4は起動時に検出されたCPUやRAMを余計なアニメーションなしで誇らしげに表示しました。当時の重要な技術的な癖は、システムに2つ目のCPUを追加しても自動的に検出されないことでした。SMP（対称マルチプロセッシング）システムに必要なHardware Abstraction Layer (HAL)を実装するには、OSのフル再インストールが必要でした。

ツールチェーン：Visual C++ 6

QuakeはもともとVC++ 4.Xでコーディングされていましたが、プロジェクトは1999年までにVisual C++ 6へと移行しました。今日、VC++ 6を設定するには、Internet Archiveやwinworldpc.comのようなアーカイブからインストーラーを入手する必要があります。

現代の高解像度モニター（例：1280x1024）でVC++ 6をインストールする際、すぐに気づくのはその不自然なレイアウトです。インストーラーは640x480または800x600の解像度向けに設計されており、広大な空きスペースが残ります。これは90年代半ばのディスプレイ標準を思い起こさせます。

ビルド・プロセスとその落とし穴

Quakeをコンパイルすることは、プロジェクトを開いて「Build」をクリックするだけのように単純ではありません。不注意な者にはいくつかの重大な罠があります。

ソースの整合性: ソースコードは特定のアーカイブ（Quake Official Archiveなど）から入手する必要があります。GitHubからダウンロードしたり、FTPでASCIIモードを使用して転送したりすると、.dsw（ワークスペース）ファイルが破損し、IDEがエラーメッセージを表示せずにプロジェクトを解析できなくなることがあります。
アセンブリのハードル: 標準的な「Rebuild All」は、最初は失敗します。これは、Quakeが.sファイルに格納されたMichael Abrashによる手動最適化されたアセンブリコードに依存しているためです。これらには、ml.exeアセンブラが必要ですが、これはVC++ 6の基本インストールには含まれていません。
依存関係の連鎖: ml.exeを入手するには、VC++ 6 Processor Packをインストールする必要があります。しかし、Service Pack 5 (setupsp5.exe) は、MDAC 2.5が先にインストールされていない限り、インストールに失敗します。解決策は、しばしば解凍されたフォルダ内にmdac_typ.exeとして隠されています。

これらの依存関係が解決されると、プロジェクトはついにコンパイルが可能です。必要なDLL（PmProXX.dll、WdirXX.dll）とid1フォルダをコピーすることで、ゲームはプレイ可能になります。

レトロ・エンジニアリングへの考察

振り返ってみると、Visual C++ 6は当時としては強力なものでした。現代のIntelliSenseのような自動補完機能は欠けてていても、1998年当時には「Go to definition」やブレークポイント、スタックトレース、変数検査といった機能が魔法のように感じられたものです。

コミュニティの議論では、Quakeのコードベースの圧倒的な品質が強調されています。一部のデベロッパーは、このプロジェクトがわずか2つの警告（warning）のみでコンパイルできることに注目しており、これはJohn Carmackと彼のチームが維持していた厳格なエンジニアリング・スタンダードの証です。デバッグビルドでassertを多用し、警告をゼロにするよう努めるというこのレベルの規律律は、現代の一般的なゲーム開発において、これほど頻繁に見られるものではありません。

哲学的な転換：なぜWin32か？

Win32への移行に関するJohn Carmackの歴史的な視点によれば、業界の軌跡を洞察することができます。彼は、DOSの制限と比較して、TCP/IPサポート、動的リンク、および強力な仮想メモリの利点から、Win32を必然的な勝者と見なしていました。彼はNeXTSTEPのUIとUnixのパワーに対して深い愛着を持っていましたが、市場とハードウェアアクセラレーション（OpenGL）の現実的な実用性から、Windows NTがid Softwareの将来にとって唯一の実行可能な選択肢となりました。

最終的に、Quakeを時代に即した環境でコンパイルすることは、単なる技術的な演習ではありません。それは、デベロッパーがCPUのサイクル数一つ、メモリのバイト数一つにまでこだわり、現代の3Dエンジン基盤を築き上げた時代の窓です。