JP5295379B2 - 組み込みプラットフォームにおけるプログラムの動的リンキング方法および組み込みプラットフォーム - Google Patents

Description

本発明は組み込み技術分野に関し、特に、組み込みプラットフォームにおけるプログラムの動的リンキング方法および組み込みプラットフォームに関する。

プログラムのリンキング技術が静的リンキング技術と動的リンキング技術とに分けられることは知られている。静的リンキング技術を採用する際に、コンパイルの段階で、アプリケーションプログラムのアドレスは決定されており、現在複数のアプリケーションプログラムが関数ライブラリ内の関数をコールした場合、メモリにコピーされる関数ライブラリの数が前記アプリケーションプログラムの数と同じである必要があって、メモリ空間を浪費してしまう。ところが、動的リンキング技術ではインポートライブラリを提供して関数ライブラリ内の関数を位置決めており、このようなインポートライブラリには関数間のコール関係に対する記述のみが記憶され、実際のコードは記憶されないため、メモリ空間を節約することができる。

現在、携帯電話などの組み込み製品では、プログラムの動的リンキングを既に実現したが、採用するのは実行可能・リンキングフォーマット（ＥＬＦ： Ｅｘｅｃｕｔａｂｌｅ ａｎｄ Ｌｉｎｋｉｎｇ Ｆｏｒｍａｔ）動的リンキングの方式であり、具体的には図１を参照する。

図１は従来技術でＥＬＦの方式を採用してプログラムの動的リンキングを実現することを示す図である。

図１に示すように、ＥＬＦ方式を採用してプログラムの動的リンキングを実現する際に、まず、アプリケーションプログラムをＥＬＦフォーマットファイルにコンパイルしてから、ＥＬＦローダ（ＥＬＦ ＬＯＡＤＥＲ）プログラムを採用して、生成されたＥＬＦファイルに対して関数のリロケーションと変数のリロケーションを行い、次に、リロケーション後のＥＬＦファイルを組み込みオペレーティングシステム（ＯＳ）にロードし、最後に、この組み込みオペレーティングシステムがこのリロケーション後の関数と変数の位置に基づいて各関数と変数にリンクすることにより、プログラムの動的リンキングを実現する。

ＥＬＦ方式を採用してプログラムの動的リンキングを実現する際に、ＥＬＦローダプログラムが重要な役割を果たし、アプリケーションプログラムにおける関数と変数のアドレスを組み込みオペレーティングシステムにおけるアドレスにリロケートすることに用いられる。具体的に、ＥＬＦローダプログラムはＥＬＦフォーマットファイルから有用な情報を抽出して、ＥＬＦフォーマットファイルにおける各関数と変数のリロケーション後のアドレスを算出してから、このアドレスによって関数と変数に対してリロケーションを行う。

ここからわかるように、ＥＬＦ方式を採用してプログラムの動的リンクを実現する際に、ＥＬＦフォーマットファイルから有用な情報を抽出し、これらの有用な情報に対して計算を行う必要があるため、プログラムの動的リンキング速度が遅くなってしまい、一方、計算リソースも浪費してしまう。

本発明は上記に鑑みてなされたものであって、プログラムの動的リンキング速度を向上できる、組み込みプラットフォームにおけるプログラムの動的リンキング方法および組み込みプラットフォームを提供することを目的とする。

上記の目的を達成するために、本発明の解決手段は下記のように実現される。

組み込みプラットフォームにおける動的リンキングプログラムの方法であって、前記組み込みプラットフォームは中間層を含み、前記中間層は１つ以上のクラスを含み、各クラスは組み込みオペレーティングシステムの１つ以上の関数インターフェースをカプセル化して得られたものであり、各クラスは１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素は前記１つ以上の関数インターフェースに一々対応され、リンキング対象のアプリケーションプログラムは１つ以上のクラスを含み、各クラスは当該アプリケーションプログラムの１つ以上の関数インターフェースをカプセル化して得られたものであり、各クラスは１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素はそれぞれ前記アプリケーションプログラムの１つ以上の関数インターフェースに一々対応され、当該方法は、

前記アプリケーションプログラムを位置独立のコードセグメントにコンパイルし、かつ当該アプリケーションプログラムの異なる関数をコンパイルして得られたコードセグメントの記憶位置が互いに相交しなく、コンパイルして得られた全てのコードセグメントを組み込みオペレーティングシステムのメモリにコピーし、

クラスポインタを確立し、中間層のクラスと前記アプリケーションプログラムのクラスとの間でクラスポインタを伝送することにより、プログラムの動的リンキングを実現することを含む。

