ここまでは、Appleの「300のリスト」に書いてあることだが、実はリストでは触れられていない事実もある。

Leopardの64bit対応の、隠れた重要なポイントは「レガシーフリー」であることだ。

32bit版のライブラリと64bit版のライブラリでは提供されているAPIが若干異なる。32bit側のライブラリはこれまでと同じもので、旧Mac OS由来の不適切なAPIも互換性維持のために残されている。

しかし、64bit版のライブラリはそうではない。そうしたobsoleteなAPIはそもそも存在しない。

たとえば、64bitのCarbonフレームワークではQuickDrawはサポートされない(図2)。QuickTimeでは以前の古いAPIは一切動作せず、Carbonのアプリケーションであっても、CocoaのQTKit経由でアクセスするようになっている。旧来のAPIを捨て、モダンなCarbon APIだけを使うアプリケーションにしないと64bit化はできないのだ。

図2: NSQuickDrawのヘッダファイル

見ての通り、64bitの場合はNSQuickDrawクラスは定義されない。これはコメントにもあるように、64bit環境ではQuickDrawが存在しないからだ

もっとも、Mac OS Xがリリースされて早7年、多くのソフトウェアはCocoaなど新しい柔軟な標準をサポートしており、それはPowerPCからIntel Macへの移行が急速に立ち上がったことですでに実証されている。きわめてごく一部の開発者をのぞいては64bitサポートによるAPIの削減は問題ではない。むしろ、これまで革新を妨げていた要因がまた1つ減ることは、喜ばしい1歩であるといえるだろう。

また、カーネル内では、sendfileやposix_spawnといったPOSIXにあるAPIのサポート追加、強化もなされている。先のリストにも以下のように書かれてはいる。

UNIX認定
Mac OS Xは、完全なUNIX認定を受けたオペレーティングシステム。Single Unix Specification(SUSv3)とPOSIX 1003.1の両方の仕様に対応しています。
(アップルジャパンWebサイト、「300を超える新機能 - Unix」より)

しかし、この認定を受けるにあたって、いったいどれだけの細かなAPIのサポートが地道に追加されたかは、決して「300を超える新機能」に書かれることはないのだ。

言語サポートの強化

開発面でうれしいのは言語サポートが強化されたことだろう。TigerでもPythonによるGUIの作成などがサポートされていたが、Leopardでは加えてRubyCocoaが搭載された。Ruby on Railsなど流行のWebアプリケーションフレームワークが標準搭載されるだけではなく、RubyからCocoaのAPIを呼び出し、RubyによるGUIアプリケーションの作成が可能となった。

もちろん、これらも先のリストに載ってはいる。

Ruby on Rails
仕事をするなら最高の環境で。Rails、Mongrel、Capistranoが組み込まれたLeopardは、Ruby on Rails開発に理想的なプラットフォームです。
(同「Unix」より)

Cocoaブリッジ
Objective-Cブリッジ、そしてXcodeとInterface Builderの完全サポートのおかげで、RubyとPythonをCocoaアプリケーション構築のためのファーストクラス言語として利用できます。
(同「Unix」より)

スクリプティングブリッジ
Objective-C、Ruby、Pythonプログラムを利用して、Macアプリケーションを最適化できます。新しいスクリプティングブリッジが、AppleScriptに似た簡潔な構文を使って、AppleEventsの生成を簡単にします。
(同「Unix」より)

そもそも、CocoaはObjective-Cの言語仕様に強く依存したフレームワークであり、WindowsのCOMのような言語非依存のメッセージング機構を持たない。このため、Objective-C以外の言語からのCocoaを利用しようとすると、Objective-Cとその言語の間を取り持つ「ブリッジ」が不可欠となる。そして、これまでのCocoaでは、APIの細かな仕様を実行時に得ることができないため(たとえば戻り値については限定的な型しか分からない)、Cocoaの持つすべてのAPIに対し対応表を用意し、メッセージの交換をしなければならないという問題があった。

これを解決するのが「スクリプティングブリッジ」(Scripting Bridge)フレームワークであり、これまで膨大な対応表を作っていた各言語とCocoaをつなぐ「Cocoaブリッジ」は、よりエレガントな形でLeopardに搭載される運びとなった。

スクリプティングブリッジの利点はそうしたブリッジの作成だけではなく、たとえばXcodeのキーワード補完機能などでも利用されている。非常に魅惑的な新機能なのであるが、その意味は先のリストの一文からは見えてこない。

Input Method Kitフレームワーク

日本人として気になるのは、新しいInput Method Kitフレームワークだろう。これまでのMac OS XのInput Methodの仕組みは古いMac OSを踏襲しており、アプリケーション側にコンポーネントを組み込むものだった。

「ことえり」を含む多くのInput Methodでは、コンポーネントはさらにプロセス間通信を用いて変換サーバにアクセスし、サーバ側で実際の変換処理を行っていた。この仕組みの場合、各Input Methodがそれぞれアプリケーション側のコンポーネントを用意しなければならない。アプリケーションに組み込まれるコンポーネントは、アプリケーションの実行アーキテクチャと同じ形式のバイナリでならなければならないため、Leopardでは、PowerPCの32bit / 64bit、Intel Coreの32bit / 64bitの合計4種類の形式をサポートする必要がある。Input MethodのコンポーネントはCarbonの低レベルの部分に接続されるため、複雑で多数のAPIにも対応しなければならない。それだけ苦労しているにもかかわらず、どのInput Methodでもやってることは「変換サーバに入力を送付し、結果をもらう」ということに代わりはない。

そこで、Appleで統一的なコンポーネントを用意し、変換サーバだけを用意することでInput Methodを実装できるようにした。これがInput Method Kitだ。

変換サーバは別プロセスとして動作するため、アプリケーション側のアーキテクチャに依存しない。32bitのアプリケーションであっても64bitのアプリケーションであっても、またはRosetta上で動作するPowerPCのアプリケーションであっても、たった1つの変換サーバさえ用意できればよくなり、Input Methodの作成が容易になるのだ。すでにことえりだけではなく、韓国語、中国語の入力についてもこのInput Method Kitベースに置き換えられている。

なお、もちろん旧来のInput MethodのAPIもまだサポートしているため、ATOKなどLeopard登場以前のInput Methodも原理的には動作する。動作サポートについてはそれぞれのInput Methodのベンダーに問い合わせてほしいが、少なくとも本稿はLeopard上で動作するATOK 2007 for Macで記述されている。