(57)【要約】  コンピュータ装置のダイナミック・リンク・ライブラリ（ＤＬＬ）が、第１のパート及び拡張パートの形態で提供される。第１のパートは、アプリケーションプログラムが第１の関数へリンクする、エントリポイントの序数を選択している。アプリケーションプログラムは、ＤＬＬの拡張パートを介してのみさらなる関数へリンクすることができる。【選択図】  図４
2007510210.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ装置において、関数と実行可能プログラムとをリンクするためのダイナミック・リンク・ライブラリを提供する方法であって、
前記実行可能プログラムを１以上の第１の関数へリンクするための第１のパートと、
前記実行可能プログラムを、前記１以上の第１の関数に追加された、１以上の更なる関数へ、当該拡張パートを介してリンクさせるための、拡張パートと、
を有する前記ダイナミック・リンク・ライブラリを提供する工程を備える
ことを特徴とする方法。
【請求項２】
前記１以上の更なる関数の少なくとも一つは、前記第１のパートに存在する
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記１以上の更なる関数の少なくとも一つは、前記拡張パートに存在する
ことを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記拡張パートは、
前記コンピュータ装置のダイナミック・リンク・ライブラリの複数の前記第１のパートにリンクされるように構成される
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記拡張パートは、
前記コンピュータ装置内において、使用するリード・オンリ・メモリ（ＲＯＭ）のコードへのリンクを提供するために用いられる
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記拡張パートはｐｒｉｖａｔｅ関数として提供されることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記ダイナミック・リンク・ライブラリのアドレス位置は、序数によってリンクされている
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記１以上の第１の関数は、前記コンピュータ装置のオペレーティングシステムの一部として提供される
ことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
請求項１乃至８のいずれか１項に記載の方法に適合して動作するように構成されたコンピュータ装置。
【請求項１０】
コンピュータ装置を、請求項１乃至８のいずれか１項に記載の方法に適合して動作させるコンピュータソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ装置におけるデータへのアクセス方法に関し、特に、コンピュータ装置におけるダイナミック・リンク・ライブラリに保持されたデータへのアクセス方法に関する。本発明は、その方法により制御されるコンピュータ装置にも関する。
【背景技術】
【０００２】
ここで用いられるコンピュータ装置という用語は、あらゆる形態の電子機器を含むように拡張的に解釈され、任意の形状因子を有する静止画及び動画に係るデジタルカメラ等を含むデータ記録装置と、携帯端末及びパーソナルコンピュータを含むあらゆる種類及び形態のコンピュータと、任意の形状因子を有する通信装置とを含む。ただし、任意の形状因子を有する通信装置には、携帯電話と、高機能電話と、通信、画像記録と再生との少なくともいずれか、及び、計算機能を単一装置内で結合するコミュニケータと、及び、他の形態の無線又は有線の情報機器とが含まれる。
【０００３】
ほとんどのコンピュータ装置は、オペレーティングシステムの制御の下で動作する。オペレーティングシステムは、全てのプログラムがコンピュータ装置上で実行することを可能にするソフトウェアと見なすことができ、動作の効率性を高め、アプリケーション開発を容易にするための重要な手段である。
【０００４】
オペレーティングシステムは、コンピュータ装置のハードウェア資源及びソフトウェア資源を管理する。これらの資源には、例えば、中央演算ユニット（ＣＰＵ：Central Processor Unit）、メモリが含まれる。ディスクがコンピュータ装置の一部を形成する、或いは、コンピュータ装置とともに用いられる場合には、ディスク空間もこの資源に含まれる。このようにして、オペレーティングシステムは、アプリケーションがコンピュータ装置上で実行するための安定した堅実な方法を提供する。当該方法によれば、アプリケーションは、そのハードウェアに利用可能な物理資源の詳細を全て知ることなく、コンピュータ装置のハードウェア資源を用いて処理を行うことができる。
【０００５】
ハードウェア資源及びソフトウェア資源を管理する上記のタスクは非常に重要である。なぜなら、多様なプログラムや入力方法は、それぞれの目的のために、ＣＰＵの割り当てを得るための競合を行い、メモリや記憶及び入出力資源（Ｉ／Ｏ：input/output）を求めるためである。各アプリケーションプログラムに必要な資源が可能な限り提供されるが、装置における利用可能な有限の物理資源に関して、各アプリケーションプログラムが、常に権利を有することを、オペレーティングシステムは、保証する。アプリケーションプログラムは、装置のユーザのために特定の機能を直接実行する、完全で自己完結的なプログラムと見なすことができる。
【０００６】
オペレーティングシステムが実行しうる他のタスクは、信頼性のあるアプリケーションプログラムの、或いは、実行可能な、インタフェース（ＡＰＩ）を提供することである。このことは、このオペレーティングシステムを用いた１以上の特定の型のコンピュータが存在する場合、或いは、コンピュータを構成するハードウェアが変更しうる場合に、特に重要である。このことは、特に、コアのオペレーティングシステムが複数の異なるユーザを有する場合にあてはまり、例えば、一般的には、スマートフォン（高機能電話）等の、無線通信装置の形式のコンピュータ装置において発生する。
【０００７】
これらの装置においては、多様な装置の製造者や装置の供給者が、コアのオペレーティングシステムに含まれるあるコンポーネントを共通のコンポーネントとして選択し、コアのオペレーティングシステムに含まれる他のコンポーネントを、個々の装置の要件に適合させることは、一般的ではない。アプリケーションプログラムとオペレーティングシステムとを区別する方法の一つは、アプリケーションは"ユーザモード"（非特権モード）で実行するのに対して、オペレーティングシステムや関連するユーティリティは、通常、"スーパーバイザーモード"（特権モード）で実行するということが指摘されている。従って、上述のスマートフォンの例においても、オペレーティングシステムにおいて重要な特定のコンポーネントが存在する。これは、カーネルコンポーネントと呼ばれることが多く、"スーパーバイザーモード"で排他的に稼働し続ける。
【０００８】
適合性のあるアプリケーションプログラム・インタフェース（ＡＰＩ：Application Program Interface）によれば、装置間でメモリ量や記憶装置の容量が異なる場合においても、あるコンピュータ装置のためのアプリケーションプログラムを、同種の他のコンピュータ装置上で実行することができる。ある特定のコンピュータ装置が他とは異なるものであっても、オペレーティングシステムは、ハードウェアがアップグレードされたり更新された場合に、アプリケーションプログラムが実行し続けることを保証することができる。これは、アプリケーションプログラムではなく、オペレーティングシステムが、ハードウェアの管理やその資源の配分を統括するためである。
【０００９】
装置の資源をより効率的に使用するため、多数のアプリケーションプログラムに共通に使用されうる特定の関数及びモジュールは、ライブラリの形式で格納しておくことができる。これにより、これらの関数及びモジュールは、一度格納されると、それらが一緒に用いられるアプリケーションプログラムのそれぞれについて複製されない。従って、ライブラリの中身は、アプリケーションプログラムのロード時又は実行時に、アプリケーションプログラムと選択的にリンクされる（関連づけられる）のであって、個々のアプリケーションプログラム自身の内部でコンパイルされるわけではない。その結果、ある関数又はモジュールを示す同じブロックのライブラリ・コードは、装置上で実行する複数のタスクにより共有されるが、各タスクが、使用するルーチンのコピーを包含するわけではない。
【００１０】
これらのライブラリは、プログラムの実行時にアプリケーションプログラムとダイナミック（動的）にリンクされる。このため、このライブラリは、ダイナミック・リンク・ライブラリ（ＤＬＬｓ：dynamic link libraries）として一般的に知られている。従って、現代のコンピュータのオペレーティングシステムのほとんどは、ダイナミック・リンク・ライブラリの機能を提供している。このダイナミック・リンク・ライブラリによれば、コンピュータ装置上で実行するアプリケーションプログラムとは分離した形で、特定の実行可能な手続き（プロシージャ）や関数（ファンクション）をライブラリの形式で提供することが可能になる。一般的に、アプリケーションプログラムは、実行時にそのライブラリとダイナミックにリンクされるため、アプリケーションプログラムは、ライブラリによりエクスポートされる１以上の手続きや関数を呼び出すことができる。エクスポートされた手続きは、一般的に、そのライブラリへのエントリポイント（entry point）として参照される。
【００１１】
一般的に初めから実行される標準的なアプリケーションとは異なり、ＤＬＬは任意のエントリポイントからエントリすることができる。これらのＤＬＬへのエントリポイントを特定する方法は、主に２つある。第１の選択肢は、名前によりエントリポイントを参照するものである。第２の選択肢は、序数（通し番号：ordinal number）によりエントリポイントを参照するものである。後者の選択肢は、関数序数マッピング（function ordinal mapping）又は関数序数リンキング（function ordinal linking）としてしばしば参照される。名前は、序数と比べて長くなる可能性があり、その定義に追加的なコードを必要とする。このため、一般的に、名前の使用は、序数の使用と比べて、コンピュータ装置のリード・オンリー・メモリ（ＲＯＭ：Read Only Memory）やランダム・アクセス・メモリ（ＲＡＭ：Random Access Memory）の資源を浪費すると考えられている。従って、アクセスポイントの序数リンキングは、特定のオペレーティングシステム、特に、スマートフォンを使用するためのオペレーティングシステムにおいて、優先的に用いられている。これは、この種のコンピュータ装置が有する物理資源は、デスクトップ又は携帯用のＰＣ装置において利用可能なものと比べて非常に限られており、コードの効率的な使用が最重要事項であるからである。
【００１２】
従って、ＤＬＬによれば、モジュール形式で提供するための方法がアプリケーションプログラムにもたらされ、これにより、機能をより容易に更新し再利用することが可能となる。ＤＬＬは、複数のアプリケーションが同時に同じ機能を使用する場合に、メモリのオーバーヘッドを削減する助けともなる。これは、各アプリケーションにはデータのコピーが提供されるが、コードは共有することができるためである。さらに、ダイナミックにリンクすることで、モジュールは、ロード時又は実行時に、エクスポートされたＤＬＬ関数を特定するために必要な情報のみを有していればよい。
【００１３】
オペレーティングシステムが互換性を備えると共にカスタマイズできるという要求が高まっている。これは、特に、例えば、英国、ロンドンのシンビアン社から供給されているＳｙｍｂｉａｎ  ＯＳ（商標）オペレーティングシステム等の、スマートフォンのオペレーティングシステムについて顕著である。一般的に、そのようなオペレーティングシステムは端末メーカーへ供給されるが、その後に、端末メーカーは、オペレーティングシステムの制御の下で動作する、装置の追加的な機能を提供する。このことは、この種のオペレーティングシステムは、ＡＰＩにバイナリ互換性を有していなければならないことを意味する。また、同時に、オペレーティングシステムを個々の端末メーカーの要件に合わせてカスタマイズするために、所望とするプラットフォームや製品に応じて、革新的で差別化要因となる機能をこれらのＡＰＩに対して追加できるようにしなければならないことを意味する。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、この種のオペレーティングシステムはあるリリースから次のものへと進化していくため、ＤＬＬのエントリポイントを調整することは困難である。
【課題を解決するための手段】
【００１５】
第１の側面において、本発明は、これらの問題を十分に軽減するような、コンピュータ装置においてダイナミック・リンク・ライブラリを提供する方法を提供することを目的とする。
【００１６】
即ち、コンピュータ装置において実行可能なプログラムが使用する関数を提供するための、ダイナミック・リンク・ライブラリを提供する方法であって、
１以上の第１の関数が、前記実行可能なプログラムにより、使用のためにアクセスされうる、第１の場所を有する第１のパートと、
前記１以上の第１の関数に追加して、前記第１の場所の、前記第１の場所に追加する場所に存在する、１以上の更なる関数に前記実行可能プログラムをアクセス可能にするための拡張パートと、
を有するダイナミック・リンク・ライブラリを提供する工程を備える方法が提供される。
【００１７】
本発明の第２の側面によれば、上記第１の側面に係る方法に基づき動作するコンピュータ装置が提供される。
【００１８】
本発明の第３の側面によれば、コンピュータ装置を上記第１の側面と適合して動作させるためのコンピュータソフトウェアが提供される。
【発明を実施するための最良の形態】
【００１９】
以下、添付図面を参照して本発明に係る例示的な実施形態を説明する。
【００２０】
図１は、スマートフォンの一般的な進化の一例を示している。明確にするため、この進化を家系図の形式で示している。この図は、進化の「家系図」のごく一部を示しているが、この例において重要な点は、エンティティのあるリリースから次のものへの進化の経路は、単一の直線的なものではないことである。
【００２１】
図１の例では、オペレーティングシステムが、ＯＳバージョンＸからＯＳバージョンＸ＋１へ進化していることが分かる。しかし、それと並行して、装置の一般的なユーザインタフェース等の、装置のプラットフォームは、プラットフォームＹからプラットフォームＹ＋１へ進化する。ただし、プラットフォームＹはＯＳバージョンＸに基づいており、プラットフォームＹ＋１はＯＳバージョンＸ＋１に基づいている。製品Ａは製品Ｂへ進化し、これらは両方ともプラットフォームＹに基づいている。そして、製品Ｂは製品Ｂのバージョン２へ進化しているが、これはプラットフォームＹ＋１に基づいている。これは、進化の各段階において、基礎となるプラットフォームへ機能を追加するという要件が存在するためである。
【００２２】
さらに、系図におけるその段階の将来のバージョンにおいても、その機能を維持するという更なる要件が存在する。このことは、機能的な成長が発生しうる複数の経路が存在することを意味する。例えば、ある特定の製品は、ＯＳの移行から、プラットフォームの移行から、及び、その製品の先行する製品から、追加的な機能を承継する必要がある。
【００２３】
オペレーティングシステムが、ＤＬＬから関数をエクスポートするために序数リンキングの手法を用いている場合、機能を承継する複数の経路が存在すると、プラットフォームの断片化を引き起こしてしまう。この種の手法を用いる場合、ＤＬＬによりエクスポートされる各関数は、シーケンシャルに番号が割り当てられる。ＤＬＬのクライアント・アプリケーションは、この序数を用いてエクスポートする関数を呼び出す。関数と序数との対応関係は、関連するアプリケーションの定義ファイル（.ＤＥＦ）に定義することができる。しかし、このようなシーケンシャルに番号割り当てる手法は、２つのパーティがそれぞれ他方を知らずに同じＡＰＩに関数を追加した場合、それぞれのパーティによって追加された関数に対して、（用いられる序数の範囲の最後に）同じ序数が与えられることがある。このことは、２つのパーティのうち第１のもの（パーティ１）によって修正されたＤＬＬに逆らってビルドされたプログラムコードがその序数を用いて、パーティ１により開発されたプラットフォームのバージョンにおいて、関連する序数の場所に存在すると思われる機能にアクセスしようとすることがあることを意味する。
【００２４】
しかし、２つのパーティの他方（パーティ２）により開発されたプラットフォームのバージョンに反して、そのプログラムコードを実行すると、問題が発生する。なぜなら、その序数におけるパーティ１により開発された関数は、同じ序数におけるパーティ２により開発された関数と同じではないからである。リリースされた製品にこの問題がいったん発生すると、一方又は他方のプラットフォームにおけるバイナリ互換性を破壊しない限り、それを修正することができない。図２は、２つのパーティが並列的に独立にＡＰＩを拡張した場合に起こることと、結果として得られる序数空間を解決できないことを説明する図である。
【００２５】
関数の承継に複数の経路を使用する場合でも、各ＡＰＩが一つの承継の経路を有するのならば、問題は発生しない。実際には、このことは、各ＡＰＩを所有するものが一つであることを意味する。所有するものは、それぞれのＡＰＩに追加することが許されているが、他のものは許されていない。このことは、ＡＰＩが、直線的に進化することを意味する。例えば、Ｓｙｍｂｉａｎ  ＯＳ（商標）オペレーティングシステムを一例として取り上げると、Ｓｙｍｂｉａｎにより所有され、提供されるＤＬＬは、Ｓｙｍｂｉａｎによってのみ拡張可能であり、派生するプラットフォームや製品の開発者は拡張することができない。しかしながら、現実には、インタフェースを所有するもの以外にインタフェースの拡張を許さないというこの理想は、共通のコアのオペレーティングシステムからプラットフォームや製品のカスタマイズを可能にするという、増大している必要性に矛盾している。
【００２６】
新しい製品を開発し、これらをできるだけ短い期間に市場に投入することを継続する必要があるため、多数の製品が一つの第１のパーティにより開発されることは比較的一般的である。ただし、この第１のパーティは、１以上の他のパーティにより所有されるインタフェースに対して機能を追加する。例えば、一つのパーティによって開発されたプラットフォームが、他のパーティによって所有される１以上のライブラリへＡＰＩを追加したり、或いは、製品が１以上のプラットフォームのライブラリへＡＰＩを追加する場合に、このような状況は発生する。両方の場合において問題は同様である。
【００２７】
重要なのは、基礎をなすプラットフォームに係る互換性が破壊されるということが問題なのではないということである。上記の場合において、製品は、現在のオペレーティングシステム／ユーザインタフェース（ＯＳ／ＵＩ）のプラットフォームと互換性がある。問題は、製品の将来的な修正が、そのＯＳ／ＵＩのプラットフォームの後のバージョン上でなされた場合、それは、新しいバージョンのプラットフォームか、或いは、その製品の過去のバージョンのいずれかのみと互換性を有し、両方には互換性を有しないということにある。しかし、プラットフォームを断片化しないようにするために、両方の互換性を保つという要件は本質的である。そのような断片化は、オペレーティングシステムを大きく損ない、回復することが非常に困難になるからである。
【００２８】
このため、ＯＳの提供者（プロバイダ）は次のようなシナリオに直面するだろう。：
・ＯＳ提供者が、ＯＳの新しいバージョンにおいて、ＡＰＩに根本的な機能を（正当に）追加する。
・ＵＩプラットフォームの提供者が、新しいバージョンにおいて、ＡＰＩに重要な機能を（正当に）追加する。
・製品のメーカーが、その製品においてＯＳ及びＵＩのプラットフォームのＡＰＩに機能を追加する。これらの製品がプラットフォームからの差別化や柔軟性を要するため、このことを期待することは適切ではない。
【００２９】
しかしながら、上述のパーティのそれぞれによって、序数の範囲の最後に機能が追加されるため、製品メーカーの機能追加は、ＵＩプラットフォーム提供者により提供されるＵＩプラットフォームの追加と、同じ序数空間に存在するだろう。これは、言い換えれば、製品メーカーの機能追加が、ＯＳの提供者により提供される追加的な機能と同じ序数空間に存在することになる。従って、範囲が分からず、不明なソースからの序数空間において、衝突が存在する可能性がある。序数空間の範囲が不明な理由は、製品メーカーが新しい製品を実現するために、プラットフォーム上で行う仕事の多くは、ＯＳ又はＵＩプラットフォームの提供者の両方とって、必ずしも明らかであるとは限らないからである。
【００３０】
現実には、２つの製品、或いは、その製品が開発されたソフトウェア開発キット（ＳＤＫ：software development kits）が、衝突するオリジナルと共に市場で利用可能になるまで、このような状況が害をなすことはない。そのときまでは、市場にリリースされていない製品及びＳＤＫを修正することができる。
【００３１】
従って、本発明は、将来の互換性を損なうことなく、安全で拡張可能な方法で、システムのユーザがＡＰＩに機能を追加することを可能にするシステムを提供することを目的とする。このようにして、第三者は、既存のＡＰＩ、特に、序数にリンクされたＡＰＩに対して、そのＡＰＩの将来の進化を損なうことなく、機能を追加することができる。第２の目的は、オリジナルのＡＰＩが将来どのように進化しても、第三者が機能を追加することを妨げないことである。
【００３２】
本発明は、第三者が、そのパーティに所有されていない既存のＡＰＩに機能を追加する必要があるあらゆる状況に適用可能である。ただし、ＡＰＩの所有者がそのＡＰＩを拡張する場合には適用しない。なぜなら、定義により、その所有者は、ＡＰＩの保持管理者であるからである。本発明は、第三者がＡＰＩに対して既に追加している場合に、さらなる衝突の可能性を取り除くためにも用いることができる。
【００３３】
図３は、プラットフォームＤＬＬのライブラリ拡張（ＬＩＢ）に反して格納された、オリジナル関数へのアプリケーションのリンクを示している。アプリケーションは、ＬＩＢファイルの序数を用いて、ＤＬＬに格納された関数を使用する。このため、アプリケーションがオリジナル関数１を呼び出す場合、リンクが、ライブラリ拡張の序数１へ提供される。これによって、アプリケーションが使用するオリジナル関数１によって供給される機能をエクスポートする。ＤＬＬの他の序数に格納された残りのオリジナル関数についても同様である。これは、ＤＬＬのリンケージ（連鎖）のパターンとして知られており、例えば、Ｓｙｍｂｉａｎ  ＯＳ（商標）オペレーティングシステムにおいて採用されている。
【００３４】
図４は、何らかの製品に関数を追加するために、アプリケーションが、拡張ＤＬＬのパターンをどのように用い得るかを示している。ただし、関数は、プラットフォームＤＬＬから提供されるオリジナル関数に追加される。これらの製品の追加分は、追加の序数６及び７を介してプラットフォームＤＬＬからエクスポートされる。しかし、これらの追加の序数６及び７は、アプリケーションから直接リンクされているのではなく、拡張ＤＬＬを経由してリンクされている。拡張ＤＬＬは、拡張ＤＬＬのために序数のアドレスを保持している拡張ライブラリを経由して、プラットフォームＤＬＬのためのアクセス経路と同様に、実際にアクセスされる。本発明においては、アプリケーションが、プラットフォームＤＬＬから追加の序数を直接使用することは許されていない。しかし、図４から分かるように、アプリケーションは、オリジナル関数１〜５を、プラットフォームＤＬＬから直接エクスポートして使用することは許されている。これは、オリジナル関数を、アプリケーションが使用するための序数１〜５をそれぞれ経由してＤＬＬからエクスポートできるということを、オペレーティングシステムとアプリケーションの両方が知っているからである。
【００３５】
多くのオペレーティングシステムは、Ｃ＋＋等の、オブジェクト指向プログラミング言語を用いて記述されている。そのようなシステムにおいては、本発明に係る方法を実現する好適な手法は、製品の追加関数をクラスのプライベートなメンバとして実装することである。これは、Ｃ＋＋のコンパイラは、クライアントのコードが拡張ＤＬＬを使用するように強制するということを意味する。さらに、この分野では、他のパーティによって独自に記述されたコードに対する改変は、最小限に抑えるべきであるということがよく知られている。従って、この分野の最適な慣行と調和させるために、拡張ＤＬＬを、プラットフォームＤＬＬへリンクするための純粋なアダプタとして供給する必要はない。ただし、拡張ＤＬＬは、アプリケーションプログラムへ追加的な機能を提供するために必要な、拡張コードの大部分を含んでいるように構成してもよい。さらに、拡張ＤＬＬは、単一のプラットフォームＤＬＬに特有なものとならないように、供給してもよい。従って、一つの”製品用拡張”ＤＬＬがコンピュータ装置のＲＯＭに供給されることが予想される。ただし、この一つの拡張ＤＬＬは、２以上の追加的な機能への、及び、おそらくは全てのプラットフォームＤＬＬへの、インタフェースを提供するだろう。このため、本発明の方法は、各プラットフォームＤＬＬのために拡張ＤＬＬをそれぞれ提供することに限られないということが強調される。このため、製品のメーカーは、複数のプラットフォームＤＬＬへのリンクを提供するために、一つの拡張ＤＬＬを追加することを選択してもよいし、或いは、追加的な機能（拡張機能）を、既存の製品のＤＬＬの実際の拡張として、拡張ＤＬＬを構成することで提供してもよい。或いは、オリジナルのプラットフォームＤＬＬの構成とは関係を持たないようにして、各拡張関数をグループ化してもよい。
【００３６】
従って、図４に示される構成のように、第三者のアプリケーションは、プラットフォームＤＬＬのライブラリ拡張である、Ｐｌａｔｆｏｒｍ．ｌｉｂの序数１〜５と、拡張ＤＬＬのライブラリ拡張である、ｅｘｔｅｎｓｉｏｎ．ｌｉｂの序数１及び２にリンクされている。このアプリケーションに関しては、Ｐｌａｔｆｏｒｍ．ｌｉｂの序数６及び７は、見ることができない。結果として、製品のための第三者のＳＤＫは、Ｐｌａｔｆｏｒｍ．ｌｉｂの拡張バージョンさえも含んでいる必要がない。従って、本発明によれば、ＳＤＫにおいて、ライブラリの拡張であるＰｌａｔｆｏｒｍ．ｌｉｂのオリジナルバージョン（序数１〜５）を置き換えて、プラットフォーム開発のためのライブラリの拡張バージョン（序数１〜７）のみを使用することが可能である。これは、追加の序数６及び７を用いて、第三者がコードを生成する可能性がないことを意味する。
【００３７】
図５は、プラットフォームの後のバージョンを示しており、プラットフォームＤＬＬの所有者が、プラットフォームＤＬＬのＡＰＩにさらに何らかのコアの機能を追加した場合を示している。この場合、序数６及び７は、所有者が、新しい関数を追加する際に用いられている。このプラットフォームＤＬＬへのアプリケーションのリンクによって、製品追加１及び２をこれらの序数で見ることが期待されていたならば、問題が発生する。なぜならば、序数６及び７は、それぞれ、所有者の追加１及び２をエクスポートするために用いられているためである。しかし、この場合は、製品追加関数１及び２は、常に、拡張ＤＬＬを介して呼び出されるため、問題は回避される。従って、これらの関数がそれぞれ異なる序数の位置へ移動することは許容される。図５において、製品追加は、序数６及び７から序数８及び９へそれぞれ移動されている。製品追加１及び２のための序数へリンクするシステムのコンポーネントは、拡張ＤＬＬのみである。コードの変更は不要であり、アプリケーションへの製品追加１及び２をエクスポートするために用いられる、新しい序数位置８及び９の場所を、拡張ＤＬＬが指すように再びリンクするだけでよい。第三者のアプリケーションコードがＥｘｔｅｎｓｉｏｎ．ｌｉｂにリンクしているため、これらの序数は同じままであり、第三者のコードを再び構築する必要がない。
【００３８】
図５に例示した本発明に係る実施形態を実現するプログラムコードは、例えば、次のようなものである。次の例は、本発明を実装するためのソースコードがどのように実現されるかを示す、比較的単純なものであることが理解されよう。
【００３９】
以下に引用したコードは、プラットフォームＤＬＬのヘッダファイルに、関数がどのように追加されうるかを示している。この例では、ヘッダに追加された関数が２つ存在する。ｐｕｂｌｉｃであるＥｘｔｅｎｓｉｏｎＦｕｎｃｔｉｏｎは、拡張ＤＬＬに実装されるだろう。従って、それは、Ｐｌａｔｆｏｒｍ．ｄｌｌではなく、Ｅｘｔｅｎｓｉｏｎ．ｄｌｌからエクスポートされるだろう。ｐｒｉｖａｔｅであるＤｏＥｘｔｅｎｓｉｏｎＦｕｎｃｔｉｏｎは、Ｐｌａｔｆｏｒｍ．ｄｌｌに実装され、従って、Ｐｌａｔｆｏｒｍ．ｄｌｌからエクスポートされるだろう。この関数はｐｒｉｖａｔｅに設定され、これにより、序数のエクスポートを介して第三者のコードがこの関数を呼ぶことは、コンパイラにより妨げられる。
2007510210.tif 000003
【００４０】
プラットフォームＤＬＬにおける実装は、ＤｏＥｘｔｅｎｓｉｏｎＦｕｎｃｔｉｏｎのためのコードに追加される。これは、必要な変更量を最小限にするために、ＤＬＬに含まれるこの拡張関数に必要な、最小限のコードを含んでいるべきである。この関数は、Ｐｌａｔｆｏｒｍ．ｌｉｂにおいてエクスポートされる。
2007510210.tif 000004
【００４１】
ｅｘｔｅｎｓｉｏｎ．ｄｌｌにおける実装によれば、主として、プラットフォームＤＬＬにおいて、ｐｒｉｖａｔｅのＤｏＥｘｔｅｎｓｉｏｎＦｕｎｃｔｉｏｎへの呼び出しを可能にする。ＤｏＥｘｔｅｎｓｉｏｎＦｕｎｃｔｉｏｎは、ｐｒｉｖａｔｅであり、従って、同じクラス内からのみ呼び出すことが可能である。なお、ＤｏＥｘｔｅｎｓｉｏｎＦｕｎｃｔｉｏｎへの呼び出しは、ｐｌａｔｆｏｒｍ．ｄｌｌ内に存在する必要のない他のコードに囲まれているため、ここでは、プラットフォームＤＬＬ上で影響を最小限にするように実装されている。
2007510210.tif 000005
【００４２】
好適には、コードは、プラットフォームＤＬＬに対して本質的な変化のみがなされることを保証すべきである。従って、好適には、他の全ての機能は拡張ＤＬＬに実装すべきである。これにより、プラットフォームが後に変更されても機能が衝突する可能性が減り、このため、将来新しいプラットフォームを統合するときのトラブルが削減されるという追加的な効果がもたらされる。
【００４３】
更に、プラットフォームＤＬＬにおいて何らかの拡張関数が提供される場合は、それらは好適には、ｐｒｉｖａｔｅの関数として作成されるべきである。これにより、第三者が、拡張ＤＬＬではなくオリジナルのＡＰＩにおける拡張関数を、不注意で使用することが困難になる。コンパイラは、確立されたルールを強制する助けとなるだろう。
【００４４】
さらに、公にリリースされたＳＤＫが、供給するものとしてオリジナルのＬＩＢファイルのみを含むようにすることも好適である。これは、第三者のコードは、おそらく、プラットフォームの追加の序数のいずれも呼び出すことができないだろう。なぜなら、それらはＬＩＢファイルに存在しないためである。従って、第三者は、拡張ＤＬＬを介して拡張の機能へアクセスせざるを得ず、これにより、将来のプラットフォームにおいて互換性の問題が発生することが防止される。
【００４５】
拡張関数をｐｒｉｖａｔｅにし、ＳＤＫから修正されたライブラリを除外することによって、第三者のコードが、プラットフォームＤＬＬの提供者によって創作された製品の追加関数を呼び出すことを防止することができる。しかし、装置内のＲＯＭコードも拡張ＤＬＬを使用することを保証することも望ましい。従って、オリジナルのＬＩＢファイルへのＳＤＫのアクセスを制限することによって、第三者だけでなく、全てのコード、言い換えれば、その後装置に組み込まれるＲＯＭコードも、追加の機能へアクセスするために拡張ＤＬＬを使用しなければならない。将来の何らかの時点において、新しいＬＩＢファイルに反してＲＯＭコードを再び作成することはできるが、可能なときはいつも、そして、特定の任意の装置のライフサイクルの間常に、バイナリの互換性を最適化することは、好ましく、また、強く望まれることである。これにより、本発明の拡張ＤＬＬが上述のように利用されるならば、この互換性を保つことは可能である。
【００４６】
以上、本発明について特定の実施形態を参照して説明したが、特許請求の範囲により定義される本発明の範囲内において修正を行うことは可能であるということを理解されたい。例えば、序数のリンキングを有するＤＬＬを例に挙げて、本発明に係る方法を説明したが、名前でリンクするＤＬＬを用いることも可能である。さらに、アプリケーションプログラムが使用する追加の関数を、一部をプラットフォームＤＬＬの範囲内で、一部を拡張ＤＬＬの範囲内で提供してもよい。この例の拡張ＤＬＬは、プラットフォームＤＬＬ又は拡張ＤＬＬ自身の範囲内で、追加の関数へリンクするように構成することができる。さらに、上記では、スマートフォンの形態のコンピュータ装置を参照して本発明を説明したが、本発明は他の形態のコンピュータ装置にも適用することができる。例えば、携帯用又はデスクトップＰＣ、携帯情報端末（ＰＤＡ：personal digital assistants）、或いは、一般のコンピュータシステムに適用することができる。
【図面の簡単な説明】
【００４７】
【図１】スマートフォン・プラットフォームの進化を模式的に示す図である。
【図２】プラットフォームの並列的な進化において、ＤＬＬの序数間での衝突がどのように発生しうるかを模式的に示す図である。
【図３】スマートフォン上のアプリケーションが、ＤＬＬから普通の関数へどのようにアクセスできるかを模式的に示す図である。
【図４】本発明の方法に基づいてＤＬＬをどのように提供することができるかを示す図である。
【図５】本発明の方法に基づいて提供されるＤＬＬの拡張を用いて、アプリケーションが、修正されたＤＬＬから関数へどのようにアクセスできるかを示す図である。
【図１】
2007510210.tif 000006
【図２】
2007510210.tif 000007
【図３】
2007510210.tif 000008
【図４】
2007510210.tif 000009
【図５】
2007510210.tif 000010
【国際調査報告】
2007510210.tif 000011