組み込みプラットフォームであって、中間層を含み、
前記中間層は１つ以上のクラスを含み、各クラスは組み込みオペレーティングシステムの１つ以上の関数インターフェースをカプセル化して得られたものであり、各クラスは１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素は前記１つ以上の関数インターフェースに一々対応され、
前記中間層は上記方法を実行できるように構成される。

ここからわかるように、本発明は組み込みオペレーティングシステムから中間層をカプセル化し、この中間層は１つまたは複数のクラスを含み、各クラスは組み込みオペレーティングシステムの複数の関数インターフェースをカプセル化して得られたものであり、各クラスは１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素は前記複数の関数インターフェースに一々対応される。リンキング対象のアプリケーションプログラムは１つまたは複数のクラスを含み、各クラスは当該アプリケーションプログラムの複数の関数インターフェースをカプセル化して得られたものであり、各クラスは１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素はそれぞれ前記アプリケーションプログラムの複数の関数インターフェースに一々対応される。前記アプリケーションプログラムを位置独立のコードセグメントにコンパイルし、かつ当該アプリケーションプログラムの異なる関数をコンパイルして得られたコードセグメントの記憶位置が互いに相交しないことによって、アプリケーションプログラムは任意の記憶空間内で運用でき、かつアプリケーションプログラムの各関数は独立にコールされることができる。コンパイルされた全てのコードセグメントを直接に組み込みオペレーティングシステムのメモリにコピーする。クラスポインタを確立し、中間層のクラスと前記アプリケーションプログラムのクラスとの間でクラスポインタを伝送することにより、プログラムの動的リンキングを実現する。

各クラスポインタが一旦確立されると、このクラスポインタに対応する仮想関数テーブルの各要素に対応する関数インターフェースも実例化され、即ち、これらの関数が相応的に実際のアドレスを付与され、この時、中間層のクラスに対応する各関数とアプリケーションプログラムに対応する各関数の間では仮想関数テーブルを通じて動的リンキングを実現する。従って、本発明ではクラスポインタを確立し、中間層のクラスと前記アプリケーションプログラムのクラスの間でこのクラスポインタを伝送することにより、プログラムの動的リンキングを実現することができる。

そして、クラスポインタを確立し、中間層のクラスとアプリケーションプログラムのクラスとの間で前記クラスポインタを伝送することによりプログラムの動的リンキングを実現するため、アプリケーションプログラムからコンパイルされたファイルをメモリにロードする際に、このファイルから情報を抽出してメモリにおける各コンパイルコードの位置を改めて算出する必要がない。従って、プログラムの動的リンキングを実現するのに必要な時間を減らし、プログラムの動的リンキングの速度を向上させる。

従来技術でＥＬＦ方式を採用してプログラムの動的リンキングを実現することを示す図である。 本発明に係る組み込みプラットフォームの構成図である。 図２に示す組み込みプラットフォームにおけるアプリケーションプログラムの動的リンキングを示す図である。 本発明に係る中間層とアプリケーションプログラムとの間のやりとりを示す図である。 インスタントメッセンジャー（ＩＭ）を核心とする動的アプリケーションプログラムの開発環境を示す図である。

本発明の目的、解決手段とメリットをさらに明確にするために、以下、図面および実施形態を参照して、本発明をさらに詳しく説明する。

図２は本発明に係る組み込みプラットフォームの構成図である。図２に示すように、この組み込みプラットフォームは中間層を含む。

本発明では、組み込みオペレーティングシステムからクラス中間層をカプセル化し、当該中間層はクラスからなり、各クラスは１つの仮想関数テーブルに対応され、仮想関数テーブルの各要素はオペレーティングシステムの各関数インターフェースに対応される。

組み込みオペレーティングシステムから中間層をカプセル化する際に、オペレーティングシステムの全ての関数のうち、アプリケーションプログラムがよく使う関数インターフェースを中間層にカプセル化することができ、ここで、機能が関連の関数のインターフェースを１つのクラスにカプセル化する。例えば、描画関数のインターフェース、文字編集関数のインターフェース、ネットワーク接続関数のインターフェース、および情報送信関数のインターフェースを中間層にカプセル化し、描画関数のインターフェースと文字編集関数のインターフェースを１つのドキュメント処理クラスにカプセル化し、ネットワーク接続関数のインターフェースと情報送信関数のインターフェースとを１つのネットワーククラスにカプセル化する。各クラスが１つのコンポーネントに相当するため、実際に、中間層は複数のコンポーネントからなるものに相当する。

図３は図２に示す組み込みプラットフォームにおいてアプリケーションプログラムの動的リンキングを示す図である。

図３に示すように、本発明に係るプログラムの動的リンキング過程は、ＢＩＮファイルへのコンパイルと生成段階、ＢＩＮファイルのダウンロードと記憶段階、ＢＩＮファイルのロード段階、及びプログラムの動的リンキング段階を含む。

