(57)【要約】  再構築又は再ローディングを必要とせずに、選択されたハードウェアアーキテクチャーを有する異種のコンピューティング環境で動作できるプラットホーム独立のバイナリオブジェクト（ＰＩＢＯ）を提供する。このＰＩＢＯは、協働するアプリケーションと共にコンパイルされ構築される例示的リンカー／ローダによって、協働するコンピューティングアプリケーションと共にロードしリンクすることができる。また、ＰＩＢＯは、次のものを含む（それらに限定されないが）種々の状況に使用することができ、即ち、ネイティブなファシリティを与えないプラットホームにおいて共有オブジェクトを動的にリンクするためのメカニズムとして使用でき、予め書かれたコードコンポーネントを、それがなければ、特定コード内のプラットホーム制約の違反のために不適合となるであろうプラットホームに利用する際に使用でき、コードに固有の多数の実行インスタンス及び繰り返し実行の制約を回避する非オブジェクト指向コードをロードするためのメカニズムとして使用でき、更に、閉じたプラットホームに機能をアドオンするためにバイナリオブジェクトの使用を可能とするメカニズムとして使用できる。【選択図】  図７Ａ
2008516324.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング環境内で動作するソフトウェアプラットホーム上でバイナリオブジェクトファイルを動的にロードしてリンクするためのシステムにおいて、
ダイナミックライブラリ（ＤＬ）と、
協働するコンピューティングアプリケーションと共にコンパイルされ構築されるダイナミックリンカー／ローダであって、前記ソフトウェアプラットホーム上で実行するバイナリ実行可能プログラムを生成する、該ダイナミックリンカー／ローダと、
を備え、
前記ダイナミックリンカー／ローダが、前記ＤＬをオープンする第１の関数と、前記ＤＬによってエクスポートされたシンボルのメモリにおけるアドレスを返す第２の関数とを有することによって、前記コンピューティングアプリケーションがランタイムに前記ＤＬにアクセスして、該ＤＬと協働することを可能にする、
システム。
【請求項２】
前記ＤＬは、選択された構造を有するバイナリオブジェクトファイルを含む、請求項１に記載のシステム。
【請求項３】
前記ＤＬの選択された構造は、実行可能リンキングフォーマット（ＥＬＦ）、及びポータブル実行可能（ＰＥ）フォーマットの何れかを含む、請求項２に記載のシステム。
【請求項４】
前記ダイナミックリンカー／ローダは、前記ＤＬをオープンする前記第１の関数を実行するための前記協働するコンピューティングアプリケーション内の命令に応答して、ランタイムに前記ソフトウェアプラットホームに前記ＤＬをロードするよう、前記ＤＬに対して動作する、請求項２に記載のシステム。
【請求項５】
前記ダイナミックリンカー／ローダは、前記ＤＬオブジェクトファイルのサイズを決定する、請求項４に記載のシステム。
【請求項６】
前記ダイナミックリンカー／ローダは、前記ソフトウェアプラットホームにＤＬオブジェクトをロードするためにメモリを割り当てる、請求項５に記載のシステム。
【請求項７】
前記ダイナミックリンカー／ローダは、前記ＤＬ上で動作し、前記ＤＬをランタイムに前記協働するコンピューティングアプリケーションにリンクする、請求項４に記載のシステム。
【請求項８】
前記第２の関数を実行するために、前記第１の関数によってオープンされた前記ＤＬからエクスポートされるシンボルのアドレスが、前記協働するコンピューティングアプリケーション内の命令に応答して返される、請求項４に記載のシステム。
【請求項９】
単一のバイナリオブジェクトファイルが、該バイナリオブジェクトファイルの再コンパイル又は再構築を必要とせずに、定義されたプロセッサアーキテクチャーにおいて実行される複数のソフトウェアプラットホーム及びオペレーティングシステムにわたって動的にロードされリンクされる、請求項２に記載のシステム。
【請求項１０】
前記ＤＬと協働するコンピューティングアプリケーションのソースコードと、前記ダイナミックリンカー／ローダのソースコードが、前記複数のソフトウェアプラットホームのうちの選択された一つのソフトウェアプラットホーム用のバイナリ実行可能プログラムへとコンパイルされリンクされる、請求項９に記載のシステム。
【請求項１１】
前記ＤＬは、該ＤＬのバイナリフォーマットをネイティブにサポートしないオペレーティングシステムで動作されるコンピューティング環境のコンピューティングアプリケーションへ動的にロードされリンクされる、請求項４又は７に記載のシステム。
【請求項１２】
前記ＤＬは、バイナリオブジェクトのダイナミックリンキングを実行するためのネイティブなダイナミックリンキングメカニズムをもたないオペレーティングシステムで動作される制約のあるコンピューティング環境におけるコンピューティングアプリケーションへ動的にロードされリンクされる、請求項１に記載のシステム。
【請求項１３】
前記協働するコンピューティングアプリケーションにＤＬへのアクセスを提供するインターフェイスモジュールを更に備える、請求項２に記載のシステム。
【請求項１４】
前記インターフェイスモジュールは、前記ＤＬが前記協働するコンピューティングアプリケーションにおける選択された関数をコールすることを可能にするソースコードを備える、請求項１３に記載のシステム。
【請求項１５】
前記インターフェイスモジュールのソースコードは、前記協働するコンピューティングアプリケーションのアプリケーションプログラミングインターフェイスを解析することによって生成される、請求項１４に記載のシステム。
【請求項１６】
前記インターフェイスモジュールのソースコードは、前記ＤＬのバイナリオブジェクトファイルを解析して該ＤＬによってインポートされたシンボルを特定することによって、生成される、請求項１４に記載のシステム。
【請求項１７】
前記インターフェイスモジュールのソースコード、前記協働するコンピューティングアプリケーションのソースコード、及び前記ダイナミックリンカー／ローダのソースコードは、前記ソフトウェアプラットホーム用にコンパイルされる、請求項１４に記載のシステム。
【請求項１８】
前記ダイナミックリンカー／ローダは、前記協働するコンピューティングアプリケーション及び前記ＤＬを前記ソフトウェアプラットホーム上の動作可能なプロセスへと結合するために、シンボル解決及び再配置を取り扱う、請求項７に記載のシステム。
【請求項１９】
前記動作可能なプロセスは、複数のダイナミックライブラリと協働し、且つ、該複数のダイナミックライブラリに結合されたコンピューティングアプリケーションを含む、請求項１８に記載のシステム。
【請求項２０】
前記ダイナミックリンカー／ローダは、前記ファイルを前記協働するコンピューティングアプリケーションにリンクするときに、ＤＬファイルと非ＤＬファイルとを区別する、請求項１８に記載のシステム。
【請求項２１】
前記動作可能なプロセスは、前記協働するコンピューティングアプリケーションを、前記ＤＬにリンクし、前記ソフトウェアプラットホーム用のネイティブなダイナミックリンクライブラリにリンクする、請求項２０に記載のシステム。
【請求項２２】
ライブラリソースコードをコンパイルして、バイナリコード及び／又はデータを含む前記ＤＬを生成する、請求項１に記載のシステム。
【請求項２３】
前記ＤＬは、前記ソフトウェアプラットホーム上で実行されるバイナリ実行可能プログラムに動的にロードされリンクされ、前記ライブラリソースコードは、前記ソフトウェアプラットホームのプログラミング制約に違反するコードを含む、請求項２２に記載のシステム。
【請求項２４】
前記プログラミング制約は、グローバル変数の使用に関する制約、又は書き込み可能なスタティック変数の使用に関する制約、又はポインタ変数の静的初期化に関する制約を含む、請求項２３に記載のシステム。
【請求項２５】
前記ダイナミックリンカー／ローダは、前記ＤＬがリンクされるプログラムの実行中に前記ソフトウェアプラットホームに前記ＤＬオブジェクトをロードするために、メモリブロックを割り当てる、請求項２４に記載のシステム。
【請求項２６】
前記ダイナミックリンカー／ローダは、前記ライブラリにおいて定義されたグローバル変数又は書き込み可能なスタティック変数の領域を、前記ＤＬによって占有されるメモリブロックに制限するように動作する、請求項２５に記載のシステム。
【請求項２７】
前記ライブラリソースコードは、該コードの多数の実行インスタンス又は繰り返し実行を制約するようにデータを取り扱い且つデータへの関数を提供するためのコードを含み、
前記ダイナミックリンカー／ローダは、前記ライブラリのインスタンスを、動的に割り当てられたメモリブロックにロードし、
前記ライブラリコードにおいて定義された前記データの変数の領域が前記メモリブロックに制限される、請求項１７に記載のシステム。
【請求項２８】
同じライブラリの多数の非衝突インスタンスが、前記コンピューティング環境において実行可能である、請求項２７に記載のシステム。
【請求項２９】
前記ＤＬにより使用されるデータは、前記コード内に定義されたグローバル変数又はスタティック変数を用いて参照される、請求項２７に記載のシステム。
【請求項３０】
非オブジェクト指向のコードをロードして、単一のコンピューティング環境のプロセス内で多数の実行インスタンスを許容する、請求項２７に記載のシステム。
【請求項３１】
ライブラリデータセットの各々の間で衝突が軽減され及び／又は除去されるように、ライブラリデータの多数のセットが単一のコンピューティング環境のプロセス内で同時に動作する、請求項３０に記載のシステム。
【請求項３２】
非オブジェクト指向のコードをロードして、単一のコンピューティング環境のプロセス内でコードの繰り返し実行を可能にする、請求項２７に記載のシステム。
【請求項３３】
多数のプロセスをサポートしないコンピューティング環境においてコードの多数の実行インスタンス及び繰り返し実行を可能にするためのコードをロードする、請求項２７に記載のシステム。
【請求項３４】
前記コンピューティング環境は、非常駐の実行可能プログラムを前記コンピューティング環境に配備することに関して制限されており、
前記協働するコンピューティングアプリケーションは、ランチャーアプリケーションを有しており、該ランチャーアプリケーションは、前記ＤＬを実行中の該ランチャーアプリケーションに動的にリンクすることによって、制限された前記コンピューティング環境に利用可能な機能を拡張するよう動作可能である、請求項２に記載のシステム。
【請求項３５】
前記制約されたコンピューティング環境は、前記コンピューティング環境用のネイティブな実行可能プログラムの追加を許可しない、請求項３４に記載のシステム。
【請求項３６】
前記コンピューティング環境は、該コンピューティング環境において実行できるプログラムの最大サイズについて制約を課する、請求項３４に記載のシステム。
【請求項３７】
前記コンピューティング環境は、ランタイム環境（ＲＴＥ）をサポートする、請求項３４に記載のシステム。
【請求項３８】
前記ＲＴＥ内で動作するプログラムは、ネイティブな前記コンピューティング環境に利用可能な一以上の関数へのアクセスを制限されている、請求項３７に記載のシステム。
【請求項３９】
前記ＲＴＥは、前記ＲＴＥにより認証されたプログラムのみを動作させよう、オペレーションを制約する、請求項３７に記載のシステム。
【請求項４０】
前記ＲＴＥは、Ｊａｖａ２モバイル・エディション（Ｊ２ＭＥ）ＲＴＥ、及び無線用のバイナリランタイム環境（ＢＲＥＷ）ＲＴＥの何れかを含む、請求項３７に記載のシステム。
【請求項４１】
前記ランチャーのモジュールは、前記コンピューティング環境においてネイティブなコンピューティングアプリケーションとして動作するように書かれている、請求項３４に記載のシステム。
【請求項４２】
前記ランチャーは、前記コンピューティング環境の前記ランタイム環境内でコンピューティングアプリケーションとして動作するように書かれている、請求項３７に記載のシステム。
【請求項４３】
少なくとも二つのランチャーモジュールを更に備える、請求項４１に記載のシステム。
【請求項４４】
前記ＤＬは、前記コンピューティング環境から物理的に離れた記憶媒体に記憶されており、該記憶媒体は、フラッシュメモリユニット、固定メモリユニット、及びマイクロドライブの何れかを含む、請求項３４に記載のシステム。
【請求項４５】
前記ランチャーアプリケーションを含む前記バイナリ実行可能プログラムは、前記コンピューティング環境から物理的に離れた記憶媒体に記憶されており、該記憶媒体は、フラッシュメモリユニット、固定メモリ媒体ユニット、及びマイクロドライブの何れかを含む、請求項３４に記載のシステム。
【請求項４６】
前記ＤＬは、前記制限されたコンピューティング環境へのコンテンツの安全な配布を促進するようにデジタルライツマネージメント構成で使用される、請求項３４に記載のシステム。
【請求項４７】
コンピューティング環境内で動作するソフトウェアプラットホーム上でバイナリオブジェクトを一体化する方法であって、
ライブラリソースコードを用意するステップと、
前記ライブラリソースコードをコンパイルして、選択されたフォーマットを有するオブジェクトファイルを備えたコードライブラリ（ＣＬ）を生成するステップと、
ダイナミックリンカー／ローダのソースコードを、前記ライブラリと協働するコンピューティングアプリケーションのソースコードと共にコンパイル及び構築して、前記ソフトウェアプラットホームで実行されるバイナリ実行可能プログラムを生成するステップと、
前記協働するコンピューティングアプリケーション内から前記コードライブラリをオープンするステップと、
を備える方法。
【請求項４８】
ＥＬＦファイルフォーマット又はＰＥファイルフォーマットを含むオブジェクトファイルフォーマットを選択するステップを更に備える、請求項４７に記載の方法。
【請求項４９】
前記ダイナミックリンカー／ローダによってメモリブロックを割り当てて、前記ＣＬをランタイムに前記コンピューティング環境のメモリに動的にロードするステップを更に備える、請求項４７に記載の方法。
【請求項５０】
前記ＣＬをオープンする第１の関数と、前記ＣＬによりエクスポートされたシンボルのメモリ内のアドレスを返す第２の関数とを前記ダイナミックリンカー／ローダ内に用意することによって、前記コンピューティングアプリケーションがランタイムに前記ＣＬにアクセスして該ＣＬと協働することを可能にするステップを更に備える、請求項４８に記載の方法。
【請求項５１】
前記第２の関数を実行するための前記協働するコンピューティングアプリケーション内の命令に応答して、前記第１の関数によってオープンされた前記ＣＬからエクスポートされたシンボルのアドレスを返すステップを更に備える、請求項５０に記載の方法。
【請求項５２】
前記協働するコンピューティングアプリケーションにおいて選択された関数をコールするための前記ＣＬへのアクセスを提供するインターフェイスモジュールをソースコードとして用意するステップを更に備える、請求項４７に記載の方法。
【請求項５３】
前記インターフェイスモジュールのソースコード、前記協働するコンピューティングアプリケーションのソースコード、及び前記ダイナミックリンカー／ローダのソースコードを、前記ソフトウェアプラットホームで実行されるバイナリ実行可能プログラムへとコンパイルするステップを更に備える、請求項５２に記載の方法。
【請求項５４】
前記バイナリオブジェクトファイルを再コンパイル又は再構築する必要なく、定義されたプロセッサアーキテクチャーで実行される複数のソフトウェアプラットホーム及びオペレーティングシステムにわたって単一のバイナリオブジェクトファイルを一体化するステップを更に備える、請求項４７に記載の方法。
【請求項５５】
前記ＣＬと協働するコンピューティングアプリケーションのソースコードと、前記ダイナミックリンカー／ローダのソースコードを、前記複数のソフトウェアプラットホームのうちの選択された一つのソフトウェアプラットホーム用のバイナリ実行可能プログラムへとコンパイルしリンクするステップを更に備える、請求項５４に記載の方法。
【請求項５６】
前記コンピューティング環境は、前記選択されたオブジェクトフォーマットをネイティブにサポートしない、請求項４７に記載の方法。
【請求項５７】
前記ＣＬをロードして、該ＣＬを、制約のあるコンピューティング環境内のコンピューティングアプリケーションであって、ネイティブなダイナミックリンキングメカニズムをもたないオペレーティングシステムで動作する該コンピューティングアプリケーションにリンクして、バイナリオブジェクトのダイナミックリンキングを実行するステップを更に備える、請求項４７に記載の方法。
【請求項５８】
前記ライブラリソースコードは、前記ソフトウェアプラットホームのプログラミング制約に違反するコードを含む、請求項４９に記載の方法。
【請求項５９】
前記プログラミング制約は、グローバル変数の使用に関する制約、書き込み可能なスタティック変数の使用に関する制約、及びポインタ変数の静的初期化に関する制約の何れかを含む、請求項５８に記載の方法。
【請求項６０】
前記ライブラリにおいて定義されたグローバル変数又は書き込み可能なスタティック変数の領域を、前記ＣＬによって占有されるメモリブロックに制限するステップを更に備える、請求項５９に記載の方法。
【請求項６１】
前記ライブラリソースコードは、コードの多数の実行インスタンス又は繰り返し実行を制限するようにデータを取り扱い且つデータへのアクセス関数を提供するコードを含み、
前記方法は、更に、前記ライブラリのインスタンスを、前記ダイナミックリンカー／ローダによって、動的に割り当てられたメモリブロックにロードするステップを備え、
前記ライブラリのコードにおいて定義されたデータ変数の領域が前記メモリブロックに制限される、請求項４７に記載の方法。
【請求項６２】
単一のコンピューティング環境プロセス内で実行されるべき同じライブラリの多数の非衝突インスタンスをロードするステップを更に備える、請求項６１に記載の方法。
【請求項６３】
ライブラリデータの多数のセットが、各ライブラリデータのセット間で衝突が軽減され及び／又は除去されるように、単一のコンピューティング環境プロセス内で同時に動作する、請求項６２に記載の方法。
【請求項６４】
単一のコンピューティング環境プロセス内でコードの実行を繰り返すために、非オブジェクト指向のコードをロードするステップを更に備える、請求項６１に記載の方法。
【請求項６５】
前記コンピューティング環境は、多数のプロセスをサポートしない、請求項６２又は６４に記載の方法。
【請求項６６】
前記コンピューティング環境は、非常駐のエグズキュータブルプログラムを前記コンピューティング環境に配備することに関して制限されており、
前記方法は、更に、前記ＣＬを、前記協働するコンピューティングアプリケーション内に含まれた実行中のランチャーアプリケーションと動的にリンクすることによって、前記制約のあるコンピューティング環境に使用できる機能を拡張するステップを備える、請求項４７に記載の方法。
【請求項６７】
前記コンピューティング環境は、
該コンピューティング環境がネイティブな実行可能プログラムの追加に対して閉じていること、
該コンピューティング環境が、実行を、プログラムサイズ限界内に入るプログラムに制限すること、
該コンピューティング環境が、ランタイム環境（ＲＴＥ）を有し、該ＲＴＥ内で動作するプログラムが、ネイティブなコンピューティング環境に使用可能な一以上の関数へのアクセスを制限すること、
該コンピューティング環境がＲＴＥを有し、該ＲＴＥが、当該ＲＴＥに対して認証されたプログラムしかランしないようにオペレーションを制限すること、及び
該コンピューティング環境がダイナミックリンキングを許可しないこと、
の何れか一つ以上を含む一以上の制限を課せられている、
請求項６６に記載の方法。
【請求項６８】
定義されたプロセッサアーキテクチャーで動作する異種のコンピューティングソフトウェア環境にわたって使用するためにコンピューティングライブラリを配布する方法であって、
選択された構造を有するバイナリオブジェクトファイルとしてダイナミックライブラリ（ＤＬ）を生成するステップと、
ダイナミックリンカーのソースコードを、少なくとも一つのコンピューティング環境で動作可能な協働するコンピューティングアプリケーションのソースコードと共にコンパイルすることによって、バイナリ実行可能プログラムを構築するステップと、
通信ネットワーク及び記憶媒体の何れかを含む入力ソースから前記異種のコンピューティング環境へ前記ＤＬを通信するステップと、
前記ＤＬを前記バイナリ実行可能プログラムに動的にリンクするステップと、
を備える方法。
【請求項６９】
少なくとも一つのＤＬと協働する前記コンピューティングアプリケーションの新たなバージョンを通信するステップを更に備える、請求項６８に記載の方法。
【請求項７０】
前記コンピューティングアプリケーションと協働する前記ＤＬの新たなバージョンを通信するステップを更に備える、請求項６８に記載の方法。
【請求項７１】
コンピューティング環境で使用するためにコンピューティングライブラリを配布するための請求項６８記載の方法であって、
前記コンピューティング環境は、
該コンピューティング環境が、ネイティブな実行可能プログラムの追加に対して閉じていること、
該コンピューティング環境が、実行を、プログラムサイズ限界内に入るプログラムに制限すること、
該コンピューティング環境が、ランタイム環境（ＲＴＥ）を有し、該ＲＴＥ内で動作するプログラムが、ネイティブなコンピューティング環境に使用できる一以上の関数へのアクセスを制限すること、
該コンピューティング環境が、ＲＴＥを有しており、該ＲＴＥが、当該ＲＴＥに対して認証されたプログラムしか動作しないようにオペレーションを制限すること、及び
前記コンピューティング環境がダイナミックリンキングを許可しないこと、
のうち何れか一以上を含む一以上の制限を課せられている、
方法。
【請求項７２】
協働するランチャーアプリケーションであってプロキシとして動作可能な該ランチャーアプリケーションを、コンピューティング装置にダウンロードし、該コンピューティング装置に利用可能なダイナミックライブラリであって通信ネットワーク及び記憶媒体の何れかを含む入力ソースからの該ダイナミックライブラリへの前記ランチャープログラムによるアクセスを可能にするステップを更に備える、請求項７１に記載の方法。
【請求項７３】
ダイナミックライブラリが前記コンピューティング装置に使用できるようになったときに、前記ランチャーアプリケーションの範囲を、協働するダイナミックライブラリの付加的な関数を含むように拡張するステップを更に備える、請求項７２に記載の方法。
【請求項７４】
前記協働するコンピューティングアプリケーションは、コンピューティング装置のコンピューティング環境に、該コンピューティング装置をエンドユーザに販売するために出荷する前に、配備される、請求項６８に記載の方法。
【請求項７５】
前記協働するコンピューティングアプリケーションは、コンピューティング装置のコンピューティング環境に、該コンピューティング装置をエンドユーザに販売するために出荷した後に、配備される、請求項６８に記載の方法。
【請求項７６】
前記コンピューティング装置は、移動電話又は無線イネーブル型ハンドセットである、請求項７４又は７５に記載の方法。
【請求項７７】
前記ＤＬは、前記コンピューティング環境へのコンテンツの安全な配布を促進するようにデジタルライツマネージメント構成で使用される、請求項６８に記載の方法。
【発明の詳細な説明】
【発明の分野】
【０００１】
本発明は、バイナリオブジェクトの生成及びオペレーションに関するものであり、より詳細には、異種のコンピューティング環境にわたって動作可能なプラットホーム独立のバイナリオブジェクトの生成、動作、及び、分配に関するものであり、特に、様々な非ネイティブのコンピューティング環境での動作を可能とするものである。
【発明の背景】
【０００２】
コンピューティング環境は、当該コンピューティング環境のハードウェアコンポーネントに対する一以上の命令を含むコンピュータコードを実行して、一以上のオペレーションを実行することができる。通常、コンピュータコードは、コンピューティング環境に実行のためにロードされる。物理的なロードの前に、コンピュータコードが、コンパイルされ、これによって、当該コンピュータコードが、特定のコンピューティング環境（例えば、コンピューティング環境のオペレーティングシステム及び／又はコンピューティング環境のプラットホーム）で動作することができる。コンピュータコードは、コンピューティング環境によって、そのコンピューティング環境に存在する他のコンピュータコードとリンクされて、一以上の動作を実行することができる。所与のコンピュータコードを扱うコンピューティング環境に応じて、バイナリオブジェクトを、コンピューティング環境及び／又は他の協働するコンピュータコードによる使用のために生成することができる。バイナリオブジェクトは、一以上の協働するコンピューティングプログラム（コンピューティングプログラム）により要求される情報、関数、及び／又は、オペレーションを含み得る。
【０００３】
一以上の関数が、次いで、コンピューティングアプリケーション、他のライブラリ、又はコンピューティング環境によって使用するために、一以上のライブラリに集められて、一以上のオペレーションを実行することが可能となる。一般的な慣例では、ライブラリは、特定のハードウェアアーキテクチャーを有する単一のコンピューティング環境によって利用できるように設計されて、実装される。ライブラリは、スタティックベース又はダイナミックベースの何れかで、所与のコンピューティング環境によって利用することができる。静的（スタティック）な場合には、ライブラリ、及び所与のコンピューティングアプリケーションの他のコンポーネントが、単一のファイルへと結合され、当該ファイルをメモリにロードして実行することができる。これに対して、動的（ダイナミック）なオペレーション（例えば、コンポーネントのダイナミックリンキング）では、コンピューティングアプリケーションが実行されるときに、関数及びコンポーネント（例えば、オブジェクト及びライブラリ）が使用可能にされる。ダイナミックコンポーネントは、コンピューティング環境で動作する幾つかのコンピューティングアプリケーションによって共有することができる。これは、動的にリンクされるコンポーネントが、それらの設計及び動作上、コンピューティングアプリケーションのメイン部分に束縛されないからである。
【０００４】
しかしながら、現在の慣例は、異種のコンピューティング環境で動作するためのコンピュータコードを生成して実行するときに、扱い難いものとなることがある。現在の慣例は、一般に、特定のコンピューティングハードウェアアーキテクチャーを有する特定のコンピューティング環境用にコンピュータコード（例えば、ソフトウェア開発キット−ＳＤＫによる）を生成して実行することを要求するので、多数の異種のコンピューティング環境（例えば、種々のオペレーティングシステム及び／又はコンピューティングプラットホームを有するもの）で動作する単一のバイナリオブジェクトを生成することは困難である。特定のコンピューティング環境用のコードを生成する場合には、コンピュータコードを、それをコンピューティング環境へロードする前にコンパイルして、そのコンピュータコードを実行するときにコンピューティング環境によってリンクすることができる。これらの制約では、コンピュータコードは、一般に、単一のコンピューティング環境（即ち、オペレーティングシステム及び／又はプラットホーム）で動作するように設計されて、生成される。
【０００５】
さらに、コンピューティング環境は、コンピュータコードを所与のコンピューティング環境において適切に実行できるように生成することに関する制約及びルールを課すことがある。例えば、プラットホーム及び／又はオペレーティングシステム（例えば、Ｓｙｍｂｉａｎ  ＱｕａｒｔｚをランするＳｙｍｂｉａｎＯＳ）は、特定のプラットホーム及び／又はオペレーティングシステムで実行するコンピュータコードに関して、多数の制約を保持することがあり、当該コンピュータコードには、限定するものではないが、書き込み可能なスタティック変数及び／又はグローバル変数の使用が含まれている。換言すれば、プラットホーム及び／又はオペレーティングシステムは、書き込み可能なスタティック変数又はグローバル変数を有するコンピュータコードのオペレーションを禁止することができる。
【０００６】
コンピュータコード開発者の中で共通の慣例には、限定するものではないが、同じオペレーションを実行するものであり、且つ、異種セットのオペレーティングシステム及びプラットホームの各々のために構築した種々のコードを開発することが含まれている。例えば、カレンダーコンピューティングアプリケーションは、Ｊａｖａ、“Ｃ＋＋”又はビジュアル・ベーシックのような単一の高レベルプログラミング言語を使用して開発することができる。開発時間及びリソースを減少するために、コアコンピューティングアプリケーションコードを開発者は再使用することができる。しかしながら、このような再使用の程度は限定されたものである。これは、現在の慣例では、更なるコンポーネント（例えば、ライブラリ、関数、データ構造、等）を開発し、カスタマイズして、コンピューティングアプリケーションが、異種のコンピューティング環境（例えば、オペレーティングシステム及び／又はプラットホーム）のセットの各々で動作できるようにする必要があるからである。
【０００７】
従来の慣例及び解決策には他の制限もあり、当該制限には、限定するものではないが、複数の異種のコンピューティング環境にわたって動作できる単一のプラットホーム独立のバイナリオブジェクトを、当該異種のコンピューティング環境の各々に対して再構築又は再コンパイルを要することなしには、もてないことがある。さらに、現在の慣例及び解決策は、このようなネイティブのファシリティを与えないプラットホームにおいて共有オブジェクトを動的にリンクするためのメカニズムを提供するものではない。また、現在の慣例では、予め書かれたコードコンポーネントが、他の場合に特定コード内におけるプラットホーム制約の違反のために互換しないであろうプラットホーム上で使用することができない。さらに、現在の慣例は、多数の実行インスタンスの制約を回避する非オブジェクト指向コードをロードするためのメカニズムを提供するものではなく、コード固有の実行を繰り返すものである。また、現在の慣例及び解決策は、閉じたプラットホーム（例えば、付加的なプログラムの実行を制約し得るプラットホーム）においてバイナリオブジェクトを動的にリンクしロードすることを可能とするメカニズムを提供するものでもない。
【発明の概要】
【０００８】
本明細書で説明するシステム及び方法は、選択されたハードウェアアーキテクチャーを有する異種のコンピューティング環境上で再コンパイル、再構築、又は再ロードを必要とせずに動作できるプラットホーム独立のバイナリオブジェクト（ＰＩＢＯ）を提供する。例示の実施の形態では、選択された構造（例えば、オブジェクトファイルフォーマット）を有するバイナリオブジェクトファイルが提供される。このバイナリオブジェクトファイルは、ソースコードが、その生成時に、プラットホーム依存性をもたないように、ソースコードをコンパイルすることによって生成できる。例示の実施の形態では、バイナリオブジェクトファイルは、ソースファイルに対するデータ及びバイナリコードを含む。さらに、例示的リンカー／ローダを提供し、当該リンカー／ローダが例示的コンピューティングアプリケーションの一部として動作して、プラットホーム独立バイナリオブジェクトをリンク及びロードし、また、協働コンピューティングプログラムとの協働を、異種のコンピューティング環境上で可能とする。また、例示的インターフェイスを提供し、当該インターフェイスによって、協働コンピューティングアプリケーションが、例示的ＰＩＢＯにアクセスすることを可能とする。
【０００９】
例示のオペレーションでは、例示的リンカー／ローダは、異種のコンピューティング環境のうちの一つに対して、協働コンピューティングアプリケーションのメインソースコードと共にコンパイルされて、異種のコンピューティング環境（及び／又はプラットホーム）のうちの一つで動作可能なバイナリ実行可能ファイル(binary executable)を発生することができる。例示の実施の形態では、例示的リンカー／ローダは、協働コンピューティングアプリケーションの実行中にＰＩＢＯをその協働コンピューティングアプリケーションにリンクしてロードするように動作する。例示の実施の形態では、リンカー／ローダは、シンボル解決及び再配置を取り扱い、協働コンピューティングアプリケーションのバイナリ実行可能ファイルを、完全に実行可能なプロセスとして、ＰＩＢＯと結合することができる。
【００１０】
例示の実施の形態では、ＰＩＢＯは、次のものを含む（それらに限定されないが）種々の状況に使用することができ、即ち、ネイティブなファシリティを与えないプラットホームにおいて共有オブジェクトを動的にリンクするためのメカニズムとして使用でき、予め書き込まれるコードコンポーネントを、それがなければ特定コード内のプラットホーム制約の違反のために不適合となるであろうプラットホームに利用するのに使用でき、コードに固有の多数の実行インスタンスの制約を回避する非オブジェクト指向コードをロードして、コードに固有の実行を繰り返すためのメカニズムとして使用でき、更に、閉じたプラットホームにアドオン機能を提供するためのプラットホーム独立のバイナリオブジェクトの使用を可能とするメカニズムとして使用できる。
【００１１】
本発明の他の特徴を、以下に詳細に説明する。
【００１２】
プラットホーム独立の動的なオブジェクト及びその使用方法を、添付図面を参照して、以下に詳細に説明する。
【詳細な説明】
【００１３】
＜１．概略＞
コンピュータコードは、コンピュータシステム又は装置内の中央処理ユニット（ＣＰＵ）又は他のコンピュータプロセッサで実行することができる。ＣＰＵアーキテクチャーの通常の例には、限定するものではないが、ＩＮＴＥＬ（登録商標）ｘ８６ファミリー、ＡＲＭ（登録商標）ＲＩＳＣ（減少インストラクションセットコード）アーキテクチャー、ＳＵＮ（登録商標）ＳＰＡＲＣ、及びＭＯＴＯＲＯＬＡ（登録商標）６８０００がある。これらに。コードは、人間が理解できる“Ｃ”、“Ｃ＋＋”、又はＪＡＶＡ（登録商標）のような高レベル言語で書くことができるが、最終的に、コードは、その後、コンピューティング環境によって、例示的コンピュータプロセッサで実行されるマシン命令へとコンパイル及びアッセンブルすることができる。
【００１４】
ＣＰＵは、システムプラットホームとして一般的に知られたソフトウェア環境内に存在することができる。プラットホームは、より大きなフォームファクタのコンピューティング環境（例えば、デスクトップ、ラップトップパーソナルコンピュータ）用のＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）やＬｉｎｕｘのようなオペレーティングシステムを含むことができる。より小さなフォームファクタのコンピューティング環境（例えば、移動及びテレコム装置）用には、種々のオペレーティングシステムが現在使用されており、これらに限定するものではないが、Ｌｉｎｕｘ、ＳｙｍｂｉａｎＯＳ、ＷｉｎｄｏｗｓＣＥ（登録商標）、ＰａｌｍＯＳ、ＢＲＥＷ、ＲＥＸ、及びＩｔｒｏｎがある。
【００１５】
プラットホームは、しばしば、ＯＳを特定の目的のために拡張する付加的な機能を保持することができる。例えば、ＷｉｎＣＥ．ＮＥＴ、Ｓｍａｒｔｐｈｏｎｅ、及びＰｏｃｋｅｔＰＣプラットホームは、Ｗｉｎｄｏｗｓ  ＣＥオペレーティングシステムを使用するが、ユーザインターフェイスのような他の観点が異なり、即ち、ＷｉｎＣＥ．ＮＥＴは、工業用装置をターゲットとすることができ、ＰｏｃｋｅｔＰＣは、タッチスクリーンをもつパーソナルデジタルアシスタント（ＰＤＡ）をターゲットとすることができ、更に、Ｓｍａｒｔｐｈｏｎｅは、キーパッドを経て動作する移動セルラー電話をターゲットとすることができる。また、プラットホームは、特定のコンピューティングアプリケーションに対して調整された拡張機能を有することもできる。提供する実施例では、ＰｏｃｋｅｔＰＣプラットホームは、ＰＤＡに対する個人的情報管理用にある範囲の機能を保持することができ、一方、Ｓｍａｒｔｐｈｏｎｅプラットホームは、移動電話に適した通信機能と共にパッケージ化することができる。
【００１６】
従来のシステムでは、特定のプラットホームにおいて実行できるバイナリコードの生成は、特定のプラットホーム（及び／又はオペレーティングシステム）用に設けられたソフトウェア開発キット（ＳＤＫ）のようなツールチェーンを介して、コードをコンパイルし、構築することによって達成することができる。異なるＳＤＫが、所与のオペレーティングシステムで動作する異なるプラットホーム用のコードを開発するために必要とされる（例えば、Ｓｙｍｂｉａｎ  Ｑｕａｒｔｚは、Ｓｙｍｂｉａｎ  Ｃｒｙｓｔａｌとは異なるＳＤＫを必要とする）。不適切なＳＤＫを使用して特定のプラットホーム用のコードを開発する場合、得られるバイナリが所望のプラットホームにおいて動作することができない。
【００１７】
ソースコードレベルにおいて、あるオペレーティングシステムは、コードを書く方法に制約及びルールを課す。例えば、ＳｙｍｂｉａｎＯＳは、書き込み可能な静的又はグローバル変数を使用しないようにコードを生成することを要求する。このような制約の結果、一つのＯＳ用に最初に書かれたレガシーコードは、異なるコードルールを要求する別のＯＳではコンパイルできないことがある。それでも、共通の慣例は、その後に多数のプラットホーム用に構築し得る単一のソースコードプログラムを書くというものである。実装時には、共通のソースファイルを開発することができる。この共通のソースファイルを、選択されたプラットホームのツールチェーンを介して別々に処理して、多数の個別の、プラットホーム特有のバイナリ出力を単一のソースファイルから生成することができる。
【００１８】
＜２．動的リンキング及びローディング＞
コンピュータプログラムは、多数のコンポーネントを備える。プログラムが実行されるときに、これらのコンポーネントを、完全な機能システムを形成するよう集めることができ、プログラムを実行する協働コンピューティング環境のメインメモリにロードすることができる。コンピュータプログラムのコンポーネントを結合するプロセスは、リンキングとして知られている。プログラムコンポーネントが一つの単一ファイルへと結合され、これをメモリにロードして実行できる場合には、かかるプロセスが「スタティックリンキング」として説明される。一般に、リンカーは、リンカーへの入力として動作可能なコンポーネントオブジェクトファイルを連結できるツールチェーンの一部分であり、オブジェクトファイルを集めてリンクし、単一の出力ファイルを形成することができる。プログラムが、多数のサブプログラムから作り上げられる場合には、あるプログラムの、別のプログラムへの参照を、シンボル（変数及び関数名のような）を介して行うことができる。他の関数及びオペレーションの中で、リンカーは、協働コンピューティング環境のメモリにおけるシンボル（一つ又は複数）の位置に注目し、呼び出し側のサブプログラムのオブジェクトコードをパッチして、コール命令がその注目したメモリ位置を参照するようにすることによって、参照を解決するように動作することができる。
【００１９】
「スタティック（静的）リンキング」では、プログラムが別のコンポーネントに記憶された関数へのコールを発するときに、その要求された関数に対するコードを、スタティックリンカーによって実行可能ファイル（executable）に組み込むことができる。実際に、スタティックリンカーは、要求された全ての関数のコードを出力実行可能ファイルにコピーする。対照的に、「ダイナミック（動的）リンキング」は、プログラムの実行中だけファンクション及びコンポーネントを使用可能にすることができる。動的にリンクされるコンポーネントは、一般に、プログラムのメイン部分に束縛されないので、幾つかの実行プログラムによってそれらを共有することができる。また、メインプログラムは、静的にリンクされたものより著しく小さくすることもできる。これは、実際のコードがプログラムの実行可能ファイルの一部分とならず、且つ動的にリンクされるコンポーネントが個別のファイルとして存在するからである。現在のコンピューティング環境では、「ダイナミックリンキング」が普及している。例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）では、動的にリンクされるコンポーネントは、ＤＬＬ（ダイナミックリンクライブラリ）と称され、そしてＵｎｉｘ／Ｌｉｎｕｘでは、それらは、共有オブジェクト（．ｓｏ）ファイルと称されている。
【００２０】
プログラムがダイナミックリンクライブラリにおける関数へのコールを行なう場合には、コンパイラ及びリンカーは、再配置テーブルを生成することができ、当該再配置テーブルによって、実行時に、協働コンピューティング環境が、ライブラリをロードして、要求された関数に対するコードを見つけることができる。ダイナミックリンクライブラリでは、ライブラリを使用するプログラムが実行を開始するまで（「ロードタイムダイナミックリンキング」として知られている）、又はプログラムが第１コールを行なうまで（「ランタイムダイナミックリンキング」）、シンボルが実際のアドレスに結合されない。
【００２１】
動的な実行可能ファイルは、ダイナミックリンカー／ローダの制御のもとで実行することができる。これらのアプリケーションは、ダイナミックライブラリ（即ち、共有オブジェクト）の形式に依存するものであり、当該ダイナミックライブラリをダイナミックリンカーによって特定して結合し、実行可能プロセスを生成することができる。また、共有オブジェクトも、更にダイナミックリンカーによって管理される他の共有オブジェクトに依存する。従来の解決策では、動的なリンク及びロード用のルーチンであって、結合（バインディング）、シンボル解決、コード再配置を扱って、結合された実行可能ファイル及び共有オブジェクトが完全なプログラムとして実行されることを可能とするルーチンは、一般に、コンピューティング環境のオペレーティングシステムの一部分である。
【００２２】
実際に、ダイナミックライブラリは、ロード時にリンクすることができる。ダイナミックライブラリが生成される際には、小さなスタブファイル、即ちインポートライブラリが生成される。このスタブファイルは、ダイナミックライブラリをロードして当該ダイナミックライブラリがエクスポートする関数を特定するために使用することができる情報（シンボル及び再配置テーブルのような情報）をコンピューティング環境に供給する。インポートライブラリ（即ちスタブファイル）はメインの実行可能プログラムが生成されるときにリンクされて、共有オブジェクトの実際のバイナリコードが分離されたままであっても、共有オブジェクトライブラリ内の全ての関数位置が実行可能プログラムに知り得るようになる。プログラムが実行開始のためにメモリにロードされると、ダイナミックライブラリもロードされ、リンクされた情報がスタブファイル内に提供された結果、エクスポートされたライブラリ関数をメインプログラムによりコールすることが可能となる。
【００２３】
ランタイムダイナミックリンキングでは、呼び出し側のプログラムは、特殊なファンクションを使用してライブラリを実行時にロードする。例えば、Ｗｉｎｄｏｗｓのオペレーティングシステムでは、これがＬｏａｄＬｉｂｒａｒｙファンクションであり、Ｌｉｎｕｘのもとでは、同等のファンクションがｄｌｏｐｅｎと称されている。この方法では、ダイナミックライブラリのロードは、呼び出し側のプログラムがロードするときには自動的でなく、プログラムが実行時にこの特定のコールを行なうまで延期される。この関数は、ロードすべきライブラリオブジェクトのパス名を含み、成功した場合には、ロードしたライブラリへのハンドルを返す。次いで、呼び出し側のプログラムは、第２ファンクション（ＷｉｎｄｏｗｓではＧｅｔＰｒｏｃＡｄｄｒｅｓｓ、そしてＬｉｎｕｘではｄｌｓｙｍと称される）にハンドルを渡し、ダイナミックライブラリによってエクスポートされた名前付きシンボルのアドレスを得る。シンボルのアドレス（通常はコールすべき手順）が分かると、シンボルが、発呼側プログラムによる使用のために呼び出される。この方法は、インポートライブラリ、即ちスタブファイルの必要性を排除する。
【００２４】
＜２(ａ)  例示的コンピューティング環境＞
図１は、本明細書で説明するシステム及び方法に基づく例示的コンピューティングシステム１００を示している。コンピューティングシステム１００は、種々のコンピューティングプログラム１８０を実行することができる。例示的コンピューティングシステム１００は、主として、コンピュータ読み取り可能な命令によって制御されるものであり、当該命令は、ソフトウェアの形態をとっていてもよく、また、このようなソフトウェアが記憶された場所やアクセスされる方法に関する命令を提供してもよい。このようなソフトウェアは、中央処理ユニット（ＣＰＵ）１１０内で実行されて、データ処理システム１００を動作させる。多くの既知のコンピュータサーバー、ワークステーション、及びパーソナルコンピュータでは、中央処理ユニット１１０が、マイクロプロセッサと称するマイクロ電子チップＣＰＵよって実現されている。コプロセッサ１１５は、メインＣＰＵ１１０とは別の任意のプロセッサで、付加的な関数を実行し、又は、ＣＰＵ１１０を支援する。ＣＰＵ１１０は、相互接続部１１２を介してコプロセッサ１１５に接続されていてもよい。一つの通常形式のコプロセッサは、フローティングポイントコプロセッサであり、数値演算コプロセッサとも称されるものであり、数値計算を汎用ＣＰＵ１１０より迅速且つ良好に実行するように設計されている。
【００２５】
例示的コンピューティング環境は、単一のＣＰＵ１１０を備えるように示されているが、このような説明は単なる例示に過ぎず、コンピューティング環境１００は、多数のＣＰＵ１１０を備えることもあることが明らかであろう。さらに、コンピューティング環境１００は、通信ネットワーク１６０又は他の何らかのデータ通信手段（図示せず）を介して遠隔のＣＰＵ（図示せず）のリソースを利用することもある。
【００２６】
動作時には、ＣＰＵ１１０は、命令をフェッチし、デコードし、実行すると共に、コンピュータのメインデータ転送経路、即ちシステムバス１０５を介して、他のリソースへ及び他のリソースから情報を転送する。このようなシステムバスは、コンピューティングシステム１００内のコンポーネントを接続し、データ交換用の媒体を画成する。システムバス１０５は、通常、データを送るためのデータライン、アドレスを送るためのアドレスライン、及び割り込みを送り且つシステムバスを動作させるための制御ラインを備えている。このようなシステムバスは、例えば、ＰＣＩ（周辺コンポーネント相互接続）バスである。今日の進歩したバスの幾つかは、拡張カード、コントローラ及びＣＰＵ１１０によってバスへのアクセスを調整するバス調停と称される機能を提供する。これらのバスに接続してバスの占拠を調停するデバイスは、バスマスターと称される。また、バスマスターは、プロセッサ及びそのサポートチップを含むバスマスターアダプタの追加によって、バスのマルチプロセッサ構成を作ることを可能にする。
【００２７】
システムバス１０５に結合されたメモリ装置は、ランダムアクセスメモリ（ＲＡＭ）１２５、及びリードオンリメモリ（ＲＯＭ）１３０を含む。このようなメモリは、情報を記憶し検索することを可能にする回路を備えている。ＲＯＭ１３０は、一般に、変更できない記憶されたデータをもつ。ＲＡＭ１２５に記憶されるデータは、ＣＰＵ１１０又は他のハードウェア装置によって読み取り又は変更することができる。ＲＡＭ１２５及び／又はＲＯＭ１３０へのアクセスは、メモリコントローラ１２０によって制御することができる。このメモリコントローラ１２０は、命令が実行されるときに、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供することができる。また、メモリコントローラ１２０は、システム内のプロセスを分離し、且つ、システムプロセスをユーザプロセスから分離するメモリ保護機能も提供することができる。従って、ユーザモードで実行されるプログラムは、通常、それ自身のプロセスの仮想アドレススペースによってマップされたメモリしかアクセスできない。即ち、プログラムは、プロセスとプロセスとの間のメモリ共有が設定されない限り、別のプロセスの仮想アドレススペース内のメモリにアクセスすることはできない。
【００２８】
さらに、コンピューティングシステム１００は、ＣＰＵ１１０から、プリンタ１４０、キーボード１４５、マウス１５０及びデータ記憶ドライブ１５５のような周辺機器へ命令を伝送する役割を果たす周辺機器コントローラ１３５を備えることができる。
【００２９】
ディスプレイ１６５は、ディスプレイコントローラ１６３によって制御されるものであり、コンピューティングシステム１００によって発生されるビジュアル出力を表示するために使用される。このようなビジュアル出力は、テキスト、グラフィック、アニメーショングラフィック、及びビデオを含むことができる。ディスプレイ１６５は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、タッチパネル、又は種々のフォームファクタの他のディスプレイ形態で実施することができる。ディスプレイコントローラ１６３は、ディスプレイ１６５へ送信されるビデオ信号を発生するために必要な電子コンポーネントを備えている。
【００３０】
さらに、コンピューティングシステム１００は、このコンピューティングシステム１００を外部通信ネットワーク１６０に接続するために使用できるネットワークアダプタ１７０も備えることができる。通信ネットワーク１６０は、ソフトウェア及び情報を電子的に通信し且つ転送する手段をコンピュータユーザに提供することが可能である。さらに、通信ネットワーク１６０は、タスクの実行時に、多数のコンピュータを関与させて、ワーク負荷の分担、即ち協力動作を行なう分散型処理を提供することも可能である。図示されたネットワーク接続は、例示に過ぎず、コンピュータ間に通信リンクを確立する他の手段を使用してもよいことが明らかであろう。
【００３１】
例示的コンピュータシステム１００は、本明細書で説明するシステム及び方法が動作し得るコンピューティング環境を単に例示するものであり、本明細書で説明する本発明の概念は、種々のコンポーネント及び構成を有する種々のコンピューティング環境で実施できるので、本明細書で説明するシステム及び方法を、異なるコンポーネント及び構成を有するコンピューティング環境で実施することを何ら制限するものでないことが明らかであろう。
【００３２】
＜２(ｂ)  例示的コンピュータネットワーク環境＞
上述したコンピューティングシステム１００は、コンピュータネットワークの一部分として配備することができる。一般に、コンピューティング環境についての上記説明は、ネットワーク環境に配備されるサーバーコンピュータ及びクライアントコンピュータの両方に適用される。図２は、例示的なネットワーク構成のコンピューティング環境２００を示すもので、サーバー２０５は、通信ネットワークを経てクライアントコンピュータと通信しており、当該ネットワーク内に本明細書で説明する装置及び方法が採用されている。図２に示すように、サーバー２０５は、通信ネットワーク１６０（固定有線又は無線ＬＡＮ、ＷＡＮ、イントラネット、エクストラネット、ピア対ピアネットワーク、インターネット、又は他の通信ネットワークのいずれか、又はその組み合せでよい）を介して、多数のクライアントコンピューティング環境、例えば、タブレットパーソナルコンピュータ２１０、移動電話２１５、電話２２０、パーソナルコンピュータ１００、及びパーソナルデジタルアシスタント２２５に相互接続することができる。さらに、本明細書で説明する装置及び方法は、通信ネットワーク１６０を介して、自動車のコンピューティング環境（図示せず）、消費者向け電子装置のコンピューティング環境（図示せず）、及びビルの自動制御のコンピューティング環境（図示せず）と協働することができる。例えば、通信ネットワーク１６０がインターネットであるネットワーク環境では、サーバー２０５は、多数の既知のプロトコル、例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、又は無線アプリケーションプロトコル（ＷＡＰ）のいずれかを経て、クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５へ及びそこからデータを通信し処理するように動作できる専用のコンピューティング環境サーバーである。各クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５は、一つ以上のコンピューティングプログラム１８０、例えば、ウェブブラウザ（図示せず）、又は移動デスクトップ環境（図示せず）を装備して、サーバーコンピューティング環境２０５へのアクセスすることが可能である。
【００３３】
動作時には、ユーザ（図示せず）は、クライアントコンピューティング環境で実行されているコンピュータプログラムと対話して、希望のデータ及び／又はコンピューティングプログラムを得ることができる。データ及び／又はコンピューティングアプリケーションは、サーバーコンピューティング環境２０５に記憶することができ、クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５を介して、例示的通信ネットワーク１６０を経て、協働するユーザへ通信することができる。参加するユーザは、サーバーコンピューティング環境２０５に全体的又は部分的に収容された特定データ及びアプリケーションへのアクセスを要求することができる。このようなデータ通信は、クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５と、サーバーコンピューティング環境との間で処理及び記憶のために行うことができる。サーバーコンピューティング環境２０５は、データの発生、認証、暗号化及び通信のために、コンピューティングプログラム、プロセス、及びアプレットをホストすることが可能であり、他のサーバーコンピューティング環境（図示せず）、第三者のサービスプロバイダー（図示せず）、ネットワークアタッチ型記憶装置（ＮＡＳ）、及び記憶エリアネットワーク（ＳＡＮ）と協働して、このようなデータトランザクションを実現することができる。
【００３４】
従って、本明細書で説明する装置及び方法は、ネットワークにアクセスして対話するためのクライアントコンピューティング環境と、このクライアントコンピューティング環境と対話するためのサーバーコンピューティング環境とを有するコンピュータネットワーク環境に使用することができる。しかしながら、移動デバイスプラットホームを提供する装置及び方法は、種々のネットワークベースのアーキテクチャーで実施することができ、従って、ここに示す実施例に限定されるものではない。
【００３５】
＜３．プラットホーム依存リンキング＞
実行可能プログラムは、一般に、プラットホーム依存している。換言すれば、所与のプログラムは、開発時に、特定のプラットホームで動作するように意図されており、従って、その特定のプラットホームに対してコンパイルされ、リンクされ、構築されなければならない。また、このようなプロセスから生成して得たバイナリ実行可能ファイルは、一般に、異なるプラットホームでは動作しない。従来のシステムでは、各個別のオペレーティングシステム用に別々のダイナミックライブラリを構築することが必要となる。多数のオペレーティングシステムをサポートすべき場合には、ライブラリコードを多数の共有オブジェクト（ダイナミックライブラリ）へと構築しなければならず、即ち、専用のツールを使用して、オペレーティングシステム毎に一つの共有オブジェクトを構築しなければならない。コードが、個々のプラットホームに固有のアイテムを明示的に参照しない場合には、対象となっている所与のオペレーティングシステム用の共有オブジェクトライブラリを生成して、当該ライブラリをそのオペレーティングシステムから導出した幾つかのプラットホーム上で機能させることで十分である。対照的に、ライブラリコードがプラットホーム固有の関数に明示的な依存性を有する場合には、共有オブジェクトを特に所与のプラットホーム用に構築しなければならず、当該共有オブジェクトは、一般に、明示的な依存性に欠ける他のプラットホームでは動作しない。
【００３６】
オペレーティングシステムが多数のプラットホームをサポートする場合には、プログラムコンポーネントのセットは、通常、限定するものではないが、次のコンポーネント、即ち、プラットホームへと一意に束縛された実行可能バイナリ、及び当該プラットホームのベースであるオペレーティングシステム用に構築されたオプションのセットの共有オブジェクト（ダイナミックライブラリ）を含む。
【００３７】
図３は、「ランタイムダイナミックリンキング」を実行する場合に例示的コンピューティング環境３００によって実行されるプロセスを示す。図３に示すように、プログラムソースファイル３５５を、ブロック３５０においてコンパイルして、オブジェクトファイルを生成する。同様に、ライブラリソースファイル３０５を、ブロック３１０においてコンパイルして、ダイナミックライブラリを生成する。そして、コンパイル処理３５０によって得たオブジェクトファイルを、ステップ３４５において、スタティック（静的に）リンクして、ダイナミックバイナリ実行可能ファイルを生成する。
【００３８】
図３に示すように、バイナリ実行可能プログラムを、ステップ３４０において、動作させることができる。動作中に、プログラムは、ステップ３３５において、命令の呼び出しを行い、動作中のプログラムによって使用するためにライブラリをオープンすることができる。これに応答して、ホスト環境に設けられた動的リンカー３２０が、要求されたライブラリ３１５を動作中のプログラムのアドレス空間内にロードし、当該ライブラリへのハンドルを返す。次いで、プログラムは、ステップ３２５において、ライブラリハンドルを特殊な関数へ渡して、ライブラリ３１５によってエクスポートされた特定のシンボルのアドレスを得る。ここで参照した特殊な関数は、通常、オペレーティングシステムによって与えられるものであり、例えば、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓの場合には、この特殊なファンクションは、ＧｅｔＰｒｏｃＡｄｄｒｅｓｓと称されている。アドレスを得ると、ライブラリによってエクスポートされたシンボルが、利用可能となり、ステップ３３０において、動作中のプログラムによって呼び出すことができる。
【００３９】
図４及び５は、従来の解決策を用いて、多数のオペレーティングシステム及びプラットホームで動作するようソースコードを処理することを可能とする方法を示している。図４を参照すると、同図では、単一のオペレーティングシステムＡ  ４８５が二つのプラットホームＡ１  ４７５及びＡ２  ４８０をサポートしており、この図４には、ライブラリソースファイル４０５及びプログラムソースファイル４１５を有する例示的なダイナミックリンキングアーキテクチャー４００が示されている。ここでは、ライブラリソースファイル４０５を、ブロック４１０においてコンパイルし、オペレーティングシステムＡ  ４８５用のダイナミックライブラリ４３０を生成する。
【００４０】
同様に、プログラムソースファイル４１５を、ブロック４２０においてコンパイルして、プラットホームＡ１  ４７５用のオブジェクトファイルを生成し、また、同ソースファイル４１５をブロック４２５においてコンパイルし、プラットホームＡ２  ４８０用のオブジェクトファイルを生成する。コンパイル処理４２０によって得たオブジェクトファイルを、スタティックリンクして、ダイナミック実行可能オブジェクトファイルＡ１ｅｘｅｃ４３５（例えば、プラットホームＡ１  ４７５における実行可能ファイル）を生成する。また、図示するように、コンパイル処理４２５によって得たオブジェクトファイルも、スタティックリンクして、ダイナミック実行可能オブジェクトファイルＡ２ｅｘｅｃ４４０（プラットホームＡ２  ４８０における実行可能ファイル）を生成する。そして、ダイナミックリンカー４５５を動作させて、実行時に、動作中のプログラムがライブラリをオープンするためのコール４４５に応答して、ダイナミックライブラリ４３０を、実行可能なプログラムＡ１ｅｘｅｃ４３５にリンクする。このライブラリ４３０を、オペレーティングシステムＡ  ４８５のアドレス空間にロードして、プラットホームＡ１  ４７５で動作する、リンクされた実行可能ファイル４６５を生成する。同様に、動的リンカー４６０が、実行時に、動作中のプログラムがライブラリをオープンするためのコール４５０に応答して、ダイナミックライブラリ４３０を、実行可能なプログラムＡ２ｅｘｅｃ４４０にリンクする。このライブラリ４３０を、オペレーティングシステムＡ  ４８５のアドレス空間にロードして、プラットホームＡ２  ４８０において動作する、リンクされた実行可能ファイル４７０を生成する。動作時には、リンクされた実行可能ファイル４６５又は４７０のいずれかが、各々、ダイナミックライブラリ４３０から関数をコールするか又はデータを検索することができる。
【００４１】
以下、図５を参照する。図５は、ライブラリソースファイル５０５及びプログラムソースファイル５１５を有する例示的なダイナミックリンキングアーキテクチャー５００を示している。ここでは、ライブラリソースファイル５０５を、ブロック５１０においてコンパイルして、オペレーティングシステムＢ  ５８５用のダイナミックライブラリ５３０を生成する。
【００４２】
同様に、プログラムソースファイル５１５を、ブロック５２０においてコンパイルして、プラットホームＢ１  ５７５用のオブジェクトファイルを生成し、また、同ソースファイル５１５を、ブロック５２５においてコンパイルして、プラットホームＢ２  ５８０用のオブジェクトファイルを生成する。コンパイル処理５２０によって得たオブジェクトファイルを、スタティックリンクして、ダイナミック実行可能オブジェクトファイルＢ１ｅｘｅｃ５３５（例えば、プラットホームＢ１  ５７５における実行可能ファイル）を生成する。また、図示するように、コンパイル処理５２５によって得たオブジェクトファイルを、スタティックリンクして、ダイナミック実行可能オブジェクトファイルＢ２ｅｘｅｃ５４０（プラットホームＢ２  ５８０における実行可能ファイル）を生成する。そして、ダイナミックリンカー５５５が、実行時に、動作中のプログラムがライブラリをオープンするためのコール５４５に応答して、ダイナミックライブラリ５３０を、実行可能プログラムＢ１ｅｘｅｃ５３５にリンクするよう動作する。このライブラリ５３０を、オペレーティングシステムＢ  ５８５のアドレス空間にロードして、プラットホームＢ１  ５７５において動作する、リンクされた実行可能ファイル５６５を生成する。同様に、ダイナミックリンカー５６０は、実行時に、動作中のプログラムがライブラリをオープンするためのコール５５０に応答して、ダイナミックライブラリ５３０を、実行可能プログラムＢ２ｅｘｅｃ５４０にリンクするよう動作する。このライブラリ５３０を、オペレーティングシステムＢ  ５８５のアドレス空間にロードして、プラットホームＢ２  ５８０において動作する、リンクされた実行可能ファイル５７０を生成する。動作時には、リンクされ実行可能ファイル５６５又は５７０のいずれかが、各々、ダイナミックライブラリ５３０から関数をコールするか又はデータを検索することができる。
【００４３】
図４及び５に示すように、アプリケーションプログラム４１５及び５１５のそれぞれと、対応のライブラリファイル４０５及び５０５のそれぞれとで構成されるソースコードの共通セットが存在する。例示の実施の形態では、アプリケーションプログラムは、四つの別々のプラットホーム、即ち共通のオペレーティングシステムＡ  ４８５から導出したプラットホームＡ１  ４７５及びＡ２  ４８０と、オペレーティングシステムＢ  ５８５から導出したプラットホームＢ１  ５７５及びＢ２  ５８０とにおいて動作するように書くことができる。アプリケーション４１５及び５１５のソースコードは、各プラットホーム、即ちプラットホームＡ１  ４７５、プラットホームＡ２  ４８０、プラットホームＢ１  ５７５及びプラットホームＢ２  ５８０に特有のインストラクションを保持でき、アプリケーション４１５及び５１５のソースコードをコンパイルするときにプラットホーム依存性を特定できるように書くことができる。
【００４４】
提供した実施の形態では、ライブラリ４０５及び５０５用のソースコードは、一般に、特定のプラットホーム依存性を保持しない。例示の動作においては、ライブラリは、協働するアプリケーションプログラムによってコールすることができ、ダイナミックライブラリとして動作することができる。図４に示すように、各プラットホーム（４７５及び４８０）は、それ自身のダイナミック実行可能ファイルＡ１ｅｘｅｃ４３５、Ａ２ｅｘｅｃ４４０を要求することができ、これらダイナミック実行可能ファイルは、プラットホーム固有のコンパイラツール（例えば、コンパイラブロック４２０及び４２５）を介して共通のアプリケーションソースファイル４１５をコンパイルすることによって生成することができる。例示の実施の形態では、協働するダイナミックライブラリ４３０は、一度で生成することができ、実行可能ファイルＡ１ｅｘｅｃ４３５又はＡ２ｅｘｅｃ４４０の両方に動的にリンクすることができ、各プラットホームＡ１  ４７５及びＡ２  ４８０において動作可能なプロセスを各々生成することができる。
【００４５】
図５は、二つの付加的な実行可能なファイルＢ１ｅｘｅｃ５３５及びＢ２ｅｘｅｃ５４０をコンパイルして、プラットホームＢ１  ５７５及びプラットホームＢ２  ５８０においてアプリケーションを動作させることを可能にすることを示している。加えて、新たなダイナミックライブラリ５３０を生成して、実行可能ファイルＢ１ｅｘｅｃ５３５及びＢ２ｅｘｅｃ５４０にリンクしている。これは、実行可能ファイルＢ１ｅｘｅｃ５３５及びＢ２ｅｘｅｃ５４０は、オペレーティングシステムＢ５８５用に構築されるからである。かかる実施の形態では、二つのオペレーティングシステム（各々、オペレーティングシステムＡ４８５及びオペレーティングシステムＢ５８５）で動作する四つのプラットホーム（プラットホームＡ１  ４７５、プラットホームＡ２  ４８０、プラットホームＢ１  ５７５、及びプラットホームＢ２  ５８０）にわたるライブラリのダイナミックリンキングを実現するために、四つのダイナミック実行可能ファイル及び二つダイナミックライブラリを構築することが要求される。従来の解決策では、異種のコンピューティング環境で動作可能なバイナリオブジェクトの開発は、リソースを消費することが明らかである。
【００４６】
図６は、例示的コンピューティング環境６００のコンポーネントを示す。図６に示すように、ソースコード６０７とＣＰＵ６７０との間にレイヤ６０５、６１０及び６１５の階層が存在することがある。このような階層は、最上位及び最下位レイヤにおいては高度の共通性を示すが、それらの間では多様性(proliferation)を示す。最も高いレベル６０５では、ソースコード６０７は、全ての協働するプラットホームに対して大部分は共通であり、幾つかの限定されたプラットホーム特有のエレメント６２０を伴っている。最も低いレベル６１５では、コードがＣＰＵ６７０において動作する。例示の実施の形態では、ＣＰＵ６７０のアーキテクチャーが多数の異種のコンピューティング環境（図示せず）の間で共通である場合に、低レベルのマシン命令が同一であることが予想される。しかしながら、中間レイヤ６１０は、多数のプラットホーム変形６３０、６３５、６４５、６５０及び６６０を各々伴う多数のオペレーティングシステム６４０、６５５及び６６５を保持し、それらの個別の特性及びツールチェーンのために個々のバイナリを要求することができる。また、図示するように、最上位レイヤ６０５は、プラットホーム及びオペレーティングシステムの両方について独立できるプラットホーム独立のソースコード６２５を含む。
【００４７】
例示の実施の形態においては、図６を参照すると、三つのオペレーティングシステムにおいて五つのプラットホームが動作する。より詳細には、プラットホームＡ１  ６３０、プラットホームＡ２  ６３５がオペレーティングシステムＡ  ６４０において動作し、プラットホームＢ１  ６４５及びＢ２  ６５０がオペレーティングシステムＢ  ６５５において動作し、更に、プラットホームＣ１  ６６０がオペレーティングシステムＣ  ６６５において動作する。従来の方法では、コンピュータプログラムの適切に動作させるために、各アプリケーションプログラムの五つの異なるバージョン（各プラットホームに対して一つ）と、三つの別々のダイナミックライブラリ（各ＯＳに対して一つ）とを生成することが要求される。本明細書で説明するシステム及び方法は、五つのプラットホーム及び二つのオペレーティングシステムにわたって動作する単一のダイナミックライブラリを提供することによって、従来の慣例の欠点を改善することを目的としている。例示の実施の形態では、特定のＣＰＵアーキテクチャーを組み込んだ全てのシステムにおいて、当該ＣＰＵにおいて動作するＯＳに関わらず、使用できる単一セットのバイナリライブラリを生成し、従って、図６の最上位レイヤ６０５及び最下位レイヤ６１５における共通性を活用する。
【００４８】
本明細書で説明するシステム及び方法は、種々のコンピューティング環境に適用することができる。例示の実施の形態では、本明細書で説明するシステム及び方法は、ＩＮＴＥＬ（登録商標）ｘ８６ファミリーからのプロセッサを一般的に含むデスクトップシステムに適用されてもよい。デスクトップＰＣにおける共通のオペレーティングシステムは、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）及びＬｉｎｕｘであり、これらは、両者とも、ダイナミックリンキング機能を有する。しかしながら、これらのオペレーティングシステムは、それらのバイナリオブジェクト用に互換性のないフォーマットを使用しており、従って、個別のライブラリが、当該ライブラリが同じＣＰＵにおいて動作することができるとしても、Ｌｉｎｕｘ及びＷＩＮＤＯＷＳ（登録商標）用に設けられる。
【００４９】
移動及び埋め込み型装置については、多様性の問題が著しく大きなものとなり得る。より詳細には、移動及び埋め込み型装置は、Ｌｉｎｕｘ、ＷＩＮＤＯＷＳ（登録商標）ＣＥ、ＰａｌｍＯＳ（登録商標）、ＳｙｍｂｉａｎＯＳ（登録商標）、ＢＲＥＷ（登録商標）、Ｉｔｒｏｎを含む（これらに限定されないが）著しく多数のオペレーティングシステムを利用する。しかしながら、ＣＰＵレベル６１５では、ＡＲＭ  ＲＩＳＣアーキテクチャーのような選択されたコンピュータハードウェアアーキテクチャーに基づく相当の共通性が存在する。現在の慣例では、このような共通性が利用されておらず、代わりに、ＯＳ又はプラットホームレイヤ（例えば、６１０）に基づいて調整されたライブラリが生成される。
【００５０】
例示の実施の形態では、本明細書で説明するシステム及び方法を、選択されたコンピューティング環境マーケット（例えば、移動装置マーケット）に適用して、選択されたハードウェアアーキテクチャー（例えば、ＡＲＭプロセッサを含む装置）で動作するコンピューティング環境上で、ソフトウェアプラットホームに関わらず動作することができる単一ソフトウェアライブラリを配布することができる。このような解決策は、ソフトウェア開発者及び顧客の両者に種々の商業的利益を提供することができ、当該利益には、限定するものではないが、特定プラットホーム向けライブラリの多数のバージョンを開発して維持するコストの節減がある。さらに、同一のコンポーネントを用いた多数のインストールに渡る経験の累積によって、コードのクオリティを迅速に確立することができる。更に、ライブラリに対する変更を、かかる解決策によって、より完全に且つ効率的にテストすることができる。装置メーカー（例えば、セルラー電話製造者）は、共通のライブラリを、当該ライブラリが単一の製品範囲において実証された場合に、それらの多様な製品範囲にわたって、使用することができる。
【００５１】
本明細書における以下の例示の実施の形態及び図面は、特に、ランタイムでのライブラリのダイナミックリンキングに関連するものである。
【００５２】
図７Ａは、例示的なプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００を示す。図示するように、プラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００は、メインアプリケーションソースコード７０５を含むソースコードと、プラットホーム独立のソースコードコンポーネントとを備え、当該ソースコードコンポーネントは、限定するものではないが、プラットホーム独立のダイナミックライブラリ（ＰＩＤＬ）ソース７２５、コンパイラ７３０、ＰＩＤＬオブジェクトファイル７３５、ＰＩＤＬ動的ローダ／リンカーのソースコード７２０を含む。
【００５３】
例示の動作においては、ＰＩＤＬソース７２５が、ブロック７３０において、標準オブジェクトフォーマットへとコンパイルされ、ＰＩＤＬオブジェクトファイル７３５が生成される。図７に示すように、メインアプリケーションソース７０５、及び動的ローダ／リンカーのソースコード７２０（例えば、コンパイルコンポーネントのソースコードのセット７４５）は、ステップ７７０において、コンパイルされ、ターゲットプラットホームに用に構築される。得られたダイナミックバイナリ実行可能ファイル７９５は、メインアプリケーションファンクション７７５、及びダイナミックＰＩＤＬローダ／リンカーファンクション７８５を利用して、関数をコールして、ＰＩＤＬオブジェクトファイル７３５からデータを取り出す。
【００５４】
例示的なプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００は、種々のコンポーネントを特定のコンフィギュレーションで有するように示されており、特定のオペレーションを実行するように説明されるが、本明細書で説明する本発明の概念は、種々のコンポーネント、コンフィギュレーション及びオペレーションを有するいかなるプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャーにも適用できるので、このような説明は、単なる例示に過ぎないことが明らかであろう。
【００５５】
例示の実施の形態では、例示的なプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００は、次の方法に基づいて動作することができる。ＰＩＤＬオブジェクトファイル７３５は、その構造が充分に定義された標準的なオブジェクトファイルフォーマットで生成することができる。ダイナミックローダ／リンカー７２０は、これがメインアプリケーションプログラム７０５と共に含まれ得るように書きことができる。例示の実施の形態では、ターゲットプラットホームが既知である場合に、結合したソースコード（例えば、コンパイルコンポーネントソースコード７４５のセット）を、所与のプラットホーム（図示せず）用のバイナリ実行可能ファイル７９５へとコンパイルすることができる。実行時には、ダイナミックローダ／リンカー７８５（例えば、コンパイルされたローダ／リンカー）が、動作中のアプリケーション７７５からの命令のもとでライブラリ７３５をロードし、ＰＩＤＬファイル７３５へハンドルを返すことができる。また、ダイナミックリンカー／ローダ７８５は、ＰＩＤＬ７３５によってエクスポートされたシンボルのアドレスを得る関数を含み、アプリケーション７７５が、ＰＩＤＬのシンボルを、それ自身で使用するために、その返されたシンボルのアドレスポインタによって呼び出すことを可能にする。
【００５６】
上述したように、ダイナミックライブラリのプラットホーム独立性は、最初に、ライブラリソース７２５のコードを既知のオブジェクトファイルフォーマット７３５へコンパイルすることによって、達成できる。意図する実施の形態においては、ＰＩＤＬソース７２５は、特定のプラットホームに対する依存性をもたない。オブジェクトファイルフォーマット（図示せず）は、通常、多数な種類の情報を含むことができる。当該情報には、限定するものではないが、コードのサイズといったヘッダ情報、コンパイラ又はアセンブラによって発生されるオブジェクトコード、オブジェクトコードのアドレスがリンカーによって扱われるときにリンカー７８５によって使用するための再配置情報、及びこのモジュールからエクスポートされるか又は他のモジュールからインポートされるシンボルのシンボルテーブルがある。
【００５７】
例示の実施の形態では、プラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００は、種々のオブジェクトファイルフォーマットを活用することができる。当該フォーマットには、限定するものではないが、ＥＬＦ（実行可能ファイル及びリンキングフォーマット）、ＭＩＣＲＯＳＯＦＴ（登録商標）ポータブル実行可能ファイル(Portable Executable)（ＰＥ）フォーマット、及び他のオブジェクトフォーマット（例えば、本明細書で説明するシステム及び方法用に特に設計されたオブジェクトフォーマット）がある。
【００５８】
従来、異なるオペレーティングシステム及びプラットホームは、異なるオブジェクトファイルフォーマットを使用している。これらプラットホーム用のリンカー及びローダは、これらの予め定義されたフォーマットでリンク可能なオブジェクトを受け取ることを期待し、他のフォーマットは拒絶する。また、プラットホームがダイナミックリンキングを提供する場合には、ダイナミックリンカーがオペレーティングシステムの一部となり、固有のオブジェクトフォーマットに「固定配線(hard wired)」することができる。
【００５９】
本明細書で説明するシステム及び方法は、汎用のローダ／リンカー７２０を提供することによって、この欠点を改善する。例示の実施の形態では、この汎用ローダ／リンカー７２０は、選択されたオブジェクトファイルフォーマット（例えば、ＥＬＦ、又は選択された他の何らかのオブジェクトフォーマット）でオブジェクトファイルを処理するように書くことができる。動作中に、汎用ローダ／リンカー７８５は、ＰＩＤＬオブジェクトファイル７３５内のシンボル、再配置情報、及び他の情報を特定するように動作する。図７に示すように、ローダ／リンカー７２０の配備は、協働するメインアプリケーション７０５のソースコードと共にコンパイルされるソースコードの生成を介して、達成することができる。この点で、リンキング及びローディング制御は、オペレーティングシステムから除去されて、動作している実行可能ファイルに含められる。また、ダイナミックローダ／リンカー７８５は、非ＰＩＤＬライブラリを処理するように動作することもできる。この点について、ダイナミックローダ／リンカー７８５は、ダイナミックライブラリがＰＩＤＬ形式であるか、非ＰＩＤＬ形式であるかを確認し、それに応じてＰＩＤＬ又は非ＰＩＤＬライブラリを処理するように設計することができる。例示の実施の形態では、非ＰＩＤＬライブラリが処理される場合には、リンキング及びローディングの制御を、基礎となるオペレーティングシステムへ戻すことができる。
【００６０】
例示の実施の形態では、ＰＩＤＬオブジェクトファイルは、再構築又は再コンパイルの必要なく、異種のプラットホームにわたって使用することができる。この実施の形態では、メインアプリケーションプログラムが、選択されたプラットホーム用のダイナミックリンカー／ローダのコードと共にコンパイルされ、リンキングの制御がプラットホームに依存せず、代わりに、実行可能ファイル内に配されるので、ランタイムでのＰＩＤＬのリンキングは、ＰＩＤＬオブジェクトを再コンパイル又は再生成する必要なく、異種のプラットホームにおいて達成することができる。
【００６１】
ダイナミックリンカー／ローダ７８５は、ファンクションコール（ＰＩＤＬＯｐｅｎ、ＰＩＤＬＣｌｏｓｅ、ＧｅｔＰＩＤＬＡｄｄｒｅｓｓ）を含むものであり、当該ファンクションコールをアプリケーションプログラム７７５によって使用して、ＰＩＤＬオブジェクト７３５をオープン及びクローズを行ない、ＰＩＤＬによってエクスポートされたシンボルのアドレスを返すことができる。ＰＩＤＬをオープン及びクローズすることは、ＰＩＤＬオブジェクトを動作中のアプリケーションのメモリ空間へロードし、また、そこからアンロードすること、シンボルアドレスの必要な再配置を実行することを含む。ＧｅｔＰＩＤＬＡｄｄｒｅｓｓ関数は、ＰＩＤＬシンボルの再配置されたアドレスを返して、アプリケーション７７５がこのアドレスに対するポインタを経てシンボルを呼び出すことを可能にする。ＧｅｔＰＩＤＬＡｄｄｒｅｓｓは、ＰＩＤＬオブジェクトファイル内のシンボルテーブルに問い合せて、ライブラリのゼロのベースメモリアドレスを想定したシンボルアドレスを検出する。このアドレスは、メモリにロードされたときのＰＩＤＬの実際の非ゼロのベースアドレスを考慮して、再配置後に返される。ダイナミックリンカー／ローダ７８５における関数のこの組み合せは、ランタイムでのダイナミックリンキングを可能とし、ロードタイムでのダイナミックリンキングのもとで必要とされるライブラリスタブファイルの必要性を排除する。
【００６２】
本明細書で説明するシステム及び方法は、メインアプリケーションがダイナミックリンカーと共にコンパイルされる場合に、メインアプリケーションが、ＰＩＤＬオブジェクトとして配備されたダイナミックライブラリへランタイムでアクセスすることを可能にすること理解されよう。図７Ａの実施の形態は、メインアプリケーション７７５による使用のために、エクスポートされたＰＩＤＬシンボルが提供される。また、ＰＩＤＬがアプリケーション７７５に含まれたシンボルをインポートして、両方向依存性を生成することも要望され得る。本明細書で説明するシステム及び方法は、ＰＩＤＬがメインアプリケーションのファンクションへのアクセスを要求する場合も考慮している（図８において説明するように）。図８を参照すると、関数、即ち、シンボルＡ及びＢ用のコードを、メインプログラム８１０内に配置することができ、また、関数Ｃ、Ｄを、ダイナミックライブラリ８２０内に配置することができる。例示の実施の形態では、ダイナミックライブラリ８２０がＡ及びＢをコールし、或いはメインプログラム８１０がライブラリ関数Ｃ又はＤを使用するために、シンボルと、全関数の位置が、結合されたプログラムにおいて解決されなければならない。例示の実施の形態では、この動作は、例示的リンカー（図示せず）によって実行することができる。
【００６３】
従来の慣例では、ダイナミックリンカーは、一般に、オペレーティングシステムの一部である。このような状況では、異なるシステムがそれら自身のリンカー及びオブジェクトフォーマットを使用するので、プラットホーム依存のライブラリスタブファイルが得られることになる。所与のプラットホーム内では、ライブラリ８２０がメインプログラム８１０へコールバックしてもよい（例えば、関数Ａ及びＢにアクセスするために）。これは、メインプログラム８１０のオブジェクトファイルのフォーマットが既知だからである。ライブラリは、ダイナミックリンカー内に設けられたランタイムファンクションコール（例えば、Ｗｉｎｄｏｗｓ（登録商標）のＧｅｔＰｒｏｃＡｄｄｒｅｓｓ）を使用して、メインプログラム８１０からインポートされたシンボルのアドレスを検出し、次いで、当該ライブラリ自身で使用するためにそのインポートされたシンボルを呼び出す。これらは、ライブラリ８２０によってエクスポートされたシンボルを特定するためにプログラム８１０によって他の方向に使用されるものと同じ関数コールである。これは、単一のプラットホームでは、全てのオブジェクトファイルが、同じ既知のフォーマットであるからである。
【００６４】
しかしながら、この従来の解決策は、本明細書に開示するプラットホーム独立のケースでは、機能しない。ランタイムリンキング関数（ＰＩＤＬＯｐｅｎ、ＰＩＤＬＣｌｏｓｅ、ＧｅｔＰＩＤＬＡｄｄｒｅｓｓ）は、ＰＩＤＬによってエクスポートされたシンボルを取り扱うときには一方向において正しく動作する。これは、ＰＩＤＬが、ダイナミックリンカー／ローダ７８５に既知の定義されたオブジェクトフォーマット（例えば、ＥＬＦ）で生成されるからである。ＧｅｔＰＩＤＬＡｄｄｒｅｓｓは、そのシンボルテーブルをサーチするときに、この予め定義されたオブジェクトフォーマットを予想して、シンボルアドレスを返す。しかしながら、同じ関数コールでは、ＰＩＤＬへインポートされるシンボルを取り扱うことはできない。これは、ダイナミックバイナリ実行ファイル７９５は、特定のターゲットプラットホーム用に構築されており、それ故、そのオブジェクトフォーマットがプラットホームに依存しており、リンカー７８５に設けられたＧｅｔＰＩＤＬＡｄｄｒｅｓｓ関数によって想定されたフォーマットとは異なるからである。それ故、図７Ａの実施の形態は、エクスポートされたシンボルを取り扱うには充分であるが、シンボルがライブラリにもインポートされる図８に示す状況を取り扱うには更なる改善が要求される。
【００６５】
図７Ｂは、インポートされるシンボルを取り扱うように拡張された、例示的なプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００を示す。図示するように、プラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００は、メインアプリケーションソースコード７０５を含むソースコードと、プラットホーム独立のソースコードコンポーネントとを備えている。当該ソースコードコンポーネントには、限定するものではないが、プラットホーム独立のダイナミックライブラリ（ＰＩＤＬ）ソース７２５、コンパイラ７３０、ＰＩＤＬオブジェクトファイル７３５、ＰＩＤＬダイナミックローダ／リンカーのソースコード７２０、定義されたアプリケーションプログラムインターフェイス（ＡＰＩ）７１０、及びＡＰＩパーサー７１５がある。
【００６６】
例示の動作においては、ＰＩＤＬソース７２５が、ブロック７３０において、標準オブジェクトフォーマットへとコンパイルされ、ＰＩＤＬオブジェクトファイル７３５が生成される。同様に、アプリケーションプログラムインターフェイス（ＡＰＩ）パーサー７１５が、ＡＰＩ７１０に対して動作して、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数を生成して、協働するメインアプリケーション７０５へのＰＩＤＬオブジェクトファイル７３５によるアクセスを可能とする。図７Ｂに示すように、メインアプリケーションソース７０５、ダイナミックローダ／リンカーのソースコード７２０、及び、実行される場合には、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌソース関数７５５（例えば、コンパイルコンポーネントのソースコードのセット７４５）が、ステップ７７０において、ターゲットプラットホーム用にコンパイルされ構築される。得られたダイナミックバイナリ実行可能ファイル７９５は、メインアプリケーション関数７７５、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数７８０、及びダイナミックＰＩＤＬローダ／リンカー関数７８５を利用して、関数をコールし、ＰＩＤＬオブジェクトファイル７３５からデータを取り出す。
【００６７】
このような状況では、メインアプリケーションによってＰＩＤＬライブラリに露出された関数をもつＡＰＩ（図７Ｂの７１０）（アプリケーションプログラミングインターフェイス）を、最初に指定して公開することができる（ＰＩＤＬがその露出された関数を使用できるように）。次いで、ＡＰＩ（図７の７１０）を解析して、ソースコード関数ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ（図７Ｂの７５５）を発生することができ、当該関数をメインアプリケーションの一部としてコンパイルすることができる（図７Ｂに示すように）。さらに、ソースコード７５５は、プラットホーム依存性をもたない。動作時には、ＰＩＤＬライブラリ７３５が、インポートされるべきシンボルの名前でＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数をコールすることによって、アプリケーションインターフェイスＡＰＩ７１０で定義されたシンボルをインポートすることができる。ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数は、要求されたシンボルのアドレスを返し、次いで、当該シンボルを、その返送されたアドレスを経てＰＩＤＬライブラリによって呼び出すことができる。
【００６８】
ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌをソースコードとしてコンパイルすることによって、ソース７４５が異なるプラットホーム用にコンパイルされる場合でも、ＰＩＤＬライブラリは、インポートされたシンボルのアドレスへのアクセスが保証される。ソースコードは、コンパイル処理７７０によって発生されるオブジェクトフォーマットに関わらず、要求されたシンボルの実際のアドレスを検出して返すことができる。動作時には、メインプログラムは、ダイナミックライブラリに存在する名前付き関数をコールすることができ（ＧｅｔＰＩＤＬＡｄｄｒｅｓｓを使用して）、ダイナミックライブラリは、メインプログラムにおける関数をコールすることもできる（ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌをコールすることにより）。正しく機能するための組み合せの場合には、ローダが全てのオブジェクトコードコンポーネントをコンピューティング環境のメモリに配置すると、関数コールを解決して、適切なアドレスに再配置することができる。
【００６９】
ソースファンクションＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌを発生するための別の実施の形態を図７Ｃに示す。図示するように、プラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャー７００は、メインアプリケーションソースコード７０５を含むソースコードと、プラットホーム独立のソースコードコンポーネントとを備えている。これらのコンポーネントには、限定するものではないが、プラットホーム独立のダイナミックライブラリ（ＰＩＤＬ）ソース７２５、コンパイラ７３０、ＰＩＤＬオブジェクトファイル７３５、ＰＩＤＬダイナミックローダ／リンカーのソースコード７２０、及びオブジェクトパーサー７４０がある。
【００７０】
例示の動作においては、ＰＩＤＬソース７２５が、ブロック７３０において、標準オブジェクトフォーマットへとコンパイルされ、ＰＩＤＬオブジェクトファイル７３５が生成される。同様に、オブジェクトパーザ７４０が、オブジェクトファイル７３５に対して動作して、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌファンクションを生成し、協働するメインアプリケーション７０５へのＰＩＤＬオブジェクトファイル７３５によるアクセスを可能とする。図７Ｃに示すように、メインアプリケーションソース７０５、動的ローダ／リンカーのソースコード７２０、及び、実行される場合には、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌソースファンクション７５５（例えば、コンパイルコンポーネントのソースコードのセット７４５）は、ステップ７７０において、ターゲットプラットホーム用にコンパイルされ構築される。得られるダイナミックバイナリ実行可能ファイル７９５は、メインアプリケーション関数７７５、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数７８０、及びダイナミックＰＩＤＬローダ／リンカー関数７８５を活用して、関数をコールし、ＰＩＤＬオブジェクトファイル７３５からデータを取り出す。
【００７１】
オブジェクトファイルフォーマット（図示せず）は、通常、多数の形式の情報を含むことができる。当該情報には、限定するものではないが、コードのサイズといったヘッダ情報、コンパイラ又はアセンブラにより発生されるオブジェクトコード、オブジェクトコードのアドレスがリンカーによって扱われるときにリンカー７８５によって使用するための再配置情報、及びこのモジュールからエクスポートされるか又は他のモジュールからインポートされるシンボルのシンボルテーブルがある。
【００７２】
予想されるオブジェクトフォーマットの知識をもつパーサー７４０は、オブジェクトを解析して、オブジェクトによってインポートされるシンボルを特定し、解析結果に基づいてソースコード関数７５５を発生して、インポートされたシンボル各々のアドレスを得ることができる。オブジェクトパーサー７４０は、ＰＩＤＬオブジェクトファイル７３５を通して解析を行ない、シンボル名及びプロパティを抽出し、ソースファイル７５５（例えば、“Ｃ”言語又はそれと同等のものを含む（これに限定されないが）高レベル言語で）をパーサー出力として生成する。このソースＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ７５５は、図７Ｂにおける同じ名前のソースと同じ関数を実行する。実施の方法の相違は、図７Ｂでは、ＡＰＩ７１０を解析すると、メインアプリケーションＡＰＩにおける全てのシンボルが、ＰＩＤＬ７３５により使用されるかどうかに関わらず、露出されることである。図７Ｃでは、オブジェクトファイル７３５を解析した結果として、ライブラリ７３５へインポートすることを実際に要求するシンボルだけが露出される。
【００７３】
例示の実施の形態の例示的動作においては、メインプログラムが動作を開始すると、当該メインプログラムが、プラットホームローダによってメモリに配置される。実行中に、メインプログラムは、それ自身に対して外部にあるライブラリをロードするためのコールを行なうか否かを決定する。このようなコールは、ＰＩＤＬローダ／リンカーを呼び出し、当該ＰＩＤＬローダ／リンカーは、最初に、呼び出された関数を含むライブラリの名前及びパスを決定する。ライブラリが、ＷＩＮＤＯＷＳ（登録商標）ＤＬＬのような普通の特定プラットホーム向けダイナミックライブラリである（ＰＩＤＬではない）場合には、リンカーは、普通のプラットホームライブラリローダが存在するときには、これに制御を引き渡す。しかしながら、そうではなく、ライブラリオブジェクトがＰＩＤＬである場合には、当該ＰＩＤＬが動作中のプログラムのメモリスペースにロードされる。
【００７４】
リンカー／ローダは、“ＯｐｅｎＰＩＤＬ”関数のコールに応答して、ＰＩＤＬオブジェクトを表すプログラムされた構造体を生成することができる。リンカー／ローダは、次いで、オブジェクトに問い合せて、コードサイズ（例えば、オブジェクトファイルフォーマット内のフィールドで定義され、従って、容易に利用できる）を検出することができ、適切なサイズのメモリの固定ブロックを割り当てることができ、ＰＩＤＬファイルをその割り当てられたメモリにロードすることができる。
【００７５】
次いで、リンカーは、メモリにおいてシンボルアドレスを再配置するように動作する。そして、ＰＩＤＬ内の内部シンボルが再配置される。動作時には、バイナリファイルは、オブジェクトコード内にシンボルのアドレスを含むが、一般的には、ライブラリコードに対してゼロのベーススタートアドレスがあるという仮定のもとで動作する。しかしながら、ＰＩＤＬは、異なるアドレスに配置されており、当該アドレスは、ＰＩＤＬがメモリにロードされるので確認することができる。リンカーによる再配置は、メモリブロックの実際のスタートアドレスを考慮するためのシンボルアドレスの調整を含むことができる。
【００７６】
内部ＰＩＤＬのシンボルを再配置した後に、リンカーは、ＰＩＤＬの外部にあってＰＩＤＬによってコールされる全ての記号、例えば、メインアプリケーションに含まれた関数をアクセスすることができる。これらのシンボルに対して、リンカーは、外部シンボルの名前を引数として用いて、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数をコールすることができる。この関数は、ＰＩＤＬによってインポートされる全てのシンボルのリストを含むので、名前を整合させて、その名前付きシンボルの実際のアドレスを返すことができる。これらのインポートされたシンボルへのＰＩＤＬによるその後のコールは、ＰＩＤＬをオープンするプロセス中にこのようにパッチされた実際のシンボルのアドレスを使用する。
【００７７】
この段階において、ＰＩＤＬは、それがエクスポート及びインポートするシンボルの正しいアドレスを保持する。再配置が完了した後に、ＰＩＤＬによってエクスポートされたシンボルの再配置されたアドレスを、リンカーへ返すことができる。メインプログラムは、再配置されたシンボルにアクセスすることができ、ＰＩＤＬの外側からＰＩＤＬのシンボルの一つへＧｅｔＰＩＤＬＡｄｄｒｅｓｓコールがなされるときに、正しいシンボルのアドレスが使用されるようにする。
【００７８】
本明細書で説明するシステム及び方法は、単一アプリケーションにリンクされた多数のライブラリ（例えば、ＰＩＤＬ）と共に使用することができる。これらのライブラリは、第１ライブラリからのＯｐｅｎＰＩＤＬ及びＧｅｔＰＩＤＬＡｄｄｒｅｓｓコールを使用して、ランタイムに一方から他方へコールを行い、第２ライブラリによってエクスポートされた関数及びシンボルにアクセスすることができる。多数のライブラリが使用される状態では、メインアプリケーションからシンボルをインポートするためのリンキングメカニズムを、均一的に適用することができる。各ダイナミックライブラリは、標準的なオブジェクトフォーマットでセーブされ、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌスタブは、ＰＩＤＬによりインポートされたシンボルへの参照を含むソースフォーマットで発生される。これは、図７Ｂの場合のように、メインアプリケーションの露出されたＡＰＩを解析することにより、又は図７Ｃの場合のように、ライブラリオブジェクトの各々を解析し、そして各解析オペレーションから得られたソースコードを単一のＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数へ収集することにより、生成されてもよい。メインプログラムは、それが使用するＰＩＤＬライブラリ用に収集されたＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌコードと共に、コンパイルされる。ダイナミックローダ／リンカーは、それがコールされたときに、ランタイムに各ライブラリをロードして再配置し、更に、ＰＩＤＬライブラリの間でメインプログラムを用いてシンボルのポインタを返すための情報が、プログラムへとコンパイルされたダイナミックローダ／リンカー（例えば、図７Ａ−Ｃの７８５）及びＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌコード（例えば、図７Ｂ−Ｃの７５５）によって取り扱われる。
【００７９】
＜４．プラットホーム独立のダイナミックライブラリ＞
図９は、一つ以上のＰＩＤＬのランタイムリンキングを実行するときに例示的コンピューティング環境によって実行される処理を示している。図示するように、処理は、ブロック９００にて始まり、ここで、ダイナミックライブラリ実行可能ファイルがコンパイルされて構築される（図７において述べたように、例示的なダイナミックバイナリ実行可能ファイルは、限定するものではないが、コンパイルされたメインアプリケーションソースコード、ＰＩＤＬローダ／リンカーのソースコード、及びＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数のソースコードを含むことができる）。ここから、処理は、ブロック９１０へ進み、例示的コンピューティング環境においてダイナビック実行可能ファイルを動作させる。次いで、処理は、ブロック９１５へ進み、協働するコンピュータプログラムがライブラリをオープンするＰＩＤＬＯｐｅｎのコールを行うことが決定される。ローダは、ブロック９２０において、ＰＩＤＬＯｐｅｎコールで指定されたパスをサーチし、次いで、ブロック９２５において、サーチが成功であったかどうかを決定するチェックが実行される。サーチが失敗の場合には、ＰＩＤＬＯｐｅｎコールは、ブロック９３０において、ナル引数を返し、処理が終了となる。
【００８０】
しかしながら、ブロック９２５において、ＰＩＤＬオブジェクトが指定のパスに見つかった場合には、処理はブロック９３５へ進み、ここで、ＰＩＤＬオブジェクト用のプログラムされた構造体が生成されて、所定のファイルフォーマットを伴うＰＩＤＬオブジェクトファイルの情報を問い合せできるようになる。次いで、ブロック９４０において、ＰＩＤＬオブジェクトのサイズが決定され、そこから、処理はブロック９４５へ進み、メモリブロックが割り当てられて、その割り当てられたブロックにＰＩＤＬオブジェクトファイルをロードすることができる。次いで、ブロック９５０において、オブジェクトファイルから抽出されたシンボルテーブル及びロードアドレスを使用して、ＰＩＤＬの内部シンボルが再配置される。ブロック９５５において、ＰＩＤＬがシンボルもインポートするか否か決定するためのチェックが行われる。シンボルをインポートしない場合には、処理はブロック９６５へ進む。しかしながら、インポートされたシンボルが利用される場合には、ダイナミックリンカーは、ブロック９６０において、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数をコールし、インポートされたシンボルの実際のアドレスを解決する。処理はブロック９６５へ進み、ＰＩＤＬを特定するハンドルを呼び出し側プログラムに提供する。ＰＩＤＬＯｐｅｎ手順は、ブロック９７０において、ＰＩＤＬをメモリにロードし、シンボルアドレスを解決して、ハンドルを返し、終了となる。
【００８１】
呼び出し側プログラムは、ブロック９７５において、ＧｅｔＰＩＤＬＡｄｄｒｅｓｓ関数をコールすることによって、エクスポートされたＰＩＤＬシンボルの一つをアクセスすることができる。この関数は、ダイナミックリンカー／ローダ（例えば、図７の７８５）に設けられており、ブロック９８０において、ＰＩＤＬによってエクスポートされるシンボルのアドレスを得て、それを呼び出し側プログラムへ返すように働く。そこから、呼び出し側プログラムは、ブロック９８５において、それ自身で使用するためのＰＩＤＬシンボルを、ブロック９８０で返送されたアドレスに対するポインタを使用して、呼び出すことができる。
【００８２】
＜５．制約のある環境におけるダイナミックリンキングのためのメカニズム＞
あるオペレーティングシステムは、ダイナミックリンキング能力を備えていない。これらシステムでライブラリが使用される場合には、ライブラリが静的にリンクされ、即ちライブラリをリンク時に実行可能ファイルに結合することができる。実行可能ファイルもまた、更なるリンキングを行なわずに実行の準備ができているので、静的であり、更に、リンキングが完了した後には変更し得ない。一般的に、スタティックリンクライブラリは、それが結合された基礎的なプログラムに影響（例えば、切断又は停止）を与えずには、変更することができない。また、ライブラリにおけるルーチン及びデータのアドレスはプログラムに結合されるので、これらのアドレスを変更すると、それに結合されたプログラムに機能不良を生じる。
【００８３】
本明細書で説明するシステム及び方法は、動的な実行をネイティブにサポートしないオペレーティングシステムにおいてランタイムに動的な実行を提供することによって、既存の慣例の欠点を改善する。例示の実施の形態では、ダイナミックリンキングは、ランタイム又はロードタイムまでリンキングを延期する能力、又は実行可能なプログラムが、スタティックリンクされていないライブラリを使用する能力と考えることができる。さらに、本明細書で説明するシステム及び方法は、所与のオペレーティングシステムによって本来はサポートされないバイナリオブジェクトフォーマットのリンキングを可能にする。
【００８４】
例示の実施の形態では、より大きなプログラムを、メインアプリケーションと、サポート機能を提供するセットのコンポーネントライブラリとに分けることができる。従来の慣例では、プログラム全体が単一の静的な実行可能ファイルとして提供される。従って、プログラムに対する変更が必要になった場合には、完全に新しい実行可能ファイルを構築して、非変更バージョンに置き換えるように配布される。対照的に、例示の実施の形態では、コンポーネントを、それらを使用するアプリケーションとは独立して、一度に供給することができる。従って、アプリケーションを、より小さなサイズとすることができ、新たなアプリケーション又は変更されたアプリケーションが要求される場合には、それに関連したライブラリの再構築を必要とせずに、アプリケーションそれ自体の再構築が要求されるだけとなる。
【００８５】
逆に、例示の実施の形態では、アプリケーションが不変のままで、コンポーネントの一つを変更する場合には、その新たなコンポーネントを、他のコンポーネントへの変更を行なわずに、以前のバージョンに置き換えることができる。改訂バージョンのシンボル名が同じである場合には、新たなコンポーネントバージョンは、ランタイムに、オリジナルのアプリケーションプログラム及び他のコンポーネントにリンクすることができる。例示の実施の形態では、ダイナミックリンカーが、アドレスリ再配置を扱う。シンボルが新たなコンポーネントバージョンにおいて異なるアドレスにある場合であっても、アドレスは、依然として、ランタイムに解決され、再配置される。
【００８６】
図１０は、動的な実行をサポートしないコンピューティング環境にＰＩＤＬを配備するときに実行される処理を示す。図１０に示すように、処理はブロック１０００で始まり、ここで、プログラムは、メインアプリケーションと、ダイナミックライブラリとしてランタイム配備されるよう意図された一つ以上のライブラリとに分けられる。次いで、ライブラリを、ブロック１０２０において、既知の標準ファイルフォーマットを有するＰＩＤＬオブジェクトファイルへとコンパイルすることができる。メインアプリケーションのソースコードは、ブロック１０１０において、ダイナミックリンカーローダのソースコードと、ＰＩＤＬがアプリケーションからシンボルをインポートする場合にはＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数用の追加のソースコードと共に、コンパイルすることができる。リンカー／ローダコンポーネントは、既知の標準ファイルフォーマットでのＰＩＤＬオブジェクトファイルを翻訳するための上述した機能を有しており、それらをメモリにロードすることができ、更に、必要なリンキング動作を行って、ライブラリとその協働するアプリケーションとの間でシンボルを分析して再配置することができる。
【００８７】
上述したブロック１０００−１０２０で実行される全ての関数及び／又はオペレーションは、プログラムを配備及び実行する前のビルドタイムにおいて実行することができる。動的なリンキングを本来はサポートしない制約のある環境では、構築された実行可能ファイルと外部ライブラリとの間のその後の協働又は相互作用を一般的に達成できない。例示の実施の形態では、対照的に、更なるブロック１０４０から１０９０を提供して、ロードタイム及びランタイムに動的なオペレーションを可能とする。構築された実行可能ファイルは、ブロック１０４０において、実行を開始するように命令され、ブロック１０５０において、通常、ネイティブなオペレーティングシステムの制御のもとでメモリにロードすることができる。
【００８８】
動作中のプログラムは、ブロック１０６０において、コールＰＩＤＬＯｐｅｎを行って、ＰＩＤＬライブラリオブジェクトをオープンすることができる。ブロック１０８０において、ＰＩＤＬファイルがホスト環境に提供される。処理は、ブロック１０７０へ進み、そこで、ブロック１０１０においてプログラムと共に以前にコンパイルされたリンカー／ローダが、ＰＩＤＬをロードし、シンボル解決を行なって、動作中のアプリケーションのメモリスペースにおいてＰＩＤＬオブジェクトを結合する。ＰＩＤＬによってエクスポートされたシンボルは、上述したように、ダイナミックリンカー／ローダに設けられたＧｅｔＰＩＤＬＡｄｄｒｅｓｓにより、ブロック１０９０において、メインアプリケーションによってコールされてもよい。
【００８９】
制約のある環境におけるダイナミックリンキングの動作を、ライブラリがプラットホーム独立であるように動作することを示したが、本明細書で説明する本発明の概念は、プラットホーム依存性を有するライブラリにも適用できるので、このような説明は、単なる例示に過ぎないことが明らかであろう。
【００９０】
＜６．コードコンポーネントメカニズム＞
移動コンピュータに使用されるあるオペレーティングシステム（ＯＳ）（例えば、ＰａｌｍＯＳ、ＳｙｍｂｉａｎＯＳ）は、グローバル変数及びスタティックの書き込み可能な変数の使用について制約を強いる。このような制約は、オペレーティングシステムがコードの再配置及びグローバル変数のアドレスマネージメントを完全に取り扱うのを回避できるようにするために存在する。スタティック変数は、グローバル変数と同じメモリセグメントに保持されるので、書き込み可能なスタティック変数も、オペレーティングシステムによって禁止されることがある。コンピュータプログラムコードが、このようなオペレーティングシステムを念頭において書かれるときには、当然、制約に従い、適合するコードを生成することができる。しかしながら、ライブラリのようなコードの断片が、このような制約を伴わずに、異なるプラットホーム用に書かれる場合には、コードは、制約のあるオペレーティングシステムにおいてコンパイル又は構築する程度にルール違反を含むことがある。これは、第三者のライブラリ、及びあるオペレーティングシステム上で予め書かれたコードを使用する能力に対して制限をもたらし、それらの融通性を低減させる。これは、生産的開発を低下させる。というのは、オペレーティングシステムの制約に従うように既存のコードを変更し、又はある場合には、スクラッチからそれを完全に再び書くことに、時間を費やさねばならないからである。
【００９１】
本明細書で説明するシステム及び方法は、オペレーティングシステムの制約を回避できるようにする。例示の実施の形態では、ソースコードがオペレーティングシステムの制約に違反するライブラリをＰＩＤＬフォーマットへとコンパイルし構築することができる。ＰＩＤＬライブラリを、次いで、アプリケーションプログラムと結合し、制約のあるオペレーティングシステムにおいて実行することができる。本明細書で説明するシステム及び方法の独特のダイナミックローディング及びリンキングメカニズムは、ＰＩＤＬ用にメモリブロックを割り当てる。さらに、この実施の形態では、グローバル変数が、ＰＩＤＬのメモリ領域を越えるグローバルとしては、処理されない。
【００９２】
このように、この実施の形態では、ライブラリ内に定義されるグローバル変数は、このメモリブロック内に拘束することができ、オペレーティングシステムにはグローバル変数として見えない。また、スタティック変数も、割り当てられたメモリブロックに拘束することができ、オペレーティングシステムの介入に依存しない。その結果、このようなグローバル及びスタティック変数の再配置をオペレーティングシステムができないことを回避することができる。この実施の形態では、ＰＩＤＬローダ／リンカーは、ライブラリ変数の再配置を実行して、それらを機能させることができる。
【００９３】
図１１は、ＰＩＤＬがコンピューティング環境の一つ以上の制約を回避できるようにＰＩＤＬを取り扱うために、制約のあるコンピューティング環境によって実行される処理を示す。図１１に示すように、処理はブロック１１００で始まり、ここで、オペレーティングシステムにより課せられた一つ以上の制約にコードが違反するライブラリからＰＩＤＬを生成することができる。ブロック１１１０において、ライブラリと協働するコンピューティングアプリケーションは、ダイナミックリンカー／ローダと共にコンパイルし構築でき、ＰＩＤＬがアプリケーションからシンボルインポートする場合にはＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ関数用の任意のソースコードと共にコンパイルし構築することができる。
【００９４】
例示の実施の形態では、アプリケーションプログラムを実行する命令をブロック１１２０において受け取ることができる。実行可能ファイルは、通常そうであるように、ブロック１１３０において、ホストコンピューティング環境によりロードすることができる。動作中のプログラムは、ブロック１１４０において、コールＰＩＤＬＯｐｅｎを行って、ＰＩＤＬライブラリオブジェクトをオープンすることができる。ＰＩＤＬは、ブロック１１８０において、コンピューティング環境により使用するために提供することができる。ＰＩＤＬＯｐｅｎコールに応答して、ダイナミックリンカー／ローダ（ブロック１１１０においてプログラムに組み込まれた）は、ブロック１１５０において、メモリブロックを割り当て、その割り当てたブロックにＰＩＤＬをロードすることができる。ブロック１１７６に示すように、ライブラリに定義されたグローバル及び書き込み可能なスタティック変数は、それらの範囲がその割り当てられたメモリブロックに制約されており、このメモリブロックを越えたところから名前ではアクセスすることができない。それらは、全てのライブラリ関数に使用可能である。というのは、これらも、割り当てられたメモリブロック内に存在し得るからであり、従って、ライブラリは、コンピューティング環境の従来の動作のもとで課せられた制約に違反してもその環境内で正しく動作することができる。ＰＩＤＬによりエクスポートされるシンボルは、上述したように、ダイナミックリンカー／ローダに設けられたＧｅｔＰＩＤＬＡｄｄｒｅｓｓ関数を用いて、ブロック１１７０において、メインアプリケーションによってコールすることができる。
【００９５】
コードコンポーネントの特徴を、ライブラリがプラットホーム独立であるように動作するものとして示したが、本明細書で説明する本発明の概念は、プラットホーム依存性を有するライブラリにも適用できるので、そのような説明は、単なる例示に過ぎないことが明らかである。
【００９６】
＜７．コードローディングメカニズム＞
従来のソフトウェア開発では、オブジェクト指向の解決策をとることができる。特定のタスクを実行するための関数をコールするのではなく、オブジェクトを生成することができ、オブジェクトのメソッドをコールして、希望のタスクを実行することができる。このような解決策は、多数のオブジェクトを生成でき、多数のタスクを同時にアクティブにできるので、有益である。計算タスクの多数のインスタンスを実行することが有益な状況は、多数ある。例えば、映画クリップをドキュメント内で再生しレンダリングするためのライブラリが存在するケースがある。かかるドキュメントが二つのこのような映画クリップを含むときには、共通のコードオブジェクトの二つのインスタンスを動作させることにより、それらクリップを同時に再生することが便利である。オブジェクト指向の解決策がない場合には、開発者は、オブジェクトがタスクを首尾良く実行する状態に遭遇することがあるが、多数の同じオブジェクトを同時に実行することを可能にすることについての困難に遭遇する。
【００９７】
開発者は、オブジェクト指向のスタイルで書くことを選択できるが、このような選択は、第三者のコードを一体化するときには無効になり得る。特に、これは、ライブラリとして配備されるコードに適用され、この場合において、ライブラリは、データを操作し、このデータへのアクセス関数を含む。説明用の実施例では、非オブジェクト指向のコードは、グローバル変数を使用することができ、また、スタティック変数の１回の初期化を使用することができる。このような状況では、あるコンピューティング環境において、そのコンピューティング環境が同じプロセス内でライブラリオブジェクトの２回以上の呼び出しを実行することが阻止される。というのは、単一のプロセスが、モジュール又はライブラリにより使用される１セットのデータしか保持しないからである。より詳細には、同じオブジェクトの２回の呼び出しは、名前付きグローバル変数の共用を通じて互いに悪く相互作用することがある。或いは、ライブラリは、１回しか実行できないように書くことができるが、その実行が完了したときには、２回目の実行の試みは失敗となる。というのは、静的に初期化された変数は、必要な初期値をもはやもたないからである。このため、スタティック変数は、ランタイムではなく、ビルドタイムに、コンパイラにより初期化され、従って、初期化された変数が実行中に変更された場合には、その後の実行がその変更された値を含み、適切な動作に必要な初期化値とは異なる値でスタートする。
【００９８】
本明細書で説明するシステム及び方法は、上述したＰＩＤＬローディングメカニズムを提供することにより、これらの欠点を改善することを目的としている。プロセス内に単一セットのデータを使用する制約は、ＰＩＤＬの多数のインスタンスが、拘束されたメモリブロック内にそれら自身の「プライベート」なデータコピーを使用することを可能とし、従って、従来の解決策において機能不良を生じさせる相互作用及び衝突を回避することにより、排除される。この方法は、同じプロセス内でも多数のインスタンス及び繰り返し実行を可能とする。また、この方法は、多数のプロセスを許可しない環境でも多数の同時実行の可能性を広げる。例示の実施の形態では、ＰＩＤＬは、グローバル変数を、動的に割り当てられたバッファ内のアドレスとして処理する。単一のＰＩＤＬを何回もロードすることができ、次いで、各コピーは、グローバル変数のそれ自身の個々の独立したコピーを有し、これによって、問題となる相互作用を回避する。同様に、ライブラリを実行するたびに、ファイルからコピーがロードされ、従って、当該コピーは、スタティック変数の正しく初期化された値を含む。
【００９９】
図１２は、例示の実施の形態において、ＰＩＤＬを取り扱うときに、例示的コンピューティング環境によって実行される処理であって、ＰＩＤＬを使用して、制約のあるコードコンポーネントの問題となる相互作用を回避できるようにする処理を示している。この処理は、ブロック１２００で始まり、ここでは、繰り返し実行を禁止する一つ以上の制約にコードが違反するライブラリからＰＩＤＬを生成することができる。ブロック１２１０において、ライブラリと協働するコンピューティングアプリケーションを、ダイナミックリンカー／ローダ及び追加のＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌソース関数と共にコンパイルし構築することができる。
【０１００】
例示の実施の形態では、アプリケーションプログラムを実行する命令を、ブロック１２２０において、受け取ることができる。実行可能ファイルは、ブロック１２３０において、ホストコンピューティング環境によりロードすることができる。動作中のプログラムは、ブロック１２４０において、コールＰＩＤＬＯｐｅｎを行って、ＰＩＤＬライブラリオブジェクトをオープンすることができる。ＰＩＤＬは、ブロック１２８０において、コンピューティング環境によって使用するように提供することができる。ＰＩＤＬＯｐｅｎコールに応答して、ダイナミックリンカー／ローダ（ブロック１１１０においてプログラムに組み込まれた）は、ブロック１２５０において、ＰＩＤＬオブジェクトをロードし、オブジェクトハンドルをその協働するアプリケーションへ返す。次いで、ブロック１２６０において、ＰＩＤＬの新たなインスタンスをコンピューティング環境にロードすべきか否かを決定するためのチェックを行うことができる。ブロック１２６０におけるチェックが、ＰＩＤＬの新たなインスタンスをロードすべきであると指示する場合には、処理がブロック１２７０へ進み、ここで、ＰＩＤＬの新たなインスタンスを個別のメモリブロックにロードでき、コンピュータプログラムにリンクすることができる。ブロック１２７０に示したように、ＰＩＤＬの各別々のインスタンスは、別々のハンドルにより特定され、その各々を個々に且つ独立してアクセスすることを可能とする。しかしながら、ブロック１２６０において、ＰＩＤＬの新たなインスタンスをロードすべきでないと決定された場合には、処理がブロック１２６０の入力へ復帰し、そこから進められる。
【０１０１】
コードローディング特徴を、ライブラリがプラットホーム独立であるよう動作するものとして示したが、本明細書で説明する本発明の概念は、プラットホーム依存性を有するライブラリにも適用できるので、この説明は単なる例示に過ぎないことが明らかであろう。
【０１０２】
＜８．閉じた又は制約のあるプラットホームに対する拡張可能なランタイム環境＞
あるコンピューティング装置は、閉じたコンピューティング環境として動作するものであり、したがって、装置が装置製造者又は供給者から運搬されるときに、常駐するプログラム及びアプリケーションしか実行できないようになっている。このような装置（例えば、移動ワイヤレス装置）は、常駐プログラムをホストするオペレーティングシステムを含むことができるが、他のアプリケーションは、そのアプリケーションがホストオペレーティングシステムに対して生成されたときでも、制約なしに追加することができない。このような閉じたプラットホームの例は、フューチャーホン(Feature Phone)として知られた移動ハンドセットの大きなカテゴリーであり、音声に加えて、固定セットの特徴（例えば、カメラファクション）が提供されているが、これらの特徴は、固定されたものであり、ユーザによって拡張することができないものである。装置は、コンピューティングプラットホームが機能を追加できないか又は制約があるために、アフターマーケット(after-market)アプリケーションに対して閉じている。
【０１０３】
対照的に、開いたコンピューティングプラットホームは、オペレーティングシステム用に書かれたアプリケーションを、毎日使用するように追加して実行することができる。ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）のプラットホームは、パーソナルコンピュータに対する開いたプラットホームの例として考えることができる。移動ハンドセットの領域では、開いたプラットホームの等価なカテゴリーがスマートホンとして知られており、これは、制約を伴わずに、装置において実行するためのアプリケーションを追加する環境を提供する。スマートホンプラットホームには、例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＳｍａｒｔＰｈｏｎｅ、Ｓｙｍｂｉａｎ  ＵＩＱ、及びＬｉｎｕｘがある。
【０１０４】
移動ハンドセットの第３カテゴリーが存在しており、当該カテゴリーは、ランタイム環境（ＲＴＥ）が装備されたフューチャーホンである。このようなランタイム環境には、例えば、Ｊａｖａ  Ｊ２ＭＥ（Ｊａｖａ２マイクロエディション）、及びＢＲＥＷ（バイナリ・ランタイム・エンビロンメント・フォー・ワイヤレス）環境がある。ＲＴＥは、ＲＴＥ用に生成されたアプリケーション、即ちＪ２ＭＥの場合にはＪａｖａアプレット、及びＢｒｅｗ環境の場合にはＢｒｅｗ認証アプリケーション、の形態の新たなファンクションをハンドセットが追加することを可能とする。これらのアプリケーションは、開いたプラットホームで動作するものとは異なる。というのは、これらアプリケーションは、ＲＴＥ用に構築され（例えば、あるインスタンスでは、ＲＴＥにより適切な動作について認証されねばならない）、スマートホンのようなネイティブなＯＳ用に構築されない。従って、ＲＴＥイネーブル型フューチャーホンは、スマートホンに比して制限を有し、そのうちの幾つかは、技術的な理由のためであり、一方、他の制約は、商業的な動機によるものである。
【０１０５】
例えば、ハードウェア装置製造者、ネットワークオペレータ、又はＲＴＥ売主は、アプリケーションプロバイダーと共に排他的又は半排他的構成に入って、アプリケーション及び／又はアプリケーションに対する更新をそれらの各々のハードウェア装置に提供することができる。一般に、ＲＴＥで動作するアプリケーションは、完全な装置機能にインターフェイスする能力に制約がある。例えば、ネットワークスタックの制御、又は装置の周辺記憶機器の制御を可能にするＡＰＩ（アプリケーションプログラミングインターフェイス）は、ＲＴＥからアクセスできないことがある。これは、ネイティブコンピューティング環境内のそれ自身の「サンドボックス(sandbox)」において動作するＲＴＥとして説明されることがある。これに比して、開いたプラットホーム（例えば、ＳｍａｒｔＰｈｏｎｅ）では、各実行可能ファイルが、それ自身のプロセスにおいて動作することができ、一般に、このような開いたプラットホームのオペレーティングシステムは、全ての装置機能を、動作中の各プロセスに露出させることができる。さらに、ある環境（Ｂｒｅｗがその一例）では、ＲＴＥアプリケーションをネットワークにわたって追加することだけが可能とであり、アプリケーションが記憶カードにより装置にロードされることが防止される。これは、ネットワークにわたってロードするために多量の帯域巾及び時間を必要とする大型のゲームのような大きなアプリケーションをロードするときに問題になり得る。
【０１０６】
本明細書で説明するシステム及び方法は、閉じたプラットホームに機能を追加する手段を提供することによって既存の慣例の欠点を改善する。例示の実施の形態では、追加される機能が、ハードウェア装置にＰＩＤＬとして提供される。閉じたプラットホームは、「ランチャー」プログラムを含むように生成することができ、このプログラムは、上述したダイナミックリンカー／ローダを、ＰＩＤＬと協働するアプリケーションと同様に備えている。このランチャープログラムは、閉じた装置内のホストオペレーティングシステム用に構築されており、当該システム上で実行することができ、出荷時に装置に常駐させることができる。ランチャーアプリケーションとＰＩＤＬライブラリとの組み合せは、装置の出荷時に新たな機能が存在しなくても、次のようにして、閉じた装置においてその新たな機能が動作することを可能にするように働く。動作時に、ＰＩＤＬが装置に使用できるようにされ、ランチャーアプリケーションがスタートされる。ランチャーアプリケーション内のダイナミックリンカー／ローダは、ランタイムにＰＩＤＬライブラリをオープンするためのランチャーによるＰＩＤＬＯｐｅｎコールに応答して、ハードウェア装置に常駐してその装置のＯＳで動作する協働ランチャープログラムにＰＩＤＬをロードし、リンクし、結合するように働くことができる。したがって、その後に、ダイナミックリンカー／ローダに設けられたＧｅｔＰＩＤＬＡｄｄｒｅｓｓ関数により、ＰＩＤＬの全ての機能を装置内の既存のプログラムへ露出させて、閉じた装置に新たな機能を使用できるようにするという希望の結果を達成することができる。この点について、ＰＩＤＬ側は、課せられたハードウェア装置の制約を歩進して、動的な実行をなすように動作する（上述したように）。
【０１０７】
「ランチャー」アプリケーションは、それ自身が、機能のセットを提供してもよく、その動作について、ＰＩＤＬの存在に依存しないことを理解されたい。同様に、同じランチャーアプリケーションが、当該ランチャーアプリケーションによってオープンし得る個別のＰＩＤＬライブラリによって提供された非常に多数の異なる形式の新たな機能をイネーブルすることもできる。このような実施の形態では、変更した機能を、動的に追加できる一種のランタイム環境をシミュレーションすることができる。
【０１０８】
説明用の実施例では、ランチャーアプリケーションは、ソフトウェアゲームコンソール及び一以上のゲームを含んでいる。更なるゲームが、ＰＩＤＬライブラリの形で、即ち、異なるゲーム毎に一つのライブラリが追加されてもよく、当該ゲームは、ＰＩＤＬが装置にダウンロードされたときにランチャーアプリケーションを通して再生可能である。或いは、ランチャーアプリケーションは、ＳＭＳのような基本メッセージング関数を提供してもよい。更に別の関数、例えば、ｅメール又はマルチメディアメッセージング、ビデオ及びオーディオプレーヤ、ブラウジング関数、ファイルビューイング、フォトアルバム、ＰＩＭ（パーソナル情報マネージメント）、及び他の形式の関数、ランチャーと相互動作するＰＩＤＬライブラリとして装置に配備することができる。
【０１０９】
別の例示の実施の形態では、閉じた装置は、二つ以上の「ランチャー」アプリケーションと共に出荷されてもよく、当該ランチャーアプリケーションの各々は、それ自身による使用のために、ＰＩＤＬライブラリの特定セットをオープンする。このように、アドオン機能の範囲を、顕著に拡張及び編成することができる。
【０１１０】
本明細書に説明する方法及びシステムは、これがなければ閉じたプラットホームとなるプラットホームで使用される場合に、既存の慣例を克服する。アフターマーケット解決策を提供する可能性は、装置ユーザに対して大きな実用性を生み出し、装置又はネットワークプロバイダーに対して収入の機会を増加することができる。この方法は、関数を実行可能ファイルとして追加することを伴わない（例えば、ＰＩＤＬライブラリは、データとして存在し、実行可能なプログラムとして存在しない）ので、プラットホームの「閉性(closed-ness)」を制御することはできない。というのは、プラットホームが、装置のオペレーティングシステムに対して実行可能ファイルとして生成される通常のアプリケーションに対しては、閉じたままであるからである。装置プロバイダーは、提供すべき追加の機能の範囲を前もって決定することができる。というのは、ランチャーによりオープンされるＰＩＤＬライブラリに含まれている関数しか動作しないからである。その結果、動的なセキュリティ及び商業的制御のセットを得ることができる。
【０１１１】
例示の実施の形態では、ＰＩＤＬは、無線又は有線ネットワークをわたるダウンロードによるか、繋がれたＰＵからのデータ転送によるか、装置に挿入された記憶カードからのデータ転送によることを含む多数の方法で装置に提供することができる。実行可能なアプリケーションではなくＰＩＤＬオブジェクトとして関数をロードする別の独特の態様は、デジタルライツマネージメント(Digital Rights management)（ＤＲＭ）技術によりＰＩＤＬを保護できることである。データファイルとしてのＰＩＤＬは、実行可能なプログラムとは異なり、ＤＲＭ技術に従うことができる。この充分に確立されたセキュリティ構成は、商業的トランザクションのもとで関数を追加するときに、オペレータ及びユーザの両方に融通性及び機密性を与える。
【０１１２】
上述したように、ＰＩＤＬオブジェクト及びリンキング構成のプラットホーム独立特性と組み合わされたときには、装置メーカー又はネットワークプロバイダーは、全ての範囲の装置が異なるホストプラットホーム又はオペレーティングシステムを使用するときでも、それらの装置にわたって単一のＰＩＤＬオブジェクトとしてアドオン機能を提供することができる。各異なるプラットホーム用のアプリケーション又はライブラリをカスタマイズする必要性を回避し、全てのプラットホームにおいて等しく機能するプラットホーム独立のダイナミックライブラリ（ＰＩＤＬ）を単に提供することによって、効率性、及び規模の経済を実現するようにオペレータを配することができる。
【０１１３】
閉じたプラットホーム（フューチャーホンのような）を参照して上述したこの方法及びシステムは、ランタイム環境（例えば、Ｊａｖａ又はＢｒｅｗ）をサポートするプラットホームに使用することもできる。この構成は、装置がファンクションを追加するための二つの方法を提供し、即ちアプレット又は認証されたアプリケーションをＲＴＥによる消費のためにダウンロードする従来の構成と、装置に常駐するランチャーアプリケーションの制御のもとでＰＩＤＬライブラリとして機能をロードする別の実施の形態を与える。
【０１１４】
互いに比較すると、ＰＩＤＬベースに構成は、従来のランタイム環境には存在し得ない追加の特徴を与えることができる。換言すれば、幾つかの機能が、単一のランチャーアプリケーション内に個別のＰＩＤＬとして配備されたときに、それらを同時に動作させることができる。この状況においては、ＰＩＤＬの実施の形態を用いて、ＰＩＤＬファンクションを、共通のランチャープロセスのもとで、同時に使用することができるときには、実行することができる。さらに、ＰＩＤＬローディングの解決策では、機能を装置にロードする手段に相当の柔軟性を得ることができ、これは、あるランタイム環境（例えば、Ｂｒｅｗ）のもとでは許されない記憶カードからロードすることを含む。ＤＲＭの状況においては、ＤＲＭは、ＰＩＤＬデータライブラリを配備するときに実現することができ、これは、実行可能なアプリケーション又はアプレットをランタイム環境に配備するときには考えられない技術である。また、もし希望があれば、装置又はネットワークプロバイダーは、追加できる関数を、装置と共に出荷されるランチャーアプリケーションにより認識される関数に限定することもできる。
【０１１５】
ビルドタイムにランチャーが含められる厳密に閉じた環境とは異なり、ランタイム環境（ＲＴＥ）を有する装置は、ランチャーアプリケーションをアフターマーケット手順としてダウンロードする能力を利用することができる。このように配備される場合に、上述したダイナミックライブラリ（ＤＬ）に基づく構成をＲＴＥと共存させながら、ＲＴＥがそれ自身では提供できない前記利益を発揮することができる。より詳細には、ＤＬライブラリは、ＲＴＥを経てアクセスできない装置関数及びＡＰＩ（記憶カードのような）にアクセスすることができる。従って、このような構成では、ランチャーアプリケーションは、例示的通信ネットワークを横切って装置ＲＴＥへダウンロードされ、そこで、ランチャーがプロキシとして働いて、記憶カードのような他の手段により更に別の機能を追加することが可能となる。同様に、ＲＴＥは、アプリケーションがＲＴＥのもとで実行するために最大サイズをしばしば課すことがある。この最大サイズは、より大きなプログラムを装置に配備できるようにするために回避でき、これは、それ自体小さくて選択されたサイズ限界内にあるがその限界を越える関数コードをＤＬライブラリに追加するランチャーアプリケーションをダウンロードすることによって行なわれる。ＤＬライブラリは、ＲＴＥアプリケーションではなくバイナリデータオブジェクトとしてロードされるので、ＲＴＥサイズ限界はそれらに適用されない。
【０１１６】
図１３は、閉じたコンピューティング環境において動的な実行を実現するためにＰＩＤＬを取り扱うときに例示的コンピューティング環境により実行される処理を示す。（同じ処理は、閉じているが従来のランタイム環境が設けられた環境で、且つ、開いたコンピューティング環境上でも、実行することができる）。図１３に示すように、処理はブック１３００で始まり、ここで、機能が、出荷時に装置（図示せず）に常駐する例示的ランチャーアプリケーション内に設けられるものと、アドオン機能として設けることが可能なものとに分けられる。
【０１１７】
例示の実施の形態では、図１３に示すように、ブロック１３２０において、アドオン機能を含むＰＩＤＬライブラリオブジェクトを生成することができる。ブロック１３１０において、ブロック１３００からの出荷時の関数を含むランチャーアプリケーションが、ダイナミックリンカー／ローダと共に、また、ＰＩＤＬがランチャーからシンボルをインポートする場合にはＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ用のオプションのソースと共に、コンパイルされ構築される。ブロック１３４０に示すように、装置が使用のために出荷されるときに、ランチャーアプリケーションを装置に含ませることができる。
【０１１８】
装置の出荷に続いて、ブロック１３５０において、アドオンファンクションを使用するための許可を与えることができる。理解できるように、この許可は、商業的トランザクション、又は、装置を配備する環境に従った他の基準に基づくことができる。許可に続いて、ＰＩＤＬライブラリは、ブロック１３６０において、装置メモリへのダウンロード、ネットワーク転送、又は装置に取り付けられた記憶装置又はカードからの供給を含む（それらに限定されないが）適当な手段により、装置に使用できるようにされる。次いで、ブロック１３７０において、装置に存在するランチャーアプリケーションを動作させることができる。実行中に、ランチャーは、ブロック１３７５において、コールＰＩＤＬＯｐｅｎを行って、ＰＩＤＬライブラリをオープンすることができる。そこから、ブロック１３８０において、ＰＩＤＬオブジェクトが装置に使用できるか否かを決定するためのチェックを実行することができる。このチェックは、ブロック１３７５においてＰＩＤＬＯｐｅｎコールにおいて提供されたパス情報を使用して、ランチャーアプリケーション内のダイナミックリンカー／ローダによって実行することができる。ブロック１３８０におけるチェックが、ＰＩＤＬが装置に使用できないことを指示する場合には、処理はブロック１３８５へ進み、そこで、ランチャーアプリケーションは、出荷時の装置の機能と同一の機能の範囲（即ち、ＰＩＤＬに含まれた更に別の機能を除外する）で実行を継続する。
【０１１９】
しかしながら、ブロック１３８０において、チェックが、ＰＩＤＬライブラリが装置に使用できることを指示する場合には、処理はブロック１３９０へ進み、そこで、ＰＩＤＬがランチャーアプリケーションにロードされ、リンクされ、結合される。このステップにより、ランチャーアプリケーションからアクセスできる機能の範囲は、ブロック１３９５に示すように、ＰＩＤＬによりエクスポートされる関数を含むように拡張される。これらの拡張された関数は、ブロック１３１０においてコンパイルされたダイナミックリンカー／ローダに設けられた前述のＧｅｔＰＩＤＬＡｄｄｒｅｓｓメカニズムによりアクセスすることができる。
【０１２０】
図１４は、ランチャーアプリケーションのダウンロードを通じて更なる機能を提供するときに実行される処理を示す。このような処理は、開いた環境へダウンロードを行なうか、又は装置の既存のＲＴＥと連動して動作するようにランチャーアプリケーションをダウンロードする場合のように、例示的コンピューティング装置が出荷された後に生じ得る。また、このような処理は、ダウンロード動作に対して閉じたままであるか、又は、他のコンピューティングアプリケーション（例えば、ランチャーとは別の）の追加に対して閉じたままである閉じた環境へ、アプリケーションをダウンロードする独特の事象として発生することができる。ランチャーは、技術的又は商業的な制御の使用を通じてこのように（例えば、ダウンロードするように）動作することができる。
【０１２１】
図示するように、処理はブロック１４００で始まり、ここでは、プログラムが、ランチャーアプリケーション及びアドオン機能に分けられる。ここから、処理は、ブロック１４１５又は１４０５へ分岐する。ブロック１４０５では、アドオン機能用のダイナミックライブラリ（ＤＬ）オブジェクトが生成される。ブロック１４１５では、ランチャーアプリケーションと、リンカー／ローダ、また、ＰＩＤＬがランチャーからシンボルをインポートする場合にはＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ用のオプションのソースが、コンパイルされ構築される。ブロック１４０５から、処理は更に分岐する。ブロック１４０５から、処理は、ブロック１４４５へ進むことができ、ここで、ＤＬがその協働する装置（例えば、移動電話）へ与えられる。ブロック１４４５から、処理は、以下に述べるブロック１４６０へ進む。
【０１２２】
ブロック１４１５から、処理はブロック１４２０へ進み、ここで、ランチャーアプリケーションが装置へダウンロードされる。次いで、ブロック１４２５において、ダウンロードされたランチャーアプリケーションが、それがダウンロードされた装置において動作することが許されるか否かを決定するためにチェックが行われる。ブロック１４２５におけるチェックが、ランチャーアプリケーションが許可されなかったことを指示する場合は、ブロック１４４０において処理が終了する。しかしながら、ブロック１４２５において、ランチャーアプリケーションが装置で動作することが許可されたと決定される場合には、処理がブロック１４３０へ進み、ここで、ランチャーアプリケーションを動作させる。実行中に、ランチャーは、ブロック１４３５において、コールＰＩＤＬＯｐｅｎを行い、ＰＩＤＬライブラリをオープンすることができる。次いで、ブロック１４５０において、上述したようにブロック１４４５を経て装置にＤＬが使用できるか否かを決定するためのチェックが行われる。ブロック１４５０のチェックが、ＤＬが装置に使用できないことを指示する場合には、ブロック１４５５に示すように、ランチャーアプリケーションの範囲が出荷時のままとされ、ＤＬにより与えられる付加的な機能へ拡張されない。しかしながら、ブロック１４５０において、ＤＬが装置に使用できることをチェックが示す場合には、処理がブロック１４６０へ進み、ここで、リンカー／ローダがＤＬをロードして、ラン中のアプリケーションと結合する。処理は、ブロック１４６５へ進み、ランチャーアプリケーションの範囲が、エクスポートされたＤＬ関数を含むように拡張され、そこから続行する。これらのエクスポートされた関数は、ブロック１４１５においてコンパイルされたダイナミックリンカー／ローダに設けられた前述のＧｅｔＰＩＤＬＡｄｄｒｅｓｓメカニズムによってアクセスすることができる。
【０１２３】
図１４に示す処理を適用して、単一のランチャーアプリケーションをダウンロードするか又は多数のランチャーをダウンロードすることができることが、明らかであろう。このようなランチャーは、ランチャーアプリケーションの動作時に当該ランチャーによって開いたライブラリファイルに基づいて、含ませることのできるライブラリスタブファイルに従って、選択された機能を追加するように動作できる。
【０１２４】
要約すれと、本明細書に説明する装置及び方法は、種々のプラットホームを動作させる異種のコンピューティング環境にわたって動作可能なプラットホーム独立のバイナリオブジェクトを提供する。しかしながら、本発明は、種々の変更や別の構造も受け容れることが可能であることが理解されよう。本発明は、本明細書に説明した特定の構造に限定されるものではない。逆に、本発明は、本発明の範囲及び精神の中に包含される全ての変更、別の構造、及び、均等物を網羅することを意図している。
【０１２５】
また、本発明は、種々のコンピュータ環境（非無線及び無線の両コンピュータ環境を含む）、部分的コンピューティング環境、及び実世界の環境において実施できることにも注意されたい。本明細書に説明した種々の技術は、ハードウェアでも、ソフトウェアでも、又はその両方の組み合せでも実施できる。好ましくは、これら技術は、プロセッサ、プロセッサにより読み取り可能な記憶媒体（揮発性及び不揮発性メモリ及び／又は記憶エレメントを含む）、少なくとも一つの入力装置、及び少なくとも一つの出力装置を含むプログラム可能なコンピュータを維持するコンピューティング環境において実施される。種々の命令セットと協働するコンピューティングハードウェアロジックは、上述した関数を実行すると共に出力情報を発生するようにデータに適用される。出力情報は、一つ以上の出力装置に適用される。例示的コンピューティングハードウェアにより使用されるプログラムは、コンピュータシステムと通信するために高レベル手順又はオブジェクト指向のプログラミング言語を含む種々のプログラミング言語で実施できることが好ましい。本明細書に説明した装置及び方法は、所望の場合には、アッセンブリ言語又はマシン言語で実施することができる。何れの場合にも、言語は、コンパイル又は解釈される言語とし得る。このような各々のコンピュータプログラムは、汎用又は特殊目的のプログラム可能なコンピュータにより読み取ることのできる記憶媒体又は装置（例えば、ＲＯＭ又は磁気ディスク）に記憶されて、上述した手順を遂行するようにコンピュータにより記憶媒体又は装置が読み取られたときにコンピュータを構成及び動作することが好ましい。また、装置は、コンピュータプログラムを有するように構成されたコンピュータ読み取り可能な記憶媒体として実施されると考えることもでき、このように構成される記憶媒体は、特定のそして予め定義された態様でコンピュータを動作させる。
【０１２６】
本発明の実施形態を以上に詳細に述べたが、当業者であれば、本発明の新規な技術及び効果から実質上逸脱せずに多数の別の変形例も可能であることが容易に明らかであろう。従って、このような全ての変形例は、本発明の範囲内に包含されるものとする。本発明は、特許請求の範囲に規定される。
【図面の簡単な説明】
【０１２７】
【図１】本明細書で説明するシステム及び方法の実施の形態に係る例示的コンピューティング環境のブロック図である。
【図２】例示的データ通信アーキテクチャーの例示的コンポーネントの協働を示すブロック図である。
【図３】動的リンキングアーキテクチャーのブロック図である。
【図４】異種のコンピューティングプラットホームを有する第１オペレーティングシステムにわたって同じライブラリをリンクするときの動的リンキングアーキテクチャーのブロック図である。
【図５】異種のコンピューティングプラットホームを有する第２オペレーティングシステムにわたって同じライブラリをリンクするときの動的リンキングアーキテクチャーのブロック図である。
【図６】本明細書で説明するシステム及び方法に係る複数のプラットホームをサポートする複数のオペレーティングシステムのブロック図である。
【図７Ａ】本明細書で説明するシステム及び方法に係る例示的プラットホーム独立リンキングアーキテクチャーの例示的コンポーネント間の相互作用を示すブロック図である。
【図７Ｂ】本明細書で説明するシステム及び方法に係る例示的プラットホーム独立リンキングアーキテクチャーの例示的コンポーネント間の相互作用を示すブロック図である。
【図７Ｃ】本明細書で説明するシステム及び方法に係る例示的プラットホーム独立リンキングアーキテクチャーの例示的コンポーネント間の相互作用を示すブロック図である。
【図８】本明細書で説明するシステム及び方法に係るメインアプリケーションプログラムとダイナミックライブラリとの間の相互作用を示すブロック図である。
【図９】本明細書で説明するシステム及び方法に係る例示的プラットホーム独立リンキングアーキテクチャーによって実行される処理を示すフローチャートである。
【図１０】ネイティブなファシリティをもたないで動的リンキングを実行するコンピューティング環境においてプラットホーム独立のバイナリオブジェクトを使用するときに実行される処理を示すフローチャートである。
【図１１】制約のあるコンピューティング環境においてプラットホーム独立のバイナリオブジェクトを使用するときに実行される処理を示すフローチャートである。
【図１２】プラットホーム独立のバイナリオブジェクトを使用して、制約のあるコンピューティング環境において協働コンピューティングアプリケーションの種々のインスタンスを実行するとくに実行される処理を示すフローチャートである。
【図１３】閉じたハードウェア環境で動作するプラットホーム独立のバイナリオブジェクトを使用してアドオン機能を提供するときに実行される処理を示すフローチャートである。
【図１４】本明細書で説明するシステム及び方法の実施の形態に係り、制約のあるコンピューティング環境に更なる機能を与えるためにランチャーアプリケーションのダウンロードを介して実行される処理を示すフローチャートである。
【図１】
2008516324.tif 000003
【図２】
2008516324.tif 000004
【図３】
2008516324.tif 000005
【図４】
2008516324.tif 000006
【図５】
2008516324.tif 000007
【図６】
2008516324.tif 000008
【図７Ａ】
2008516324.tif 000009
【図７Ｂ】
2008516324.tif 000010
【図７Ｃ】
2008516324.tif 000011
【図８】
2008516324.tif 000012
【図９】
2008516324.tif 000013
【図１０】
2008516324.tif 000014
【図１１】
2008516324.tif 000015
【図１２】
2008516324.tif 000016
【図１３】
2008516324.tif 000017
【図１４】
2008516324.tif 000018
【手続補正書】
【提出日】平成19年5月31日(2007.5.31)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
コンピューティング環境内で動作するターゲットソフトウェアプラットホーム上で、該ターゲットソフトウェアプラットホームのネイティブなダイナミックリンキングファシリティがもしあれば、該ファシリティとは独立して、ダイナミックライブラリ（ＤＬ）(735)の動的ローディング及びリンキングを可能にするシステム(700)であって、
選択された構造を有するバイナリーオブジェクトファイルを含む前記ＤＬ(735)と、
ソースコードとして提供されたダイナミックローダ／リンカー(720)と、
協働するコンピューティングアプリケーション用のアプリケーションソースコード(705)と、
前記ダイナミックローダ／リンカー(720)の前記ソースコードを、前記アプリケーションソースコード(705)と共にコンパイルすることによって、前記ターゲットソフトウェアプラットホーム用のバイナリー実行可能プログラム(795)を生成するようになっているコンパイル及び構築プロセス(770)と、
を備え、
前記プログラム(795)は、前記ダイナミックローダ／リンカー(720)から導出されたダイナミックローダ／リンカー関数(785)を含み、該ダイナミックローダ／リンカー関数(785)が、前記ＤＬ(735)をオープンするための第１の関数と、前記ＤＬ(735)によってエクスポートされるシンボルのメモリ内のアドレスを返すための第２の関数とを含むことによって、前記コンピューティングアプリケーションがランタイムに前記ＤＬにアクセスして、該ＤＬと協働することを可能にする、
システム。
【請求項２】
前記ＤＬの選択された構造は、実行可能リンキングフォーマット（ＥＬＦ）、及びポータブル実行可能（ＰＥ）フォーマットの何れかを含む、請求項１に記載のシステム。
【請求項３】
前記実行可能プログラム(795)が、前記アプリケーションソースコード(705)から導出されたメインアプリケーション関数(775)を含み、
前記ダイナミックローダ／リンカー関数(785)が、前記ＤＬをオープンする前記第１の関数を実行するための前記メインアプリケーション内の命令に応答して、ランタイムに前記ＤＬ(735)を前記ソフトウェアプラットホームにロードするよう、前記ＤＬ(735)に対して動作する、
請求項１に記載のシステム。
【請求項４】
前記ダイナミックローダ／リンカー関数(785)が、前記ＤＬのオブジェクトファイル(735)のサイズを決定する、請求項３に記載のシステム。
【請求項５】
前記ダイナミックローダ／リンカー関数(785)が、前記ソフトウェアプラットホームに前記ＤＬのオブジェクト(735)をロードするためのメモリを割り当てる、請求項４に記載のシステム。
【請求項６】
前記ダイナミックローダ／リンカーファンクション(785)は、前記ＤＬ(735)をランタイムに前記協働するメインアプリケーションファンクション(775)にリンクするよう、前記ＤＬ(735)に対して動作する、請求項３に記載のシステム。
【請求項７】
前記第１の関数によってオープンされ前記ＤＬ(735)からエクスポートされるシンボルのアドレスが、前記第２の関数を実行するための前記協働するメインアプリケーションファンクション(775)内の命令に応答して、返される、請求項３に記載のシステム。
【請求項８】
単一のＤＬオブジェクトファイル(735)が、該ＤＬオブジェクトファイル(735)の再コンパイル又は再構築を必要とせずに、定義されたプロセッサアーキテクチャーにおいて実行される複数のソフトウェアプラットホーム及びオペレーティングシステムにわたって動的にロードされリンクされる、請求項１に記載のシステム。
【請求項９】
前記ＤＬ(735)と協働する前記コンピューティングアプリケーションの前記ソースコード(705)と、前記ダイナミックローダ／リンカーの前記ソースコード(720)とが、前記複数のソフトウェアプラットホームのうちの選択された一つのソフトウェアプラットホーム用のバイナリー実行可能プログラム(795)へとコンパイルされリンクされる、請求項８に記載のシステム。
【請求項１０】
前記ＤＬ(735)は、コンピューティング環境がもつコンピューティングアプリケーションであって、該ＤＬ(735)のバイナリーフォーマットをネイティブにサポートしないオペレーティングシステム上で動作する該コンピューティングアプリケーションへ、動的にロードされリンクされる、請求項３又は６に記載のシステム。
【請求項１１】
前記ＤＬ(735)は、制約のあるコンピューティング環境におけるコンピューティングアプリケーションであって、バイナリーオブジェクトのダイナミックリンキングを実行するためのネイティブなダイナミックリンキングメカニズムをもたないオペレーティングシステム上で動作される該コンピューティングアプリケーションへ、動的にロードされリンクされる、請求項１に記載のシステム。
【請求項１２】
インターフェイスモジュール(755)を更に備え、
前記プログラム(795)は、コンパイルされ構築されたときに、前記ＤＬ(735)へのアクセスを協働するコンピューティングアプリケーションに提供するための前記インターフェイスモジュール(755)から導出されるインターフェイス関数(780)を含む、
請求項１に記載のシステム。
【請求項１３】
前記インターフェイスモジュール(755)が、ソースコードを備えており、
該ソースコードは、前記プログラム(795)がコンパイルされ構築されるときに、前記ＤＬ(735)が前記協働するコンピューティングアプリケーションにおける選択された関数をコールすることを可能にする、請求項１２に記載のシステム。
【請求項１４】
前記インターフェイスモジュール(755)の前記ソースコードは、前記協働するコンピューティングアプリケーションのアプリケーションプログラミングインターフェイス(710)を解析することによって、生成される、請求項１３に記載のシステム。
【請求項１５】
前記インターフェイスモジュール(755)の前記ソースコードは、前記ＤＬのバイナリーオブジェクトファイル(735)を解析して前記ＤＬ(735)によってインポートされるシンボルを特定することによって、生成される、請求項１３に記載のシステム。
【請求項１６】
前記インターフェイスモジュール(755)の前記ソースコード、前記協働するコンピューティングアプリケーションのソースコード(705)、及び前記ダイナミックローダ／リンカーのソースコード(720)は、前記ソフトウェアプラットホーム用にコンパイルされる、請求項１３に記載のシステム。
【請求項１７】
前記実行可能プログラム(795)は、前記アプリケーションソースコード(705)から導出されたメインアプリケーション関数(775)を備え、
前記ダイナミックローダ／リンカーは、シンボル解決及び再配置を取り扱い、前記協働するメインアプリケーションファンクション(775)及び前記ＤＬ(735)を、前記ターゲットソフトウェアプラットホーム上で動作可能なプロセスへと結合する、請求項６に記載のシステム。
【請求項１８】
前記動作可能なプロセスは、複数のダイナミックライブラリと協働し、且つ、該複数のダイナミックライブラリに結合するためのコンピューティングアプリケーションを含む、請求項１７に記載のシステム。
【請求項１９】
前記ダイナミックローダ／リンカーファンクション(785)は、前記ファイルを前記協働するメインアプリケーションファンクション(775)にリンクするときに、ＤＬファイルと非ＤＬファイルとを区別する、請求項１７に記載のシステム。
【請求項２０】
前記動作可能なプロセスは、前記協働するメインアプリケーションファンクション(775)を、前記ＤＬ(735)と、前記ソフトウェアプラットホーム用のネイティブなダイナミックリンクライブラリとにリンクする、請求項１９に記載のシステム。
【請求項２１】
バイナリーコード及び／又はデータを含む前記ＤＬ(735)を生成するように、ライブラリソースコード(725)がコンパイルされる(730)、請求項１に記載のシステム。
【請求項２２】
前記ＤＬ(735)は、前記ターゲットソフトウェアプラットホーム上で実行される前記バイナリー実行可能プログラム(795)に動的にロードされリンクされるようになっており、
前記ライブラリソースコード(725)は、前記ターゲットソフトウェアプラットホームのプログラミング制約に違反するコードを含む、
請求項２１に記載のシステム。
【請求項２３】
前記プログラミング制約は、グローバル変数の使用に関する制約、又は書き込み可能なスタティック変数の使用に関する制約、又はポインタ変数の静的初期化に関する制約を含む、請求項２２に記載のシステム。
【請求項２４】
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬ(735)がリンクされるプログラム(795)の実行中に前記ターゲットソフトウェアプラットホームに前記ＤＬオブジェクト(735)をロードするために、メモリブロックを割り当てる、請求項２３に記載のシステム。
【請求項２５】
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬ(735)において定義されたグローバル変数又は書き込み可能なスタティック変数の領域を、前記ＤＬ(735)により占有されるメモリブロックに制限するように動作可能である、請求項２４に記載のシステム。
【請求項２６】
前記ライブラリソースコード(725)は、コードの多数の実行インスタンス又は繰り返し実行を制限するように、データを取り扱い且つデータへのアクセス関数を提供するためのコードを含み、
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬ(735)のインスタンスを、動的に割り当てられたメモリブロックにロードし、
前記ライブラリコード(725)において定義されたデータ変数の領域が、前記メモリブロックに制限される、請求項１６に記載のシステム。
【請求項２７】
同じＤＬ(735)の多数の非衝突インスタンスが、前記コンピューティング環境で実行可能である、請求項２６に記載のシステム。
【請求項２８】
前記ＤＬ(735)によって使用されるデータは、前記コード(725)内に定義されたグローバル変数又はスタティック変数を用いて、参照される、請求項２６に記載のシステム。
【請求項２９】
単一のコンピューティング環境のプロセス内に多数の実行インスタンスを許可するために、非オブジェクト指向のコードをロードする、請求項２６に記載のシステム。
【請求項３０】
ライブラリデータの多数のセットが、該ライブラリデータのセットの各々の間で衝突が軽減され及び／又は除去されるように、単一のコンピューティング環境のプロセス内で同時に動作する、請求項２９に記載のシステム。
【請求項３１】
単一のコンピューティング環境のプロセス内でコードの繰り返し実行を可能にするために、非オブジェクト指向コードのロード動作を可能にするようなっている、請求項２６に記載のシステム。
【請求項３２】
多数のプロセスをサポートしないコンピューティング環境においてコードの多数の実行インスタンス及び繰り返し実行を許可するよう、コードのロード動作を可能にする、請求項２６に記載のシステム。
【請求項３３】
前記コンピューティング環境は、非常駐の実行可能プログラムを前記コンピューティング環境に配備することに関して制限されており、
前記協働するコンピューティングアプリケーションが、ランチャーアプリケーションを有しており、
該ランチャーアプリケーションは、前記ＤＬ(735)を、実行中の該ランチャーアプリケーションに動的にリンクすることによって、制限された前記コンピューティング環境に利用可能な機能を拡張するよう動作可能である、
請求項１に記載のシステム。
【請求項３４】
前記制限されたコンピューティング環境は、前記コンピューティング環境用のネイティブな実行可能プログラムの追加を許可しない、請求項３３に記載のシステム。
【請求項３５】
前記コンピューティング環境は、前記コンピューティング環境において実行できるプログラムの最大サイズについて制限を課する、請求項３３に記載のシステム。
【請求項３６】
前記コンピューティング環境は、ランタイム環境（ＲＴＥ）をサポートする、請求項３３に記載のシステム。
【請求項３７】
前記ＲＴＥ内で動作するプログラムは、前記ネイティブなコンピューティング環境に利用可能な一以上の関数へのアクセスを制限されている、請求項３６に記載のシステム。
【請求項３８】
前記ＲＴＥは、該ＲＴＥによって認証されたプログラムしか動作させないよう、動作を制限する、請求項３６に記載のシステム。
【請求項３９】
前記ＲＴＥは、Ｊａｖａ２モバイル・エディション（Ｊ２ＭＥ）ＲＴＥ、及び、無線用のバイナリーランタイム環境（ＢＲＥＷ）ＲＴＥの何れかを含む、請求項３６に記載のシステム。
【請求項４０】
前記ランチャーのモジュールは、前記コンピューティング環境においてネイティブなコンピューティングアプリケーションとして動作するように書かれている、請求項３３に記載のシステム。
【請求項４１】
前記ランチャーは、前記コンピューティング環境の前記ランタイム環境内でコンピューティングアプリケーションとして動作するよう、書かれている、請求項３６に記載のシステム。
【請求項４２】
少なくとも二つのランチャーモジュールを更に備える、請求項４０に記載のシステム。
【請求項４３】
前記ＤＬ(735)は、前記コンピューティング環境から物理的に離れた記憶媒体に記憶されており、該記憶媒体は、フラッシュメモリユニット、固定メモリユニット、及びマイクロドライブの何れかを含む、請求項３３に記載のシステム。
【請求項４４】
前記ランチャーアプリケーションを含む前記バイナリー実行可能プログラム(795)は、前記コンピューティング環境から物理的に離れた記憶媒体に記憶されており、該記憶媒体は、フラッシュメモリユニット、固定メモリ媒体ユニット、及びマイクロドライブの何れかを含む、請求項３３に記載のシステム。
【請求項４５】
前記ＤＬ(735)は、前記制限されたコンピューティング環境へのコンテンツの安全な配布を促進するようにデジタルライツマネージメント構成で使用される、請求項３３に記載のシステム。
【請求項４６】
コンピューティング環境内で動作するターゲットソフトウェアプラットホーム上で、該ターゲットソフトウェアプラットホームのネイティブなダイナミックリンキングファシリティがもしあれば、該ファシリティとは独立して、ダイナミックライブラリ（ＤＬ）(735)を動的にロードしリンクする方法であって、
ＤＬソースコード(725)を用意するステップと、
前記ＤＬソースコード(725)をコンパイルして、前記ＤＬ(735)を、選択されたフォーマットを有するオブジェクトファイルとして生成する、ステップ(730)と、
前記ＤＬ(735)と協働するコンピュータアプリケーション用のアプリケーションソースコード(705)を用意するステップと、
ダイナミックローダ／リンカーのソースコード(720)を用意するステップと、
前記ダイナミックローダ／リンカーの前記ソースコード(720)を、前記アプリケーションソースコード(705)と共にコンパイルし構築して、前記ターゲットソフトウェアプラットホームで実行可能なバイナリー実行可能プログラム(795)を生成するステップ(770)であって、前記プログラム(795)が、前記ダイナミックローダ／リンカー(720)から導出されたダイナミックローダ／リンカー関数(785)を含み、前記ダイナミックローダ／リンカー関数(785)が、前記ＤＬ(735)をオープンするための第１の関数と、前記ＤＬ(735)によってエクスポートされるシンボルのメモリ内のアドレスを返すための第２の関数と、を含むことによって、前記コンピューティングアプリケーションがランタイムに前記ＤＬにアクセスして該ＤＬと協働することを可能にする、該ステップと、
前記プログラム(795)が前記ターゲットソフトウェアプラットホームで実行されるときに、ランタイムに、前記ダイナミックローダ／リンカー関数(785)によって前記ＤＬ(735)を動的にロードしリンクするステップと、
を含む方法。
【請求項４７】
ＥＬＦファイルフォーマット又はＰＥファイルフォーマットを含むオブジェクトファイルフォーマットを選択するステップを更に備える、請求項４６に記載の方法。
【請求項４８】
前記ＤＬ(735)をコンピューティング環境メモリに動的にランタイムにロードするために、前記ダイナミックローダ／リンカー関数(785)によってメモリブロックを割り当てるステップを更に備える、請求項４６に記載の方法。
【請求項４９】
前記実行可能プログラム(795)が、前記アプリケーションソースコード(705)から導出されたメインアプリケーション関数(775)を含み、
更に、前記第２の関数を実行するための前記協働するメインアプリケーション関数(775)内の命令に応答して、前記第１の関数によってオープンされた前記ＤＬ(735)からエクスポートされるシンボルのアドレスを返すステップを更に備える、請求項４６に記載の方法。
【請求項５０】
前記プログラム(795)は、前記アプリケーションソースコード(705)から導出されたメインアプリケーション関数(775)を含み、
更に、前記協働するメインアプリケーションファンクションにおいて選択された関数をコールするためのＤＬ(735)へのアクセスを提供するインターフェイスモジュール(755)を、ソースコードとして用意するステップを更に備える、請求項４６に記載の方法。
【請求項５１】
前記インターフェイスモジュールのソースコード(755)、前記協働するコンピューティングアプリケーションのソースコード(705)、及び前記ダイナミックローダ／リンカーのソースコード(720)を、前記ターゲットソフトウェアプラットホームで実行されるバイナリー実行可能プログラム(795)へとコンパイルするステップを更に備える、請求項５０に記載の方法。
【請求項５２】
前記ＤＬバイナリーオブジェクトファイル(735)を再コンパイル又は再構築する必要なく、定義されたプロセッサアーキテクチャーで実行される複数のソフトウェアプラットホーム及びオペレーティングシステムにわたって、単一のＤＬバイナリーオブジェクトファイル(735)を一体化するステップを更に備える、請求項４６に記載の方法。
【請求項５３】
前記ＤＬ(735)と協働する前記コンピューティングアプリケーションの前記ソースコードと、前記ダイナミックローダ／リンカーのソースコード(720)とを、前記複数のソフトウェアプラットホームのうちの選択された一つのソフトウェアプラットホーム用の前記バイナリー実行可能プログラム(795)へとコンパイルしリンクするステップを更に備える、請求項５２に記載の方法。
【請求項５４】
前記コンピューティング環境は、前記選択されたオブジェクトフォーマットをネイティブにサポートしない、請求項４６に記載の方法。
【請求項５５】
バイナリーオブジェクトのダイナミックリンキングを実行するためのネイティブなダイナミックリンキングメカニズムをもたないオペレーティングシステムで動作する制約のあるコンピューティング環境において、前記ＤＬをロードして、該ＤＬをコンピューティングアプリケーションにリンクするステップを更に備える、請求項４６に記載の方法。
【請求項５６】
前記ＤＬソースコード(725)は、前記ターゲットソフトウェアプラットホームのプログラミング制約に違反するコードを含む、請求項４８に記載の方法。
【請求項５７】
前記プログラミング制約は、グローバル変数の使用に関する制約、書き込み可能なスタティック変数の使用に関する制約、及びポインタ変数の静的初期化に関する制約のいずれかを含む、請求項５７に記載の方法。
【請求項５８】
前記ＤＬ(735)において定義されたグローバル変数又は書き込み可能なスタティック変数の領域を、前記ＤＬ(735)により占有されるメモリブロックに制限するステップを更に備える、請求項５７に記載の方法。
【請求項５９】
前記ＤＬソースコード(725)は、コードの多数の実行インスタンス又は繰り返し実行を制限するように、データを取り扱い且つデータへのアクセス関数を提供するためのコードを含み、
前記方法は、更に、前記ＤＬ(735)のインスタンスを、前記ダイナミックローダ／リンカー関数(785)によって、動的に割り当てられたメモリブロックにロードするステップを備え、
前記ＤＬコード(725)において定義されたデータ変数の領域が、前記メモリブロックに制限される、
請求項４６に記載の方法。
【請求項６０】
単一のコンピューティング環境のプロセス内で実行されるべき同じＤＬ(735)の多数の非衝突インスタンスをロードするステップを更に備える、請求項５９に記載の方法。
【請求項６１】
ライブラリデータの多数のセットが、該ライブラリデータのセットの各々の間で衝突が軽減され及び／又は除去されるように、単一のコンピューティング環境のプロセス内で同時に動作する、請求項６０に記載の方法。
【請求項６２】
単一のコンピューティング環境のプロセス内でコードの実行を繰り返すために、非オブジェクト指向のコードをロードするステップを更に備える、請求項５９に記載の方法。
【請求項６３】
前記コンピューティング環境は、多数のプロセスをサポートしない、請求項６０又は６２に記載の方法。
【請求項６４】
前記コンピューティング環境は、非常駐の実行可能プログラムを前記コンピューティング環境に配備することに関して制限されており、
前記方法は、前記ＤＬ(735)を、前記協働するコンピューティングアプリケーション内に含まれた実行中のランチャーアプリケーションと動的にリンクすることによって、制限された前記コンピューティング環境に使用可能な機能を拡張するステップを更に備える、請求項４６に記載の方法。
【請求項６５】
前記コンピューティング環境は、
該コンピューティング環境がネイティブな実行可能プログラムの追加に対して閉じていること、
該コンピューティング環境が、実行を、プログラムサイズ限界内に入るプログラムに制限すること、
該コンピューティング環境がランタイム環境（ＲＴＥ）を有し、該ＲＴＥ内で動作するプログラムは、ネイティブなコンピューティング環境に利用可能な一以上の関数へのアクセスを制限すること、
該コンピューティング環境がＲＴＥを有しており、該ＲＴＥが、当該ＲＴＥに対して認証されたプログラムしか動作させないように、動作を制限すること、及び
該コンピューティング環境が、ダイナミックリンキングを許可しないこと、
のうち何れか一つ以上を含む一以上の制限を課せられている、
請求項６４に記載の方法。
【請求項６６】
定義されたプロセッサアーキテクチャーで動作する異種のコンピューティングソフトウェア環境にわたって使用するためにダイナミックライブラリ（ＤＬ）(735)を配布する方法であって、
ＤＬソースコード(725)を用意するステップと、
前記ＤＬソースコード(725)をコンパイルして、前記ＤＬ(735)を、選択されたフォーマットを有するオブジェクトファイルとして生成するステップ(730)と、
前記ＤＬ(735)と協働するコンピュータアプリケーション用のアプリケーションソースコード(705)を用意するステップと、
ダイナミックローダ／リンカーのソースコード(720)を用意するステップと、
前記ダイナミックローダ／リンカーの前記ソースコード(720)を、前記アプリケーションソースコード(705)と共にコンパイルし構築して、少なくとも一つの前記コンピューティング環境で動作可能なバイナリー実行可能プログラム(795)を生成するステップ(770)と、
通信ネットワーク及び記憶媒体の何れかを含む入力ソースから前記異種のコンピューティング環境へ前記ＤＬ(735)を通信するステップと、
前記ＤＬ(735)を前記バイナリー実行可能プログラム(795)に動的にリンクするステップと、
を備える方法。
【請求項６７】
少なくとも一つのＤＬ(735)と協働する前記コンピュータアプリケーションの新たなバージョンを通信するステップを更に備える、請求項６６に記載の方法。
【請求項６８】
前記コンピュータアプリケーションと協働する前記ＤＬ(735)の新たなバージョンを通信するステップを更に備える、請求項６６に記載の方法。
【請求項６９】
コンピューティング環境で使用するためにＤＬ(735)を配布する、請求項６６に記載の方法であって、
前記コンピューティング環境は、
該コンピューティング環境が、ネイティブな実行可能プログラムの追加に対して閉じていること、
該コンピューティング環境が、実行を、プログラムサイズ限界内に入るプログラムに制限すること、
該コンピューティング環境がランタイム環境（ＲＴＥ）を有し、該ＲＴＥ内で動作するプログラムは、ネイティブなコンピューティング環境に使用可能な一以上の関数へのアクセスを制限されていること、
該コンピューティング環境がＲＴＲを有し、該ＲＴＥが、当該ＲＴＥに対して認証されたプログラムしか動作させないように、動作を制限すること、及び
該コンピューティング環境が、ダイナミックリンキングを許可しないこと、
のうち何れか一つ以上を含む一以上の制約を課せられている、
方法。
【請求項７０】
協働するランチャーアプリケーションであってプロキシとして動作可能な該ランチャーアプリケーションを、コンピューティング装置にダウンロードし、該コンピューティング装置に利用可能なダイナミックライブラリであって通信ネットワーク及び記憶媒体の何れかを含む入力ソースからの該ダイナミックライブラリへの前記ランチャープログラムによるアクセスを可能にするステップを更に備える、請求項６９に記載の方法。
【請求項７１】
ダイナミックライブラリが前記コンピューティング装置に使用できるようになったときに、前記ランチャーアプリケーションの範囲を、協働するダイナミックライブラリの付加的なファンクションを含むように拡張するステップを更に備える、請求項７０に記載の方法。
【請求項７２】
前記協働するコンピュータアプリケーションは、コンピューティング装置のコンピューティング環境に、該コンピューティング装置をエンドユーザに販売するために出荷する前に、配備される、請求項６６に記載の方法。
【請求項７３】
前記協働するコンピュータアプリケーションは、コンピューティング装置のコンピューティング環境に、該コンピューティング装置をエンドユーザに販売するために出荷した後に、配備される、請求項６６に記載の方法。
【請求項７４】
前記コンピューティング装置は、移動電話又は無線イネーブル型ハンドセットである、請求項７２又は７３に記載の方法。
【請求項７５】
前記ＤＬ(735)は、前記コンピューティング環境へのコンテンツの安全な配布を促進するようにデジタルライツマネージメント構成で使用される、請求項６６に記載の方法。
【請求項７６】
コンピューティング環境内で動作するターゲットソフトウェアプラットホーム上で実行可能なバイナリー実行可能プログラムファイル(795)と、ダイナミックライブラリ（ＤＬ）(735)とを備えるコンピュータプログラム製品であって、
前記ＤＬ(735)が、選択された構造を有するバイナリーオブジェクトファイルを含み、
前記プログラムファイル(795)が、
前記ＤＬ(735)と協働可能なコンピューティングアプリケーション用のメインプリケーション関数(775)と、
前記ＤＬのためのダイナミックローダ／リンカー関数(785)と、
を備え、
前記ダイナミックローダ／リンカー関数(785)が、前記ＤＬ(735)をオープンするための第１の関数と、前記ＤＬ(735)によってエクスポートされるシンボルのメモリ内のアドレスを返すための第２の関数とを含むことによって、ターゲットソフトウェアプラットホームのネイティブなダイナミックリンキングファシリティがもしあれば、該ファシリティとは独立して、前記コンピューティングアプリケーションがランタイムに前記ＤＬ(735)にアクセスして該ＤＬと協働することを可能にする、
コンピュータプログラム製品。
【請求項７７】
前記ＤＬの選択された構造は、実行可能リンキングフォーマット（ＥＬＦ）、及びポータブル実行可能（ＰＥ）フォーマットの何れかを含む、請求項７６に記載のコンピュータプログラム製品。
【請求項７８】
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬオブジェクトファイル(735)のサイズを決定する、請求項７６又は７７に記載のコンピュータプログラム製品。
【請求項７９】
前記ダイナミックローダ／リンカー関数(785)は、前記ターゲットソフトウェアプラットホームに前記ＤＬオブジェクト(735)をロードするために、メモリを割り当てるようになっている、請求項７８に記載のコンピュータプログラム製品。
【請求項８０】
前記ダイナミックローダ／リンカー関数(785)は、ランタイムに前記ＤＬ(735)をその協働するメインアプリケーションファンクション(775)にリンクするように、前記ＤＬ(735)に対して動作するようになっている、請求項７６〜７９の何れか一項に記載のコンピュータプログラム製品。
【請求項８１】
前記第１の関数によってオープンされた前記ＤＬ(735)からエクスポートされるシンボルのアドレスは、前記第２の関数を実行するための前記協働するメインアプリケーションファンクション内の命令に応答して返される、請求項７６〜８０の何れか一項に記載のコンピュータプログラム製品。
【請求項８２】
前記協働するメインアプリケーションファンクション(775)に前記ＤＬ(735)へのアクセスを提供するインターフェイスファンクション(780)を更に備える、請求項７６〜８１の何れか一項に記載のコンピュータプログラム製品。
【請求項８３】
前記ダイナミックローダ／リンカー関数(790)は、前記協働するメインアプリケーションファンクション(775)及び前記ＤＬ(735)を、前記ターゲットソフトウェアプラットホーム上で動作可能なプロセスへと結合するために、シンボル解決及び再配置を取り扱うようになっている、請求項７６〜８２の何れか一項に記載のコンピュータプログラム製品。
【請求項８４】
前記動作可能なプロセスは、複数のダイナミックライブラリと協働して該複数のダイナミックライブラリに結合すコンピューティングアプリケーションを含む、請求項８３に記載のコンピュータプログラム製品。
【請求項８５】
前記ダイナミックローダ／リンカー関数(785)は、前記ファイルを前記協働するメインアプリケーションファンクション(775)にリンクするときに、ＤＬファイルと非ＤＬファイルとを区別するようになっている、請求項７６〜８４の何れか一項に記載のコンピュータプログラム製品。
【請求項８６】
前記動作可能なプロセスは、前記協働するメインアプリケーションファンクション(775)を、前記ＤＬ(735)にリンクし、前記ターゲットソフトウェアプラットホーム用のネイティブなダイナミックリンクライブラリにリンクする、請求項８３に記載のコンピュータプログラム製品。
【請求項８７】
前記ＤＬ(735)は、前記ターゲットソフトウェアプラットホーム上で実行されるときに、前記バイナリー実行可能プログラム(795)に動的にロードされリンクされるようになっており、
前記ＤＬ(735)は、前記ターゲットソフトウェアプラットホームのプログラミング制約に違反するコードを含む、
請求項７６〜８６の何れか一項に記載のコンピュータプログラム製品。
【請求項８８】
前記プログラミング制約は、グローバル変数の使用に関する制約、又は書き込み可能なスタティック変数の使用に関する制約、又はポインタ変数の静的初期化に関する制約を含む、請求項８７に記載のコンピュータプログラム製品。
【請求項８９】
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬ(735)がリンクされる前記プログラム(795)の実行中に、前記ターゲットソフトウェアプラットホームに前記ＤＬオブジェクト(735)をロードするために、メモリブロックを割り当てるようになっている、請求項８８に記載のコンピュータプログラム製品。
【請求項９０】
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬ(735)において定義されたグローバル変数又は書き込み可能なスタティック変数の領域を、前記ＤＬ(735)により占有されるメモリブロックに制限するように動作可能である、請求項８９に記載のコンピュータプログラム製品。
【請求項９１】
前記ＤＬ(735)は、データを取り扱い且つデータへのアクセス関数を提供するコードを、該コードの多数の実行インスタンス又は繰り返し実行を制限するように、含んでおり、
前記ダイナミックローダ／リンカー関数(785)は、前記ＤＬ(735)のインスタンスを、動的に割り当てられたメモリブロックにロードするようになっており、
前記ＤＬコードにおいて定義されたデータ変数の領域が、前記メモリブロックに制限される、
請求項７６〜９０の何れか一項に記載のコンピュータプログラム製品。
【請求項９２】
前記コンピューティング環境は、非常駐の実行可能プログラムを前記コンピューティング環境に配備することに関して制限されており、
前記メインアプリケーション関数(775)は、ランチャーモジュールを備えており、
前記ランチャーモジュールは、前記ＤＬ(735)を実行中の該ランチャーアプリケーションに動的にリンクすることによって、制限された前記コンピューティング環境に使用可能な機能を拡張するよう動作可能である、
請求項７６〜９１の何れか一項に記載のコンピュータプログラム製品。
【請求項９３】
前記ランチャーモジュールは、前記コンピューティング環境においてネイティブなコンピューティングアプリケーションとして動作するように書かれている、請求項９２に記載のコンピュータプログラム製品。
【請求項９４】
前記ランチャーモジュールは、前記コンピューティング環境の前記ランタイム環境内でコンピューティングアプリケーションとして動作するように書き込まれる、請求項９２に記載のコンピュータプログラム製品。
【請求項９５】
少なくとも二つのランチャーモジュールを更に備える、請求項９２に記載のコンピュータプログラム製品。
【請求項９６】
前記ＤＬ(735)は、前記制限されたコンピューティング環境へのコンテンツの安全な配布を促進するようにデジタルライツマネージメント構成で使用される、請求項９２に記載のコンピュータプログラム製品。
【請求項９７】
更に、前記ＤＬ(735)を、ランタイムに、コンピューティング環境のメモリに動的にロードするために、前記ダイナミックローダ／リンカー関数(785)によってメモリブロックを割り当てるようになっている、請求項７６〜９６の何れか一項に記載のコンピュータプログラム製品。
【国際調査報告】
2008516324.tif 000019
2008516324.tif 000020