2026/04/20 13:14
テセウス：静的な Windows エミュレーターです。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
プロジェクト Theseus は、静的バイナリ翻訳（Static Binary Translation）により従来のパフォーマンスのボトルネックを克服する、新たな Windows および x86 エミュレーターです。これは、遅いインタプリタや複雑な即時実行（JIT）コンパイラとは異なります。入力データをコンパイル時に分析し、PE パースや IAT の解決といったタスクを処理することで、This approach は機械語を最適化されたネイティブコードに変換し、ランタイムオーバーヘッドなしに動作します。このアプローチは動的な制御フローに対して完璧ではありませんが、それには手動での介入が必要な場合があります。それでも、翻訳されたインストラクションは読みやすいソースコードとして機能するため、ネイティブデバッグ、スタックトレース、オフライン CPU プロファイリングが可能となり、開発者にとって大きな利点を提供します。
著者がこれらの概念を考察するきっかけとなったのは、「retrotick」というウェブベースのエミュレーターへの貢献でした。このエミュレーターは AI を用いて短時間で構築されたと報告されています。これは、古いゲームを手動でパッチ修正するという慢性的なプロセス（数カかりかかる場合もあり）から、複雑なシーンを数週間で作成できるような簡素化された開発への文化的転換を浮き彫りにしました。さらに、Theseus は層状アーキテクチャ（ホスト WASM VM → Theseus WASM VM → x86 VM）を通じて WebAssembly をターゲットにできることで多様性を示しています。将来の進化は動的な制御フローを手動で管理することと、「変換的著作物」に関する法的課題を解決することに依存しますが、Theseus は現在のエミュレーション手法に対する実現可能で堅牢な代替手段を表しています。
本文
この投稿は、私の「retrowin32」シリーズのおおむね最終回となろうか。ここでは、静的にプログラムを翻訳する新しい Windows/x86 エミュレータTheseusをご紹介いたします。本ツールはいくつかの従来のエミュレーション上の課題を解決すると同時に、新たな課題も確かに引き起こすものですが、それはまた非常に興味深い点です。
retrowin32 の行方は？
私は自分の Windows 用 x86 エミュレータ「retrowin32」の開発を進めておりませんでした。これは、日々の生活への支障と、同プロジェクトの今後がどこへ向かうべきか確信を持てなかったことによる部分もあります。そこに、以前から貢献されていた方が、より洗練された Web 上の Windows エミュレータ**「retrotick」**を公開し、ハッカーニュース (HN) 上で「Claude という AI ツールを使ってわずか 1 時間で完成させた」と投稿されました。
これは AI に特化した投稿ではありません（既にそのような投稿は数多く存在するため）が、現時点で AI に関する私自身の感情はまだ整理できていないのです。しかし、私は一つの小さな点について思索を続けてきました。それは以下の 2 つの事実です。
- AI が、次第に若手エンジニアから上級エンジニアへと登竜門を昇りつめていること。
- シニアエンジニアであることの主要な要件は、「どう実装するか」という技術的な側面ではなく、「何を生み出すべきか」という本質的な方向性をより深く理解していることにあります。
（これは単なる「イノベーターズ・ジレンマ」における「上位市場への撤退」という概念を、私が人間として持つ有用性に適用したに過ぎないのでしょうか？それとも全く別の意味でしょうか？）私は幸運です。この作業は私の好奇心を満たすために取り組んでいるため、企業のビジネスのように存在基盤の危機を感じることなく、単なる旅情に身を委ねることができます（Benny Feldman の言葉で言えば、「私などには物質的富への執着がないため、カジノで裏から勝っているようなもの」です）。
さて、ご質問です。「シニアエンジニアという立場で、我々は何を生み出すべきでしょうか？」エミュレータを用いて解決すべき本質的な問題は何か。そして、現在のアプローチはそれらをどのように捉えているのでしょうか？私はある非公式な解決策に至り、それを皆様に紹介したいと考えております。
エミュレータと JIT（Just-In-Time コンパイル）
最も単純な CPU エミュレータは、インタプリタと非常に似ています。入力されたプログラムが解析され、x86 命令として以下のように記述されます：
mov eax, 3add eax, 4call ... ; Windows システム API の呼出
インタプリタ方式のエミュレータでは、この一連の命令をループ処理して実行します。以下のような実装イメージになります：
loop { let instr = next_instruction(); // 次の命令を取得 match instr { // 例：mov eax, 3 Mov => { set(argument_1(), argument_2()); } // 例：add eax, 4 Add => { set(argument_1(), argument_1() + argument_2()); } ... } }
このアプローチは、インタプリタと同様に低速です。高レベルで見れば、インタプリタは各命令に対して多数の動的な処理を行わねばならないため遅いからです。同一の
addまた、x86 の
addエミュレーション性能を向上させるための様々な面白い技術がありますが、もし高速化を目指すのであれば、コードの解析とそれからのネイティブマシーンコードの生成、つまり JIT (Just-In-Time コンパイル) を組み合わせるしかないのです。JIT は書き方が特に難しいことで知られています。実質的に最適化コンパイラを記述する必要があるため、最適化の複雑さやマシーンコード生成の難しさに加え、そのコンパイル自体の実行時間がパフォーマンスのボトルネックとなるからです。この投稿で論じられた「JIT がなぜ難しいのか」という点については、すでに Python の JIT を試みた 15 の以上のアプローチが存在するということが言及されています。
静的バイナリ翻訳
効率的なマシーンコードを生成したいが、JIT を書くのは困難だと考えている場合、何が本当にコードの解析と効率化されたコード生成において優れているでしょうか？それはコンパイラです。
したがって、ここで提案する主要なアイデアは以下の通りです。上記の入力 x86 コードスニペットを例として与えられたコードから、次のようなソースコードのように処理することができます：
regs.eax = 3; regs.eax = add(regs.eax, 4); windows_api(); // 呼出された API に対応するネイティブ実装
その後、このコードを最適化コンパイラに再度入力することで、現在のアーキテクチャ（x86 の必要のない）ネイティブなプログラムを得ることができます。つまり、JIT コード生成を行う可能性があるエミュレータに直接
.exe.exe（※ここでいう「ネイティブ」とは引用符で囲んでいるのは、生成された実行ファイルが確かにネイティブバイナリであるにもかかわらず、その内部には x86 の状態を表すような仮想マシンを載せ持っており、上記コード内の
regsこの基本的なアイデアは、私が達成しようとする目的を深く思索した結果、独自に思いついたものだと思いましたが、実際にはこのアプローチは**「静的バイナリ翻訳」**として知られており、よく研究されている手法です。これには素晴らしい利点もあれば、大きな課題もあります。
逆コンパイル（Decompilation）
その課題について詳述する前に、私がどのようにしてこの道筋に至ったかという小さな逸話を付け加えておきます。「逆コンパイル (decompilation)」をご存知でしょうか？狂人たちの集団（マッドピープル？）が、古いビデオゲームのソースコードを手作業で機能ごとに再構築しています。彼らはゲームのバイナリから一つの関数のマシーンコードを抽出し、「最近のアクティビティ」などのメニュー項目をクリックするといった高度な UI を使いながら、その高級なコード（ソースコード）を実行した際に得られる同じマシーンコードを生成するように、反復的に推敲を行っていきます。これは実に驚くべきことです。
（この作業を行うためには、目標とするゲームをコンパイルに使用した元のコンパイラーを実行する必要があります。これらのコンパイラは Windows 向けのプログラムであることが多く、その UI を実装するには Linux サーバー上で古い Windows バイナリを実行しなければならないという設定になっています。私はここで初めて彼らの存在を知りました——彼らには Windows エミュレータが必要だからです！）
逆コンパイルは単なる奇妙で魅力的（かつおそらく面倒な？）人間による作業にとどまらず、私にとって重要なことを浮き彫りにしました。「どんなプログラムもランできるエミュレータ」を所有したいという欲求よりも、「ごく特定の少数のプログラムを動作させたい」という欲求の方が強く、それを実現するために手作業であっても惜しまないのです。
実際、Windows エミュレータを作る人間を見ると、手術をする医師のようにプログラムの心臓部（コア部分）に手を突っ込んでポンピングしなければならない状況に陥ります。ターゲットとなるプログラムをデバッグしたり、個々のバグを取り回したりするのも当然含まれます。エミュレータであっても、動作が確認されているか失敗するかというプログラムのリストを手作業で管理・キュレーションすることは一般的です。
古き良きアイデア
マシーンコードを静的に翻訳するというアイデアは決して新しいものではありません。なぜより普及していないのでしょうか？私がこれに関連する論文を読み込んだ際のもう一つの印象としては、それは機能しないと言いがられがちですが、少なくとも現時点ではうまく機能しています。私自身、まだ見過ごしている不可能な問題を発見していないかもしれませんか？
（このブログ投稿に関連する先行技術を調べる際、「NES の静的翻訳は不可能である」と結論付けた試みも目にしましたが、同時にそれを成功させている人々も見かけましたので、その可否を断じるのは困難です。）
主に二つの問題があります。一つは技術的な課題、もう一つは文化的な課題です。
- 技術的な側面： 単純なアイデアには複雑な詳細が存在します。まず、実行時にコードを生成するすべてのプログラム（例えば JIT を内部に含むもの）はこのアプローチでは機能しません。私はそれらをスコープ外と見なして差し置けば簡単です。制御フローの働きなども課題ですが、それは些細で興味深く、将来的な投稿で触れたいと思います。一般的な研究トピックとして、実行時にコードを生成しないプログラムであっても、vtable やジャンプテーブルによる動的制御フローが存在するため、静的に実行される可能性のあるすべてのコードを見つけるのは理論上不可能です。特に、ほとんどのコードを見つける技術は存在しますが、完全な成功を保証するアプローチはありません。ここで逆コンパイルの考え方が私の見方を転換させました：特定のプログラムに対して少しの手動による援助を許容すれば、この問題は解決できるかもしれませんか？
- 文化的な理由： バイナリ翻訳は、すでにほとんどのプログラムを処理する汎用エミュレータほど便利ではありません。ユーザーはコンパイラツールチェーンを実行することを望まず、プロジェクト全体で LLVM を埋め込むなどの工夫をして回避する場合もありますが、依然として障壁です。もう一つの文化的問題は、翻訳されたプログラムを配布することの法的帰結にあります。すべてのビデオゲームエミュレータは、「まず、物理的に所有しているコピーからゲームデータを複製し、それを入力として渡す」という法的不正（法的フィクション）に頼っており、それによって派生的著作物ではないと主張しています。しかし私はユーザーを解決するためではなく、自分の関心のために動いているのです。これらの文化的課題には私が配慮する必要はありません。
利点
再び上記のスニペットを考えます（3 と 4 を足す例）。静的翻訳の世界では、インタプリタが実行時にどこから値を読み書きしているかを考慮するのではなく、命令ストリームを事前に解析するため、コンパイラは
eaxコンパイラはターゲットアーキテクチャ向けの正しいマシーンコードを生成するだけでなく、上記のようなコードを単一の値「7」の保存に変えるように最適化します。また、適切な文脈で設定すれば、コンパイラはパリティ計算など不要なコードを排除することも可能です。Theseus のコード生成は「オフライン（プログラム実行とは別個）」に起こるため、JIT が持つような「コード解析のために実行時間を消費する」ことへの懸念が少ないのです。
このプロジェクトを開始した当初、「このアプローチの最大の利点はパフォーマンス向上だ」と思っていたのですが、実際には開発も容易になるという利点がありました。それは以下の他の開発ツールを活用できるためです：
- 翻訳された命令は出力プログラム内の正規のコードとして表示されるため、ネイティブデバッガーを使って翻訳された命令（ソースコードとして見える）を行単位でステップ実行できます。
- プログラムがクラッシュした際、ネイティブスタックトレースによって元のプログラムの（翻訳されたアセンブリの）状態まで追跡できます。
- CPU プロファイリングについても同様の利点が期待できます。
retrowin32 では、問題の特定を助けるための全体にわたるデバッガー UI を構築せざるを得ませんでしたが、Theseus においては現時点ではシステム標準のデバッガーで十分動作しています。
また、retrowin32 ではエミュレータとネイティブコードをつなぐ境界（ブリッジ）に時間を費やしましたが、Thisues でもその境界は存在しますが非常に小さくなりました。翻訳されたコードは直接、私によるネイティブ Windows 32 システム API 実装を呼ぶことができるためです（データのやり取りのために必要な小さなグルーコードを介します）。
MacOS 上で retrowin32 を動かす場合、Rosetta の下で動作しましたが、全体の実行可能ファイルが x86-64 バイナリになる必要があり、クロスコンパイルされた SDL も必要でした。一方、Theseus のバイナリはネイティブコードであり、単にネイティブ SDL を呼び出すだけです。
総じて言えば、これははるかにシンプルです。このアイデアからテストプログラムの動作確認に至るまで、最初のシーンの実行を含め、DirectX、FPU、MMX などを含めたすべての要素を試行錯誤しながらも、数週間で完成させることができました。
部分的評価（Partial Evaluation）
インタプリタから JIT へ、そして静的バイナリ翻訳へと至るアプローチの違いは、「事前にどの程度の作業を、および実行時にどの程度の作業を行うか」というスペクトルとして捉えることができます。Theseus は「どのような
mov別の例として、典型的な Windows エミュレータは起動時に PE 実行ファイルを解析・読み込む必要がありますが、Theseus はコンパイル時に行い、必要なデータ構造のみを出力します。結果のプログラムには PE 解析コードそのものは不要です。
同様に、プログラムの起動時には関連する DLL（システム由来も含む）とのリンクと読み込みが必要です。しかし Theseus は実行するすべてのコードを見る必要があるため、このリンクもコンパイル時に事前に行います。Windows API の呼出付近の出力例では、コンパイル時に IAT（Import Address Table）参照（
ds:[...]// 004012a0 push 4070A4h push(ctx, 0x4070a4u32); // 004012a5 push 8 push(ctx, 0x8u32); // 004012a7 call dword ptr ds:[4060E8h] call(ctx, 0x4012ad, Cont(user32::CreateWindowExA_stdcall))
ある意味で、Theseus はコンパイル時にシステムバイナリラダーを部分的に実行しているように見え、出力されたソースコードは準備状態のスナップショットです。これは実装ファイルの解凍問題（アンパック）に少し似ています。
WebAssembly
Theseus は WebAssembly 上で動作するよう拡張しやすく、生成したプログラムをほぼそのまま wasm ターゲットアーキテクチャにコンパイルすれば完了します。（当初はこれを動作させていましたが、現在では追加の複雑さは不要だと判断して実装を行っていません。）
また、別個に言えば、Theseus の出力プログラムは WebAssembly の実行方法にも着想を得ています。どちらも、コードとメモリを持つのみの「機械」を持ち、そこから読み書きするのみで外部へのブリッジ（ホストへの接続）のために提供されたフックを呼ぶ必要がある、という外部のホストプログラムがあります。WebAssembly と同様に、Theseus の出力実行可能コードはデータから隔離されており、意図しないあるいは悪意のあるメモライットがどれだけ行われようと新しいコードを生成することはできないという利点があります。
Wasm 対応の Theseus は「トゥルデンcken（ターデケン：3 つのカテゴリの機械を重ねたもの）」のような構造になります：
- ネイティブホストマシンの WebAssembly 実装（例：Chrome のランタイム）と、その記憶領域概念。
- その中にこれら Thisues wasm ブLOB と自身の記憶領域概念（例：私の Rust Windows API 実装による割り当て位置）。
- さらにその内部には x86 仮想マシンと、Windows プログラムの記憶領域概念（例：「メモリオフセット $x の静的データテーブルから読み取る」など）。
これについて考えてみると、いくつかの階層を混合させたり、WebAssembly プログラムのメモリアドレスを Windows プログラムのメモリアドレスと 1:1 に合わせることを試みたくなるかもしれません。すなわち、入力プログラムが $x アドレスに書き込む場合、それをまさに WebAssembly メモリの $x アドレスへの書き込みとして翻訳するということです。（中間層には調整が必要で、x86 プログラムで使用していない場所でのデータ構造を隠蔽する必要があります）。私は retrowin32 を x86 エミュレータ下で動作させるために、似たようなことをしました。
WebAssembly はさらにもう一つ利点を提供します。バイナリから直接メモリの配置を行うことができるという点です。しかしこれは実際の利益にはあまりなりにくく、むしろちょっと愛らしいだけです。
この WebAssembly と静的バイナリ翻訳に関する話題について詳しく知りたい場合は、WebAssembly を実行する問題に適用した静的バイナリ翻訳であるwastrelをご確認ください。これらを読み、私のアイデアの種を与えられたことになりました。
Theseus
私はこのプロジェクトを「Theseus（ THESEUS：タイタン神族に属する英雄で、船の名前）」と名付けました。
上記の投稿冒頭の x86 アセンブリを再び考えてみましょう。これは何をしているでしょうか？その解釈方法による正しい答えは、「3 と 4 を足すこと」、あるいは単に「7 を計算すること」です。あるいは、「eax レジスタに 3 を格納し、eax に 4 を加算し、CPU クロックを消費し、各種 CPU フラグを設定すること」と言っても良いでしょう。
私のコンパイラがこれらの解釈の一つを別のものと置換した場合、それはまだ同じプログラムでしょうか？文脈によって異なります（例：NES のようなシミュレーションではクロックの正確さが重要視される）。Theseus の場合、私は入力されたプログラムのすべての部品を一つずつ置換してしまっているため、もはや元のプログラムとは異なるものとして扱います。
さらに遠い将来のアイデアとして、またタイタンの船のような概念に基づいています。Windows API の実装は「ハリームズ法則（Hyrum's Law：API が公開されると後で使う人が想定外の使い方をしようとする）」への対処を永遠に続けることと同義です。前述のランダムなバグ回避策を考えてみてください。「DirectPlayEnumerateA」の API をドキュメント化する場合、コールバックを呼ぶ旨だけを記すべきでしょうか、それともコールバックを呼んだ後でスタックポインタを復元することについても正しく説明すべきでしょうか？現在の Wine（Windows エミュレータ）のコードを見ると、これらのような箇所が満載です。
私が考えているアイデアの一つは、こうした問題に対してエミュレータをより複雑にするのではなく、逆コンパイル手法から学んでプログラムの部品そのものを置き換えるための簡単な方法を提供することです。プログラムの一部さえ置き換えることに同意すれば、より興味深い可能性が生まれます。プログラムの中でパフォーマンスが良くないコードが存在する場合、JIT をより高度なものとすることがなくても、単にあなたのオリジナル実装でコードを置き換えるだけで十分かもしれません。（アルゴリズムを変更する必要もなく、同じアルゴリズムをネイティブコードで書き直し、現代のコンパイラの自動ベクトル化ロジックが適用されるだけでも十分です）。十分な仕組みがあれば、機能追加のための部品置換さえも可能です（retrowin32 の貢献者らがここで調査し、一部の GameBoy ゲームに対して実際に実装したものです）。