本発明では、図２に示すオペレーティングシステムにおいて動的リンキングを実現するアプリケーションプログラムも１つまたは複数のクラスからなり、各クラスがこのアプリケーションプログラムの複数の関数インターフェースをカプセル化して得られ、各クラスが１つの仮想関数テーブルに対応され、各仮想関数テーブルの各要素がそれぞれ前記アプリケーションプログラムの複数の関数インターフェースに一々対応される。中間層のクラスの構成方式と同じように、アプリケーションプログラムのクラス内の各インターフェースに対応する関数も互いに関連の関数である。アプリケーションプログラムにおいて、各クラスも１つのコンポーネントに相当する。従って、クラスを通じてアプリケーションプログラムを実現するのは、実際にアプリケーションプログラムを複数のコンポーネントに分けることに相当する。

説明すべきところとして、組み込みプラットフォームにおいてプログラムの動的リンキングを実現しようとする場合は、以下の関数インポート問題、関数エクスポート問題、サブ関数コール問題、およびグローバル変数位置決め問題のような４つの問題を解決する必要がある。

関数インポート問題とは、動的リンキングが必要なアプリケーションプログラムが如何に中間層を通じて組み込みオペレーティングシステムの関数をコールするかを指すものであり、関数エクスポート問題とは、組み込みオペレーティングシステムが如何に中間層を通じてアプリケーションプログラムの関数をコールするかを指すものであり、サブ関数コール問題とは、アプリケーションプログラム内のサブ関数が如何にアプリケーションプログラムまたは中間層を通じてコールされるかを指すものであり、グローバル変数位置決め問題とは、アプリケーションプログラムにグローバル変数が含まれる場合、アプリケーションプログラムを組み込みプラットフォームにリンキングした後に、前記組み込みプラットフォームにおいて当該アプリケーションプログラムにおけるグローバル変数のリロケーションを如何に実現するかを指すものである。

関数インポート問題および関数エクスポート問題は主にＢＩＮファイルへのコンパイルと生成段階およびプログラムの動的リンキング段階に関し、サブ関数コール問題およびグローバル変数位置決め問題は主にＢＩＮファイルへのコンパイルと生成段階に関する。

以下、図３に示す４つの段階を順に、ＡＲＭ組み込みオペレーティングプラットフォームの特性に応じて、図２に示す組み込みプラットフォームにおいてプログラムの動的リンキングを実現する方法を説明する。

一、ＢＩＮファイルへのコンパイルと生成段階
まず、アプリケーションプログラムの開発者はクラスの形式でアプリケーションプログラムを書く必要があり、アプリケーションプログラムがクラスからなり、各クラスがこのアプリケーションプログラムの１つまたは複数の関数インターフェースをカプセル化して得られ、各クラスが１つの仮想関数テーブルに対応され、各仮想関数テーブルの各要素がそれぞれ異なる関数インターフェースに対応されることを保証する必要がある。即ち、アプリケーションプログラムを複数のコンポーネントに分け、各コンポーネントを１つのクラスに書くことに相当する。

その後、アプリケーションプログラムをＢＩＮファイル形式の位置独立のコード（ＰＩＣ：Ｐｏｓｉｔｉｏｎ Ｉｎｄｅｐｅｎｄｅｎｃｅ Ｃｏｄｅ）にコンパイルする。ここで、位置独立のコードとは、その運用が具体的な記憶位置に依存せずに、任意の記憶空間内に運用できるコードを指すものである。

具体的に、ＡＲＭ ＡＤＳ１．２コンパイラを採用してアプリケーションプログラムをコンパイルする際に、コンパイルオプションａｃｐｓ／ｒｏｐｉを通じてアプリケーションプログラムのコードセグメントを位置独立のコード（ＰＩＣ：Ｐｏｓｉｔｉｏｎ Ｉｎｄｅｐｅｎｄｅｎｃｅ Ｃｏｄｅ）セグメントにコンパイルし生成することができ、ここで、ｒｏｐｉオプションの役割はコンパイルされたリードオンリーセグメントの位置が独立であることを指示する。

アプリケーションプログラムを位置独立のコードにコンパイルするため、ＢＩＮファイルのロード段階で、ＢＩＮファイルを組み込みプラットフォームのメモリの任意の記憶位置にロードして運用することができる。

アプリケーションプログラムを複数のコンポーネントに分け、中間層も複数のコンポーネントによって実現されるため、アプリケーションプログラムおよび中間層はコンポーネント間のやりとりにより、言い換えればクラスにより、関数のインポートおよびエクスポートを実現することができる。アプリケーションおよび中間層が如何にクラスにより関数のインポートおよびエクスポートを実現するかについては、プログラムの動的リンキング段階で詳しく説明する。

