アプリケーションを配布してのUniversal Binaryアプリケーション調査というのは、以前から一度やりたいと思っていたものだ。
Universal Binaryという「対象」についてではなく、そのような形態の調査をマッシブに行ってみると面白いというか、予期しない結果が得られるのではないかと思っていたのだ。
公開する前に集計プログラムまで手が回らなかったので、集計部分が半手動である点が残念ではあるが、なかなか得難いチャンスを得たと思っている。
……ひとつハードルをクリアすると欲が出てくるもので、アプリケーションアイコンの収集機能を付与することには成功した。みんなでよってたかって、アイコンの画像データをアップロードするという寸法だ。
まあ、これも別に難易度が高いわけではない。AppleScriptのコードは書けたし、サーバーホステイング会社にそういう処理をやってよいかどうか打診中で、まだ返事が来ていない段階だ。
そこで目に留まったのが「Scriptabilityの調査」という項目だ。これは以前からやりたいと思っていたのだが、実施する側のメリットはあってもそれに協力したいと思わせるだけの見返りが用意できなかった。
Universal Binary調査は千載一遇のチャンスといえる。こんな、下手をすればEvilな行為として後ろ指をさされかねない調査を、比較的寛容かつ脅威の回答率（初期回答率30％強というのは驚愕の数字である）でもって行えるというのは、なかなか得難いチャンスだ。
……で、どのアプリケーションがAppleScriptによるスクリプティングに対応しているかという「Scriptability調査」のコードをAppleScriptで書き始めた。
AppleScriptでは、application fileをopenしなくてもScriptabilityを調べられるようになっている。「has script terminology」という属性値をapplication fileから取得すれば、それでわかるという寸法だ。少なくとも、Classic Mac OSの頃はそうだった。
……おかしい。スクリプタブルなアプリケーションに対して実行して、とれる場合ととれない場合がある。
この属性自体、Classic Mac OSの頃の遺品ともいえるものであり、十分にMac OS X環境に対応したものではないということのようだ。この件でAppleのバカ担当者をML上で糾弾するのはいつでもできるので、後回しにして現実的な対応をどのように行うかを考えた。
一応、アプリケーションパッケージ中のInfo.plistファイルを調べれば、NSAppleScriptEnabledという属性値を調べられる。だが、この属性値がついていない場合も往々にしてあり得る。
仕方がないので、パッケージ中のResourceフォルダにその手のScript用語リソースファイルが転がっていないかどうかを調べることにした。これで、ずいぶん片付く。
……だが、ものすごくイリーガルなフォーマットのパッケージも世の中には存在して……あきらかにXcodeではなくCodeWorriorで作られたバイナリで、パッケージ中の実行ファイル内にリソースを持つタイプのものが存在するのだ。
このへん、（リソースへのアクセスは）AppleScriptの機能限界を超えているので、命令拡張書類（OSAX）をインストールして乗り切ることも考えないではなかったが、再配布条件で見合うものがなかった。
そこで、REALbasicを引っ張りだしてきて、リソースをアクセスするコードを書き、aeteリソースから用語辞書を文字列として取り出すことにしてみた。
とりあえず、これでかなりの割合をカバーできるはずだ。
ただ、REALbasicのアプリケーションを一緒に配布しようとすると、平気で数Mバイト増えてしまう。その上、REALbasic自体がバージョンアップを重ねたすえにランタイムの処理が重くなり、結果として実行速度がAppleScript以下になるという場面も多く見られるようになってきた。
Developpet Toolsに入ってくるDeRezツールを用いて、指定ファイルの指定リソースを文字ファイル化してチェック、ということも考えないではない。だが、DeRez自体を再配布できない。
やっぱり……MLでAppleのバカ担当者を糾弾するというシンプルな話になるのかもしれない。うーーん、ここまで調査したのにいまひとつ美しくない結論だ。
