【ITニュース解説】Box of bugs (emulated)

エミュレータ「86Box」のバージョン5.0がリリースされた。この新しいバージョンは、IBM PCとその互換機を低レベルで再現するソフトウェアで、動的なプロセッサ命令再コンパイラの導入、より広範なハードウェアサポート、そして既存の多くのコンポーネントでの大幅な性能向上を実現した。特に、Windows 95の発売30周年という記念すべき日にリリースされたことは、このエミュレータが目指す「過去のコンピュータ環境の忠実な再現」という目標を象徴している。

では、なぜ現代において古いコンピュータをエミュレートする必要があるのだろうか。一般的な仮想化技術であるハイパーバイザは、複数のオペレーティングシステムを効率的に実行するために、ハードウェアを抽象化する。しかし、86Boxのようなエミュレータは、個々のハードウェア部品、例えば特定のCPUやグラフィックカードの具体的な振る舞いまでソフトウェアで完全に模倣する。これは、オリジナルの4.77MHzで動作するIBM PC XT向けゲームのように、プロセッサの速度ではなく、当時のハードウェアの特性に依存するプログラムを正確に動作させる上で不可欠な機能だ。エミュレーションの精度が高ければ高いほど、過去のソフトウェアが意図された通りに動作することを保証できる。わずかな再現の抜け漏れが、エミュレートされたシステムの全体的な誤動作につながることもあるため、開発者は詳細な技術資料を綿密に確認し、バグを修正する。

このような開発の現場で、プログラムの品質を向上させ、バグを早期に発見するために役立つのが「静的解析ツール」だ。静的解析とは、プログラムを実際に実行することなく、ソースコード自体を解析して、潜在的なバグや脆弱性を見つけ出す手法である。手作業でのコードレビューだけでは見落とされがちな問題も、ツールを使うことで効率的に洗い出すことができる。今回のニュースでは、PVS-Studioという静的解析ツールが86Boxのコード解析に用いられた事例が紹介されている。

PVS-Studioを86Boxのプロジェクトに適用するためには、まずツールをインストールし、解析の設定を行う。86Boxのプロジェクトは、Windows上でMSYS2/MinGWという環境を使ってコンパイルされる。これは、Windowsの標準的な開発環境では利用できないUnix系のヘッダーファイルや関数を使用しているためだ。プロジェクトのソースコードを特定のバージョン（v5.0）に固定し、デバッグ情報を含むリリースビルド設定でコンパイルする。その後、PVS-Studioのコマンドラインツールを使って、プロジェクトが使用するコンパイラを指定し、コード解析を実行する。解析結果はPlogConverterというツールでJSON形式に変換され、統合開発環境であるJetBrains CLionのプラグインを通じて視覚的に確認できるようになる。86Boxの開発チームは既にSonarQubeやCodeQLといった品質管理ツールを使用しており、コード品質には高い意識を持っているが、PVS-Studioはさらに別の視点からバグを発見できることを示している。

解析の結果、86Boxのコードベースからいくつかの興味深いバグが見つかった。例えば、チップセットのエミュレーション部分では、VIA Apolloシリーズの北橋チップ（CPUとメモリを接続する重要な部品）の設定に関する問題が見られた。dev->id == 0x06910600のような条件式が常に偽となるため、特定のチップセットモデルの設定が正しく適用されないというバグだ。これにより、メモリのアクセスパターンなどが意図しないものとなり、システム全体の安定性や性能に影響を与える可能性がある。また、VLSI VL82C311Lチップセットの初期化では、dev->card_memというメモリアドレスを指すポインタがNULL（何も指していない状態）のまま算術演算に使われるという重大な問題が発見された。これはプログラムがメモリにアクセスしようとした際にクラッシュする可能性が高いバグである。Intel PIIX3チップセットのUSBコントローラ初期化では、dev->type > 3という条件が常に真と評価されるため、USBコントローラが常にUSB 1.0の暫定的なモードで初期化されてしまうという問題があった。機能的には動作するものの、最新の仕様に合わせた設定ができない状態だった。さらに、SiS 5571チップセットのリセット処理では、同じメモリ位置に同じ値を2回続けて書き込むという冗長なコードが見つかった。これは直接的なバグではないが、コードの可読性を損ない、将来的な修正の際に片方だけを変更してしまい、意図しない挙動を引き起こす原因となる可能性がある。

ビデオカードのエミュレーション部分でもバグが発見された。Bochs SVGAというVESA互換アダプタのエミュレーションコードでは、水平ブランキング期間（画面の描画で、次の行へ移動する際に一時的に信号を停止する期間）の計算式がsvga->hblankend = mode.hdisplay + (mode.htotal - mode.hdisplay - 1)と冗長で、mode.hdisplayが相殺されてしまうため、svga->hblankend = mode.htotal - 1と簡略化できることが指摘された。これはコードの可読性を高め、わずかながら処理効率を改善する。また、Matrox Mystiqueグラフィックカードの描画処理（ブリッター）では、if (!transc || (transc && ...))という条件式が見つかった。このtranscという変数の真偽に応じて条件分岐が変わる部分で、transcが偽の場合は!transcが真となり、残りのtransc && ...は評価されない。transcが真の場合は!transcが偽となり、transc && ...が評価されるため、常に!transc || ...と簡略化できることが示された。これも冗長な記述であり、コードのメンテナンス性を向上させる機会となる。

分類が難しいその他のバグとしては、CPUエミュレーションにおけるCyrix 6x86プロセッサの処理で見つかったものがある。if (CPU_Cx6x86)という条件式が使われていたが、CPU_Cx6x86は列挙型定数であり、その値（34）は常に真と評価される。本来はcpu_s->cpu_type == CPU_Cx6x86のように比較演算子を使うべきだが、誤って定数そのものが条件式に使われたため、Cyrix 6x86シリーズのプロセッサでCPUID命令（プロセッサの情報を取得する命令）が意図せず無効化されてしまう可能性があった。これは特定のソフトウェアが正しく動作しない原因となる機能的なバグだ。また、ISAPnPカード（古い拡張カードの規格）の有効化処理では、if (条件1) { ... } if (条件2) { ... }という記述があり、本来ならelse ifを使うべき箇所がifで繋がっていた。このケースでは、いずれかの条件が満たされれば実行されるか、あるいはどちらも実行されないという結果になるため、致命的なバグではないが、論理的な意図が不明瞭になる問題であった。

これらの発見から、86Boxプロジェクトが高いコード品質を維持していることがわかる。開発チームは既に様々な品質管理プロセスを導入しており、PVS-Studioのような追加の静的解析ツールは、さらに細かな改善点を見つけ出すのに貢献した。正確なハードウェアエミュレーションは、もはや入手困難となった古いPCハードウェアの体験を現代に蘇らせる上で極めて重要である。ニッケルカドミウム電池の液漏れや古いハードディスクの故障など、時間の経過とともに多くのレトロハードウェアが失われる中、エミュレータは過去の技術遺産を未来に伝える貴重な手段となる。86Boxの開発は今後もプロセッサエミュレーションの改良やNVIDIA RIVA 128のような新たなハードウェアの再現に取り組む予定であり、その進化が期待されている。