サブ関数コール問題に対して、本発明ではＢＩＮファイルへのコンパイルと生成段階で、このアプリケーション内の各関数を互いに位置独立、かつ互いに交差しないコードセグメントにコンパイルすることにより、各関数が互いに独立して運用するようにすることができ、従って、各異なる関数を便利にコールするが、ほかの関数に影響を与えないようになる。

具体的に、ＡＲＭ ＡＤＳ１．２コンパイラを採用してアプリケーションプログラムをコンパイルする際に、ＺＯコンパイルオプションによりこのアプリケーションプログラム内の各関数を互いに位置独立、かつ互いに交差しないコードセグメントにコンパイルすることができる。

例えば、仮に以下のようなアプリケーションプログラムがある。
ｉｎｔ ａｐｐＭａｉｎ（Ｉｓｈｅｌｌ＊ｐｔｒ，ｖｏｉｄ＊＊ｐｐｏｂｊ）
｛
ｆｕｎ１（）；
ｒｅｔｕｒｎ ０；
｝
ｖｏｉｄ ｆｕｎ１（ｖｏｉｄ）
｛
｝

仮にａｐｐＭａｉｎ関数がずっとＢＩＮファイルの開始アドレス ０ｘ００００００００のところにコンパイルされ、ａｃｐｓ／ｒｏｐｉとＺＯコンパイルオプションを採用してこのアプリケーションプログラムをコンパイルするとする場合、コンパイル結果は表１に示すようである。

表１において、ＰＣはＢＩＮファイルの開始アドレスであり、０ｘ０Ａは関数ｆｕｎ１のオフセットアドレスを代表する。

表１からわかるように、アプリケーションプログラムを位置独立、かつ各関数が互いに独立して交差しないコードセグメントにコンパイルした後、各関数間のジャンプは相対的なジャンプであり、具体的にどこにジャンプするかはオフセットアドレスによって決定される。このようにして、アプリケーションプログラム内の各関数がいずれもこのアプリケーションプログラム内部の関数またはこのアプリケーションプログラム外部の関数により独立にコールされることができるようになる。

グローバル変数位置決め問題については、２つの処理方式を採用することができる。その１はグローバル変数をアプリケーションプログラムの構造体に置き、従って構造体が位置独立のコードセグメントにコンパイルされる場合、構造体内のグローバル変数もこの位置独立のコードセグメントにコンパイルされる。その２はグローバル変数を位置独立のデータ（ＰＩＤ：Ｐｏｓｉｔｉｏｎ Ｉｎｄｅｐｅｎｄｅｎｃｅ Ｄａｔａ）セグメントにコンパイルする。上記１の処理方式を採用する場合は、複数のアプリケーションプログラムを同時に図２に示す組み込みプラットフォーム上にロードすることができるが、グローバル変数がアプリケーションプログラムの構造体に記憶されているため、グローバル変数を使用する場合に、相応の構造体から前記グローバル変数を取る必要があって、操作が比較的複雑である。上記２の処理方式を採用する場合は、グローバル変数が位置独立のデータセグメントにコンパイルされるため、グローバル変数を構造体以外の位置に格納することができ、通常、グローバル変数をコードセグメント所在のランダムアクセスメモリ（ＲＡＭ）記憶空間の後の記憶空間内に記憶して、データのオーバーフローアクセスを避ける。

ＡＲＭ ＡＤＳ１．２コンパイラを採用してアプリケーションプログラムをコンパイルする際に、コンパイルオプションａｃｐｓ／ｒＷｐｉによりアプリケーションプログラムのデータセグメントを位置独立のデータ（ＰＩＤ：Ｐｏｓｉｔｉｏｎ Ｉｎｄｅｐｅｎｄｅｎｃｅ Ｄａｔａ）セグメントにコンパイルし生成することができ、位置独立のデータセグメントとは、ＲＡＭの任意の記憶空間内にコピーして運用できるデータセグメントを指すものである。コンパイルオプションａｃｐｓ／ｒＷｐｉはアプリケーションプログラムのデータセグメントを位置独立のデータセグメントにコンパイルし、このデータセグメントは（［Ｒ９］＋ＯＦＦＳＥＴ）の記憶空間内に記憶され、ここで、［Ｒ９］はレジスタＲ９の値を表し、ＯＦＦＳＥＴはオフセットアドレスの値である。データのオーバーフローアクセスを防止するために、レジスタＲ９の値をメモリバッファ（ＢＵＦＦＥＲ）の開始アドレスとＢＩＮファイル大きさとの和の値に設定、即ち、グローバル変数を、アプリケーションプログラムをコンパイルして得られたＢＩＮファイルの後に記憶するようにしてよい。

