(57)【要約】  実行ファイルと、コンピュータ装置における新しいダイナミック・リンク・ライブラリ（ＤＬＬ）に保持された関数との間のリンクを容易にするために、再マップコンポーネントが提供される。新しいダイナミック・リンク・ライブラリにおける関数のアドレス位置を有する、再マップコンポーネントのためのエクスポート・データ・テーブルのエントリを、ロード時に、更新するように構成された、再配置命令を有する再マップコンポーネントが提供される。このようにして、実行ファイルは、知られたＤＬＬのアドレス位置における関数を呼び出すときに、新しいＤＬＬの関数のアドレス位置へ自動的にジャンプする。このため、ＤＬＬの再マップが通常関連づけられたサブルーチンの追加を防ぐことができ、コンピュータ装置の動作を改善することが可能となる。【選択図】  図３
2007510211.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムと、コンピュータ装置のダイナミック・リンク・ライブラリにおける関数との間のリンクを提供する方法であって、
前記アプリケーションプログラムによる、第１のダイナミック・リンク・ライブラリのアドレス位置における前記関数へリンクするための呼び出しに応じて、更なるダイナミック・リンク・ライブラリにおける前記関数のためのアドレス位置を提供するように構成された、再マップコンポーネントを提供する工程を備え、
前記アプリケーションプログラムが、前記更なるダイナミック・リンク・ライブラリにおける前記関数へ直接リンクすることを可能にする
ことを特徴とする方法。
【請求項２】
前記更なるダイナミック・リンク・ライブラリにおける前記関数の前記アドレス位置は、前記アドレス位置を、前記再マップコンポーネントのエクスポート・データ・テーブルへ挿入することにより提供される
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記再マップコンポーネントの再配置命令を用いて、前記アドレス位置を前記エクスポート・データ・テーブルへ挿入する工程を備える
ことを特徴とする請求項２に記載の方法。
【請求項４】
前記再マップコンポーネントは、複数の更なるダイナミック・リンク・ライブラリにおける、複数の関数のアドレス位置のそれぞれを提供するように構成される
ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記第１のダイナミック・リンク・ライブラリと前記更なるダイナミック・リンク・ライブラリとの間に複数の前記再マップコンポーネントを提供する工程を備える
ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記アプリケーションプログラムは、前記ダイナミック・リンク・ライブラリへ、序数によりリンクするように構成される
ことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記アプリケーションプログラムは、前記ダイナミック・リンク・ライブラリへ、名前によりリンクするように構成される
ことを特徴とする請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
請求項１乃至７のいずれか１項に記載の方法に基づいて動作するコンピュータ装置。
【請求項９】
コンピュータ装置を、請求項１乃至７のいずれか１項に記載の方法に基づいて動作させる、コンピュータソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ装置におけるデータへのアクセス方法に関し、特に、コンピュータ装置におけるダイナミック・リンク・ライブラリに保持されたデータへのアクセス方法に関する。本発明は、その方法により制御されるコンピュータ装置にも関する。
【背景技術】
【０００２】
ここで用いられるコンピュータ装置という用語は、あらゆる形態の電子機器を含むように拡張的に解釈され、任意の形状因子を有する静止画及び動画に係るデジタルカメラ等を含むデータ記録装置と、携帯端末及びパーソナルコンピュータを含むあらゆる種類及び形態のコンピュータと、任意の形状因子を有する通信装置とを含む。ただし、任意の形状因子を有する通信装置には、携帯電話と、高機能電話と、通信、画像記録と再生との少なくともいずれか、及び、計算機能を単一装置内で結合するコミュニケータと、及び、他の形態の無線又は有線の情報機器とが含まれる。
【０００３】
ほとんどのコンピュータ装置は、オペレーティングシステムの制御の下で動作する。オペレーティングシステムは、全てのプログラムがコンピュータ装置上で実行することを可能にするソフトウェアと見なすことができ、動作の効率性を高め、アプリケーション開発を容易にするための重要なコンポーネントと見なすことができる。
【０００４】
オペレーティングシステムは、それがインストールされたコンピュータ装置のハードウェア資源及びソフトウェア資源を管理する。これらの資源には、例えば、中央演算ユニット（ＣＰＵ：Central Processor Unit）、メモリが含まれる。ディスクがコンピュータ装置の一部を形成する、或いは、コンピュータ装置とともに用いられる場合には、ディスク空間もこの資源に含まれる。このようにして、オペレーティングシステムは、アプリケーションプログラムとしても知られる実行ファイルがコンピュータ装置上で実行するための安定した堅実な方法を提供する。当該方法によれば、実行ファイルは、そのハードウェアに利用可能な物理資源の詳細を全て知ることなく、装置のハードウェア資源を用いて処理を行うことができる。実行ファイル／アプリケーションプログラムは、装置のユーザのために特定の関数を直接実行する、完全で自己完結型のプログラムとみなすことができる。
【０００５】
ハードウェア資源及びソフトウェア資源を管理する上記のタスクは非常に重要である。なぜなら、多様なプログラムや入力方法は、それぞれの目的のために、ＣＰＵの割り当てを得るための競合を行い、メモリや記憶及び入出力資源（Ｉ／Ｏ：input/output）を求めるためである。各アプリケーションプログラムに必要な資源が可能な限り提供されるが、装置における利用可能な有限の物理資源に関して、各アプリケーションプログラムが、常に権利を有することを、オペレーティングシステムは、保証する。
【０００６】
オペレーティングシステムが実行しうる他のタスクは、信頼性のあるアプリケーション、或いは、実行ファイルのインタフェースを提供することである。このことは、このオペレーティングシステムを用いた１以上の型のコンピュータが存在する場合、或いは、コンピュータを構成するハードウェアが変更しうる場合に、特に重要である。このことは、特に、コアのオペレーティングシステムが複数の異なるユーザを有する場合にあてはまり、例えば、一般的には、スマートフォン（高機能電話）等の、無線通信装置の形式のコンピュータ装置において発生する。
【０００７】
これらの装置においては、多種多様なメーカーや装置の供給者が、コアのオペレーティングシステムに含まれるあるコンポーネントを共通のコンポーネントとして選択し、コアのオペレーティングシステムに含まれる他のコンポーネントを、個々の装置の要件に適合させることは、一般的ではない。アプリケーションプログラム／実行ファイルとオペレーティングシステムとを区別する方法の一つは、アプリケーションは"ユーザモード"（非特権モード）で実行するのに対して、オペレーティングシステムや関連するユーティリティは、通常、"スーパーバイザーモード"（特権モード）で実行するということが指摘されている。従って、上述のスマートフォンの例においても、コアのオペレーティングシステムにおいて重要な特定のコンポーネントが存在する。これは、カーネルコンポーネントとして知られており、"スーパーバイザーモード"で排他的に稼働するように維持され、オペレーティングシステムの所有者又は提供者によってのみアクセス可能、つまり、変更可能である。
【０００８】
適合性のあるアプリケーションプログラム・インタフェース（ＡＰＩ：Application Program Interface）によれば、装置間でメモリ量や記憶装置の容量が異なる場合においても、あるコンピュータ装置のためのアプリケーションプログラムを、同種の他のコンピュータ装置上で実行することができる。ある特定のコンピュータ装置が他とは異なるものであっても、オペレーティングシステムは、ハードウェアがアップグレードされたり更新された場合に、アプリケーションが実行し続けることを保証することができる。これは、アプリケーションではなく、オペレーティングシステムが、装置のハードウェアの管理やその資源の配分を統括するためである。
【０００９】
装置の資源をより効率的に使用するため、多数の実行ファイル／アプリケーションプログラムに共通に使用されうる特定の関数及びモジュールは、ライブラリの形式で格納しておくことができる。これにより、これらの関数及びモジュールは、一度格納されると、それらが一緒に用いられる実行ファイル／アプリケーションプログラムのそれぞれについて複製されない。従って、ライブラリの中身は、アプリケーションプログラムのロード時又は実行時に、選択的に呼ばれ、そのようなプログラムとリンクされる（関連づけられる）のであって、個々のプログラム自身の内部でコンパイルされるわけではない。その結果、このプロセスが続いたときに、同じブロックのライブラリ・コードは、装置上で実行する複数のタスクにより共有されるが、各タスクが、使用するルーチンのコピーを包含するわけではない。ライブラリの中に保持されるこれらの関数は、一般にエクスポート関数として知られており、エクスポート関数のアドレスを有するライブラリの中にテーブルが提供される。このテーブルは、一般に、エクスポート・データ・テーブルとして知られている。
【００１０】
これらのライブラリは、アプリケーションの実行時にアプリケーションプログラムとダイナミック（動的）にリンクされる。このため、このライブラリは、ダイナミック・リンク・ライブラリ（ＤＬＬｓ：dynamic link libraries）として一般的に知られている。従って、現代のコンピュータのオペレーティングシステムのほとんどは、１以上のダイナミック・リンク・ライブラリの機能を提供している。このダイナミック・リンク・ライブラリによれば、コンピュータ装置上で実行するアプリケーションプログラムとは分離した形で、特定の実行可能な手続き（プロシージャ）や関数（ファンクション）を１以上のライブラリの形式で提供することが可能になる。一般的に、アプリケーションプログラムは、実行時にその１以上のライブラリとダイナミックにリンクされるため、アプリケーションプログラムは、ライブラリによりエクスポートされる１以上の手続きや関数を呼び出すことができる。エクスポートされた手続きは、一般的に、そのライブラリへのエントリポイント（entry point）として参照される。
【００１１】
一般的に単一のエントリポイント（通常はプログラムの初め）から実行される標準的なアプリケーションとは異なり、ＤＬＬは任意のエントリポイントからエントリすることができる。これらのＤＬＬへのエントリポイントを特定する方法は、主に２つある。第１の選択肢は、名前（識別名）によりエントリポイントを参照するものである。第２の選択肢は、序数（通し番号：ordinal number）によりエントリポイントを参照するものである。ただし、序数は、エクスポート・データ・テーブルにおける位置を示す。この第２の選択肢は、序数によるリンクとしてよく参照される。名前は序数と比べて長くなる可能性が高く、名前によるリンクは、対応する序数を見つけるために、常に、関連するＤＬＬ内に通常保持される、付加的なテーブルの走査を伴う。このため、名前は、補助的な重要性を有していると考えることができる。結果として、名前が使用される場合、ライブラリへのエントリポイントを決定するために、追加のコードと処理工程が必要となる。このため、名前によるリンクは、一般に、序数によるリンクよりも、コンピュータ装置のリード・オンリ・メモリ（ＲＯＭ：Read Only Memory）及びランダム・アクセス・メモリ（ＲＡＭ：Random Access Memory）の資源を無駄に使用すると考えられている。このため、エントリポイントの序数リンクは、あるオペレーティングシステム、特に、スマートフォンの使用において優先的である。なぜなら、この種のコンピュータ装置は、物理資源、特に、利用可能なメモリのサイズが、デスクトップ又は携帯用ＰＣ装置において利用可能なものと比べて、非常に限られているためである。従って、これらの装置においては、コードを効率的に使用することが最重要である。以下の例では、本発明を、序数リンクを使用するシステムについて説明するが、本発明は、名前によってリンクするシステムにも同等に適用可能であるということが理解される。
【００１２】
従って、ＤＬＬによれば、モジュール形式で提供するための方法がアプリケーションプログラムにもたらされ、これにより、ある機能をより容易に共有し、更新し再利用することが可能となる。ＤＬＬは、複数のアプリケーションが同時に同じ機能を使用する場合に、メモリのオーバーヘッドを削減する助けともなる。これは、各アプリケーションにはデータのコピーが提供されるが、それぞれは、その機能を示すコードを共有することができるためである。さらに、ダイナミックにリンクすることで、そのアプリケーションプログラム内のモジュールを、ロード時又は実行時に、エクスポート可能なＤＬＬ関数を特定するために必要な情報のみによって示すことが可能になる。
【００１３】
オペレーティングシステムが互換性を備えると共にカスタマイズできるという要求が高まっている。これは、特に、例えば、英国、ロンドンのシンビアン社から供給されているＳｙｍｂｉａｎ  ＯＳ（商標）オペレーティングシステム等の、スマートフォンのオペレーティングシステムについて顕著である。一般的に、そのようなオペレーティングシステムはスマートフォンの端末メーカーへ供給されるが、その後に、端末メーカーは、オペレーティングシステムの制御の下で動作する、装置の追加的な機能を提供する。このことは、この種のオペレーティングシステムは、アプリケーション・プログラム・インタフェース（ＡＰＩ）にバイナリ互換性を有していなければならないことを意味する。また、同時に、オペレーティングシステムを個々の端末メーカーの要件に合わせてカスタマイズするために、所望とするプラットフォームや製品に応じて、革新的で差別化要因となる機能をこれらのＡＰＩに対して追加できるようにしなければならないことを意味する。バイナリ互換性は、古い実行ファイル／アプリケーションプログラムを新しい環境で使用し、その機能を正しく使用する能力を提供することと定義することができる。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかし、システムがあるリリースから次のものへ進化するときに、ＤＬＬエントリポイントを統合することが困難である。このため、オリジナルＤＬＬの機能を一緒に再び実装する１以上のＤＬＬに関して、オリジナルＤＬＬのインタフェースを効率的に提供する、再マップするＤＬＬの必要性が高い。さらに、再マップするＤＬＬは、ＤＬＬのインタフェースが完全には下位互換性がないように変更された場合において、古いアプリケーションのためにバイナリ互換性を提供する問題を解決するための有用な手段となる。
【００１５】
従って、本発明の目的は、そのような下位互換性を提供する方法を提供することである。
【課題を解決するための手段】
【００１６】
本発明の第１の側面によれば、
アプリケーションプログラムと、コンピュータ装置のダイナミック・リンク・ライブラリにおける関数との間のリンクを提供する方法であって、
前記アプリケーションプログラムによる、第１のダイナミック・リンク・ライブラリのアドレス位置における前記関数へリンクするための呼び出しに応じて、更なるダイナミック・リンク・ライブラリにおける前記関数のためのアドレス位置を提供するように構成された、再マップコンポーネントを提供する工程を備え、
前記アプリケーションプログラムが、前記更なるダイナミック・リンク・ライブラリにおける前記関数へ直接リンクすることを可能にする
ことを特徴とする方法が提供される。
【００１７】
本発明の第２の側面によれば、
第１の側面に係る方法に基づいて動作するコンピュータ装置が提供される。
【００１８】
本発明の第３の側面によれば、
コンピュータ装置を、第１の側面に係る方法に基づいて動作させる、コンピュータソフトウェアが提供される。
【発明を実施するための最良の形態】
【００１９】
以下、添付図面を参照して、本実施形態に係る実施形態の一例を説明する。
【００２０】
上述のように、各ＤＬＬは、エクスポート関数のＤＬＬの範囲でアドレスの一覧を有する、エクスポート・データ・テーブルを有する。図１に示す例では、ステップ３に示すように、エクスポート・データ・テーブルは、メモリアドレス位置４０００から始まる。
【００２１】
序数リンクが用いられる場合、各エクスポート関数は序数によって参照される。ただし、序数は、エクスポート関数が格納されるアドレスに対応する、エクスポート・データ・テーブルにおけるインデックスである。ＤＬＬの中には各関数について識別名も格納するものがある。しかし、上述の理由により、これは、より多くのメモリを消費する。このため、以下に説明する本発明の実施例においては、名前によるリンクを用いない場合を想定する。しかし、強調するが、ＤＬＬのアドレスを示すために名前が用いられる場合においても、本発明は同様に適用可能である。
【００２２】
エクスポート・データ・テーブルから名前が削除されたシステムにおいては、ＤＥＦファイルと呼ばれるソースファイルを含めることが従来より行われている。これは、ＤＬＬのためにエクスポート・データ・テーブルを特定するために用いられる。即ち、個別のエクスポート関数のそれぞれについてＤＬＬ内で用いられる序数である。
【００２３】
ＤＬＬが生成された場合、コンパイルツールは、他のコンパイルにおけるＤＬＬを示す"インポート・ライブラリ"と呼ばれるコンパニオンファイルを、通常、生成する。インポート・ライブラリは、ＤＬＬにおいてエクスポート可能な関数のそれぞれについて"インポート・スタブ"関数を有する。各スタブ関数は、"Ａ"の場所に格納されたアドレスへ"ジャンプ"することになるコードを有する。ただし、"Ａ"は、各スタブ関数とは異なる。ＤＬＬを用いる実行ファイルをコンパイルする場合、インポート・ライブラリにおける関数は、ＤＬＬ内の現実のコードの場所に存在する。
【００２４】
コンピュータ装置のオペレーティングシステムは、ローダとして知られるコンポーネントを有する。実行可能な実行ファイル／アプリケーションを生成するプロセスは、"ロード"すると呼ばれるが、これは、ローダにより行われる。
【００２５】
基本的に、ローダの仕事は、ディスクからメモリへ実行ファイルを読み出し、必要なＤＬＬを全てロードし、ＤＬＬ内において分離して格納された再配置命令（relocation instruction）の全てを実行することである。この分野の当業者に知られているように、再配置命令は、コンピュータ装置のメモリ空間における特定のアドレスにおいて、実行するための実行ファイルを用意するために、実行ファイルの中で場所をどのように修正するかを記述する、（分離して格納された）符号化された命令である。従って、ロードした後の最終結果は、メモリにおいて実行可能な実行ファイルのイメージであるが、実際の、制御の伝達や、命令の実行は、オペレーティングシステムの他の部分の制御の下で行われる。
【００２６】
ローダは、ハードディスク等の、不揮発性の実行可能でないメモリからロードされるアプリケーションプログラムのために、コンピュータ装置のメモリ空間においてメモリを割り当てなければならない。これにより、アプリケーションプログラムのファイルが、ロードされ、続いて実行可能なメモリから読み込まれることが可能となる。従って、"Ａ"のアドレスについて適切な値を、実行ファイルのスタブ関数のコードに設定することは、オペレーティングシステムのローダの仕事であり、この時に、実行ファイルは実行可能になる。
【００２７】
このため、図１を参照すると、ステップ１からは、ロード前の実行ファイルは、アドレスＡ＋９のサブルーチンを呼び出す任意のアドレスＡのコードを含んでいることが分かる。本質的に、記号Ａは、"実行ファイルにおける、第１の場所又はアドレス"を示している。アドレスＡ＋９におけるサブルーチンは、アドレスＡ＋１０のデータとして格納すべきアドレスへジャンプする命令を含んでいる。言い換えれば、実行ファイルと全てのＤＬＬがロードされた場合、アドレスＡ＋１０は、実行ファイルの一部を構成するわけではないが、実行ファイルが適切に機能するために必要な、ルーチン（この例では、関数ｆｏｏ()）のＤＬＬの範囲における、アドレス位置を提供するデータを含むことになる。実行ファイルは再配置の項目も含んでおり、この項目はアドレスＡ＋１０のコンテンツをｏｒｉｇｉｎａｌ．ｄｌｌにおけるエクスポート１のコンテンツへ設定する。ただし、これは、エクスポート関数ｆｏｏ()を実装する命令のアドレスである。
【００２８】
コンピュータ装置内の実行可能メモリに実行ファイルをロードするために、システムローダは、メモリ空間を割り当てる。従って、図１のステップ２から分かるように、ローダはアドレス１０００（実行ファイルのためのアドレスの開始位置であり、アドレスＡと同等である）からメモリ空間を割り当て、ディスクから実行ファイルのロードを開始している。このため、実行ファイルがロードされた後に、実行ファイルの内部にありアドレス１０００にロードされたコードは、アドレス１００９（Ａ＋９）のサブルーチンを呼び出し、アドレス１００９のサブルーチンは、アドレス１０１０にデータとして保持されたアドレスへジャンプするために呼び出す。実行ファイル内の再配置命令は、アドレス１０１０のコンテンツを、ｏｒｉｇｉｎａｌ．ｄｌｌのエクスポート１のコンテンツとなるように設定する。従って、この例では、上述の実行ファイルにおけるインポート・スタブ関数のコードにおけるＡが、アドレス１０００で置き換えられているということが分かる。
【００２９】
まとめると、インポート・スタブ関数を含む実行ファイルについて、一般的に、各インポートスタブについて、ローダは、以下の工程を実行する。
１．インポート・スタブに関連づけられたＤＬＬを識別する。
２．（まだロードしていない場合は）そのＤＬＬをロードする。
３．ＤＬＬのエクスポート・データ・テーブルから適切なエントリを読み出す。
４．そのエントリのための値をアドレスＡに格納する。
【００３０】
この処理を効率的に行うために、各実行ファイルは、通常、"ＤＬＬ参照テーブル"を有する。この参照テーブルは、関連する実行ファイルが適切に機能するために必要な全てのＤＬＬを一覧にしたものである。各ＤＬＬについて、参照テーブルは、必要なエクスポート・データ・テーブルのエントリと、それぞれが格納される実行ファイル内のアドレスとの一覧を有する。ロードの手順は、対象とするオペレーティングシステムや用いられるファイルフォーマットによって、正確には異なるが、細部の相違は、本発明に係る動作において重要ではない。そのような全てのシステムの本質において、ロードされる実行ファイルは、必要なＤＬＬがそれぞれロードされるコンピュータ装置のメモリ空間において、実アドレスを反映するように調整される。
【００３１】
従って、図１を再び参照すると、ローダは、実行ファイルが実行するために必要なＤＬＬを再帰的にロードする。ただし、このＤＬＬには、関数ｆｏｏ()を実装する命令を含むｏｒｉｇｉｎａｌ．ｄｌｌが含まれる。ここに示す例では、ローダは、ｏｒｉｇｉｎａｌ．ｄｌｌのためにアドレス位置４０００からメモリを割り当てており、アドレス位置４０００から始めて、このライブラリのためにディスクからファイルの読み出しを開始する。ｏｒｉｇｉｎａｌ．ｄｌｌのためのエクスポート・データ・テーブルはアドレス位置４０００にロードされ、このテーブルの最初のエントリ（ｅｘｐｏｒｔ１）はアドレス４０７７を含んでいる。ただし、アドレス４０７７は、関数ｆｏｏ()を実装するの命令のアドレスである。
【００３２】
この例では、さらなるＤＬＬからｏｒｉｇｉｎａｌ．ｄｌｌへエクスポートされる全ての関数のインポートを解決する必要はないが、ｏｒｉｇｉｎａｌ．ｄｌｌのロードは終了している。ｏｒｉｇｉｎａｌ．ｄｌｌがロードされた場合、"ｏｒｉｇｉｎａｌ．ｄｌｌにおけるエクスポート１のコンテンツに１０１０を設定する"という、実行ファイルにおける再配置命令は終了する。そして、これにより、実行ファイル内のアドレス１０１０におけるデータとして格納されているアドレスは、ｏｒｉｇｉｎａｌ．ｄｌｌ内の関数ｆｏｏ()を実装するための命令の位置である、アドレス４０７７に設定される。これは、図１のステップ４に示されており、この処理は、この分野で一般的に"インポートの解決"として知られている。従って、まとめると、実行ファイルを実行可能にする関数ｆｏｏ()へ到達する実行のシーケンスは、図１のステップ５のように示される。
【００３３】
しかしながら、オペレーティングシステムの実行中に、ＤＬＬによって提供されるインタフェースを変更することが望ましい状況が発生しうる。例えば、新しいアプリケーションがコンピュータ装置上で実行するために、新しい実行ファイルを提供することなどである。しかし、既存の実行ファイルとの互換性を保つことも望ましい。これは、コアのオペレーティングシステムが複数の異なるユーザを有し、それぞれに対して、そのオペレーティングシステムの制御の下で異なるアプリケーションを実行するように適用する場合に、特に当てはまる。このような状況は、例えば、スマートフォン等の無線通信装置のようなコンピュータ装置において頻繁に発生しうる。
【００３４】
これらの装置について、様々な装置のメーカーや装置の供給者が、コアのオペレーティングシステムのあるコンポーネントを共通コンポーネントとして採用し、コアのオペレーティングシステムの他のコンポーネントを個々の装置の要件に適合させることは、一般的でない。スマートフォンにおいて使用されるオペレーティングシステムの一例としては、英国、ロンドンのシンビアン社により提供されているＳｙｍｂｉａｎ  ＯＳ（商標）オペレーティングシステムがある。そのようなシステムを用いたスマートフォンの開発においては、与えられたＤＬＬに対して、オペレーティングシステムの提供者と１以上の端末メーカーの両方により、別個に改変がなされる可能性が高い。例えば、市場における消費者の個々の端末について提供するために、端末メーカーは追加のＡＰＩを取り入れるだろうし、新しい機能がオペレーティングシステムに組み込まれた場合、オペレーティングシステムの提供者は追加のＡＰＩを個別に取り入れるだろう。
【００３５】
このような状況が発生した場合、追加のＡＰＩの集合の両方、即ち、端末メーカーにより提供されたものと、オペレーティングシステムの提供者により提供されたものの両方に対応する、修正済みのＤＬＬを提供する必要が生じる。しかしながら、ＤＬＬへのエントリポイントは序数によって定義され、これらは、通常、使用されていない序数の範囲の最後における、シーケンシャルな基準に割り当てられるため、端末メーカーとオペレーティングシステムの提供者が、異なる関数をそれぞれ参照するために同じ序数を個別に使用してしまっている可能性が高い。
【００３６】
例えば、序数７７が、端末メーカーのＤＬＬのバージョンにおける関数Ａと、オペレーティングシステムの提供者のＤＬＬのバージョンにおける関数Ｂとに用いられていると仮定する。この場合、単一のＤＬＬを用いて、この共通の序数へリンクする既存のバイナリコードのシーケンスの集合の両方に対応することはできない。これは、序数７７は、一つの関数のみを参照することができるからであり、この例では、関数Ａと関数Ｂのいずれかを参照でき、両方はできないためである。しかし、対象とする実行ファイルの実行中に、任意の特定の序数が呼ばれ、或いは、重大なエラーが発生した場合、全てのＤＬＬファイルは、受け入れ、正確なデータや実行ファイルが期待する制御インタフェースを供給することが重要である。
【００３７】
このため、再マップのコンポーネントが、ＤＬＬにおいて提供され、これは、新しいＤＬＬに関してＤＬＬインタフェースの再実装を可能にする。上述の例では、（オペレーティングシステムの提供者による）関数Ｂを有する新しいＤＬＬが序数７７に生成され、（端末メーカーによる）関数Ａが序数７８に生成される。既存の実行ファイルに対応するために、再マップするＤＬＬは、関数Ａへの呼び出しを、新しいＤＬＬの序数７８における関数への呼び出しに変換する。ただし、実行ファイルは、端末メーカーにより用いられるオリジナルのＤＬＬにおいて序数７７からエクスポートするようにプログラムされている。利便性のために、オペレーティングシステムを、再マップするＤＬＬが適用される状況を自動的に識別するように修正してもよい。これは、本来要求されるＤＬＬに対応して、再マップするＤＬＬを選択するように、機構をロードするＤＬＬを修正することを含むかもしれない。
【００３８】
再マップするＤＬＬは、比較的単純な（些細な）関数を含むソースファイルを生成することによって実装され、それぞれは、新しいＤＬＬ内の適切な関数を呼び出す。なお、関数は、通常、単一のジャンプ命令まで削減することができるため、"些細な"という言葉をここでは用いている。これらの関数は、適切なＤＥＦファイルを使用することによって、再マップするＤＬＬに係るエクスポート・データ・テーブルにおいて、正しい位置にエクスポートされる。そして、この分野の当業者によく知られたコンパイルツールを用いてソースファイルとＤＥＦファイルをコンパイルすることによって、再マップするＤＬＬを生成することができる。
【００３９】
図２は、そのような些細な関数を含む再マップするＤＬＬに係る一形態を示す図である。この例において、実行ファイルが要求する関数への各呼び出しには、些細なジャンプ関数のオーバーヘッドと、標準のインポート関数のコストが存在する。このことは、以下の記述により明らかとなる。
【００４０】
図２の例においては、関数ｆｏｏ()を実装する命令がｏｒｉｇｉｎａｌ．ｄｌｌの序数１においてエクスポートされているが、新しいＤＬＬの序数３においてエクスポートされている。図２のステップ１は、アドレス位置１０００から始まって、実行ファイルがロードされている、図１のステップ２を完全にしたものに対応する。図２の例において、アドレス位置２０００は、ＤＬＬの再帰的なロードを開始するために選択されているという点を除いて、図２のステップ２及び３は、基本的には、図１のステップ３を完全にしたものに対応する。しかし、この例では、再マップするＤＬＬだけでなく、関数ｆｏｏ()が序数３においてエクスポートされる新しいＤＬＬもロードする必要がある。以下の説明では、再マップするＤＬＬをｒｅｍａｐｐｉｎｇ．ｄｌｌで参照し、新しいＤＬＬをｎｅｗ．ｄｌｌで参照する。ここに示す例では、ローダは、ｎｅｗ．ｄｌｌをロードするためにメモリアドレス３０００から割り当てを行い、次に、このライブラリのためのファイルがディスクから読み出される。
【００４１】
次に、インポート関数を解決するために、実行ファイル、ｒｅｍａｐｐｉｎｇ．ｄｌｌ（ｏｒｉｇｉｎａｌ．ｄｌｌの再マップバージョンと見なすこともできる）、及び、ｎｅｗ．ｄｌｌのために、再配置を実行する。図２のステップ４は、各ＤＬＬ内に分離して格納された再配置命令を実行することによって、全てのインポートが解決された場合の結果を示している。従って、図２からは、実行ファイルがアドレス１０００から再びロードされることが分かる。アドレス１０００のコードは、アドレス１００９のサブルーチンを呼び出し、このサブルーチンは、アドレス１０１０におけるデータとして格納されたアドレスへのジャンプである。ただし、この例では、これは、ｒｅｍａｐｐｉｎｇ．ｄｌｌのエクスポート・データ・テーブルにおける第１のエントリ（アドレス２０００）から、ｒｅｍａｐｐｉｎｇ．ｄｌｌのアドレス位置２０１５へ設定される。アドレス位置２０１５のサブルーチンは、アドレス位置２０１６のデータとして格納されたアドレスへジャンプするものである。再配置が実行された場合、このデータは、ｎｅｗ．ｄｌｌのエクスポート・データ・テーブルの第３のエントリ（アドレス３００２）のコンテンツ、即ち、アドレス３０２７に設定される。ただし、アドレス３０２７は、関数ｆｏｏ()を実装する命令のアドレスである。従って、実行ファイルが要求された関数ｆｏｏ()へ到達する実行のシーケンスは、図２のステップ５のようにまとめられる。
【００４２】
なお、図２における、ｒｅｍａｐｐｉｎｇ．ｄｌｌを介してｎｅｗ．ｄｌｌの関数ｆｏｏ()へ到達するために必要なジャンプ命令の数は、図１において、ｏｒｉｇｉｎａｌ．ｄｌｌにおけるこの関数へ到達するために必要なジャンプ命令の数と比較すると、１つ多いということに注意されたい。したがって、まとめると、この種の再マップするＤＬＬに関しては、実行ファイルがロードされた場合、ｏｒｉｇｉｎａｌ．ｄｌｌにおけるエクスポート関数への参照は、ｒｅｍａｐｐｉｎｇ．ｄｌｌにおけるエクスポート関数へのリンクに代替され、これによりｎｅｗ．ｄｌｌ内の正当なエクスポート関数へジャンプする。言い換えると、実行ファイルは、ｒｅｍａｐｐｉｎｇ．ｄｌｌにおいて提供されるリダイレクトを介して、常に、ｎｅｗ．ｄｌｌの関数ｆｏｏ()の序数へとリンクされる。これは、実行シーケンスにおいて追加的なジャンプの工程が避けられない理由である。
【００４３】
本発明によれば、再マップするＤＬＬをより効率的に実装する方法が提供される。これは、図３に示される。以下の説明では、より効率的に再マップするこのＤＬＬを再マップコンポーネント（remapping component）として参照する。この再マップコンポーネントの重要な特徴は、コンポーネント内の再配置命令を使用して、コンポーネント自身のエクスポート・データ・テーブルを修正することである。この特徴は、特に有用であると考えられる。なぜなら、これは、実行ファイルに、当該実行ファイルのための実際の機能を提供する、実装中の（新しい）ＤＬＬを直接参照させることによって、再マップするＤＬＬが通常必要とする実行リソースのオーバーヘッドを削減するためである。言い換えれば、再マップコンポーネントがその通信の準備に関与するが、実行ファイル中のインポートスタブは、所望とする関数を有する新しいＤＬＬを直接参照する。従って、図３の再マップコンポーネントの動作は、図２に示す再マップするＤＬＬの動作と、はっきり対照をなしている。
【００４４】
図３のステップ１は、ロードする前の再マップコンポーネントを示している。このステップに関しては、再マップコンポーネントは、実行可能コードを含んでいないということが特に重要である。再マップコンポーネントは、エクスポート・データ・テーブルと再配置のみを備えている。エクスポート・データ・テーブルは、再マップコンポーネントのアドレス位置Ａ〜Ａ＋２に、３つのエントリを有する。再マップコンポーネントにおける再配置の項目を示すデータは、アドレス位置Ａのコンテンツをｎｅｗ．ｄｌｌのエクスポート３のコンテンツに設定し、アドレス位置Ａ＋１のコンテンツをｎｅｗ．ｄｌｌのエクスポート２のコンテンツに設定し、アドレス位置Ａ＋２のコンテンツを第３のＤＬＬのエクスポート７のコンテンツに設定する。ただし、第３のＤＬＬを、この例では、ａｎｏｔｈｅｒ．ｄｌｌと呼ぶ。図２に示した例と同様に、ｆｏｏ()を実装する命令は、ｎｅｗ．ｄｌｌの序数３においてエクスポートされることを理解されたい。
【００４５】
図３のステップ２は、本質的には、図２のステップ１、２及び３を結合したものである。つまり、アドレス位置１０００への実行ファイルのロードと、アドレス位置２０００への再マップするコンポーネント、及び、アドレス位置３０００へのｎｅｗ．ｄｌｌの、再帰的なロードとが示されている。
【００４６】
従って、図１及び２のように、アドレス１０００の実行可能コードは、アドレス１００９のサブルーチンを呼び出し、これは、アドレス位置１０１０にデータとして格納されているアドレスへジャンプする。アドレス位置１０１０は、実行ファイル内の再配置命令により、ｏｒｉｇｉｎａｌ．ｄｌｌにおけるエクスポート１のコンテンツとして設定される。再マップコンポーネントにおける再配置命令は、再マップコンポーネントにおけるアドレス位置２０００のコンテンツを、ｎｅｗ．ｄｌｌのエクスポート３におけるコンテンツに設定する。ｎｅｗ．ｄｌｌのエクスポート・データ・テーブルにおける第３のエントリ（アドレス位置３００２）は、関数ｆｏｏ()を実装する命令のアドレスである、アドレス３０２７を有する。
【００４７】
上述のように、この再マップコンポーネントにおいては、再配置の実行は、再マップコンポーネント自身の中でエクスポート・データ・テーブルを修正するために用いられる。図２を参照して説明したｒｅｍａｐｐｉｎｇ．ｄｌｌの場合と同様に、再マップコンポーネントは、実行ファイルからｏｒｉｇｉｎａｌ．ｄｌｌのアドレス位置への呼び出しを、再マップコンポーネント内のサブルーチンを使用して、ｎｅｗ．ｄｌｌの正しいアドレス位置にリダイレクトしない。従って、再配置が終了した場合、再マップコンポーネントのエクスポート・データ・テーブル内に存在する、再マップコンポーネントのアドレス位置２０００のデータは、ｎｅｗ．ｄｌｌの関数ｆｏｏ()を実装する命令のアドレスである、アドレス３０２７を有するように修正される。ただし、そのアドレスは、再マップコンポーネントそれ自身を有するために、ローダによって割り当てられるメモリには存在しない。
【００４８】
従って、実行ファイル内のサブルーチンが、アドレス位置１０１０にデータとして保持されたアドレスへジャンプする命令を実行する場合、実行ファイルは、ｎｅｗ．ｄｌｌ内のアドレス位置３０２７に直接ジャンプする。従って、この再マップコンポーネントの関数は、図２のｒｅｍａｐｐｉｎｇ．ｄｌｌとはっきり対照をなしている。図２では、再配置が終了した後、実行ファイル内のアドレス位置１０１０にデータとして格納されたアドレスは、再マップするＤＬＬのアドレス位置２０１５であり、このアドレス位置におけるサブルーチンは、アドレス位置２０１６にデータとして格納されたアドレスへ、さらにジャンプする。ただし、アドレス位置２０１６に格納されたアドレスは、関数ｆｏｏ()のためのアドレス位置３０２７である。従って、図３の再マップコンポーネントによれば、図２のステップ５に示される、２つのジャンプ工程を有する再マップの実行シーケンスのように、再マップＤＬＬを介して実行ファイルからの呼び出し経路を切り替える必要がない。結果として、実行ファイルは、ｎｅｗ．ｄｌｌ内の必要な関数ｆｏｏ()へ、単一のジャンプでリンクすることができる。つまり、アドレス位置１００９のサブルーチンは、ｎｅｗ．ｄｌｌ内のアドレス位置３０２７へ直接ジャンプする。したがって、図３のステップ４から分かるように、再マップコンポーネントを用いてｎｅｗ．ｄｌｌ内の関数ｆｏｏ()へ到達する実行ファイルのための実行シーケンスは、ｏｒｉｇｉｎａｌ．ｄｌｌ内の関数ｆｏｏ()へ到達するために必要な工程と同じ工程数を有する。従って、実行ファイルとｎｅｗ．ｄｌｌにおいて必要な関数とをリンクするための実行のオーバーヘッドはなく、コンピュータ装置をより効率的に動作させることが可能となる。
【００４９】
実行ファイル、再マップコンポーネント、及び、ｎｅｗ．ｄｌｌをロードし、図３に示した方法に基づいて、実行ファイルとｎｅｗ．ｄｌｌ内に保持された関数ｆｏｏ()とをリンクする処理は、次のように示される。
【００５０】
＜実行ファイルをロードする＞
（アドレス１０００からメモリを割り当て、ディスクから実行ファイルをロードする）
１０００  Ａ＋９を呼び出す
・・・
１００９  Ａ＋１０のアドレスへジャンプする
１０１０  データ＝？
（分離して格納された）再配置命令は、Ａ＋１０を、ｏｒｉｇｉｎａｌ．ｄｌｌにおけるエクスポート１のコンテンツに設定する。
【００５１】
（実アドレス（アドレス１０００）の選択によって可能となる再配置を実行する）
１０００  １００９を呼び出す
・・・
１００９  １０１０のアドレスへジャンプする
１０１０  データ＝？
（分離して格納された）再配置命令は、１０１０を、ｏｒｉｇｉｎａｌ．ｄｌｌにおけるエクスポート１のコンテンツに設定する。
【００５２】
＜必要なＤＬＬ（再マップコンポーネントとｎｅｗ．ｄｌｌを含む）を再帰的にロードする＞
（・再マップコンポーネント）
アドレス２０００からメモリを割り当て、ディスクから再マップコンポーネントのファイルを読み出し、実アドレス（アドレス２０００）を選択することにより可能となる再配置を実行する
２０００  エクスポート１＝？
２００１  エクスポート２＝？
２００３  エクスポート３＝？
（分離して格納された）再配置命令
２０００を、ｎｅｗ．ｄｌｌのエクスポート３のコンテンツに設定する
２００１を、ｎｅｗ．ｄｌｌのエクスポート２のコンテンツに設定する
２００２を、ａｎｏｔｈｅｒ．ｄｌｌのエクスポート７のコンテンツに設定する。
【００５３】
（・ｎｅｗ．ｄｌｌ）
アドレス３０００からメモリを割り当て、ディスクからｎｅｗ．ｄｌｌのファイルを読み出し、実アドレス（アドレス３０００）を選択することにより可能となる再配置を実行する
３０００  エクスポート１＝３０１９
３００１  エクスポート２＝３００６
３００３  エクスポート３＝３０２７
・・・
３０２７  ＜ｆｏｏ()を実装する命令＞。
【００５４】
（再マップコンポーネントにおけるインポートを解決するために再配置を実行する）
ｎｅｗ．ｄｌｌは完全にロードされ、これにより、"２０００を、ｎｅｗ．ｄｌｌのエクスポート３のコンテンツに設定する"という再配置命令は実行される。従って、再マップコンポーネントのアドレス位置２０００〜２００２におけるデータは、それぞれ以下のようになる：
２０００  エクスポート１＝３０２７
２００１  エクスポート２＝３００６
２００２  エクスポート３＝４０１１    （ａｎｏｔｈｅｒ．ｄｌｌから、示さず）。
【００５５】
必要なＤＬＬにおける必要なアドレス位置へのこれらのリンクは、ＤＬＬのロード処理の通常部分としてもたらされるということは特に興味深い。即ち、再配置が実行され、全てのＤＬＬのコンテキスト全体への参照や、ロードすべき実行ファイルは不要である。従って、この方法は、通常のロード処理を除いて追加のステップが全く必要ない。これにより、"インポートを解決する"ステップが実行される前に、要求されたＤＬＬの個々のエクスポート・データ・テーブルは全て完全であるということが保証される。
【００５６】
（実行ファイルにおいてインポートを解決する）
ｏｒｉｇｉｎａｌ．ｄｌｌは完全にロードされ、これにより、実行ファイル内の"１０１０を、ｏｒｉｇｉｎａｌ．ｄｌｌのエクスポート１のコンテンツに設定する"という再配置命令を実行することができる。
【００５７】
重要なのは、（ｏｒｉｇｉｎａｌ．ｄｌｌ内の）エクスポート１のコンテンツは、再マップコンポーネント内のいかなるアドレスも参照していないことである。本発明の結果として、メモリアドレス１０１０のコンテンツは、ｎｅｗ．ｄｌｌからの関連するエクスポートのコピーであり、従って、実行のシーケンスは以下のようなものとなる：
１０００  １００９を呼び出す
・・・
１００９  １０１０のアドレスへジャンプする
１０１０  データ＝３０２７。
【００５８】
従って、全体的な効果としては、実行ファイルは変更されず、依然としてｏｒｉｇｉｎａｌ．ｄｌｌを参照しているにも関わらず、例えば、オペレーティングシステムの提供者が必要とする、ｎｅｗ．ｄｌｌの関数ｆｏｏ()に対して、実行ファイルが直接リンクしていることである。即ち、実行ファイルと必要とされた関数との間のリンクは、図２に示されるｒｅｍａｐｐｉｎｇ．ｄｌｌの場合と同様に、再マップするＤＬＬにおけるサブルーチンのリダイレクトによってなされるのではない。
【００５９】
以上、本発明について、特定の実施形態を参照して説明したが、添付の特許請求の範囲に定義された本発明の範囲内であれば、修正が効果的になりうるといことを理解されたい。例えば、上記では、実行ファイルとある新しいＤＬＬ内の一つの関数との間のリンクを供給することを参照して、再マップコンポーネントを説明した。しかし、複数の新しいＤＬＬに設けられうる複数の関数に関連して、そのデータテーブルを更新するように、再マップコンポーネントを構成することができる。さらに、再マップコンポーネントによって参照される任意の新しいＤＬＬは、それ自身が、更に他のＤＬＬを参照する再マップコンポーネントであってもよい。この場合、本発明は、関連する再マップするＤＬＬのシーケンスの長さに関わらず、実行ファイルから他のＤＬＬへの更なる直接の呼び出しをも提供する。従って、本発明の方法によりもたらされる"実行コストゼロ"は、将来ｎｅｗ．ｄｌｌへのインタフェースが変更されても、有効であり続ける。最終結果は、実行ファイルから、将来提供されるＤＬＬ内の適切なアドレスへの、直接のジャンプとなるだろう。ＤＬＬの些細な再マップ手法は、リダイレクトの段階毎に追加のオーバーヘッドを招いてしまう。従って、例えば、再マップするＤＬＬが２つの場合は、ｒｅｍａｐｐｉｎｇ．ｄｌｌは、本発明の再マップコンポーネントよりも、２つのジャンプ分コストが高くなるだろう。或いは、再マップするＤＬＬが３つの場合は、３つのジャンプ分コストが高くなるだろう。
【図面の簡単な説明】
【００６０】
【図１】エクスポート関数が、実行ファイル／アプリケーションプログラムによってどのようにＤＬＬから呼ばれうるかを示す図である。
【図２】ＤＬＬのインタフェースが他のＤＬＬによって再実装された場合、ＤＬＬがどのように再マップされうるかを示す図である。
【図３】本発明に係る再マップコンポーネント／ＤＬＬを示す図である。
【図１】
2007510211.tif 000003
【図２】
2007510211.tif 000004
【図３】
2007510211.tif 000005
【国際調査報告】
2007510211.tif 000006
2007510211.tif 000007
2007510211.tif 000008