昨日に引き続き、だる〜いClassic上のScript書き作業。Mac OS 9ネイティブ環境で動いていたものが、Classic環境で動かなくなったのでその改修を依頼されたのだ。
Classicというのは、Mac OS X上のMac OS 9エミュレーション環境。PowerPCのMacであれば、昔のアプリケーションの多くをそのまま動かすことができる。ただし最近のIntel MacにはClassic環境が乗っていないので、昨日書いたフリーのMacエミュレーター（SheepShaver）を入れて昔のソフトを動かしてみたりする（個人的にはClassicもSheepShaverもいっさい必要ない）。
昔から、UNIX上でMacのアプリを動かすエミュレータ（MAEとか）は存在していたのだけれども、Classicほど再現性の高いエミュレータにはお目にかかったことがない。Appleが作ったにしては「うまくできすぎている」と感じる。根も葉もない噂では、Classic環境にはその昔騒がれたMac OS互換OS「COS」のテクノロジーが生かされているとかいないとか。
＜引用＞
Omega Fails To Deliver COS As Promised
[TOP STORY 8:10AM] Skepticism about the alternative Macintosh-compatible operating system German developer Omega GmbH claims to have in the works will heighten, following admission from the company that they will not have the software available on their Web site today, as they originally planned and promised. For months, Omega said that COS would be released to coincide with this week's MacWorld & Publishing Expo 97 in D?sseldorf, although since details of the operating system surfaced, many have been skeptical about the existence of an OS that offers what Omega claims it does (everything from preemptive multi-tasking, to memory protection, to full Mac OS compatibility, to a genuine B2 security layer is what COS would supposedly bring to Mac desktops). And now this morning, the day in which Omega was scheduled to release the software, the company has posted the following note on their homepage:
Omega Homepage
"We are very sorry that we are unable to deliver the COS at this point in time. When we have further news we will display it on the this serve
＜/引用＞
さっそく、セオリーどおりサブルーチンごとにオーバーホールし、内部で使用しているOSAXがMac OS 9ネイティブ起動時と異なる挙動を行っていることをつきとめた。
AppleScriptの持つ命令語はプラグイン構造になっていて、OSAXと呼ばれるシステム拡張書類で追加できるようになっている。Mac OS 9からMac OS Xに移行する際、私はMac OS 9上のOSAX（200種類ぐらい収集していた）をすべて「使わない」という決断を行い、それ以来Classic環境はほとんど利用してこなかった。
Mac OS 9上のOSAXでできるようなことは、とっくの昔にだいたいMac OS X上のネイティブのAppleScriptで置き換えが済んでしまっている（でないと、人工知能インタフェース「Newt On」なんて、Mac OS X 10.1の時代に書けるわけがない）。
固有のOSAXとオサラバしたことで、他のOSAXをインストールしていないマシン上でも等しく稼働するAppleScriptのアプリケーションが書けるようになり、のちにAppleScript Studio（Xcode上で書くAppleScript。CocoaのGUI部品が利用できる）への移行も比較的スムースに行えた。ユーザー環境にOSAXのインストールが必要ということになると、アプリの配布もままならない。
ちょっと補足しておくと、のちにAppleScript Studioのアプリケーション内にOSAXを同梱して配布する方法がUS AppleのML上で公開され、OSAXに依存しているプログラムであっても配布が不可能というわけではない（ただし、ライセンス上の問題でOSAXの再配布が許可されていなければ、この方法は使えない）。
話を元に戻す。そんなわけで、Mac OS 9上のOSAXの機能を肩代わりする「何か」を作る必要に迫られた。
REALbasicでスクリプタブルなClassic用アプリケーションをビルドすることもできたが、もうREALbasicを使わなくなって久しいので、やはり一番手っ取り早く作れるMac OS X上のScriptによるアプレット（起動しっぱなしのアプリケーション）を作ることで解決した。
同一マシン上でClassicのスクリプトエディタから、Mac OS Xネイティブのアプレットに命令を投げて、処理を行うようにしたわけで……これで大成功！ のはずだった。
ところが、アプレット側で日本語の処理時に予想外の挙動をすることがあった。しばし考えたすえに、アプレットのバンドル内に「Japanese.lproj」フォルダを作成。これだけでうまく動くようになった。ああ、しょーもないところに落とし穴が（汗）。これを追加しないと、日本語の文字エンコーディングが適用されていなかったのだ。ただScriptでアプレットを書きたいだけなのに、なーーんでアプリケーション開発のディープな知識まで必要になるんだか。
ひととおり悪態をついて気が済んだので、作業をすすめた。
思えば、この手のOSAX置き換えアプレットを幾つも作っておくのは効率が悪い。むかーーしお世話になっていたMac OS 9上のOSAXについて、ひととおりMac OS XネイティブのScriptで置き換えてアプレット内に放り込んでおき、ログイン時にこのアプレットを起動するようログイン項目に登録。さらに、アプレットのアイコンがDockに出ないようにInfo.plistを書き換えてしまえば、ユーザー環境で混乱が起こることもないだろう。
もんんのすごくつまらないテクノロジーを開発してしまった（汗）。まあ、目的を果たすことができればそれでよいので、この方向でMac OS 9のOSAX依存プログラムをどんどんMac OS XのClassic環境に移行させてしまうこととしよう。