グローバル変数を位置独立のデータセグメントにコンパイルする際に、レジスタＲ９を使用する必要があるため、上記２のグローバル変数位置決め方法を採用する場合、各アプリケーションプログラムのシングルロードしか実現できず、即ち、複数のアプリケーションプログラムの同時ロードは実現できない。

また、ＢＩＮファイルへのコンパイルと生成段階で、アプリケーションプログラムのメイン関数、即ち、アプリケーションプログラムの関数入口をＢＩＮファイルの開始アドレスのところにコンパイルして、今後、プログラムの動的リンキング時にアプリケーションプログラムの各コンポーネントに位置決めできることを保証する必要がある。具体的に、アプリケーションプログラムをコンパイルする過程中に、アプリケーションプログラムの入口関数を−ｆｉｒｓｔに設定しさえすればいい。

ＡＲＭ ＡＤＳ１．２コンパイラを採用してアプリケーションプログラムをコンパイルする際に、ｔｈｕｍｂモードを採用してアプリケーションプログラムをＢＩＮファイルにコンパイルするようにしてよい。ｔｈｕｍｂモードを採用してコンパイルされたコードの関数アドレスは通常ａｒｍモードを応用してコンパイルされたコードの関数アドレスよりそのアドレスが後ろに３２ビットオフセット（即ち４バイトオフセット）する。組み込みオペレーティングシステムが初回に中間層を通じてアプリケーションプログラムをコールする時、アプリケーションプログラムの入口関数ポインタをアプリケーションプログラムＢＩＮ所在のメモリバッファ領域の開始アドレスが４バイトオフセットした位置に指向してアプリケーションプログラムを実行する。例えば、ＢＩＮファイルの開始アドレスが０ｘ８０００であると、確立された入口関数ポインタは０ｘ８００４ところに指向すべきである。

ｔｈｕｍｂモードを採用してアプリケーションプログラムをコンパイルする場合、アプリケーションプログラム内の各指令が２バイト（ａｒｍモードを採用してコンパイルする場合に、各指令は４バイト）にコンパイルされるため、コンパイルされたＢＩＮファイルの大きさを減らすと共に、アプリケーションプログラム運用の速度も向上させ、消費電力を節約することができる。

上記のように、ＢＩＮファイルへのコンパイルと生成段階で、アプリケーションプログラムをＢＩＮファイルにコンパイルし、このアプリケーションの入口関数がＢＩＮファイルの開始アドレスのところに位置し、このアプリケーションプログラムを位置独立のコードセグメントにコンパイルし、かつこのアプリケーションプログラムの異なる関数からコンパイルされたコードセグメントの間の記憶空間が交差しなく、アプリケーションプログラム内のグローバル変数を位置独立のデータセグメントにコンパイルし、または、グローバル変数をアプリケーションプログラムの構造体に格納する。

二、ＢＩＮファイルのダウンロードと記憶段階
ＢＩＮファイルのダウンロードと記憶段階で、これらのＢＩＮファイルを直接にファイルシステムにコピーする。

三、ＢＩＮファイルのロード段階
ＢＩＮファイルをロードする必要がある場合は、ＢＩＮファイルを解析したり、ＢＩＮファイル内の情報を利用して算出したりする必要がなくて、このＢＩＮファイルを直接にファイルシステムからメモリにコピーする。

四、プログラムの動的リンキング段階
プログラムの動的リンキング段階で、実際のクラスポインタを確立し、中間層のクラスとアプリケーションプログラムのクラスとの間にクラスポインタを伝送することにより、関数のインポートおよびエクスポートを実現する。

関数インポート問題に対して、アプリケーションプログラムは中間層のクラスのポインタを確立することにより、確立されたクラスポインタが組み込みオペレーティングシステムの関数所在の中間層クラスに指向するようにし、この中間層クラスに対応する仮想関数テーブルの相応要素により相応の関数を実例化することにより、組み込みオペレーティングシステムの関数をコールする。

例えば、仮に中間層に１つのＩＦａｓｔＳｔｒｉｎｇクラスが含まれ、このＩＦａｓｔＳｔｒｉｎｇクラスに仮想関数テーブルポインタｐｖｔが含まれ、この仮想関数テーブルに３つのサブ関数ＩＦａｓｔＳｔｒｉｎｇ＿Ｒｅａｌａｓｅ、ＩＦａｓｔｒｉｎｇＳｔｒｉｎｇ＿ＧｅｔＬｅｎｇｔｈおよびＩｆａｓｔＳｔｒｉｎｇ＿Ｆｉｎｄが含まれるとする。

表２はＩＦａｓｔＳｔｒｉｎｇクラスの構成を示す表である。

