　まずは、アドレス解決に関するデザインです。実行時にローディングされるライブラリ内の、関数アドレスを解決する方法は大きく2つあります。1つは関数のシグネチャを動的に検索する方法。もう1つはDLL内の関数の配置順序（これを「序数」といいます）に従い、検索を行わず関数アドレスを解決する方法。前者は柔軟性を、後者は性能を優先した方法です。Windowsはどちらの方法もサポートしており、選ぶのは開発者の責任となっています。しかしSymbian OSは、ローディング時の実行性能および実行イメージのサイズ削減のため、序数を使う方法に統一されています。

　「何がベストプラクティスかを明確に宣言する」ことが筆者の思う「Symbian OSらしさ」なのですが、この件はその好例といえる事例です。

※コラム：DLLから見たWindowsとSymbian OS

ちなみに、筆者が「桐」というデータベースをWindows向けに作っていたときにも、「起動を速くするためDLLは序数インターフェイスにしようか」という話がありました。そうするとローダが行うフィックスアップが圧倒的に速くなるとMicrosoft自身がTIPS情報を出していたからです。

複数の選択肢を用意して、そのうえでそれらを判断する情報を公開するというのは、汎用OSとしては妥当なアプローチだと思います。しかしSymbian OSのような携帯電話に特化したOSでは、ベストプラクティスをOS側が提示する（何を選ぶのか迷えなくする）方がすっきりしていると思われます。

　もう1つの、「DLLがグローバル変数を持てない」というデザインについて。これはROMサポートのところで記したように、Symbian OSではプログラムの実行はXIPが基本であると割り切っているようです。実行イメージをメモリに持ち上げてから走らせるのは、RAMが潤沢ではない携帯電話環境では高くつくという判断によるのでしょう。

　そう理解できると、一見理不尽なこのデザインが実行性能とのトレードオフの結果に見えてきます。XIP環境でDLLにグローバル変数を許すとなると、DLLのローディングごとにページ単位（4kbytes）のメモリが消費されます。このメモリのコストと、プログラマへの負担を勘案した結果がこのデザインなのだと思われます。このような割り切りもSymbian OSの特徴だと筆者は考えています。

　駆け足でしたがカーネル関連を一回りしてきました。マイクロカーネルに基づくOSということで、各種の機能をクライアント／サーバで提供するというモダンな部分と、メモリをケチるためにDLLではグローバル変数を使用不可とするなどの割り切りの部分。携帯電話という制約がある環境の上で、開発効率と性能という相反する要求を2つとも達成しようとしているSymbian OSならではのアプローチが垣間見えたかと思います。

　ただし、これだけのことであればSymbian OSは「ちょっと面白い」というレベルにすぎぎません。Symbian OSのすごい部分は、注意深く定義されたこれらのカーネルデザインの上に、OO（Object Oriented）ベースの環境が構築され、実用的に動作しているところにあります。

　次回はOSがOOベースになるとはどういうことなのかを、まずは言語の側面から明らかにしていきたいと思います。（次回に続く）