- Sierra On-Line の Space Quest II 2.0D/2.0F 720KB Disk 1 には、ファイル一覧には見えない AGI インタープリタのソースコードが残っており、マスターディスク準備時のミスが市販ディスクにそのまま複製された事例だった
- DOS FAT ではファイル削除時にデータ自体は消去されず、セクタを 未使用としてマーク するだけなので、フォーマットしていないディスクをマスターに使うと以前のデータが複製全体に持ち越される可能性がある
- Disk 1 の 402,432 バイトの “free” 領域には、フォーマットの埋め値 0xF6 の代わりに C/アセンブリのソースが残っており、抽出の結果 93 ファイル、15,000 行以上、AGI インタープリタのソース約 70% が確認された
- FormMaster 複製装置がファイル単位ではなくディスクの全セクタをバイト単位でコピーしたことで、実際のファイル一覧にない 削除済みデータ まで顧客・小売店向けディスクに広がった可能性がある
- 1988 年 3 月、AGI 時代の末期に起きたこのミスは、2016 年 10 月に NewRisingSun が最初の既知の発見をするまで埋もれており、36 年後に Sierra の AGI 実装をのぞき込むデジタル考古学の資料となった
ファイル一覧だけでは見えなかった痕跡
- Space Quest II バージョン 2.0D と 2.0F の 720KB フロッピーディスクは外見上これといった特徴はなく、ファイル一覧も一般的な Sierra のゲームディスクのように見える
- 2.0D のディレクトリには怪しい追加ファイルはなく、PICDIR、LOGDIR、VIEWDIR、SNDDIR、VOL.0、VOL.1 などの主要データファイルは 1988 年 3 月 14 日に作成されている
.OVL ファイルは 1988 年 3 月 15 日、AGI インタープリタのコードは 1988 年 3 月 18 日のタイムスタンプを持っており、Sierra のオフィスで Space Quest II 2.0D の準備が 1 週間にわたって進められた痕跡が残っている- ディスクの使用済み領域は 302,918 バイト、 “free” 領域は 402,432 バイト と表示され、空き領域の方が使用済み領域より大きかった
ヘクスエディタで見えた未使用領域
- DOS で新たにフォーマットしたフロッピーディスクの未使用セクタは通常、フォーマットの埋め値である 0xF6 で埋められる
- Space Quest II 2.0D の Disk 2 では未使用セクタが 0xF6 で埋められていたが、Disk 1 には 0xF6 で埋められた未使用セクタが 1 つもなかった
- Disk 1 で連続する 0xF6 バイトの最長は 2 バイトにすぎず、半分以上が “free” なのに実際には以前のデータが残っていた
- 未使用としてマークされた領域には C ソースコードのように見えるテキスト が入っており、このディスクが Space Quest II Disk 1 のマスターに使われる前に別用途で使われていたことを強く示している
- DOS FAT ファイルシステムではファイル削除時に実データは消去されず、セクタを再利用可能としてマークするだけなので、新しいファイルで上書きされない限り以前の内容はそのまま残る
残っていた AGI インタープリタのソースコード
- 未使用領域の ASCII テキストを抽出すると、
DisplayStatusLine や StatusLineOn といった C 関数 が確認できた
DisplayStatusLine は現在のスコアとサウンド on/off 状態を含むテキスト行を表示するコードで、Space Quest II 画面上部の白いステータスバーと結び付く- このコードはゲームデータではなく、Sierra の AGI インタープリタそのもの に属するソースコードだった
- 未使用セクタには大量のソースコードが入っており、コードは連続したセクタに保存されていたため、比較的容易に抽出してファイルごとに分割できた
- 各ファイル上部にはソースファイル名を示すコメントがあり、分割位置を見つけやすく、分離結果は合計 93 ファイル だった
- 75 個の C ソースファイル
- 16 個のアセンブリソースファイル
- 2 個の DOS BAT ファイル
- 全体のコードは 15,000 行以上 で、ほとんどのファイルは完全な形だった
- このディスクには Sierra On-Line の AGI インタープリタのソースコード約 70% がコメントと変更履歴まで含んだ状態で入っていた
変更履歴と開発者の痕跡
- 一部のソースファイル上部のヘッダコメントには Change History が含まれている
ANIMATE.C のヘッダには、ソースファイル名、「adventure game でアニメーションの 1 サイクルを処理する」という短い説明、compile: MWC などの情報が入っているMWC は当時よく使われていた Mark Williams 社の C コンパイラを指すとみられる- 変更履歴には日付、時刻、変更者のイニシャル、変更内容が含まれる
- イニシャルのうち JAS は AGI インタープリタのコードを主に担当した Jeff Stephenson、DCI は Chris Iden に対応する
- Robert Heitman も登場するが、彼の主な焦点は Picture Editor や View Editor のようなグラフィックツールで、Jeff Stephenson と Chris Iden は主にインタープリタコードを担当していた
AGI.EXE メモリマップと 70% の算出
- Space Quest II 2.0D 720KB Disk 1 には 93 個のソースファイルに加えて、AGI.EXE 実行ファイルのメモリマップ も 2,000 行以上収められていた
- 発売版 AGI ゲームではインタープリタ実行ファイル名は単に
AGI であり直接実行はできないが、開発中は .EXE 拡張子を持つ直接実行可能なインタープリタが使われていた
- Sierra の誰かが 1987 年 10 月 7 日に AGI.EXE、つまり AGI インタープリタのメモリマップを生成していた
- この日付は、ソースコード変更履歴で最も新しいコメントが 1987 年 9 月である点とも一致する
- メモリマップは AGI インタープリタを構成するモジュールとソースファイル一覧を比較的完全な形で提供する
- メモリマップに登場する異なるソースファイルは 98 個 で、そのうち SQ2 ディスク上に完全な形で存在するファイルは 71 個 だった
- この比率を基準に、Space Quest II ディスクには AGI インタープリタのソースコード約 70% が入っていたと計算している
- 一部のモジュールは C ヘッダファイルしか含まれていないため、この計算には含まれていない
Sierra の知的財産としての AGI
- Sierra On-Line は 1984 年の King’s Quest 発売前後に事業面で厳しい時期を経験し、Ken Williams は従業員約 100 人を解雇して人員を約 130 人から約 30 人まで減らさなければならなかった
- その後、AGI アドベンチャーゲームシステムとその上で作られたゲーム群の成功が会社の状況を変える一因となった
- 1984 年末までに King’s Quest はコンピュータゲームソフト販売チャートの上位 20 位に入り、King’s Quest II 発売前まで約半年間そのチャートにとどまった
- Tandy Radio Shack との契約により Radio Shack 店舗で Tandy 版ゲームを販売したことも追い風になった
- 1985 年から 1988 年まで AGI ゲームはベストセラーであり続け、AGI インタープリタは Sierra On-Line の主要な収益手段であり中核的な 知的財産 だった
- AGI インタープリタのソースコード 70% が大量複製され、数万または数十万の顧客に渡ったことは、Sierra にとって大きなミスだった
フォーマットを忘れたマスターディスクの余波
- Sierra が新作ゲームのリリースを準備する際には、FormMaster ディスク複製装置で使う production copy マスターディスク を作成していた
- FormMaster はマスターディスクからファイルだけをコピーするのではなく、使用中かどうかに関係なくディスク上の全セクタをバイト単位でコピーした
- Space Quest II 2.0D と 2.0F の Disk 1 では、この方式のため実ファイルとして使われていなかった 402,432 バイト まで一緒にコピーされた
- マスターディスク準備の過程では、ゲームファイルをコピーする前にディスクを完全にフォーマットする必要があり、Sierra はほとんどのオリジナルゲームディスクでこの手順を正しく実施していた
- Space Quest II 2.0D Disk 1 では誰かがこのフォーマット手順を省いたようで、同じディスクが 2.0F にも使われた
- その結果、顧客や小売店に渡った SQ2 ディスク数十万枚に、AGI インタープリタのソースコード 70% が隠れたまま含まれていた可能性がある
2016 年になってようやく知られたデジタル考古学の事例
- この出来事はほぼ間違いなく意図しないミスであり、Sierra も競合他社も顧客も当時は誰も気づかなかったとみられる
- 最初の既知の発見は、オンラインユーザー NewRisingSun が 2016 年 10 月に行ったものだった
- この出来事が AGI 時代の末期に起きた点も重要である
- 1988 年 3 月の時点で Sierra はすでに SCI アドベンチャーゲームシステムを開発していた
- SCI を使った最初のゲームである King’s Quest IV の発売を控えていた
- AGI インタープリタのソースコードが誤って公開されうる時期があと 1〜2 年早ければ、より大きな問題になっていた可能性がある
- 抽出された AGI インタープリタのソースコードは GitHub リポジトリ にアップロードされている
- Web ベースの AGI インタープリタである AGILE の実装は、もともと AGI ソースコードの一部の助けを受けていた
1件のコメント
Hacker Newsのコメント
1989年のDOS版 Double Dragon II: The Revenge はフロッピーディスク2枚で配布されていたが、そのうち1枚にソースコード全体が削除済みの圧縮ファイルの形で入っていた。
DIRコマンドでは見えなかったが、簡単に復元できた: https://tcrf.net/Double_Dragon_II:The_Revenge(DOS)文字どおり1バイト1バイトがコストだった時代でさえ、人々のFATエントリがカートリッジに焼かれているケースがかなりあるのは笑える。
https://forums.nesdev.org/viewtopic.php?t=17324
ゲームを完成させて何らかのマスターディスクを作り、それを大量生産施設に送ったはずなのに、削除済みの圧縮ファイルがどうやってマスターに入ったのだろうと思う。誤ってコピーして、発売前に消したのだろうかとも思う。
1本目も同じコンピュータで遊んだDOS版Spacewar!だった。記憶が正しければ、ボスまで行くとゲームが止まってしまい、Double Dragon IIを最後までクリアすることはできなかったが、いい思い出だ。
最近、シンセサイザーROMのリバースエンジニアリングをよくやっている。
Yamaha DX9のROMには、バイナリに残った空き領域の中にファームウェアのシンボルテーブルの断片が入っていて[0]、おそらく開発システム由来と思われる6303コードのブロックも大きく入っていた。こういうものを偶然見つけると、本当に驚かされる。こうした方面にすっかりはまっていて、過去を少しのぞき見るソフトウェア考古学者のような気分になり、Yamahaがどんな開発ツールを使っていたのか突き止めようとして深いウサギ穴にはまり込んだ。確定的なことは見つけられなかったが、当時の開発ツールのドキュメントを読むうちに、現代のワークフローへのありがたみが増した。
0: https://ajxs.me/blog/Hacking_the_Yamaha_DX9_To_Turn_It_Into_...
BeBoxで生の入出力や生のディスクセクタ解析をかなり行ったが、BeOSにはファイルシステムのハックに向いたツールがあった。それを通じてWindows向けのファイルシステムドライバを作り、Yamahaの支持を得るほど十分に動作した。いつかA-sampler向けのYamaha ROMをリバースエンジニアリングする気になったら連絡してほしい。この分野にはとても関心がある。DX9/DX7での作業も素晴らしいし、両方のシンセを発売当時から使ってきたユーザーとして本当に面白い。
このゲームは自分の子ども時代であまりにも強烈な位置を占めているので、長い時間が過ぎた今から考えると、むしろ夢のように感じる。
今の生活で、あるゲームに同じ種類のつながりを感じると想像すると、不可能に思える。身の回りのあらゆるものはただのゲーム、番組、物のように感じられるのに、Space Quest 2、3、4は自分のDNAの根本的な一部のように絡みついている。
あの時期のSierraのゲームは本当に特別だった。特にPolice Quest II、LSL III、Hero's Questを同じ頃によく遊んだ。テキストベースのEGA Sierraゲームには魔法のような何かがあり、自分にとってはInfocomと、その後のポイント＆クリック式VGA版との間で、感情的・創作的なつながりがちょうどよい位置にあった。
Space Questは、自分が一番好きな初期インターネットの思い出とも絡み合っている。ウェブサイトが主にGeocitiesや暇な大学生によってホストされていた頃、Space Questのファンサイトがあり、大きなSQサイトの一つの運営者に、ゲームとサイトが好きだとメールを送った。当時14歳くらいだったが、彼はオリジナルのゲーム一式を40ドルくらいで送れると返信してきた。元の箱とフロッピーがある全オリジナル作品だった。1997年頃だったので、国の反対側にいる知らない人に40ドルを送り、本当に送ってくれることを期待するのは少し不安だったが、彼は本当に送ってくれた。数週間後、すべてのゲームが説明どおりに届き、ものすごくうれしかった。一晩で本物の信者になり、今も抱えている楽観主義の太陽の核のような記憶だ。Jess、もしどこかにいるなら、あなたは本物だった。いつかまた会えることを願っている。
父は製鉄所で働いていて、そこのコンピュータ担当者と友人だったのだが、その人が家で試してみるようにとSQ2のコピーをくれた。そのゲームを夢中で遊んだが、かなり幼かったので多くの部分が分からなかった。本当に行き詰まると、父にそのコンピュータ担当者へ特定の箇所をどう越えるのか聞いてもらった。彼は答えをそのまま教えるのではなく、親切にヒントをくれたように思う。35年ほど経ったが、そのゲームに関して見た夢までかなり詳しく覚えている。本当に大きな影響を受けた。
SQ Iはずっと後になってから遊んだし、SQ IIIはそこまで強く響かなかった。残りはもはやEGAのテキスト入力ゲームでもなかった。SQ IIは多くの記憶を呼び起こし、英語もある程度それで覚えた。Roger Wilcoに「rub berries」できると気づいたときの満足感を覚えている。
こういう種類のゲームを初めて遊んだのがこの作品で、10歳くらいのときに何週間もかじりついていた。
AGIエンジンに、競合他社が流出で利益を得られるほど特別な秘伝のソースがあったとは思わない
ほかにも例はあるかもしれないが、Hugo's House of Horrors は数年後に1人で作られたAGI風のゲームだった。グラフィックアドベンチャーという初期の新しさを超えて Sierra のゲームが成功したのは、グラフィックを作り、実際のゲームを書くことに途方もない労力を注いだからだ。技術が何でもないという意味ではないが、最終成果物に占める割合は小さいほうだ
動くソフトウェアを学び、作ることは今日よりも非常に大変で、土台にできるものはほとんどなかった。MS-DOSには意味のあるオープンソースはほとんどなく、オープンソースのゲームエンジンはなおさらなかった。そうした環境でAGIソースが広く流出していたなら、少なくとも当時最も人気のあったPCゲームが正確にどのように作られていたかを示す設計図として、かなり意味があったかもしれない
特にキーやバックドアのようにハッカーが悪用できる秘密が入っていないコードならなおさらだ。流出コードには当然ライセンスがないので、訴訟を避けたいなら自分の製品にそのまま再利用することはできない。結局そのコードを読み、手法を理解し、著作権侵害のにおいがしないように自分の仕事へ適用する必要があるが、たいていは最初から作るより難しい。有利になる場合があるとしても、実際の競争優位につながることがどれほど頻繁にあるのかも疑問だ。開発者は、文書が整っていて寛容なライセンスのオープンソースがあっても、新しくコードを書くことがある。コードを読むことは書くことより難しい場合が多く、単に再ビルドするだけでも難しいことがある。複製を少し簡単にできるかもしれないが、ゲームは通常数日以内にクラックされて配布されていたし、コピー防止コードがソースに含まれていなかった可能性もある
その言語を話せる人自体がおそらく何桁も少なく、それで一貫した何かを作れる人はさらに少なかった
今日では急速に下がっているので、いま触れているものが内部の重みを形成する力は当時ほど大きくない
変更履歴コメントが本当に良い
ソース管理ツールがこうしたものを明確に見せるようになるずっと前の時代に、高い水準の細やかさと職人技を示している。正直、CVS/SVN/Git以後でも、多くの人にとってなお明確ではなかった。この文章は、1986年にソフトウェアは今後もおおむね当時と同じように、プログラマーが1つずつ命令を苦労して書いていくものだろうと予測した有名な「No Silver Bullet」の記事[1]も思い出させる。元記事のゲームエンジンのコードとコメントが、今日自分が書きそうなものと似ているという点は、40年近く後でもその予測を裏付けていると思う
[1] https://en.wikipedia.org/wiki/No_Silver_Bullet
Famicom版Air Fortressには、意図せずROMに入ってしまったものが途方もなく多い
コンパイルされていないASMコード、MS-DOSのディレクトリ一覧、ゲームのビルドに使われたEXEの1つの文字列など、さらに多くのものが入っている。日本版カートリッジは128+128KBだった。その後、米国NES版を作る際にグラフィックデータ128KBの大半が重複グラフィックか未使用で、実際の固有グラフィックは約36KBだった。エンディング中のある惑星画像を削除してグラフィックを32KBに減らし、128+128KBカートリッジではなく128+32KBカートリッジとして発売した
Source: https://tcrf.net/Air_Fortress
こういう状況は実際には非常によく起きていた
The Cutting Room Floor には、偶然含まれたコードが少し入っているケースから大半が入っているケースまで、約500件が挙げられている
https://tcrf.net/Category:Games_with_uncompiled_source_code
自分も同じ判断か気になる。King's Quest III のディスクでも同じことがあり、実際には Space Quest II の事例とほぼ同じ時期に起きたように見える
いちばん気に入っている点は、1世代が過ぎるまでディスク上に置かれたソースコードを誰も発見しなかったように見えることだ
「驚くべきことに、Sierraも競合他社も顧客もこの出来事に気づかなかったようで、発見されたのは数十年後だった。知られている最初の発見は、2016年10月にオンラインユーザー NewRisingSun によるものだ。」最近の Tetris や Super Mario Bros. のブレークスルーも思い出す。子どものころにこれらのゲームを遊んだときは、数十年後には忘れられた遺物として残り、最も熱心な愛好家でなければ実行することすら不可能になっているだろうと思っていた。ところがインターネットとエミュレーターが、そうした初期のゲームやコンピューティングに新たな命を吹き込んだ
削除されたファイルを発見した人は確かにいただろうが、インターネットが普及する前だったため、広く知られたり記録されたりしなかった可能性が高い
こうしたディスクをイメージ化している途中で、空き領域に残っていたデータを誰かが見つけたのかもしれない
1987年から1993年の間に、Macアプリ2本のために約9枚のマスターディスクを用意した
いつも新しいフロッピーを使い、ディスクが正しいことを確認するための長いチェックリストがあった。幸いどれも問題なく、特にその一部は10万枚のディスクを作るのに使われた。今では誰もこんな作業をしなくてよくなっていて本当に良かった
こういうレイヤーを見たことがある：base、ツール追加、ソースコード追加、コンパイル、ソースコード削除、追加ツール削除、リリース。「なぜDockerイメージがこんなに大きいんだ？ まあストレージは安いし……」というような状況。マルチステージビルドのような簡単な解決策もある（ https://docs.docker.com/build/building/multi-stage/ ）。ただ、現在のDockerイメージのビューに過去のレイヤーがすべて含まれるということを知らなければ、たまにはミスが起きる
リリース成果物を手作業で作っていた時代には、リリースするつもりのなかった残骸がよく入り込んでいた
カットされたコンテンツ[1]やデバッグシンボル[2]のようなものだ。自分がリバースエンジニアリングしているビデオゲームのデモ版データアーカイブの中に隠れていたデバッグシンボルを偶然見つけたときは、予想外だったが非常に役に立った。最近はCI/CD、自動ビルド、その他の現代的な開発慣行のおかげで、こういうことは起きにくくなっている可能性が高い
[1] https://tcrf.net
[2] https://www.retroreversing.com/games/symbols
エラーがなければ、何千行ものコンソール出力を誰も見ない。最終リリースパッケージに不要なものが過剰に入っていても、テストは通る可能性が高い。だから私の直感はむしろ逆だ。もっと頻繁に起きるかもしれないし、少なくとも手動ビルドよりCI/CDのほうが、こうしたことを起こしやすくしている可能性もある。他の要因もあるかもしれない