アプリケーションプログラムはＩＦａｓｔＳｔｒｉｎｇクラスの関数をコールする際に、ＩＦａｓｔＳｔｒｉｎｇクラスポインタを確立し、このポインタにより指向された仮想関数テーブルの３つのメンバーＩＦａｓｔＳｔｒｉｎｇ＿Ｒｅａｌａｓｅ、ＩＦａｓｔｒｉｎｇＳｔｒｉｎｇ＿ＧｅｔＬｅｎｇｔｈ、およびＩｆａｓｔＳｔｒｉｎｇ＿Ｆｉｎｄに実際の関数アドレスを付与する。このようにして、アプリケーションプログラムは組み込みオペレーティングシステムにおけるＩＦａｓｔＳｔｒｉｎｇ＿Ｒｅａｌａｓｅ、ＩＦａｓｔｒｉｎｇＳｔｒｉｎｇ＿ＧｅｔＬｅｎｇｔｈ、およびＩｆａｓｔＳｔｒｉｎｇ＿Ｆｉｎｄの３つの関数に位置決めできるようになる。

そのため、アプリケーションプログラムは組み込みオペレーティングシステムの関数をコールする際に、管理クラス（例えばＳｈｅｌｌクラス）を通じて中間層におけるそれぞれ異なるクラスポインタを確立し、クラスの識別子（ＩＤ）に基づいて相応のクラスを確立しかつこのクラス内の仮想関数テーブルにおける各要素に対応するインターフェース関数を実例化する。アプリケーションプログラムは確立されたクラスポインタを使用して、このポインタにより指向された仮想関数テーブルにおける相応のインターフェースの関数に位置決める。ここで、中間層のクラスＩＤは中間層を書く時に決定されたものであり、アプリケーションプログラムは中間層のクラスをコールする際に、コール対象のクラスのＩＤを管理クラスに伝送し、管理クラスはこのＩＤに基づいて相応のクラスポインタを確立しアプリケーションプログラムに返信する。

従って、アプリケーションプログラムの入口関数は下記の形式を採用してよい。
ｉｎｔ ａｐｐＭａｉｎ（Ｓｈｅｌｌ＊ｐｔｒ，ｖｏｉｄ＊＊ｐｐｏｂｊ）
｛
ｒｅｔｕｒｎ ０；
｝

アプリケーションプログラムはクラスポインタおよび仮想関数テーブルの各要素に対応する関数インターフェースＩＤを確立することにより、このクラスポインタを仮想関数テーブルに指向し、前記関数インターフェースＩＤを通じて仮想関数テーブルにおける相応の関数インターフェースに対応する関数をコールする。

関数エクスポート問題に対しては、アプリケーションプログラムもクラスの形式を採用して書かれたため、即ち、アプリケーションプログラムがクラスからなり、各クラスが１つの仮想関数テーブルに対応され、この仮想関数テーブルの各要素が各関数インターフェースに対応されるため、アプリケーションプログラムはこのアプリケーションプログラム自身のクラスポインタを確立することにより、このクラス内の仮想関数テーブルの各要素を実例化した後に中間層に伝送して保存し、中間層はアプリケーションプログラムの関数をコールする必要がある場合に、中間層に保存されているアプリケーションプログラムのクラスの相応の関数インターフェースをコールさえすればいい。このように、関数エクスポートの過程が完成される。

関数インポート過程に対して、アプリケーションプログラムは管理クラスを通じてクラスポインタを確立し、中間層のクラスに指向する。関数エクスポート過程に対しては、アプリケーションプログラムを書くときにアプリケーションプログラムの各クラスを実例化したため、アプリケーションプログラムからコンパイルされたＢＩＮファイルを中間層にロードする（即ちＢＩＮファイルのロード）ことは、アプリケーションプログラムが既に実例化したクラスを直接に中間層にコピーすることに相当し、組み込みオペレーティングシステムがアプリケーションプログラムのクラスをコールしようとする場合は、即ち、関数のエクスポートを実現しようとする場合は、中間層にコピーされたアプリケーションプログラムクラスを直接にコールさえすればいい。

上記のように、本発明では組み込みオペレーティングシステムから中間層をカプセル化し、クラスを利用してアプリケーションプログラムを複数のコンポーネントに分けることにより、中間層とアプリケーションプログラムとの間がコンポーネントによりやりとりを実現できるようになり、具体的には、図４を参照する。

図４は本発明に係る中間層とアプリケーションプログラムとの間のやりとりを示す図である。

図４において、アプリケーションプログラムが中間層を通じて組み込みオペレーティングシステムをコールする必要がある場合、アプリケーションプログラムはクラスポインタを確立することにより中間層における相応のクラスに指向し、コンポーネントのやりとりを実現する。中間層がアプリケーションプログラムをコールする必要がある場合、中間層は既に保存されているアプリケーションプログラムクラスポインタにより相応のアプリケーションプログラムをコールし、このアプリケーションプログラムクラスポインタはアプリケーションプログラム自身が確立して中間層に保存したものである。

