Quake を 1997 年の道具でビルドし直す — 再現性を運用者目線で読む

結論 — 1997 年の Quake 再ビルドは懐古ではなく「環境を固定する」話

Fabien Sanglard の "Compile Quake like it's 1997"（1997 年当時のツールチェーンで Quake をビルドし直す試み）を読んで、私が手元に残したのは懐かしさではなく「ビルドは環境ごと固定しないと再現しない」という当たり前の再確認でした。彼がやっているのは、Windows NT 4 に Visual C++ 6 を入れ、Service Pack 5 と Processor Pack を重ね、WinQuake.dsw を開いて Rebuild All を押すだけ。手順は短いのに、つまずく場所はすべて「環境の固定漏れ」に集約されます。私は auto-publish の Docker ビルドで同じ轍を何度も踏んできたので、これは過去の話に見えて、2026 年の自分への注意書きでした。

なお、この記事は AI が下書きを書き、私が一次情報（元記事）に当たって確認・編集してから公開しています。懐古の感想ではなく、運用に効く読み方だけを抜き出します。

何をやっているか — VC++6 SP5 + Processor Pack で WinQuake.dsw を組む

要点だけ言うと、当時の Win32 版 Quake を「当時の道具」で組み直す手順は、思ったより素直です。元記事の再現環境は Windows NT 4.0（または Windows 98SE）に Visual C++ 6 + Service Pack 5 + Processor Pack を入れ、q1source.zip を展開して WinQuake.dsw ワークスペースを開き、Rebuild All を押すだけ。インストールはおよそ 30 分で終わると書かれています。

ここで面白いのは、id Software の開発環境そのものが時期でころころ変わっていることです。初期は NeXT を載せた HP 712-60 で書き、DEC Alpha 上の DJGPP でクロスコンパイルしていた。1996 年 6 月以降は Windows NT の Intergraph ワークステーションに移り、Visual C++ 4.X を使う。1999 年ごろには VC++6 へ。つまり「Quake のビルド環境」は単一ではなく、製品の歴史とともに動いていました。再現するときに「いつの Quake か」を決めないと、そもそも道具が定まらない。

一次資料を運用目線に翻訳する読み方は、以前 自サイトで llms.txt を半年運用している立場から annas-archive の手紙を読む でもやりました。やることは同じで、短い手順の裏にある前提条件を拾います。

つまずきは、全部「前提の固定漏れ」だった

元記事の難所を並べると、技術的な難しさではなく、ほぼ全部が「暗黙の前提が抜けると動かない」という同じ形をしています。これは現代のビルドでも寸分違わず起きる失敗です。

具体的には 3 つでした。1 つ目、Service Pack 5 が MDAC 2.5（Microsoft のデータアクセス系ランタイム）を先に入れないとインストールできない。2 つ目、Michael Abrash が手で最適化したアセンブリ（.s ファイル）をビルドするのに ml.exe（Macro Assembler、アセンブラ本体）が要り、これは Processor Pack 側に同梱されている。3 つ目、.dsw ワークスペースファイルを FTP や GitHub 経由で運ぶと壊れることがあり、q1source.zip のまま展開する必要がある。どれも「あって当然の前提」が 1 つ欠けるだけで、Rebuild All がそもそも通らない。

30 分で組める、と書いてあるのはたぶん本当です。ただ「MDAC 2.5 が無い」の一行に気付くまで午後が溶ける、というのは OS もモデルも違えど私の身に覚えがある。足りない前提が半日を溶かすのは、どうやら時代を超えて普遍らしい。

私が Docker で同じ轍を踏んだ話

正直に書くと、私はこの「前提の固定漏れ」を 2026 年の Docker で何度もやっています。古い話どころか、つい先月の私の失敗です。

auto-publish のビルドで、ベースイメージを node:24 のようにメジャーだけ固定して minor / patch を流していた時期がありました。ある朝、半年動いていたビルドが突然落ちる。原因は base image の patch 更新で、依存の 1 つが入れ替わっていたからでした。Quake の MDAC 2.5 と構造はまったく同じで、「あって当然と思っていた前提が、いつの間にか別物になっていた」だけです。私はそこから base image を digest（@sha256:...）でピン留めし、lockfile を必ずコミットに含める運用に切り替えました。固定する手間より、ある朝ビルドが落ちて原因を探す午後の方がずっと高い、と身体で学んだ格好です。

「いつ・何を選んだか」を記録に残す話は ツール選定ジャーナルを未来の自分に渡す に書きました。20 年放置された MySQL Bug #11472 を今になって読み直したときも感じましたが、古いものを再現・再訪する作業は、たいてい現在の自分の足元を点検することになります。

1997 と 2026 で、変わったものと変わらないもの

道具は別物になったのに、再現性の急所はほとんど変わっていない、というのがこの記事の一番の収穫でした。変わったのは、固定の「やり方」だけです。

当時は OS とコンパイラと Service Pack を物理的に揃えるしかなかった。今は Dockerfile に base image の digest を書き、lockfile を添え、CI で同じ手順を回せば、誰の手元でも同じバイナリに近づけられます。Sanglard が NT 4 のメディアと VC++6 を集めて 30 分かけて再現した作業は、2026 年なら docker build 一発に畳める。一方で変わらないのは、「前提を 1 つでも書き落とすと再現しない」という冷たい事実の方です。digest を書き忘れた Dockerfile は、MDAC 2.5 を入れ忘れた NT 4 と同じくらい無力になります。

供給側の前提が崩れる怖さは npm/PyPI のサプライチェーン攻撃を個人開発で踏まないために でも書いた通りで、固定は再現性だけでなく安全性の土台でもあります。

まとめ — 古いビルドの再現は、今の足元の点検になる

Quake を 1997 年のツールチェーンで組み直す記事から私が持ち帰れたのは、「再現性は道具ではなく前提の固定で決まる」「前提は 1 つ抜けるだけで全部止まる」「固定の作法は時代で変わるが急所は変わらない」の 3 行でした。懐古趣味の記事に見えて、読み終わると自分の Dockerfile を開きたくなる。

私の auto-publish は明日も Docker でビルドされますが、base image は digest で、lockfile はコミットに入っています。MDAC 2.5 の一行で午後を溶かさないために、未来の私への前提は、できるだけ全部書き出しておく。それが 1997 年の Quake から受け取った、いちばん実用的な土産でした。