Windows プログラムのうち、コードではない半分

ダイアログとは、見出しの付いた四角い枠に、数行の固定テキスト、三つの入力欄、二つのボタンが載っているものだ。そのほとんどは実行時に計算されていない。各コントロールがどこに置かれるか、ボタンに何と書くか、どの書体を使うか、Tab キーがどの順に欄を渡り歩くか、最初にどこへフォーカスが入るか — すべて事前に決められ、実行ファイルの中の、機械語命令の隣にありながら一度も実行されない領域に収められている。タイトルバーのアイコン、起動画面のビットマップ、ウィンドウ上端のメニュー、キーの組み合わせを命令に対応づける表、そして読み込み時に画面のあらゆるラベルを供給する文字列テーブルも、同じ場所にいる。

この作りがあるからこそ、プログラムは再コンパイルなしに別の言語へ移せるし、ソースを一行も見たことのない人間がその見た目を変えられる。Resource Hacker は、まさにその領域のための閲覧兼編集の道具である。実行ファイルを指せば、リソースディレクトリをたどって中身を木構造で並べる。アイコン、ビットマップ、カーソル、ダイアログ、メニュー、文字列テーブル、バージョン情報、アプリケーションのマニフェスト、そして人間向けの形を持たない生のバイナリの塊。推測はなく、再生成もない。リンカがそこに置いたものが、そのまま見える。

四つの動詞、そして四つ目が軽く見られる

一つ目は読むこと。変更する前に、まず眺めておく価値がある。この木は、他のやり方では聞きにくい問いに答えてくれる。このプログラムにはダイアログが実際いくつあるのか、もう誰も使わない言語の文字列テーブルが残っていないか、あのアイコンの組は複数のサイズを束ねたものか、それとも一つしかないものをシステムが無理に引き伸ばしているのか。

二つ目は書き換えること。テキスト、アイコン、ビットマップ、ダイアログの配置全体まで、その場で変えられる — コンパイラに触れずに、プログラムの見える表面を変えるということだ。ダイアログには視覚的な編集画面があり、コントロールをドラッグして大きさを変えられる。メニュー、文字列テーブル、バージョン情報は伝票のような形で編集する。バイナリのリソースはバイト単位で継ぎを当てられる。正解になることは少ないが、唯一の手段になることはある。

三つ目は取り出すこと。アイコンもビットマップもカーソルも、ファイルとして書き出せる。これだけでも多くの人にとってこの道具を残す理由になる。何年も前に手放されたプログラムに埋まっているアイコンは、しばしば世界に残った最後の一個だからだ。取り出すことは、リソースを分解して構造を眺め、直した版を戻すための手順でもある。

四つ目が、この道具を「物好き向け」から「毎週使うもの」に変える。まとめて処理することだ。リソースを足す、消す、差し替えるは別々の操作だが、関連する実行ファイル一式に対して同じことをするのは、一度やるのとほとんど変わらない手間で済む。同じプログラムの複数のビルドを抱えている人にとって、これは「半日」と「コーヒー一杯」の差になる。

ダイアログを編集するとは実際に何をすることか

視覚的な編集は手になじむ。なじみすぎて、実際の制約を覆い隠してしまう。ダイアログの配置はピクセルではない単位で決まる。ある言語のラベルのために幅を計算した欄は、別の言語の長いラベルを切り落とす。場所を空けようとして動かしたコントロールは、もともと窮屈だった隣と重なることがある。画面の文字を変える人は、後で寸法を直す前提で臨み、しかも複数の表示倍率で結果を確かめるべきだ。ダイアログの単位は絶対座標のようには振る舞わない。

この道具は、様式の背後にあるリソーススクリプトも見せてくれる。同じ変更を多くのダイアログで繰り返す必要が出たとき、これが効く。文字を書き換えるほうがコントロールを引くより速いし、スクリプトは配置の構造を、描画面では得られない形で可視化する。同時に、編集画面が何を出力しているかの正直な姿でもある。様式はリソース定義の上に載った一層であって、その代わりではない。

本当に役に立つ場面

まず翻訳だ。翻訳されることを想定していないプログラムを別の言語に移すときは、たいてい文字列テーブルとダイアログの配置を直接いじることになる。この道具はそのために作られている。二つ目は画面の手入れで、案内文の言い回しを変える、古びたアイコンを今のものに差し替える、原作者が窮屈に残した配置を少し緩める。三つ目はゲームの改造で、これが一番読めない。ゲームの実行ファイルはリソースを大量に抱えており、メニューや起動画面、画面まわりの絵に対する小さな変更の多くは、突き詰めればリソースの差し替えにすぎない。

元の記事が挙げている三種類 — 開発者、画面の設計者、技術的に踏み込める利用者 — は的確な想定で、共通しているのは技量ではなく意図だ。これは「自分が何を書かせたいか既に分かっている人が、特定の一点を変える」ための道具である。探索には向かない。リソースの木は、そのダイアログが何のためのものかを一言も教えてくれないからだ。

道具が強制できない規律

ここでの操作はすべて、他のプログラムが依存しているファイルへ直接書き込む。失敗の現れ方は警告の窓ではない。二度と起動しないプログラムだ。だから最初の決まりは地味で、交渉の余地がない。最初の変更の前に、手を付けていない元の複製を残す。毎回、うまくいくと確信している回も含めて。複製の上で作業し、原本を別に置くのは費用がかからず、最悪の結果を丸ごと消してくれる。

二つ目の決まりは、変える前にそのリソースを理解すること。ダイアログは絵ではなく構造体だ。文字列テーブルには番号が振られ、その番号はコードから指されている。だから途中に一行挿し込むと、それ以降のラベルの番号がすべてずれる。三つ目は小さく始めること。アイコンを一つ替えて起動を確かめ、それから本当に大事なダイアログへ進む。この習慣は地味だが、変えたプログラムと壊れたプログラムの差は、そっくりこれだけである。

そうではないもの

開発環境ではないし、論理の理解を助けもしない。リソースが語るのは、プログラムがどう見えるか、部品が何と呼ばれるかだ。振る舞いはコードの中にあり、この道具はそこに意図的に触れない。逆コンパイラでもない。この二つを混同するのが最も多い誤解だ。実行ファイルからダイアログを抜き、別のものを戻すのは正当で普通の作業であり、機械語からソースを復元するのは別の行為で、場所によって法的な重さも違う。この道具は前者だけを扱い、後者には近寄らない。

正確に言えば、これは範囲の切り方がうまい小さな道具だ。仕様の公開されたファイル形式を読み、中身を正直に見せ、変更させ、あとは黙って下がる。欲張っていない。だからこそ、これだけ長く使われ続けている。

結論

プログラムの画面の一語を変えたい、アイコンを差し替えたい、実行ファイルが何を抱えているのか覗きたい — そう思ったことがあるなら、問いと答えのあいだの最短経路がここにある。画面は素朴で、説明は行き届き、まわりの共同体は同じ実務的な疑問に何年も答え続けてきた。入場料は習慣ひとつ分だ。まずファイルを複製する。それ以外のところは、この道具は驚くほど寛容である。