オペレーティングシステムから中間層をカプセル化した後、中間層とアプリケーションプログラムがクラスを通じて中間層とアプリケーションプログラムにおける各コンポーネントのやりとりを実現できるため、相応のアプリケーションプログラムは中間層で開発することができる。

図５はインスタントメッセンジャー（ＩＭ）を核心とする動的アプリケーションプログラムの開発環境を示す図である。

図５に示すように、この開発環境は組み込みオペレーティングシステムと、動的アプリケーションプログラム中間層プラットフォーム（ＳＤＫ）と、動的アプリケーションプログラムとを含む。ここでＳＤＫは即ち前述の組み込みオペレーティングシステムからカプセル化された中間層であり、動的アプリケーションプログラムは即ち前述のクラス形式で書かれたアプリケーションプログラムである。

図５の動的アプリケーションプログラムは、基礎のＩＭ機能を実現できるコンポーネントＡと、ＩＭゲームを実現するコンポーネントＢと、ＩＭペット機能を実現するコンポーネントＣと、ＩＭビデオ機能を実現するコンポーネントＤと、ＩＭ音楽機能を実現するコンポーネントＥと、拡張応用のためのコンポーネントＦおよびコンポーネントＧとを含む。コンポーネントＡ、コンポーネントＦおよびコンポーネントＧはクラスを通じて中間層とやりとりし、コンポーネントＢからコンポーネントＥまではコンポーネントＡがロードされた上でロードして運用し、つまり、複数のコンポーネントを同時に運用する場合であり、コンポーネントＢからコンポーネントＥまではそのクラスを通じてコンポーネントＡのクラスと通信して、アプリケーションプログラムのプラグイン化の過程を実現することができる。

図５において、コンパイルの際に、ＳＤＫと組み込みオペレーティングシステムとを同時にコンパイルしチップにダウンロードするが、動的アプリケーションプログラムに対しては、クラス形式で具体的なアプリケーション機能を実現できる動的アプリケーションプログラムを書き、また図３に示す方法を採用して動的アプリケーションプログラムを単独にコンパイルした後に、チップにおけるファイルシステムにダウンロードし、アプリケーションプログラムをロードする必要がある場合にそれを直接に組み込みオペレーティングシステムのメモリにコピーし、最後にＳＤＫと動的アプリケーションプログラムとがクラスを通じてやりとりを行う。

上記の解決手段からわかるように、アプリケーションプログラムをＢＩＮファイルにコンパイルしてダウンロードした後、アプリケーションプログラムを運用する必要がある場合は、それを直接にメモリにコピーする必要だけであり、後続の関数インポートおよびエクスポート問題は中間層とアプリケーションとが実際のクラスポインタを確立し、相互間にクラスポインタを伝送することにより自動的に実現され、ＢＩＮファイルに対して解析または算出を行う必要がないため、プログラムの動的リンキングの速度を向上させる。

また、同一のアプリケーションプログラムをＥＬＦファイルにコンパイルすることに比べて、ＢＩＮファイルにコンパイルする場合は、コンパイルされたＢＩＮファイルの占める記憶空間がＥＬＦファイルの占める記憶空間の３分の１であるため、アプリケーションプログラムをＢＩＮファイルにコンパイルすることによってはメモリ空間も節約することができる。

なお、中間層とアプリケーションプログラムとの間はクラスを通じてやりとりを実現し、このようなやりとりがコンポーネントレベルに属するため、アプリケーションプログラムのコンポーネント化のアップデート、および中間層のコンポーネント式のアップデート、または両者の同期のアップデートに有利し、さらには中間層またはアプリケーションプログラムの既存コンポーネントを有効に利用して新しいアプリケーションを構築して、アプリケーションプログラムのプラグイン化を実現することができる。合理なアプリケーション層プラットフォームを構築することによっては、アプリケーションプログラムの開発を簡略化することもできる。これは非スマートフォオペレーティングシステムのアプリケーションプログラムの開発に非常に有益である。

上記は、本発明の好ましい実施例にすぎず、本発明の保護範囲を限定するものではない。本発明の精神と原則内で行われる種々の修正、均等置換え、改善などは全て本発明の保護範囲内に含まれるべきである。

Claims (8)

1. 組み込みプラットフォームにおけるプログラムの動的リンキング方法であって、前記組み込みプラットフォームが中間層を含み、前記中間層が１つ以上のクラスを含み、各クラスが組み込みオペレーティングシステムの１つ以上の関数インターフェースをカプセル化して得られたものであり、各クラスが１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素が前記１つ以上の関数インターフェースに一々対応され、リンキング対象のアプリケーションプログラムが１つ以上のクラスを含み、各クラスが当該アプリケーションプログラムの１つ以上の関数インターフェースをカプセル化して得られたものであり、各クラスが１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素がそれぞれ前記アプリケーションプログラムの１つ以上の関数インターフェースに一々対応され、当該方法が、
   前記アプリケーションプログラムを位置独立のコードセグメントにコンパイルし、かつ当該アプリケーションプログラムの異なる関数をコンパイルして得られたコードセグメントの記憶位置が互いに相交しなく、コンパイルして得られた全てのコードセグメントを組み込みオペレーティングシステムのメモリにコピーし、
   クラスポインタを確立し、中間層のクラスと前記アプリケーションプログラムのクラスとの間でクラスポインタを伝送することにより、プログラムの動的リンキングを実現する、
   ことを含み、
   前記クラスポインタを確立し、中間層のクラスと前記アプリケーションプログラムのクラスとの間でクラスポインタを伝送することが、
   前記アプリケーションプログラムが組み込みオペレーティングシステムの関数をコールする場合、アプリケーションプログラムが管理クラスを通じて中間層のクラスポインタを確立し、当該ポインタが中間層のクラスに指向し、当該クラスポインタをアプリケーションプログラムのクラスに伝送し、
   アプリケーションプログラムが前記アプリケーションプログラム自身のクラスポインタを確立することにより、前記クラス内の仮想関数テーブルの各要素を実例化した後に中間層に伝送して保存し、中間層がアプリケーションプログラムの関数をコールする必要がある場合に、中間層に保存されているアプリケーションプログラムのクラスの相応の関数インターフェースをコールする、
   ことを含むことを特徴とする方法。
2. 前記アプリケーションプログラムがグローバル変数を含み、当該方法が、
   前記アプリケーションプログラム内のグローバル変数を位置独立のデータセグメントにコンパイルし、前記データセグメントを前記位置独立のコードセグメントの後ろに記憶して、プログラムの動的リンキング過程中のグローバル変数のリロケーションを実現する、
   ことをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記アプリケーションプログラムがグローバル変数と、構造体とを含み、前記方法が、
   前記アプリケーションプログラム内のグローバル変数を当該アプリケーションプログラムの構造体に記憶することを含み、
   前記位置独立のコードセグメントにコンパイルすることが、前記構造体を位置独立のコードセグメントにコンパイルする、
   ことを含むことを特徴とする請求項１に記載の方法。
4. 前記アプリケーションプログラムを位置独立のコードセグメントにコンパイルし、かつ前記アプリケーションプログラムの異なる関数をコンパイルして得られたコードセグメントの記憶位置が互いに相交しないことが、
   組み込みオペレーティングシステムＡＲＭ ＡＤＳ１．２コンパイラ内のコンパイルオプションＡＣＰＳ／ＲＯＰＩおよびＺＯを採用して前記アプリケーションプログラムをコンパイルする、
   ことを含むことを特徴とする請求項１に記載の方法。
5. 前記アプリケーションプログラム内のグローバル変数を位置独立のデータセグメントにコンパイルすることが、
   組み込みオペレーティングシステムＡＲＭ ＡＤＳ１．２コンパイラ内のコンパイルオプションＡＣＰＳ／ＲＷＰＩを採用して前記アプリケーションプログラムをコンパイルする、
   ことを含むことを特徴とする請求項２に記載の方法。
6. 前記位置独立のコードセグメントが２値化ＢＩＮファイルであることを特徴とする請求項１に記載の方法。
7. 前記コンパイルが、
   ｔｈｕｍｂモードを採用してアプリケーションプログラムをコンパイルすることを含み、
   前記クラスポインタを確立し、中間層のクラスと前記アプリケーションプログラムのクラスとの間でクラスポインタを伝送することにより、プログラムの動的リンキングを実現することが、
   組み込みオペレーティングシステムが初回に中間層を通じてアプリケーションプログラムをコールする時、アプリケーションプログラムのＢＩＮファイル所在のメモリバッファ領域の開始アドレスから４バイトシフトすることによって得られる位置を指すアプリケーションプログラムの入口関数ポインタを確立して、入口関数を実行する、
   ことを含むことを特徴とする請求項６に記載の方法。
8. 組み込みプラットフォームであって、中間層を含み、
   前記中間層が１つ以上のクラスを含み、各クラスが組み込みオペレーティングシステムの１つ以上の関数インターフェースをカプセル化して得られたものであり、各クラスが１つの仮想関数テーブルに対応され、当該仮想関数テーブルの各要素が前記１つ以上の関数インターフェースに一々対応され、
   前記中間層が請求項１〜７のいずれか１項に記載の方法を実行できるように構成される、
   ことを特徴とする組み込みプラットフォーム。