JP2008516323A - プラットホーム独立の動的リンキング - Google Patents

Abstract

再構築又は再ローディングを必要とせずに、選択されたハードウェアアーキテクチャを有する異種のコンピューティング環境において動作できるプラットホーム独立のバイナリオブジェクト（ＰＩＢＯ）が提供される。ＰＩＢＯをパーズしてソースコードスタブファイルを生成することができる。ＰＩＢＯは、スタブファイルを使用する例示的リンカー／ローダーによりロードして、協働するコンピューティングアプリケーションとリンクすることができる。また、ＰＩＢＯは、次のものを含む（それらに限定されないが）種々の状況に使用することができ、即ち、ネイティブなファシリティを与えないプラットホームにおいて共有オブジェクトを動的にリンクするためのメカニズムとして使用でき、予め書き込まれるコードコンポーネントを、それがなければ、特定コード内のプラットホーム制約の違反のために不適合となるであろうプラットホームに利用するのに使用でき、コードに固有の複数の実行インスタンス及び繰り返し実行の制約を回避する非オブジェクト指向コードをロードするためのメカニズムとして使用でき、更に、閉じたプラットホームにファンクションをアドオンするためにバイナリオブジェクトの使用を許すメカニズムとして使用できる。
【選択図】 図７

Description

発明の分野

本発明は、バイナリオブジェクトの生成及び動作に関し、より詳細には、とりわけ、種々の非ネイティブなコンピューティング環境で動作を行えるように、異種のコンピューティング環境にわたって動作可能なプラットホーム独立のバイナリオブジェクト（Ｐｌａｔｆｏｒｍ Ｉｎｄｅｐｅｎｄｅｎｔ Ｂｉｎａｒｙ Ｏｂｊｅｃｔ）を生成し、作動させ、配布することに関する。

発明の背景

コンピューティング環境は、コンピューティング環境のハードウェアコンポーネントが一又は複数の動作をできるようにするために、一又は複数のインストラクションを含むコンピュータコードを実行することができる。通常、コンピュータコードは、実行のためにコンピューティング環境へロードされる。物理的なロードの前に、コンピュータコードは、それが特定のコンピューティング環境（例えば、コンピューティング環境のオペレーティングシステム及び／又はコンピューティング環境のプラットホーム）で動作するようにコンパイルされる。コンピュータコードは、コンピューティング環境により、そのコンピューティング環境に存在する他のコンピュータコードとリンクされ、一又は複数の動作を実行することができる。所与のコンピュータコードについてのコンピューティング環境の取り扱いに基づいて、そのコンピューティング環境及び／又は他の協働するコンピュータコードに使用されるバイナリオブジェクトを生成することができる。バイナリオブジェクトは、一又は複数の協働するコンピューティングプログラム（コンピューティングプログラム）により望まれる情報、ファンクション及び／又はオペレーションを含んでもよい。

一又は複数のファンクションは、次いで、一又は複数の動作を実行するために、コンピューティングアプリケーション、他のライブラリ、又はコンピューティング環境によって使用されるように一又は複数のライブラリに集められる。一般的な慣例では、ライブラリは、特定のハードウェアアーキテクチャを有する単一のコンピューティング環境によって利用されるように設計及び実装される。ライブラリは、静的なベース又は動的なベースのいずれかで所与のコンピューティング環境により利用することができる。静的な状況では、ライブラリと所与のコンピューティングアプリケーションの他のコンポーネントとが、単一ファイルへと結合され、これがメモリにロードされて実行される。これに比して、動的な動作（例えば、コンポーネントの動的リンキング）では、コンピューティングアプリケーションが実行されるときに、ファンクション及びコンポーネント（例えば、オブジェクト及びライブラリ）が使用可能とされる。動的なコンポーネントは、コンピューティング環境で動作している複数のコンピューティングアプリケーションにより共有することができる。この理由は、動的にリンクされたコンポーネントは、それらの設計及び動作上、コンピューティングアプリケーションの主要部に縛られないからである。

しかしながら、現在の慣例では、異種のコンピューティング環境で動作するためのコンピュータコードを生成して実行するときに、問題が起こり得る。現在の慣例では、一般に、特定のコンピューティングハードウェアアーキテクチャを有する特定のコンピューティング環境（例えば、ソフトウェア開発キット−ＳＤＫによる）に対してコンピュータコードを生成して実行することを要求するので、複数の異種のコンピューティング環境（例えば、種々のオペレーティングシステム及び／又はコンピューティングプラットホームを有する）で動作するための単一のバイナリオブジェクトを生成することは困難である。特定のコンピューティング環境のためのコードを生成するとき、コンピュータコードは、それをコンピューティング環境へロードする前にコンパイルされ得ると共に、コンピュータコードを実行するときにコンピューティング環境によりリンクされ得る。これらの制約の下、コンピュータコードは、一般に、単一のコンピューティング環境（即ち、オペレーティングシステム及び／又はプラットホーム）で動作するように設計され生成される。

更に、コンピューティング環境は、コンピュータコードが所与のコンピューティング環境において適切に実行されるように、コンピュータコードを生成する方法について制約及びルールを課すことができる。例えば、プラットホーム及び／又はオペレーティングシステム（例えば、Ｓｙｍｂｉａｎ ＱｕａｒｔｚをランするＳｙｍｂｉａｎＯＳ）は、書き込み可能な静的変数及び／又はグローバル変数の使用を含む（これらに限定されない）、特定のプラットホーム及び／又はオペレーティングシステムで実行されるコンピュータコードに対して、多くの制約を維持することができる。換言すれば、プラットホーム及び／又はオペレーティングシステムは、書き込み可能な静的変数又はグローバル変数を有するコンピュータコードの動作を禁止し得る。

コンピュータコード開発者の中で共通の慣例は、これには限定されないが、同じ動作を行うが、オペレーティングシステム及びプラットホームの異種セットの各々に対して構築される種々のコードを開発することを含む。例えば、カレンダーコンピューティングアプリケーションは、Ｊａｖａ、“Ｃ＋＋”又はビジュアル・ベーシックのような単一の高水準プログラミング言語を使用して開発することができる。開発時間及びリソースを減少するための工夫として、コアのコンピューティングアプリケーションコードが開発者によって再使用される。しかしながら、現在の慣例では、異種のコンピューティング環境（例えば、オペレーティングシステム及び／又はプラットホーム）の各セットにおいてコンピューティングアプリケーションが動作することを保証するために、付加的なコンポーネント（例えば、ライブラリ、ファンクション、データ構造、等）を開発してカスタマイズする必要があるので、このような再使用の程度は制限される。

従来の慣例及びアプローチには、これに限定されないが、異種のコンピューティング環境の各々に対して再構築又は再コンパイルを必要とせずに複数の異種のコンピューティング環境にわたって動作できる単一のプラットホーム独立のバイナリオブジェクトを持てないという制限もある。更に、現在の慣例及びアプローチは、このようなネイティブなファシリティを与えないプラットホームにおいて共有オブジェクトを動的にリンクするためのメカニズムを提供するものではない。また、現在の慣例では、予め書き込まれたコードコンポーネントを、それがなければ特定コード内のプラットホーム制約に違反するために不適合となるであろうプラットホームに使用することができない。更に、現在の慣例は、複数の実行インスタンスの制約を回避してコード固有の実行を繰り返す非オブジェクト指向コードをロードするためのメカニズムを提供するものではない。また、現在の慣例及びアプローチは、閉じたプラットホーム（例えば、付加的なプログラムの実行を制約し得るプラットホーム）においてバイナリオブジェクトを動的にリンクしロードすることを許すメカニズムを提供するものでもない。

発明の概要

ここに説明するシステム及び方法は、再コンパイル、再構築、又は再ロードを必要とせずに、選択されたハードウェアアーキテクチャを有する異種のコンピューティング環境において動作できるプラットホーム独立のバイナリオブジェクト（ＰＩＢＯ）を提供する。ここに例示する実施形態では、選択された構造（例えば、オブジェクトファイルフォーマット）を有するバイナリオブジェクトファイルが設けられる。このバイナリオブジェクトファイルは、ソースコードがその生成時にプラットホーム依存性をもたないように、ソースコードをコンパイルすることにより生成できる。ここに例示する実施形態では、バイナリオブジェクトファイルは、ソースファイルについてのバイナリコード及びデータを含む。更に、ここに例示する実施形態では、ソースコードスタブファイルを生成するために例示的なバイナリオブジェクトファイルに対して動作する例示的なパーザが設けられる。更に、例示的なコンピューティングアプリケーションの一部として動作して、そのスタブファイルを使用してプラットホーム独立のバイナリオブジェクトをリンクしロードすると共に、異種のコンピューティング環境において協働するコンピューティングプログラムとの協働を許す例示的リンカー／ローダーが設けられる。また、協働するコンピューティングアプリケーションが例示的ＰＩＢＯにアクセスするのを許す例示的インターフェイスを設けることもできる。

ここに例示する動作において、例示的なパーザがＰＩＢＯファイルをパーズして、スタブファイルをソースコードとして生成することができる。スタブファイルソースコードは、プラットホーム依存性を維持しないようにされる。例示的リンカー／ローダー及びスタブファイルは、異種のコンピューティング環境の１つに対して、協働するコンピューティングアプリケーションのメインソースコードと共にコンパイルして、異種のコンピューティング環境（及び／又はプラットホーム）の１つにおいて動作可能なバイナリ実行可能(binary executable)を生成することができる。ここに例示する実施形態では、例示的リンカー／ローダーは、協働するコンピューティングアプリケーションの実行中にその協働するコンピューティングアプリケーションでＰＩＢＯをリンクしロードするように動作できる。ここに例示する実施形態では、リンカー／ローダーは、シンボル分析及びリロケーションを取り扱い、協働するコンピューティングアプリケーションのバイナリ実行ファイル（ｂｉｎａｒｙ ｅｘｅｃｕｔａｂｌｅ）を、完全にラン可能なプロセスとして、ＰＩＢＯと結合することができる。

ここに例示する実施形態では、ＰＩＢＯは、これらに限定されないが次のものを含む種々の状況に使用することができる。即ち、ネイティブなファシリティを与えないプラットホームにおいて共有オブジェクトを動的にリンクするためのメカニズムとして使用でき、予め記述されたコードコンポーネントを、それがなければ特定コード内のプラットホーム制約の違反のために不適合となるであろうプラットホームに利用するのに使用でき、コードに固有の複数の実行インスタンス及び繰り返し実行の制約を回避する非オブジェクト指向コードをロードするためのメカニズムとして使用でき、更に、閉じたプラットホームにアドオンファンクションを設けるためにプラットホーム独立のバイナリオブジェクトの使用を許すメカニズムとして使用できる。

本発明の他の特徴については、以下に詳細に説明する。

プラットホーム独立の動的なオブジェクト及びその使用方法は、添付図面を参照して、一例として、以下に詳細に述べる。

詳細な説明

１．概略
コンピュータコードは、コンピュータシステム又は装置内の中央処理ユニット（ＣＰＵ）又は他のコンピュータプロセッサにおいて実行することができる。ＣＰＵアーキテクチャの一般的な例としては、ＩＮＴＥＬ（登録商標）ｘ８６ファミリー、ＡＲＭ（登録商標）ＲＩＳＣ（リデュースドインストラクションセットコード）アーキテクチャ、ＳＵＮ（登録商標）ＳＰＡＲＣ、及びＭＯＴＯＲＯＬＡ（登録商標）６８０００が挙げられるが、これらに限定されない。コードは、人間が理解できる“Ｃ”、“Ｃ＋＋”、又はＪＡＶＡ（登録商標）のような高水準言語で書くことができるが、最終的に、コードは、その後、コンピューティング環境により、例示的なコンピュータプロセッサで実行されるマシンインストラクションへとコンパイル及びアッセンブルされ得る。

ＣＰＵは、システムプラットホームとして一般的に知られたソフトウェア環境内に存在することができる。プラットホームは、大きなフォームファクタのコンピューティング環境（例えば、デスクトップ、ラップトップパーソナルコンピュータ）については、ＭＩＣＲＯＳＯＦＴ（登録商標）WINDOWS（登録商標）やＬｉｎｕｘのようなオペレーティングシステムを含むことができる。より小さなフォームファクタのコンピューティング環境（例えば、移動及びテレコム装置）については、Ｌｉｎｕｘ、ＳｙｍｂｉａｎＯＳ、ＷｉｎｄｏｗｓＣＥ（登録商標）、ＰａｌｍＯＳ、ＢＲＥＷ、ＲＥＸ及びＩｔｒｏｎを含む（これらに限定されないが）種々のオペレーティングシステムが現在使用されている。

プラットホームは、多くの場合に、ＯＳを特定の目的について拡張する付加的なファンクションを維持することができる。例えば、ＷｉｎＣＥ．ＮＥＴ、Ｓｍａｒｔｐｈｏｎｅ、及びＰｏｃｋｅｔＰＣプラットホームは、Ｗｉｎｄｏｗｓ ＣＥオペレーティングシステムを使用するが、ユーザインターフェイスのような他の観点が異なり、即ち、ＷｉｎＣＥ．ＮＥＴは、工業用装置をターゲットとすることができ、ＰｏｃｋｅｔＰＣは、タッチスクリーンをもつパーソナルデジタルアシスタント（ＰＤＡ）をターゲットとすることができ、更に、Ｓｍａｒｔｐｈｏｎｅは、キーパッドを経て動作する移動セルラー電話をターゲットとすることができる。また、プラットホームは、特定のコンピューティングアプリケーションに対して仕立てられた拡張されたファンクションを含むこともできる。ここに示す例では、ＰｏｃｋｅｔＰＣプラットホームは、ＰＤＡに対する個人的情報管理についてある範囲のファンクションを維持することができ、一方、Ｓｍａｒｔｐｈｏｎｅプラットホームは、移動電話に適した通信ファンクションと共にパッケージすることができる。

従来のシステムでは、特定のプラットホームにおいてランできるバイナリコードの生成は、特定のプラットホーム（及び／又はオペレーティングシステム）に対して設けられたソフトウェア開発キット（ＳＤＫ）のようなツールチェーンを通してコードをコンパイルし、構築することにより達成できる。所与のオペレーティングシステムで動作する異なるプラットホームのためのコードを開発するために、異なるＳＤＫが要求される（例えば、Ｓｙｍｂｉａｎ Ｑｕａｒｔｚは、Ｓｙｍｂｉａｎ Ｃｒｙｓｔａｌとは異なるＳＤＫを要求する）。特定のプラットホームのためのコードを開発するのに不適切なＳＤＫが使用された場合には、それにより得られるバイナリが希望のプラットホームにおいて不作動になり得る。

ソースコードレベルにおいて、あるオペレーティングシステムは、コードを書き込む仕方に制約及びルールを課す。例えば、ＳｙｍｂｉａｎＯＳは、書き込み可能な静的又はグローバル変数を使用しないようにコードを生成することを要求する。このような制約の結果として、１つのＯＳについて最初に書かれたレガシーコードは、異なるコードルールを要求する別のＯＳにおいてコンパイルされないことがある。それにも関わらず、共通の慣例として、複数のプラットホーム向けにその後に構築され得る単一のソースコードプログラムを記述する。実装時に、共通のソースファイルが展開される。この共通のソースファイルは、選択されたプラットホームのツールチェーンを介して別々に処理して、複数の個別の、プラットホーム特有のバイナリ出力を単一のソースファイルから生成することができる。

２．動的リンキング及びローディング
コンピュータプログラムは、複数のコンポーネントで構成される。プログラムがランされるときに、これらのコンポーネントを一緒にして、完全なファンクションシステムを形成できると共に、プログラムを実行する協働するコンピューティング環境のメインメモリにロードすることができる。コンピュータプログラムのコンポーネントを結合するプロセスは、リンキングとして知られている。プログラムコンポーネントが１つの単一ファイルへと結合され、これをメモリにロードして実行できる場合には、このようなプロセスが「静的リンキング」として説明される。一般に、リンカーは、リンカーへの入力として働くことのできるコンポーネントオブジェクトファイルを連結できるツールチェーンの一部分であり、複数のオブジェクトファイルを一緒にリンクして単一の出力ファイルを形成することができる。プログラムが負空のサブプログラムで作り上げられるときには、あるプログラムの、別のプログラムへの参照を、シンボル（変数及びファンクション名のような）を介して行うことができる。他のファンクション及びオペレーションの中で、リンカーは、協働するコンピューティング環境のメモリにおけるシンボル（１つ又は複数）の位置にノートし、そして発呼側サブプログラムのオブジェクトコードをパッチして、コールインストラクションがそのノートしたメモリ位置を参照するようにすることで、参照を分析するように動作することができる。

「静的なリンキング」では、プログラムが、別のコンポーネントに記憶されたファンクションへコールを発するときに、その要求されたファンクションに対するコードを静的リンカーにより実行可能ファイル（エグズキュータブル）において合体することができる。実際に、静的なリンカーは、要求された全てのファンクションのコードを出力実行可能ファイルにコピーする。対照的に、「動的なリンキング」は、プログラムの実行中だけファンクション及びコンポーネントを使用可能にすることができる。動的にリンクされたコンポーネントは、一般に、プログラムのメイン部分に束縛されないので、複数の実行されるプログラムによりそれらを共有することができる。また、メインプログラムは、静的にリンクされる相手部分より著しく小さくすることもできる。というのは、実際のコードがプログラムの実行可能ファイル（エグズキュータブル）の一部分とならず、且つ動的にリンクされるコンポーネントが個別のファイルとして存在するからである。現在のコンピューティング環境の間では「動的なリンキング」が一般的である。例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）では、動的にリンクされるコンポーネントは、ＤＬＬ（動的リンクライブラリ）と称され、そしてＵｎｉｘ／Ｌｉｎｕｘでは、それらは、共有オブジェクト（．ｓｏ）ファイルと称される。

動的にリンクされたライブラリ中のファンクションへプログラムがコールを行なうインスタンスでは、コンパイラ及びリンカーは、ランタイムの際に、協働するコンピューティング環境がライブラリをロードすると共に、要求されたファンクションに対するコードを見つけるのを許すことのできる情報を含むリロケーションテーブルを生成することができる。動的にリンクされたライブラリでは、ライブラリを使用するプログラムがランを開始するまで（「ロードタイム動的リンキング」として知られている）、又はプログラムが第１コールを行なうまで（「ランタイム動的リンキング」）、シンボルが実際のアドレスに結合されない。

動的な実行可能ファイル（エグズキュータブル）は、動的なリンカー／ローダーの制御のもとで実行することができる。これらのアプリケーションは、ラン可能なプロセスを生成するように動的なリンカーにより探索して結合することのできる動的なライブラリ（又は共有オブジェクト）の形態の依存性を有する。また、共有オブジェクトは、これも動的なリンカーにより管理される他の共有オブジェクトに対する依存性を有する。従来の解決策では、結合された実行可能ファイル（エグズキュータブル）及び共有オブジェクトが完全なプログラムとしてランするのを可能とする結合、シンボル分析、及びコードリロケーションを取り扱う動的なリンキング及びローディングのためのルーチンは、一般に、コンピューティング環境のオペレーティングシステムの一部分である。

実際に、動的なライブラリは、ロード時にリンクすることができる。動的なライブラリが生成されると、小さなスタブファイル又はインポートライブラリが生成され、これは、動的なライブラリをロードすると共にそれがエクスポートするファンクションを探索するのに使用できる情報（シンボル及びリロケーションテーブルのような）を、コンピューティング環境に供給する。インポートライブラリ（又はスタブファイル）は、メインの実行可能なプログラムが生成されるときにリンクすることができ、従って、共有オブジェクトの実際のバイナリコードが別々のままであっても、共有オブジェクトライブラリ内の全てのファンクション位置が実行可能なプログラムに分かる。

２(ａ) 例示的コンピューティング環境
図１は、ここに述べるシステム及び方法に基づく例示的コンピューティングシステム１００を示す。このコンピューティングシステム１００は、種々のコンピューティングプログラム１８０を実行することができる。例示的コンピューティングシステム１００は、主として、コンピュータ読み取り可能なインストラクションにより制御され、これらインストラクションは、ソフトウェアの形態でもよく、また、このようなソフトウェアをどこにどのように記憶し又はアクセスするかのインストラクションも与える。このようなソフトウェアは、中央処理ユニット（ＣＰＵ）１１０内で実行されて、データ処理システム１００を機能させる。多くの既知のコンピュータサーバー、ワークステーション、及びパーソナルコンピュータでは、中央処理ユニット１１０が、マイクロプロセッサと称するマイクロ電子チップＣＰＵにより実施される。コプロセッサ１１５は、メインＣＰＵ１１０とは別の任意のプロセッサで、付加的なファンクションを遂行し、又はＣＰＵ１１０をアシストする。ＣＰＵ１１０は、相互接続部１１２を経てコプロセッサ１１５に接続されてもよい。１つの通常の形式のコプロセッサは、ニューメリック又はマス(math)コプロセッサとも称されるフローティングポイントコプロセッサで、これは、数値計算を汎用ＣＰＵ１１０より迅速且つ良好に遂行するように設計される。

例示的コンピューティング環境は、単一のＣＰＵ１１０を備えるように示されているが、このような説明は単なる例示に過ぎず、コンピューティング環境１００は、複数のＣＰＵ１１０を備えてもよいことが明らかであろう。更に、コンピューティング環境１００は、通信ネットワーク１６０又は他の何らかのデータ通信手段（図示せず）を通してリモートＣＰＵ（図示せず）のリソースを利用してもよい。

動作中に、ＣＰＵ１１０は、インストラクションをフェッチし、デコードし、実行すると共に、コンピュータのメインデータ転送経路であるシステムバス１０５を経て他のリソースへ及び他のリソースから情報を転送する。このようなシステムバスは、コンピューティングシステム１００内のコンポーネントを接続すると共に、データ交換のための媒体を定義する。システムバス１０５は、通常、データを送るためのデータライン、アドレスを送るためのアドレスライン、及び割り込みを送り且つシステムバスを動作するための制御ラインを備えている。このようなシステムバスは、例えば、ＰＣＩ（周辺コンポーネント相互接続）バスである。今日の進歩したバスの幾つかは、拡張カード、コントローラ及びＣＰＵ１１０によるバスへのアクセスを調整するバスアービトレーションと称されるファンクションを与える。これらのバスにアタッチしてバスを引き継ぐようにアービトレーション（調停）する装置は、バスマスターと称される。また、バスマスターは、プロセッサ及びそのサポートチップを収容するバスマスターアダプタの追加により、バスのマルチプロセッサコンフィギュレーションが生成されるようにサポートする。

システムバス１０５に結合されるメモリ装置は、ランダムアクセスメモリ（ＲＡＭ）１２５、及びリードオンリメモリ（ＲＯＭ）１３０を含む。このようなメモリは、情報を記憶し検索するのを許す回路を備えている。ＲＯＭ１３０は、一般に、変更できない記憶されたデータを含む。ＲＡＭ１２５に記憶されるデータは、ＣＰＵ１１０又は他のハードウェア装置により読み取り又は変更することができる。ＲＡＭ１２５及び／又はＲＯＭ１３０へのアクセスは、メモリコントローラ１２０により制御できる。このメモリコントローラ１２０は、インストラクションが実行されるときにバーチャルアドレスを物理的アドレスに変換するアドレス変換ファンクションを与えることができる。また、メモリコントローラ１２０は、システム内のプロセスを分離すると共に、システムプロセスをユーザプロセスから分離するメモリ保護ファンクションも与えることができる。従って、ユーザモードでランするプログラムは、通常、それ自身のプロセスのバーチャルアドレススペースによりマップされたメモリしかアクセスできない。換言すれば、プログラムは、プロセスとプロセスとの間のメモリ共有が設定されない限り、別のプロセスのバーチャルアドレススペース内のメモリにアクセスすることはできない。

更に、コンピューティングシステム１００は、ＣＰＵ１１０から、プリンタ１４０、キーボード１４５、マウス１５０及びデータ記憶ドライブ１５５のような周辺機器へインストラクションを通信する役割を果たす周辺機器コントローラ１３５を含むこともできる。

ディスプレイコントローラ１６３により制御されるディスプレイ１６５は、コンピューティングシステム１００により生成されるビジュアル出力を表示するのに使用される。このようなビジュアル出力は、テキスト、グラフィック、アニメーショングラフィック、及びビデオを含むことができる。ディスプレイ１６５は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、タッチパネル、又は種々のフォームファクタの他のディスプレイ形態で実施することができる。ディスプレイコントローラ１６３は、ディスプレイ１６５へ送信されるビデオ信号を生成するのに必要な電子コンポーネントを備えている。

更に、コンピューティングシステム１００は、このコンピューティングシステム１００を外部通信ネットワーク１６０に接続するのに使用できるネットワークアダプタ１７０も含むことができる。通信ネットワーク１６０は、ソフトウェア及び情報を電子的に通信し且つ転送する手段をコンピュータユーザに与えることができる。更に、通信ネットワーク１６０は、複数のコンピュータを伴うと共に、タスクの遂行にワークロードの分担や協力の努力を伴う分散型処理を与えることもできる。図示されたネットワーク接続は、例示に過ぎず、コンピュータ間に通信リンクを確立する他の手段を使用してもよいことが明らかである。

例示的コンピュータシステム１００は、ここに述べるシステム及び方法が動作し得るコンピューティング環境を単に例示するもので、ここに述べる本発明の概念は、種々のコンポーネント及びコンフィギュレーションを有する種々のコンピューティング環境で実施できるので、ここに述べるシステム及び方法を、異なるコンポーネント及びコンフィギュレーションを有するコンピューティング環境で実施することを何ら制限するものでないことが明らかである。

２(ｂ) 例示的コンピュータネットワーク環境
上述したコンピューティングシステム１００は、コンピュータネットワークの一部分として配備することができる。一般に、コンピューティング環境についての上記説明は、ネットワーク環境に配備されるサーバーコンピュータ及びクライアントコンピュータの両方に適用される。図２は、例示的なネットワーク構成のコンピューティング環境２００を示すもので、サーバー２０５は、ここに述べる装置及び方法を使用できる通信ネットワークを経てクライアントコンピュータと通信する。図２に示すように、サーバー２０５は、通信ネットワーク１６０（固定ワイヤ又はワイヤレスのＬＡＮ、ＷＡＮ、イントラネット、エクストラネット、ピア対ピアネットワーク、インターネット、又は他の通信ネットワークのいずれか、又はその組み合せでよい）を経て、複数のクライアントコンピューティング環境、例えば、タブレットパーソナルコンピュータ２１０、移動電話２１５、電話２２０、パーソナルコンピュータ１００、及びパーソナルデジタルアシスタント２２５に相互接続することができる。更に、ここに述べる装置及び方法は、通信ネットワーク１６０を経て、自動車のコンピューティング環境（図示せず）、消費者向け電子装置のコンピューティング環境（図示せず）、及びビルの自動制御のコンピューティング環境（図示せず）と協働することができる。例えば、通信ネットワーク１６０がインターネットであるネットワーク環境では、サーバー２０５は、複数の既知のプロトコル、例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、ファイル転送プロトコル（ＦＴＰ）、シンプルオブジェクトアクセスプロトコル（ＳＯＡＰ）、又はワイヤレスアプリケーションプロトコル（ＷＡＰ）のいずれかを経て、クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５へ及びそこからデータを通信し処理するように動作できる専用のコンピューティング環境サーバーである。各クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５は、サーバーコンピューティング環境２０５へのアクセスを得るために、一又は複数のコンピューティングプログラム１８０、例えば、ウェブブラウザ（図示せず）、又は移動デスクトップ環境（図示せず）を装備することができる。

動作中に、ユーザ（図示せず）は、クライアントコンピューティング環境でランしているコンピュータプログラムと対話して、希望のデータ及び／又はコンピューティングプログラムを得ることができる。データ及び／又はコンピューティングアプリケーションは、サーバーコンピューティング環境２０５に記憶することができると共に、クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５を通り、例示的通信ネットワーク１６０を経て、協働するユーザへ通信することができる。参加するユーザは、サーバーコンピューティング環境２０５に全体的又は部分的に収容された特定データ及びアプリケーションへのアクセスを要求することができる。このようなデータ通信は、クライアントコンピューティング環境１００、２１０、２１５、２２０及び２２５と、サーバーコンピューティング環境との間で処理及び記憶のために行うことができる。サーバーコンピューティング環境２０５は、データの生成、認証、暗号化及び通信のために、コンピューティングプログラム、プロセス、及びアプレットをホスト処理できると共に、他のサーバーコンピューティング環境（図示せず）、第三者のサービスプロバイダー（図示せず）、ネットワークアタッチ型記憶装置（ＮＡＳ）、及び記憶エリアネットワーク（ＳＡＮ）と協働して、このようなデータトランザクションを実現することができる。

従って、ここに述べる装置及び方法は、ネットワークにアクセスして対話するためのクライアントコンピューティング環境と、このクライアントコンピューティング環境と対話するためのサーバーコンピューティング環境とを有するコンピュータネットワーク環境に使用することができる。しかしながら、移動装置プラットホームを与える装置及び方法は、種々のネットワークベースのアーキテクチャで実施することができ、従って、ここに示す実施例に限定されるものではない。

３．プラットホーム依存リンキング
実行可能なプログラムは、一般に、プラットホーム依存である。換言すれば、所与のプログラムは、展開されたときに特定のプラットホームでランするように意図され、従って、その特定のプラットホームに対してコンパイルされ、リンクされ、構築されねばならない。また、このようなプロセスから生成されて得られるバイナリ実行可能ファイルは、一般に、異なるプラットホームではランされない。従来のシステムでは、各個々のオペレーティングシステムのために別々の動的ライブラリを構築することが必要となる。複数のオペレーティングシステムをサポートすべき場合には、専用のツールを使用して、ライブラリコードを複数の共有オブジェクト（動的ライブラリ）内に構築しなければならず、即ち各オペレーティングシステムに対して１つずつ構築しなければならない。コードが、個々のプラットホームに対して独特のアイテムを明確に参照しない場合には、所与の当該オペレーティングシステムに対して共有オブジェクトライブラリを生成して、そのオペレーティングシステムから導出される複数のプラットホーム上でファンクションさせるのに充分である。これとは対照的に、ライブラリコードがプラットホーム独特のファンクションに対して明確な依存性を有する場合には、共有オブジェクトを特に所与のプラットホームに対して構築しなければならず、この共有オブジェクトは、一般に、明確な依存性を持たない他のプラットホームでは動作しない。

オペレーティングシステムが複数のプラットホームをサポートするインスタンスでは、プログラムコンポーネントのセットは、通常、次のコンポーネントを含むが、これに限定されない。即ち、プラットホームに独特に拘束された実行可能なバイナリ、及びプラットホームの基礎となるオペレーティングシステムに対して構築された共有オブジェクト（動的ライブラリ）の任意のセットである。

図３は、「動的なリンキング」を遂行するときに例示的コンピューティング環境３００により遂行されるプロセスを示す。図３に示すように、プログラムソースファイル３５０は、ブロック３４５においてオブジェクトファイルを生成するようにコンパイルされる。同様に、ライブラリソースファイル３０５は、ブロック３１０において動的ライブラリを生成するようにコンパイルされる。それにより得られる動的ライブラリオブジェクトファイル３１５は、インポートライブラリアン３２０への入力として働き、これは、動的ライブラリオブジェクトファイル３１５に対して動作して、インポートライブラリスタブファイル３２５を生成する。コンパイル３４５からのオブジェクトファイルは、スタブファイル３２５に静的にリンクされ、動的なバイナリ実行可能ファイル３４０を生成する。

図３に示すように、動的リンカー３３０は、動的に実行可能なオブジェクトファイル３４０及び動的ライブラリオブジェクトファイル３１５を入力として受け取り、完全にリンクされ且つ結合された実行可能なファイル３３５（例えば、ラン可能なプロセス）を生成する。動作中に、コンピューティングアプリケーション（例えば、プログラムソースファイル３５０）は、協働する動的リンクライブラリから一又は複数のファンクションをコールすることができる。ファンクションがコールされたとき、又はプログラムが実行されるとき（上述したように）、動的リンカー３３０は、プログラムアプリケーションによりコールされるファンクションを代表するメモリで見つかるシンボル又はプログラム実行に要求されるものを動的に探索するように動作する。

図４及び５は、従来の解決策により複数のオペレーティングシステム及びプラットホームでランさせるためにソースコードをどのように処理できるか示す。単一のオペレーティングシステムＡ ４８５が２つのプラットホームＡ１ ４７５及びＡ２ ４８０をサポートする図４を参照すれば、ライブラリソースファイル４０５及びプログラムソースファイル４１５を有する例示的な動的リンキングアーキテクチャ４００が示されている。ライブラリソースファイル４０５は、ブロック４１０においてコンパイルされて、オペレーティングシステムＡ ４８５に対する動的ライブラリを生成する。それにより動的ライブラリＡ ４３０に対して得られる動的ライブラリオブジェクトファイルは、インポートライブラリアン４４５への入力として働き、これは、動的ライブラリＡ ４３０に対する動的ライブラリオブジェクトファイルを処理して、インポートライブラリスタブファイルＡ ４５０を生じさせる。

同様に、プログラムソースファイル４１５は、ブロック４２０においてコンパイルされて、プラットホームＡ１ ４７５に対するオブジェクトファイルを生成し、また、ブロック４２５においてコンパイルされて、プラットホームＡ２ ４８０に対するオブジェクトファイルを生成する。コンパイル４２０から生じるオブジェクトファイルは、スタブファイル４５０と静的にリンクされ、それにより、動的に実行可能なオブジェクトファイルＡ１ｅｘｅｃ４３５（例えば、プラットホームＡ１ ４７５における実行可能ファイル）を生成する。また、図示されたように、コンパイル４２５から生じるオブジェクトファイルは、スタブファイル４５０に静的にリンクされて、それにより、動的に実行可能なオブジェクトファイルＡ２ｅｘｅｃ４４０（プラットホームＡ２ ４８０における実行可能ファイル）を生成する。動的リンカー４５５は、動的ライブラリ４３０を、動的に実行可能なオブジェクトファイルＡ１ｅｘｅｃ４３５にリンクして、完全にリンクされた実行可能ファイル（エグズキュータブル）４６５を生成するように動作し、これは、オペレーティングシステムＡ ４８５のメモリへロードされ、プラットホームＡ１ ４７５においてラン可能なプロセスを生成する。同様に、動的リンカー４６０は、動的ライブラリ４３０を、動的に実行可能なオブジェクトファイルＡ２ｅｘｅｃ４４０にリンクして、完全にリンクされた実行可能ファイル（エグズキュータブル）４７０を生成するように動作し、これは、オペレーティングシステムＡ ４８５のメモリへロードされ、プラットホームＡ２ ４８０においてラン可能なプロセスを生成する。動作中に、完全にリンクされた実行可能ファイル４６５又は４７０のいずれかが、各々、動的ライブラリ４３０からファンクションをコールするか又はデータを検索することができる。

図５を参照すれば、ライブラリソースファイル５０５及びプログラムソースファイル５１５を有する例示的な動的リンキングアーキテクチャ５００が示されている。ライブラリソースファイル５０５は、ブロック５１０においてコンパイルされて、オペレーティングシステムＢ ５８５に対する動的ライブラリを生成する。それによりオペレーティングシステムＢ ５８５に対して得られる動的ライブラリオブジェクトファイル５３０は、インポートライブラリアン５４５への入力として働き、これは、動的ライブラリオブジェクトファイル５３０を処理して、インポートライブラリスタブファイルＢ ５５０を生成する。

同様に、プログラムソースファイル５１５は、ブロック５２０においてコンパイルされて、プラットホームＢ１ ５７５に対するオブジェクトファイルを生成し、また、ブロック５２５においてコンパイルされて、プラットホームＢ２ ５８０に対するオブジェクトファイルを生成する。コンパイル５２０から生じるオブジェクトファイルは、スタブファイル５５０と静的にリンクされ、それにより、動的に実行可能なオブジェクトファイルＢ１ｅｘｅｃ５３５（例えば、プラットホームＢ１ ５７５における実行可能ファイル（エグズキュータブル））を生成する。また、図示されたように、コンパイル５２５から生じるオブジェクトファイルは、スタブファイル５５０に静的にリンクされて、それにより、動的に実行可能なオブジェクトファイルＢ２ｅｘｅｃ５４０（プラットホームＢ２ ５８０における実行可能ファイル）を生成する。動的リンカー５５５は、動的ライブラリ５３０を、動的に実行可能なオブジェクトファイルＢ１ｅｘｅｃ５３５にリンクして、完全にリンクされた実行可能ファイル５６５を生成するように動作し、これは、オペレーティングシステムＢ ５８５のメモリへロードされ、プラットホームＢ１ ５７５においてラン可能なプロセスを生成する。同様に、動的リンカー５６０は、動的ライブラリ５３０を、動的に実行可能なオブジェクトファイルＢ２ｅｘｅｃ５４０にリンクして、完全にリンクされた実行可能ファイル（エグズキュータブル）５７０を生成するように動作し、これは、オペレーティングシステムＢ ５８５のメモリへロードされ、プラットホームＢ２ ５８０においてラン可能なプロセスを生成する。動作中に、完全にリンクされた実行可能ファイル（エグズキュータブル）５６５又は５７０のいずれかが、各々、動的ライブラリ５３０からファンクションをコールするか又はデータを検索することができる。

図４及び５に示すように、アプリケーションプログラム各々４１５及び５１５と、ライブラリファイル各々４０５及び５０５とで構成されるソースコードの共通セットが存在する。ここに示す実施形態では、アプリケーションプログラムは、４つの別々のプラットホーム、即ち共通のオペレーティングシステムＡ ４８５から導出されるプラットホームＡ１ ４７５及びＡ２ ４８０と、オペレーティングシステムＢ ５８５から導出されるプラットホームＢ１ ５７５及びＢ２ ５８０とにおいてランするように書き込むことができる。アプリケーション４１５及び５１５のソースコードは、各プラットホーム、即ちプラットホームＡ１ ４７５、プラットホームＡ２ ４８０、プラットホームＢ１ ５７５及びプラットホームＢ２ ５８０に特有のインストラクションを維持できると共に、アプリケーション４１５及び５１５のソースコードがコンパイルされるときにプラットホーム依存性を識別できる仕方で書き込むことができる。

ここに示す実施形態では、ライブラリ４０５及び５０５に関するソースコードは、一般に、特定のプラットホーム依存性を維持しない。ここに例示する動作においては、ライブラリは、協働するアプリケーションプログラムによりコールすることができ、そして動的なライブラリとして動作することができる。図４に示すように、各プラットホーム（４７５及び４８０）は、それ自身の動的に実行可能なファイルＡ１ｅｘｅｃ４３５、Ａ２ｅｘｅｃ４４０を要求することができ、これらは、プラットホーム特有のコンパイラツール（例えば、コンパイラブロック４２０及び４２５）を介して共通のアプリケーションソースファイル４１５をコンパイルすることにより生成することができる。ここに例示する実施形態では、協働する動的ライブラリ４３０は、一度生成されて、実行可能ファイルＡ１ｅｘｅｃ４３５又はＡ２ｅｘｅｃ４４０の両方に動的にリンクされ、各プラットホームＡ１ ４７５及びＡ２ ４８０においてラン可能なプロセスを各々生成することができる。

図５に示すように、プラットホームＢ１ ５７５及びプラットホームＢ２ ５８０においてアプリケーションをランさせるのを許すために、２つの付加的な実行可能なファイルＢ１ｅｘｅｃ５３５及びＢ２ｅｘｅｃ５４０がコンパイルされる。更に、新たな動的なライブラリ５３０が、エグズキュータブルＢ１ｅｘｅｃ５３５及びＢ２ｅｘｅｃ５４０にリンクするように生成される。というのは、実行可能なファイルＢ１ｅｘｅｃ５３５及びＢ２ｅｘｅｃ５４０は、オペレーティングシステムＢ５８５に対して構築されるからである。このような実施形態では、２つのオペレーティングシステム（各々、オペレーティングシステムＡ４８５及びオペレーティングシステムＢ５８５）で動作する４つのプラットホーム（プラットホームＡ１ ４７５、プラットホームＡ２ ４８０、プラットホームＢ１ ５７５、及びプラットホームＢ２ ５８０）にわたるライブラリの動的リンキングを実現するために、４つの動的に実行可能なファイル及び２つの動的なライブラリを構築することが要求される。従来の解決策では、異種のコンピューティング環境で動作可能なバイナリオブジェクトの開発は、リソース集中となることが明らかである。

図６は、例示的コンピューティング環境６００のコンポーネントを示す。図６に示すように、ソースコード６０７とＣＰＵ６７０との間にレイヤ６０５、６１０及び６１５のヒエラルキーが存在することができる。このようなヒエラルキーは、最上位及び最下位レイヤには高度の共通性を示すが、それらの間には多様性を示す。最も高いレベル６０５では、ソースコード６０７が、幾つかの限定されたプラットホーム特有のエレメント６２０を伴う全ての協働するプラットホームに対して主として共通である。最も低いレベル６１５では、コードがＣＰＵ６７０においてランする。ここに示す実施形態では、ＣＰＵ６７０のアーキテクチャが、複数の異種のコンピューティング環境（図示せず）の間で共通であるときには、低レベルのマシンインストラクションが同一であることが予想される。しかしながら、中間レイヤ６１０は、複数のプラットホーム変形６３０、６３５、６４５、６５０及び６６０を各々伴う複数のオペレーティングシステム６４０、６５５及び６６５を維持することができ、そしてそれらの個別の特性及びツールチェーンのために個々のバイナリを要求することができる。また、図示されたように、最上位レイヤ６０５は、プラットホーム及びオペレーティングシステムの両方について独立できるプラットホーム独立のソースコード６２５を含む。

ここに示す実施形態において、図６を参照すれば、３つのオペレーティングシステムにおいて５つのプラットホームが動作する。より詳細には、プラットホームＡ１ ６３０、プラットホームＡ２ ６３５がオペレーティングシステムＡ ６４０においてランし、プラットホームＢ１ ６４５及びＢ２ ６５０がオペレーティングシステムＢ ６５５においてランし、更に、プラットホームＣ１ ６６０がオペレーティングシステムＣ ６６５においてランする。従来の方法では、コンピュータプログラムの適切な動作を確保するために、各アプリケーションプログラムの５つの異なるバージョン（各プラットホームに対して１つ）と、３つの別々の動的なライブラリ（各ＯＳに対して１つ）とを生成することが要求される。ここに述べるシステム及び方法は、５つのプラットホーム及び２つのオペレーティングシステムにわたって機能する単一の動的なライブラリを設けることにより従来の慣例の欠点を改善することに向けられる。ここに示す実施形態では、ＣＰＵにおいてランするＯＳに関わらず、特定のＣＰＵアーキテクチャを合体した全てのシステムに使用でき、従って、図６の最上位レイヤ６０５及び最下位レイヤ６１５における共通性の利点を取り入れた単一セットのバイナリライブラリを生成することができる。

ここに述べるシステム及び方法は、種々のコンピューティング環境に適用することができる。ここに示す実施形態では、ここに述べるシステム及び方法は、ＩＮＴＥＬ（登録商標）ｘ８６ファミリーからのプロセッサを一般的に含むデスクトップシステムに適用されてもよい。デスクトップＰＣにおける共通のオペレーティングシステムは、ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）及びＬｉｎｕｘであり、これらは、両方とも、動的リンキングのファンクションを有する。しかしながら、これらのオペレーティングシステムは、それらのバイナリオブジェクトに対して不適合のフォーマットを使用し、従って、Ｌｉｎｕｘ及びＷＩＮＤＯＷＳ（登録商標）については、たとえそれらが同じＣＰＵにおいてランできるとしても、個別のライブラリが設けられる。

移動及び埋め込み型装置については、多様性の問題が著しく大きなものになり得る。より詳細には、移動及び埋め込み型装置は、Ｌｉｎｕｘ、ＷＩＮＤＯＷＳ（登録商標）ＣＥ、ＰａｌｍＯＳ（登録商標）、ＳｙｍｂｉａｎＯＳ（登録商標）、ＢＲＥＷ（登録商標）、Ｉｔｒｏｎを含む（これらに限定されないが）著しく多くのオペレーティングシステムを利用する。しかしながら、ＣＰＵレベル６１５では、ＡＲＭ ＲＩＳＣアーキテクチャのような選択されたコンピュータハードウェアアーキテクチャに基づく相当の共通性が存在し得る。現在の慣例では、このような共通性が利用されず、むしろ、ＯＳ又はプラットホームレイヤ（例えば、６１０）に基づいて仕立てられたライブラリが生成される。

ここに示す実施形態では、ここに述べるシステム及び方法は、ソフトウェアプラットホームに関わらず、選択されたハードウェアアーキテクチャ（例えば、ＡＲＭプロセッサを含む装置）において動作するコンピューティング環境でランできる単一ソフトウェアライブラリを流通させるために、選択されたコンピューティング環境市場（例えば、移動装置市場）に適用することができる。このような解決策は、ソフトウェア開発者及び顧客の両方に、特定プラットホーム向けライブラリの複数のバージョンを開発して維持するコストの節減を含む（これに限定されないが）種々の商業的利益を提供することができる。更に、複数の設置にわたって同じコンポーネントを伴う経験の累積によりコードのクオリティを迅速に確立することができる。更に、このような解決策では、ライブラリに対する変更をより完全に且つ効率的にテストすることができる。装置メーカー（例えば、セルラー電話製造者）は、このようなライブラリが単一製品範囲において証明された場合には、それらの種々の製品範囲にわたって共通のライブラリを使用することができる。

図７は、例示的プラットホーム独立バイナリオブジェクト及びリンキングアーキテクチャ７００を示す。図示されたように、プラットホーム独立バイナリオブジェクト及びリンキングアーキテクチャ７００は、メインアプリケーションソースコード７０５を含むソースコードと、プラットホーム独立のソースコードコンポーネントとを備え、これらのコンポーネントは、プラットホーム独立の動的ライブラリ（ＰＩＤＬ）ソース７２５、コンパイラ７３０、ＰＩＤＬオブジェクトファイル７３５、オブジェクトパーザ７４０、ＰＩＤＬスタブファイルのソースコード７６５、ＰＩＤＬ動的ローダー／リンカーのソースコード７２０、定義されたアプリケーションプログラムインターフェイス（ＡＰＩ）７１０、及びＡＰＩパーザ７１５を含むが、これらに限定されない。

ここに示す動作においては、ＰＩＤＬソース７２５が、ブロック７３０において、標準オブジェクトフォーマットへとコンパイルされ、ＰＩＤＬオブジェクトファイル７３５を生成する。ＰＩＤＬオブジェクトファイルは、次いで、オブジェクトパーザ７４０によりパーズされ、ＰＩＤＬスタブファイル７６５に対するソースコードを生成することができる。同様に、アプリケーションプログラムインターフェイス（ＡＰＩ）パーザ７１５は、ＡＰＩ７１０において動作して、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌファンクションを生成し、ＰＩＤＬオブジェクトファイル７３５による協働するメインアプリケーション７０５へのアクセスを可能とする。図７に示すように、メインアプリケーションソース７０５、動的ローダー／リンカーのソースコード７２０、ＰＩＤＬスタブファイルのソースコード７６５、及びもし実行されれば、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌソースファンクション７５５（例えば、コンパイルコンポーネントのソースコードのセット７４５）は、ステップ７７０において、ターゲットプラットホームに対してコンパイルされ構築される。それにより生じる動的なバイナリ実行可能ファイル７９５は、メインアプリケーションファンクション７７５、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌファンクション７８０、及び動的なＰＩＤＬローダー／リンカーファンクション７８５を利用して、ファンクションをコールすると共に、ＰＩＤＬオブジェクトファイル７３５からデータを検索する。

例示的なプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャ７００は、種々のコンポーネントを特定のコンフィギュレーションで有するように示され、特定のオペレーションを遂行するように説明されるが、ここに述べる本発明の概念は、種々のコンポーネント、コンフィギュレーション及びオペレーションを有するいかなるプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャにも適用できるので、このような説明は、単なる例示に過ぎないことが明らかである。

ここに示す実施形態では、例示的なプラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャ７００は、次の方法に基づいて動作することができる。ＰＩＤＬオブジェクトファイル７３５は、その構造が充分に定義された標準的なオブジェクトファイルフォーマットで生成することができる。オブジェクトパーザ７４０は、標準的なＰＩＤＬオブジェクト構造体をパーズして、スタブファイル７６５を生成するように動作することができる。スタブファイル７６５は、ソースコードとして生成される。更に、スタブファイル７６５のソースコードは、プラットホーム依存性をもたない。動的ローダー／リンカー７２０は、これをメインアプリケーションプログラム７０５の一部分として含むことができるように書き込むことができる。更に、ＰＩＤＬライブラリがメインアプリケーションをコールできるようにするインターフェイスであるＡＰＩ７１０は、これを指定して、ソースコードファンクション（ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ）７５５へ変換し、メインアプリケーション７０５でコンパイルすることができる。ここに示す実施形態では、ターゲットプラットホームが既知である場合に、結合したソースコード（例えば、コンパイルコンポーネントソースコード７４５のセット）を、所与のプラットホーム（図示せず）に対するバイナリ実行可能７９５へとコンパイルすることができる。ランタイムに、動的ローダー／リンカー７８５（例えば、コンパイルされたローダー／リンカー）は、シンボル分析及びリロケーションを取り扱い、動的なバイナリ実行可能７９５及びＰＩＤＬファイル７３５を完全にラン可能なプロセスとして結合することができる。

上述したように、動的ライブラリのプラットホーム独立性は、最初に、ライブラリソース７２５のコードを既知のオブジェクトファイルフォーマット７３５へコンパイルすることにより達成できる。意図される実施形態においては、ＰＩＤＬソース７２５は、特定のプラットホームに対する依存性を含まない。オブジェクトファイルフォーマット（図示せず）は、通常、コードのサイズのようなヘッダ情報、コンパイラ又はアッセンブラにより生成されるオブジェクトコード、オブジェクトコードのアドレスがリンカーによりジャッグルされたときにリンカー７８５により使用するためのリロケーション情報、及びこのモジュールからエクスポートされるか又は他のモジュールからインポートされるシンボルのシンボルテーブルを含む（これらに限定されないが）複数の形式の情報を収容することができる。

ここに例示する実施形態では、プラットホーム独立のバイナリオブジェクト及びリンキングアーキテクチャ７００は、ＥＬＦ（実行可能・リンキングフォーマット）、ＭＩＣＲＯＳＯＦＴ（登録商標）ポータブル実行可能(Portable Executable)（ＰＥ）フォーマット、及び他のオブジェクトフォーマット（例えば、ここに述べるシステム及び方法のために特に設計されたオブジェクトフォーマット）を含む（これらに限定されないが）種々のオブジェクトファイルフォーマットを利用することができる。

従来、異なるオペレーティングシステム及びプラットホームは、異なるオブジェクトファイルフォーマットを使用している。これらプラットホームのためのリンカー及びローダーは、これらの予め定義されたフォーマットでリンク可能なオブジェクトを受け取ることを期待し、他のフォーマットは拒絶する。また、プラットホームが動的リンキングを与えるときには、動的リンカーがオペレーティングシステムの部分であり、独特のオブジェクトフォーマットに「ハードワイヤド」することができる。

ここに述べるシステム及び方法は、一般的なローダー／リンカー７２０を設けることによりこの欠点を改善する。ここに例示する実施形態では、この一般的ローダー／リンカー７２０は、選択されたオブジェクトファイルフォーマット（例えば、ＥＬＦ、又は選択された他の何らかのオブジェクトフォーマット）でオブジェクトファイルを処理するように書き込むことができる。動作中に、一般的なローダー／リンカー７８５は、ＰＩＤＬオブジェクトファイル７３５内のシンボル、リロケーション情報及び他の情報を探索するように動作する。図７に示すように、ローダー／リンカー７２０の展開は、協働するメインアプリケーション７０５のソースコードと共にコンパイルされるソースコードの生成によって達成される。この点について、リンキング及びローディング制御は、オペレーティングシステムから除去されて、ランしている実行可能ファイル（エグズキュータブル）に含まれる。また、動的なローダー／リンカー７８５は、非ＰＩＤＬライブラリを処理するように動作することもできる。この点について、動的なローダー／リンカー７８５は、動的なライブラリがＰＩＤＬ形式であるか、非ＰＩＤＬ形式であるか確かめ、それに応じてＰＩＤＬ又は非ＰＩＤＬライブラリを処理するように設計することができる。ここに例示する実施形態では、非ＰＩＤＬライブラリが処理されるときに、リンキング及びローディングの制御は、基礎となるオペレーティングシステムへ戻すことができる。

ここに例示する実施形態では、ＰＩＤＬオブジェクトファイルは、再構築又は再コンパイルの必要なく、異種のプラットホームにわたって使用することができる。この実施形態では、メインアプリケーションプログラムが、選択されたプラットホームの動的なリンカー／ローダーコードで一緒にコンパイルされると共に、リンキングの制御がプラットホームに依存せず、むしろ、実行可能ファイル（エグズキュータブル）内に配されるので、ランタイムにおけるＰＩＤＬのリンキングは、ＰＩＤＬオブジェクトを再コンパイル又は再生成する必要なく、異種のプラットホームにおいて達成することができる。

図７に示すように、スタブファイル７６５は、ソースコードとして生成される。従来の慣例に比較して、図３を参照すれば、従来の解決策は、エクスポート及びインポートされる両グローバルシンボルを定義するオブジェクトファイル３２５としてライブラリスタブを生成することである。動作中に、スタブファイルは、一般的に小さく、結合／アッセンブルされたプログラムにおいてリンカーがシンボルを分析するのを許す。動作中に、メインプログラムは、動的ライブラリに存在する名前付きファンクションをコールすることができ、また、動的ライブラリも、メインプログラム内のファンクションをコールすることができる。適切に機能するための組み合せについては、ローダーが全てのオブジェクトコードコンポーネントをコンピューティング環境のメモリに配したときに、ファンクションコールを分析して適切なアドレスでリロケーションすることができる。

図８に示すように、ファンクション又はシンボルＡ及びＢに対するコードは、メインプログラム８１０に配置することができ、また、ファンクションＣ、Ｄは、動的ライブラリ８２０に配置することができる。ここに例示する実施形態では、動的ライブラリ８２０がＡ及びＢをコールし、或いはメインプログラム８１０がライブラリファンクションＣ又はＤを使用するために、シンボルと、全ファンクションの位置が、結合されたプログラムにおいて分析される。ここに例示する実施形態では、この動作は、例示的リンカー（図示せず）により遂行することができる。従来の慣例では、スタブライブラリ（例えば、図３の３２５）は、ライブラリからエクスポートされるファンクション（例えば、Ｃ及びＤ）とそれによりコールされるファンクション（例えば、Ａ、Ｂ）とを結合するのに必要な情報を保持することができる。図３を参照すれば、従来の慣例では、アーキテクチャ３００が、ライブラリスタブ３２５を、静的リンキング段階においてメインプログラムの予めコンパイルされたオブジェクトファイルにリンクして、バイナリ実行可能ファイル３４０を生成する。その後、バイナリ実行可能ファイルが実行のためにロードされるときに、動的リンカー３３０の制御のもとで動的ライブラリ３１５と動的にリンクすることができる。従来の解決策では、動的リンカーは、一般に、オペレーティングシステムの部分である。このような状況では、異なるシステムがそれら自身のリンカー及びオブジェクトフォーマットを使用するので、プラットホーム依存のライブラリスタブファイルが得られることになる。従って、単一ライブラリは、異なるオペレーティングシステムに対して異なるスタブファイルを必要とする。

ここに述べるシステム及び方法は、スタブファイルをソースコードファイルとして設けることにより既存の慣習の欠点を改善することに向けられる。図７を参照すれば、スタブライブラリ７６５は、オブジェクトパーザ７４０を使用して生成される。オブジェクトパーザ７４０は、ＰＩＤＬオブジェクトファイル７３５を通してパーズして、シンボル名及びプロパティを抽出すると共に、ソースファイル７６５（例えば、“Ｃ”言語又はそれと同等のものを含む（これに限定されないが）高水準言語において）をパーザの出力として生成する。ここに例示する実施形態では、図７に示すように、ＰＩＤＬスタブファイル７６５に対して生成されるソースコードは、プラットホーム独立であると共に、その後、メインアプリケーションプログラムの部分としてコンパイルされる（動的リンカーコードと共に）。ＰＩＤＬスタブ情報をコンパイル段階で含むことにより、ＰＩＤＬからエクスポートされるシンボルは、それにより得られる動的実行可能ファイル（エグズキュータブル）において宣言することができる。

明らかなように、従来の解決策と同様に、スタブファイルをオブジェクトコードではなくソースコードとして生成することは、スタブに含まれたライブラリ情報を、構築プロセスのコンパイル段階に含ませねばならないことを示す。対照的に、従来の解決策は、メインアプリケーションが既にコンパイルされた後に、スタブを静的リンキング段階に合体させる。静的リンカーは、オペレーティングシステムの制御のもとにあり、これは、リンクされたオブジェクトが、オペレーティングシステム特有のオブジェクトフォーマットであることを要求し、このフォーマットは、一般に、異なるオペレーティングシステムのリンカーにより認識されない。プラットホーム独立の解決策を得るためには、リンキング段階に頼ることをなくす必要がある。ここに述べるシステム及び方法では、このような目標は、スタブファイルを、リンクすべきオブジェクトコードではなく、コンパイルすべきソースコードとして設けることにより、達成することができる。

明らかなように、ここに述べるシステム及び方法では、メインアプリケーションが動的リンカー及び適切なＰＩＤＬスタブファイルと共にコンパイルされるとすれば、メインアプリケーションが、ＰＩＤＬオブジェクトとして展開された動的ライブラリにアクセスすることが許される。また、ここに述べるシステム及び方法は、ＰＩＤＬがメインアプリケーションのファンクションへのアクセスを要求するときのインスタンスも考慮している（図８に示すように）。このような状況では、メインアプリケーションによりＰＩＤＬライブラリに露出されるファンクションのＡＰＩ（図７の７１０）（アプリケーションプログラミングインターフェイス）は、これを最初に指定してパブリッシュすることができる（ＰＩＤＬがその露出されたファンクションを使用できるように）。次いで、ＡＰＩ（図７の７１０）をパーズして、ソースコードファンクションＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ（図７の７５５）を生成することができ、これは、メインアプリケーションの部分としてコンパイルすることができる（図７に示すように）。ここに例示する実施形態では、ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌファンクションは、ＡＰＩにより露出された名前付きシンボルのアドレスを返送できると共に、ＰＩＤＬによりコールされたシンボルのアドレスに置き換わるようにリロケーション中に動的リンカーにより使用することができる。従って、ＰＩＤＬがメインアプリケーション内のファンクションをコールするときには、リンケージ及びアドレスが動的リンカー（図７の７８５）により既に分析されている。

更に、動的リンカーは、ＰＩＤＬオブジェクトのランタイムリンキングを可能とする。メインアプリケーションソースファイルは、図７に示すように、ターゲットプラットホームに対してコンパイルして、動的リンカー及びＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌファンクション並びにメインプログラムを含むバイナリ実行可能ファイルを生成することができる。ＰＩＤＬライブラリを生成することができ、これは、オブジェクトファイルとして利用できる。

ここに例示する実施形態の例示的動作においては、メインプログラムがランをスタートするときに、それをプラットホームローダーによりメモリに配置することができる。実行が始まるときに、メインプログラムは、それ自身に対して外部のシンボルへのコールを行うかどうか決定する。このようなコールは、ＰＩＤＬリンカーを呼び出し、これは、最初に、被呼ファンクションを含むライブラリの名前及びパスを決定する。ライブラリが、ＷＩＮＤＯＷＳ（登録商標）ＤＬＬのような普通の特定プラットホーム向け動的ライブラリである（ＰＩＤＬではない）場合には、リンカーは、普通のプラットホームライブラリローダーが存在するときにこれに制御を引き渡す。しかしながら、そうではなくて、被呼ファンクションがＰＩＤＬ内にある場合には、それが露出するシンボルを含むと共にメインプログラムへとコンパイルされていて、従って、シンボル参照が定義されているＰＩＤＬスタブファイルを使用して、シンボル名によりそれを識別することができる。

リンカーは、ファンクションコールに応答して、ＰＩＤＬオブジェクトを表すプログラムされたストラクチャを生成することができる。これは、次いで、オブジェクトにアクセスしてコードサイズ（例えば、オブジェクトファイルフォーマット内のフィールドに定義され、従って、容易に利用できる）を見出すことができ、適切なサイズのメモリの固定ブロックを割り当てることができ、そしてＰＩＤＬファイルをその割り当てられたメモリにロードすることができる。

次いで、リンカーは、メモリにおいてシンボルアドレスをリロケーションするように動作する。ＰＩＤＬ内の内部シンボルがリロケーションされる。動作中に、バイナリファイルは、オブジェクトコード内のシンボルのアドレスを含むが、一般的に、ライブラリコードに対してゼロのベーススタートアドレスがあるという仮定のもとで動作する。しかしながら、ＰＩＤＬは、ＰＩＤＬがメモリにロードされるので確認できる異なるアドレスに配置される。リンカーによるリロケーションは、メモリブロックの実際のスタートアドレスを考慮するためのシンボルアドレスの調整を含むことができる。

内部ＰＩＤＬシンボルをリロケーションした後に、リンカーは、ＰＩＤＬの外部にあってＰＩＤＬによりコールされる全てのシンボル、例えば、メインアプリケーションに含まれたファンクションをリロケーションすることができる。これらのシンボルに対して、リンカーは、引数としてリロケーションされるべき外部シンボルの名前でＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌファンクションをコールすることができる。このファンクションは、アプリケーションＡＰＩにより露出される全てのシンボルのリストを含むので、名前に一致させて、その名前付きシンボルの実際のアドレスを返送することができる。

この段階において、ＰＩＤＬは、それがエクスポート又はインポートする内部及び外部シンボルの正しいアドレスを維持する。リロケーションが完了した後に、ＰＩＤＬによりエクスポートされたシンボルのリロケーションされたアドレスをリンカーへ返送することができる。メインプログラムは、リロケーションされたシンボルにアクセスすることができ、ＰＩＤＬの外側からＰＩＤＬシンボルの１つへコールがなされるときに、正しいシンボルアドレスが使用される。

ここに述べるシステム及び方法は、単一アプリケーションにリンクされた複数のライブラリ（例えば、ＰＩＤＬ）と共に使用することができる。これらのライブラリは、それらがエクスポートするファンクション及びシンボルを使用して、互いにコールを行うことができる。複数のライブラリが使用される状態では、リンキングメカニズムを均質に適用することができ、即ち動的ライブラリは、標準的なオブジェクトフォーマットでセーブされ、スタブは、ソースフォーマットで生成され、そしてメインプログラムは、それが使用するＰＩＤＬライブラリに対してスタブでコンパイルされる。動的ローダー／リンカーは、ロードタイム又はランタイムにそれがコールされたときに各ライブラリをロードし、更に、リロケーションを遂行し且つＰＩＤＬライブラリ間でメインプログラムと共にシンボルを分析するための情報は、プログラムにコンパイルされた動的ローダー／リンカー（例えば、図７の７８５）により取り扱われる。

４．プラットホーム独立の動的ライブラリ
図９は、一又は複数のＰＩＤＬのランタイムリンキングを実行するときに例示的コンピューティング環境により遂行される処理を示す。図示されたように、処理は、動的ライブラリ実行可能ファイルがコンパイルされ構築されるブロック９００で始まる（図７において述べたように、例示的な動的バイナリ実行可能は、コンパイルされたメインアプリケーションソースコード、ＰＩＤＬローダー／リンカーのソースコード、及びＰＩＤＬスタブソースコードを含むことができるが、これに限定されない）。ここから、処理は、ブロック９１０へ進み、例示的コンピューティング環境において動的実行可能ファイル（エグズキュータブル）がランされる。次いで、処理は、ブロック９１５へ進み、協働するコンピュータプログラムがライブラリファンクションにコールを発することが決定される。次いで、ブロック９２０において、被呼ファンクションが協働するＰＩＤＬにあるかどうか決定するためのチェックが遂行される。ブロック９２０のチェックが、被呼ファンクションが協働するＰＩＤＬにないことを指示すると、処理は、ブロック９２５へ進み、協働する動的ライブラリが通常のオペレーティングシステム／プラットホームリンカーを通してロードされる。これで処理は終了となる。

しかしながら、ブロック９２０において、被呼ファンクションが協働するＰＩＤＬにあると決定された場合には、処理がブロック９３０へ進み、ここで、ＰＩＤＬオブジェクトについてプログラムされたストラクチャが生成され、所定のファイルフォーマットをもつＰＩＤＬオブジェクトファイルの情報を取得できるようにする。

次いで、ＰＩＤＬオブジェクトのサイズがブロック９３５において決定される。そこから、処理は、ブロック９４０へ進み、メモリブロックが割り当てられると共に、ＰＩＤＬオブジェクトファイルをその割り当てられたブロックへロードすることができる。次いで、ＰＩＤＬの内部シンボルが、ブロック９４５において、オブジェクトファイルから抽出されたシンボルテーブル及びロードアドレスを使用してリロケーションされる。次いで、外部のＰＩＤＬシンボルが、ブロック９５０において、ＡＰＩ（ＰＩＤＬ＿ｇｅｔＳｙｍｂｏｌ）ファンクションコールを使用してリロケーションされる。そこから、協働するコンピュータプログラムは、ブック９５５において、ＰＩＤＬリンカーによりＰＩＤＬシンボルアドレスが通知される。そこから、ブロック９６０において、シンボル及びコールが分析されリロケーションされるときに、リンキングが完了したことになる。これで処理が終了する。

５．制約のある環境における動的リンキングのためのメカニズム
あるオペレーティングシステムは、動的なリンキング能力を備えていない。これらのシステムにライブラリが使用されるときには、ライブラリが静的にリンクされる。即ち、ライブラリがリンク時に実行可能バイナリに結合される。実行可能ファイルは、付加的なリンキングを行なわずに実行の準備ができるので、静的でもあり、更に、リンキングが完了した後に変更しなくてもよい。一般的に、静的にリンクされたライブラリは、それが結合された基礎となるプログラムに影響（例えば、切断又は停止）を与えずに変更することができない。また、ライブラリにおけるルーチン及びデータのアドレスはプログラムに結合されるので、これらのアドレスを変更すると、それに結合されたプログラムに機能不良を生じさせる。

ここに述べるシステム及び方法は、動的な実行をネイティブにサポートしないオペレーティングシステムにおいて動的な実行を与えることにより既存の慣例の欠点を改善する。ここに例示する実施形態では、動的リンキングには、ランタイム又はロードタイムまでリンキングを遅延させる特性、または、静的にリンクされないライブラリを実行可能プログラムが使用する特性があると考えることができる。更に、ここに述べるシステム及び方法は、所与のオペレーティングシステムによりネイティブにサポートされないバイナリオブジェクトフォーマットのリンキングを可能とする。

ここに例示する実施形態では、より大きなプログラムを、メインアプリケーションと、サポートファンクションを与えるセットコンポーネントライブラリとに仕切ることができる。従来の慣例では、プログラム全体が単一の静的な実行可能ファイルとして設けられる。従って、プログラムに対する変更が必要になった場合には、完全に新しい実行可能ファイルを構築して、非変更バージョンに置き換わるように配布される。これとは対照的に、ここに例示する実施形態では、コンポーネントを、それらを使用するアプリケーションとは独立して、一度だけ供給することができる。従って、アプリケーションは、より小さなサイズとすることができ、新たなアプリケーション又は変更されたアプリケーションが要求される場合には、それに関連したライブラリの再構築を必要とせずに、アプリケーションそれ自体だけの再構築が要求される。

反対に、ここに示す実施形態では、アプリケーションが不変のままであるが、コンポーネントの１つが変更される場合には、他のコンポーネントへ変更を施すことなく、新たなコンポーネントを以前のバージョンに代わって置き換えることができる。改訂バージョンのシンボル名が同じであるとすれば、新たなコンポーネントバージョンは、ランタイムに、オリジナルのアプリケーションプログラム及び他のコンポーネントにリンクすることができる。ここに例示する実施形態では、動的リンカーがアドレスリロケーションを処理する。シンボルが新たなコンポーネントバージョンにおいて異なるアドレスにある場合には、アドレスを、ランタイムに、依然、分析してリロケーションすることができる。

図１０は、動的な実行をサポートしていないコンピューティング環境にＰＩＤＬを展開するときに遂行される処理を示す。図１０に示すように、処理はブロック１０００で始まり、ここで、プログラムは、メインアプリケーションと、動的なライブラリとしてランタイム展開されるよう意図された一又は複数のライブラリとに仕切られる。ライブラリは、次いで、ブロック１０２０において、既知の標準的ファイルフォーマットを有するＰＩＤＬオブジェクトファイルへとコンパイルすることができる。プラットホーム独立のソースコードを含むスタブファイルは、ブロック１０３０において、上述したようにＰＩＤＬオブジェクトファイルをパーズすることにより生成することができる。スタブファイルは、ブロック１０１０において、メインアプリケーションのためのソースコード及び動的リンカーローダーのためのソースコードと一緒にコンパイルされる。リンカー／ローダーコンポーネントは、既知の標準的ファイルフォーマットのＰＩＤＬオブジェクトファイルを解釈するための上述した機能を有し、それらをメモリにロードすることができ、更に、必要なリンキング動作を行って、シンボルを分析すると共に、ライブラリとその協働するアプリケーションとの間にリロケーションすることができる。

上述したブロック１０００−１０３０で遂行される全てのファンクション及び／又はオペレーションは、プログラムを展開及び実行する前の構築タイムに遂行することができる。動的なリンキングをネイティブにサポートしない制約のある環境では、構築された実行可能ファイルと外部ライブラリとの間のその後の協働又は相互作用を一般的に達成できない。ここに例示する実施形態では、対照的に、ランタイムに動的なオペレーションを可能とするために、付加的なブロック１０４０から１０８０が設けられる。構築された実行可能ファイルは、ブロック１０４０において、実行を開始するように命令されると共に、ブロック１０５０において、通常、ネイティブなオペレーティングシステムの制御のもとでメモリにロードされる。ブロック１０１０の結果として実行可能ファイル内に含まれた動的リンカー／ローダーは、ＰＩＤＬライブラリをロードしてラン中のアプリケーションに結合するように動作することができる。（図９のブロック９１５から９６０を参照されたい。）それにより得られるプログラムは、分析された全てのライブラリコールと完全に結合されるが、次いで、ブロック１０８０においてランすることができる。

制約のある環境における動的リンキングの動作は、ライブラリがプラットホーム独立であるように動作することが示されたが、ここに述べる本発明の概念は、プラットホーム依存性を有するライブラリにも適用できるので、このような説明は、単なる例示に過ぎないことが明らかである。

６．コードコンポーネントメカニズム
移動コンピュータに使用されるあるオペレーティングシステム（ＯＳ）（例えば、ＰａｌｍＯＳ、ＳｙｍｂｉａｎＯＳ）は、グローバル変数及び静的な書き込み可能な変数の使用について制約を強いる。このような制約は、オペレーティングシステムがコードのリロケーション及びグローバル変数のアドレスマネージメントを完全に取り扱うのを回避できるようにするために存在し得る。静的変数は、グローバル変数と同じメモリセグメントに保持されるので、書き込み可能な静的変数も、オペレーティングシステムにより禁止されることがある。コンピュータプログラムコードが、このようなオペレーティングシステムを念頭において書き込まれるときには、当然、それらの制約に従い、適合するコードを生成することができる。しかしながら、ライブラリのようなコードの一部が、このような制約を伴わない異なるプラットホームのために記述されたときには、コードは、制約のあるオペレーティングシステムにおいてコンパイル又は構築する程度までルール違反となり得る。これは、第三者のライブラリ及び予め記述されたコードを、ある種のオペレーティングシステムで使用する能力に対して制限を招き、それらの融通性を低減させる。これは、生産的開発を低下させる。というのは、オペレーティングシステムの制約に従うように既存のコードを変更し、また、ある場合には、スクラッチからそれを完全に再記述するのに、時間を費やさねばならないからである。

ここに述べるシステム及び方法は、オペレーティングシステムの制約を回避できるようにする。ここに例示する実施形態では、ソースコードがオペレーティングシステムの制約に違反するライブラリを、ＰＩＤＬフォーマットへとコンパイルし構築することができる。ＰＩＤＬライブラリは、次いで、アプリケーションプログラムと結合し、制約のあるオペレーティングシステムにおいてランされる。ここに述べるシステム及び方法の独特の動的ローディング及びリンキングメカニズムは、ＰＩＤＬのためにメモリブロックを割り当てる。更に、この実施形態では、グローバル変数が、ＰＩＤＬのメモリ領域を越えるグローバルとしては処理されない。

このように、この実施形態では、ライブラリ内に定義されるグローバル変数は、このメモリブロック内に拘束され、オペレーティングシステムにはグローバル変数として見えない。また、静的変数も、割り当てられたメモリブロックに拘束することができ、オペレーティングシステムの介入に依存しない。その結果、このようなグローバル及び静的変数のリロケーションをオペレーティングシステムでなし得ないことが回避される。この実施形態では、ＰＩＤＬローダー／リンカーは、ライブラリ変数のリロケーションを遂行して、それらを機能させることができる。

図１１は、ＰＩＤＬがコンピューティング環境の一又は複数の制約を回避できるようにＰＩＤＬを取り扱うために、制約のあるコンピューティング環境により遂行される処理を示す。図１１に示すように、処理はブロック１１００で始まり、ここでは、オペレーティングシステムにより課せられた一又は複数の制約にコードが違反するライブラリから、ＰＩＤＬを生成することができる。ソースコードを含むスタブファイルを、ブロック１１１０において、上述したように生成することができ、また、ブロック１１２０において、そのスタブファイルを、動的リンカーローダー、及びライブラリと協働するコンピューティングアプリケーションと一緒にコンパイルし構築することができる。

ここに例示する実施形態では、ランタイムに、アプリケーションプログラムを実行するインストラクションをブロック１１３０において受け取ることができる。実行可能ファイルは、通常そうであるように、ブロック１１４０において、ホストコンピューティング環境によりロードすることができる。ＰＩＤＬは、ブロック１１６０において、コンピューティング環境により使用するために設けることができる。アプリケーションプログラムとライブラリとの間の依存性を識別するときに、動的リンカー／ローダー（ブロック１１２０においてプログラムに組み込まれた）は、ブロック１１５０において、メモリブロックを割り当て、その割り当てたブロックにＰＩＤＬをロードすることができる。ブロック１１７０に示すように、ライブラリに定義されたグローバル及び書き込み可能な静的変数は、それらの範囲がその割り当てられたメモリブロックに制限されており、このメモリブロックを越えたところから名前ではアクセスすることができない。それらは、全てのライブラリファンクションに使用可能である。というのは、これらも、割り当てられたメモリブロック内に存在するようにできるからであり、従って、ライブラリは、コンピューティング環境の従来の動作のもとで課せられた制約に違反したとしても、その環境内で正しく動作することができる。次いで、ＰＩＤＬのリンキングがブロック１１８０で完了され、完全に結合されたラン可能なプロセスが形成される。

コードコンポーネントの特徴は、ライブラリがプラットホーム独立であるように動作するものとして示されたが、ここに述べる本発明の概念は、プラットホーム依存性を有するライブラリにも適用できるので、そのような説明は、単なる例示に過ぎないことが明らかである。

７．コードローディングメカニズム
従来のソフトウェア開発では、オブジェクト指向の解決策をとることができる。特定のタスクを遂行するためのファンクションをコールするのではなく、オブジェクトを生成できると共に、オブジェクトのメソッドをコールして、希望のタスクを遂行することができる。このようなアプローチは、複数のオブジェクトを生成できると共に、複数のタスクを同時にアクティブにできるので、有益である。計算タスクの複数のインスタンスを実行することが有益な状況が複数ある。例えば、映画クリップをドキュメント内で再生しレンダリングするためのライブラリが存在するケースである。このようなドキュメントが２つのこのような映画クリップを含むときには、共通のコードオブジェクトの２つのインスタンスをランさせることによりそれらクリップを同時に再生することが便利である。オブジェクト指向のアプローチがない場合には、開発者は、オブジェクトがタスクを首尾良く遂行する状態に遭遇することがあるが、複数の同じオブジェクトを同時に実行させる際に困難に陥る。

開発者は、オブジェクト指向のスタイルで書き込むことを選択できるが、このような選択は、第三者のコードを一体化するときに無効になり得る。特に、これは、データを操作し、このデータへのアクセスファンクションを含むライブラリとして展開されるコードの場合があてはまる。ここに例示する実施例では、非オブジェクト指向のコードは、グローバル変数を使用し、また、静的変数の１回の初期化を使用できる。このような状況では、あるコンピューティング環境において、そのコンピューティング環境が同じプロセス内でライブラリオブジェクトの２回以上の呼び出しを実行することが阻止される。というのは、一つのプロセスが、モジュール又はライブラリにより使用される１セットのデータしか保持しないからである。より詳細には、同じオブジェクトの２回の呼び出しは、指定されたグローバル変数を共用することによって、互いに悪影響を与えることがある。或いは、ライブラリは、１回しか実行できないように書き込まれてもよいが、その実行が完了したときにも、２回目を実行する試みは失敗となる。というのは、静的に初期化された変数が必要な初期値をもはやもたないからである。これは、静的な変数は、ランタイムではなく、構築タイムに、コンパイラにより初期化されるためである。従って、初期化された変数が実行中に変更された場合には、その後の実行がその変更された値を含み、適切な動作に必要な初期化値とは異なる値でスタートする。

ここに述べるシステム及び方法は、上述したＰＩＤＬローディングメカニズムを設けることによりこれらの欠点の改善を図る。制限されたメモリブロック内でＰＩＤＬの複数のインスタンスがそれら自身の「プライベート」なデータコピーを使用できるようにし、これにより、従来のアプローチにおいて機能不良を生じさせる相互作用及び衝突を回避することにより、プロセス内にデータの一つのセットを使用する制約が排除される。この方法により、同じプロセス内でも複数のインスタンス及び繰り返しが実行可能となる。また、複数のプロセスを許さない環境でも複数の同時実行の可能性を広げる。ここに例示する実施形態では、ＰＩＤＬは、グローバル変数を、動的に割り当てられたバッファ内のアドレスとして処理する。単一のＰＩＤＬを何回もロードすることができ、次いで、各コピーは、グローバル変数のそれ自身の個々の独立したコピーを有し、これにより、問題となる相互作用を回避する。同様に、ライブラリを実行するたびに、ファイルからコピーがロードされ、従って、それは静的変数の正しく初期化された値を含む。

図１２は、ここに例示する実施形態において、ＰＩＤＬを取り扱うときに、例示的コンピューティング環境により遂行される処理であって、ＰＩＤＬを使用して、制約のあるコードコンポーネントの問題となる相互作用を回避できるようにする処理を示している。この処理は、ブロック１２００で始まり、ここでは、繰り返し実行を禁止する一又は複数の制約にコードが違反するライブラリからＰＩＤＬを生成することができる。ソースコードを含むスタブファイルは、ブロック１２１０において、上述したように生成することができ、次いで、ブロック１２２０において、ライブラリと協働するコンピューティングアプリケーション及び動的リンカーローダーと一緒に、スタブファイルをコンパイルし構築することができる。

ここに例示する実施形態では、ランタイムに、アプリケーションプログラムを実行するインストラクションを、ブロック１２３０において、受け取ることができる。実行可能ファイルは、ブロック１２４０において、ホストコンピューティング環境によりロードすることができる。ＰＩＤＬは、ブロック１２６０において、コンピューティング環境により使用するように設けることができる。アプリケーションプログラムとライブラリとの間の依存性を識別する際に、動的リンカー／ローダー（ブロック１２２０においてプログラムへと構築された）は、ブロック１２５０においてメモリブロックを割り当てることができ、その割り当てられたブロックへＰＩＤＬをロードすることができ、更に、ＰＩＤＬを協働するアプリケーションとリンクすることができる。次いで、ブロック１２７０において、ＰＩＤＬの新たなインスタンスをコンピューティング環境へロードすべきかどうか決定するためのチェックを遂行する。ブロック１２７０におけるチェックが、ＰＩＤＬの新たなインスタンスをロードすべきであると指示する場合には、処理がブロック１２８０へ進み、ここで、ＰＩＤＬの新たなインスタンスを個別のメモリブロックにロードできると共に、コンピュータプログラムにリンクすることができる。しかしながら、ブロック１２７０において、ＰＩＤＬの新たなインスタンスをロードすべきでないと決定された場合には、処理がブロック１２７０の入力へ復帰し、そこから進められる。

コードローディングの特徴は、ライブラリがプラットホーム独立であるように動作するものとして示されたが、ここに述べる本発明の概念は、プラットホーム依存性を有するライブラリにも適用できるので、この説明は単なる例示に過ぎないことが明らかである。

８．閉じた又は制約のあるプラットホームのための拡張可能なランタイム環境
あるコンピューティング装置は、装置が装置製造者又は供給者から運搬されるときに常駐するプログラム及びアプリケーションしか実行できないように、閉じたコンピューティング環境として動作する。このような装置（例えば、移動ワイヤレス装置）は、常駐プログラムをホストするオペレーティングシステムを含むことがあるが、他のアプリケーションがそのホストオペレーティングシステムに対して生成されたときであっても、制約なしにそのアプリケーションを追加することができない。このような閉じたプラットホームは、例えば、音声に加えて、固定セットの特徴（例えば、カメラファクション）が設けられたフューチャーホン(Feature Phone)として知られた移動ハンドセットの大きなカテゴリーである。しかし、これらの特徴は、固定され、ユーザにより拡張することができない。装置は、コンピュータプラットホームが機能を追加できないか又は制約があるために、アフターマーケット(after-market)アプリケーションに対して閉じている。

対照的に、開いたコンピューティングプラットホームは、そのオペレーティングシステム向けに記述されたアプリケーションを、日常的な使用において追加して実行することができる。ＭＩＣＲＯＳＯＦＴ（登録商標）ＷＩＮＤＯＷＳ（登録商標）プラットホームは、パーソナルコンピュータに対する開いたプラットホームの例として考えることができる。移動ハンドセットの領域では、開いたプラットホームの同等カテゴリーがスマートホンとして知られており、これは、制約を伴わずに、装置において実行するためのアプリケーションを追加できる環境を与える。スマートホンプラットホームは、例えば、ＭＩＣＲＯＳＯＦＴ（登録商標）ＳｍａｒｔＰｈｏｎｅ、Ｓｙｍｂｉａｎ ＵＩＱ、及びＬｉｎｕｘを含む。

移動ハンドセットの第３カテゴリーとして、ランタイム環境（ＲＴＥ）が装備されたフューチャーホンが存在する。このようなランタイム環境は、例えば、Ｊａｖａ Ｊ２ＭＥ（Ｊａｖａ２マイクロエディション）、及びＢＲＥＷ（バイナリ・ランタイム・エンビロンメント・フォー・ワイヤレス）環境を含む。ＲＴＥは、ＲＴＥのために生成されたアプリケーションの形式、即ちＪ２ＭＥの場合にはＪａｖａアプレット、及びＢｒｅｗ環境の場合にはＢｒｅｗ認証アプリケーション、の形態の新たなファンクションをハンドセットが追加することを可能とする。これらのアプリケーションは、開いたプラットホームでランするものとは異なる。というのは、これらアプリケーションは、ＲＴＥに対して構築され（例えば、あるインスタンスでは、ＲＴＥにより適切な動作について認証されねばならない）、スマートホンのようなネイティブなＯＳに対して構築されない。従って、ＲＴＥイネーブル型フューチャーホンは、スマートホンに比して制限を有し、そのあるものは、技術的な理由についてであり、一方、他の制約は、商業的な動機によるものである。

例えば、ハードウェア装置製造者、ネットワークオペレータ、又はＲＴＥベンダーは、アプリケーションプロバイダーと共に排他的又は半排他的なアレンジメントをして、アプリケーション及び／又はアプリケーションに対する更新をそれらの各々のハードウェア装置に与えることができる。一般に、ＲＴＥでランするアプリケーションは、完全な装置ファンクションとインターフェイスするそれらの能力に制限がある。例えば、ネットワークスタックの制御、又は、装置の周辺記憶機器の制御を可能とするＡＰＩ（アプリケーションプログラミングインターフェイス）は、ＲＴＥからアクセスできないことがある。これは、時々、ネイティブコンピューティング環境内のそれ自身の「サンドボックス(sandbox)」において動作するＲＴＥとして説明される。これに比して、開いたプラットホーム（例えば、ＳｍａｒｔＰｈｏｎｅ）では、各実行可能ファイルがそれ自身のプロセスにおいてランすることができ、一般に、このような開いたプラットホームのオペレーティングシステムは、全ての装置ファンクションを、ラン中の各プロセスにさらすことができる。更に、ある環境（Ｂｒｅｗがその一例）では、ＲＴＥアプリケーションをネットワークにわたってのみ追加することが許され、アプリケーションが記憶カードにより装置にロードされることが防止される。これは、ネットワークにわたってロードするために多量の帯域巾及び時間を必要とする大型のゲームのような大きなアプリケーションをロードするときに問題になり得る。

ここに述べるシステム及び方法は、閉じたプラットホームにファンクションを追加する手段を設けることにより既存の慣例の欠点を改善する。ここに例示する実施形態では、追加されるファンクションは、ハードウェア装置にＰＩＤＬとして与えられる。閉じたプラットホームは、「ランチャ」プログラムを含むように生成することができ、このプログラムは、上述した動的リンカー／ローダー及びＰＩＤＬスタブファイルを、ＰＩＤＫと協働するアプリケーションと共に備えている。このランチャプログラムは、閉じた装置内のホストオペレーティングシステム向けに構築されその上で実行されると共に、出荷時に装置に常駐させることができる。ランチャアプリケーションとＰＩＤＬライブラリとの組み合せにより、装置の出荷時に新たなファンクションが存在しなくても、次のようにして、閉じた装置においてその新たなファンクションが動作することが可能となる。ランタイムにおいて、ＰＩＤＬが装置で使用できるようにされ、ランチャアプリケーションがスタートされる。スタブファイルからの情報を使用して、ランチャアプリケーション内の動的リンカー／ローダーは、ハードウェア装置に常駐してその装置のＯＳでランする協働するランチャプログラムにＰＩＤＬをロードし、リンクし、結合させるように働くことができる。それ故、ＰＩＤＬ内の全てのファンクションを、装置内の実行中のプログラムにさらし、閉じた装置に新たなファンクションを使用できるようにするという望みの結果を達成することができる。この点について、ＰＩＤＬ側では、課せられたハードウェア装置の制約を歩進させると共に、動的な実行をなすように動作する（上述したように）。

「ランチャ」アプリケーションは、それ自身が、一連のファンクションを与えてもよく、その動作について、ＰＩＤＬの存在に依存しないことを理解されたい。同様に、同じランチャアプリケーションが、そのランチャアプリケーションとコンパイルされるスタブが個別のＰＩＤＬライブラリに各々設けられた、非常に多くの異なる形式の新たなファンクションをイネーブルすることもできる。このような実施形態では、変更したファンクションを動的に追加できる一種のランタイム環境をシミュレーションすることができる。

例えば、ランチャアプリケーションは、ソフトウェアゲームコンソール、及び、一又は複数のゲームを含んでもよい。各異なるゲームに対して１つのＰＩＤＬというようにして、ＰＩＤＬライブラリの形態で更に別のゲームが追加されてもよく、これらは、ＰＩＤＬが装置にダウンロードされたときにランチャアプリケーションを通して再生できる。或いは、ランチャアプリケーションは、ＳＭＳのような基本的なメッセージングファンクションを与えてもよい。更に別のファンクション、例えば、ｅメール又はマルチメディアメッセージング、ビデオ及びオーディオプレーヤ、ブラウジングファンクション、ファイルビューイング、フォトアルバム、ＰＩＭ（パーソナル情報マネージメント）、及び他の形式のファンクションを、ランチャと相互動作するＰＩＤＬライブラリとして装置に展開することができる。

ここに例示する別の実施形態では、閉じた装置は、ＰＩＤＬライブラリの特定セットを認識するように各々構築された２つ以上の「ランチャ」アプリケーションと共に出荷されてもよい。このように、アドオン機能の範囲を顕著な仕方で拡張し編成することができる。

ここに述べる方法及びシステムは、これがなければ閉じたプラットホームであるプラットホームに使用されたときに既存の慣例を克服する。アフターマーケットソリューションを提供し得ると、装置ユーザには大きなユーティリティを、装置又はネットワークプロバイダーには売上増加の機会を与えることができる。この方法は、ファンクションを実行可能ファイルとして追加することを含まないので（例えば、ＰＩＤＬライブラリは、データとして存在し、実行可能なプログラムとして存在しない）、プラットホームの「閉じていること(closed-ness)」を制御することができる。というのは、それが、装置のオペレーティングシステム向けに実行可能ファイルとして生成される通常のアプリケーションに対して閉じたままであるからである。装置プロバイダーは、与えられるべき付加的なファンクションの範囲を前もって決定することができる。というのは、ＰＩＤＬスタブがランチャへとコンパイルされるファンクションしか動作しないからである。その結果、動的なセキュリティ及び商業的コントロールのセットを得ることができる。

ここに例示する実施形態では、ＰＩＤＬは、ワイヤレス又はワイヤードネットワークにわたるダウンロードによるか、繋がれたＰＣからのデータ転送によるか、装置に挿入された記憶カードからのデータ転送によることを含む複数の仕方で装置に与えることができる。実行可能アプリケーションではなくＰＩＤＬオブジェクトとしてファンクションをロードすることの他の独自の利点は、デジタル権利マネージメント(Digital Rights management)（ＤＲＭ）技術によりＰＩＤＬを保護できることである。データファイルとしてのＰＩＤＬは、実行可能プログラムとは異なり、ＤＲＭ技術に従うことができる。この充分に確立されたセキュリティ構成は、商業的トランザクションのもとでファンクションを追加するときにオペレータ及びユーザの両方に融通性及び機密性を与える。

上述したように、ＰＩＤＬオブジェクト及びリンキングスキームのプラットホーム独立特性と組み合わされたときには、装置メーカー又はネットワークプロバイダーは、全ての範囲の装置が異なるホストプラットホーム又はオペレーティングシステムを使用するときでも、それらの装置にわたって単一のＰＩＤＬオブジェクトとしてアドオン機能を与えることができる。各異なるプラットホームに対してアプリケーション又はライブラリをカスタマイズする必要性を回避し、全てのプラットホームにおいて等しく機能するプラットホーム独立の動的ライブラリ（ＰＩＤＬ）を単に与えることにより、スケールの効率及び経済性を実現するようにオペレータを配することができる。

また、閉じたプラットホーム（フューチャーホンのような）を参照して上述したこの方法及びシステムは、ランタイム環境（例えば、Ｊａｖａ又はＢｒｅｗ）をサポートするプラットホームに使用することもできる。この構成は、装置がファンクションを追加するための２つの仕方を与える。即ち、アプレット又は認証されたアプリケーションをＲＴＥで使用するためにダウンロードする従来の構成と、装置に常駐するランチャアプリケーションの制御のもとでＰＩＤＬライブラリとしてファンクションをロードする代替の態様がある。

互いに比較すると、ＰＩＤＬベースのスキームは、従来のランタイム環境には存在し得ない追加特徴を与えることができる。換言すれば、ファンクションの複数の断片が、単一のランチャアプリケーション内に複数の個別のＰＩＤＬとして展開されたときに、それらを同時にランすることができる。この状況において、ＰＩＤＬ実施形態では、ＰＩＤＬファンクションが共通のランチャプロセスのもとで実行でき、従って、同時に使用することができる。更に、ＰＩＤＬローディングアプローチでは、ファンクションを装置にロードする手段に相当の柔軟性を得ることができ、これは、あるランタイム環境（例えば、Ｂｒｅｗ）のもとでは許されていない、記憶カードからロードすることを含む。ＤＲＭの状況において、ＤＲＭは、ＰＩＤＬデータライブラリを展開するときに実現することができ、これは、実行可能アプリケーション又はアプレットをランタイム環境に展開するときには利用できない技術である。また、もし希望があれば、装置又はネットワークプロバイダーは、追加されるファンクションを、装置と共に出荷されるランチャアプリケーションにより認識されるファンクションに限定することもできる。

構築タイムにランチャが含められる厳密に閉じた環境とは異なり、ランタイム環境（ＲＴＥ）を有する装置は、ランチャアプリケーションをアフターマーケットの手続としてダウンロードできる利点を有する。このように展開されるときには、上述した動的ライブラリ（ＤＬ）ベースのスキームをＲＴＥと共存させながら、ＲＴＥがそれ自身では与えられない上述の利益を享受することができる。より詳細には、ＤＬライブラリは、ＲＴＥを経てアクセスできない装置ファンクション及びＡＰＩ（記憶カードのような）にアクセスすることができる。従って、このような構成では、ランチャアプリケーションは、例示的通信ネットワークを介して装置ＲＴＥへダウンロードされ、そこで、ランチャがプロキシとして働いて、記憶カードのような他の手段により更に別の機能を追加することが可能となる。同様に、ＲＴＥは、アプリケーションがＲＴＥのもとで実行するために最大サイズをしばしば課すことがある。この最大サイズは、より大きなプログラムを装置に展開できるようにするために回避され、これは、それ自体小さくて選択されたサイズ限界内にあるがその限界を越えるファンクションコードをＤＬライブラリに追加するランチャアプリケーションをダウンロードすることで行なわれる。ＤＬライブラリは、ＲＴＥアプリケーションではなくバイナリデータオブジェクトとしてロードされるので、ＲＴＥサイズ限界はそれらに適用されない。

図１３は、閉じたコンピューティング環境において動的な実行を実現するためにＰＩＤＬを取り扱うときに例示的コンピューティング環境により遂行される処理を示す。（閉じているが従来のランタイム環境が設けられた環境、及び開いたコンピューティング環境においても、同じ処理を遂行することができる。）図１３に示すように、処理はブック１３００で始まり、ここでは、ファンクションが、出荷時に装置（図示せず）に常駐する例示的ランチャアプリケーション内に設けられるもの、及び、アドオンファンクションとして設けることが可能なものに仕切られる。

ここに例示する実施形態では、図１３に示すように、ブロック１３２０において、アドオンファンクションを含むＰＩＤＬライブラリオブジェクトを生成することができ、更に、ブロック１３３０において、スタブファイルがソースコードとして生成される。ブロック１３１０において、ブロック１３００からの出荷時ファンクションを、スタブファイル１３３０及び動的リンカー／ローダーと一緒に含むランチャアプリケーションがコンパイルされ構築される。ブロック１３４０に示すように、装置が使用のために出荷されるときにランチャアプリケーションを装置に含ませることができる。

装置の出荷に続いて、ブロック１３５０において、アドオンファンクションを使用するための許可が与えられる。この許可は、装置を展開する環境に基づいて、商業的トランザクション又は他の基準を前提とできることが理解されよう。許可に続いて、ＰＩＤＬライブラリは、ブロック１３６０において、装置メモリへのダウンロード、ネットワーク転送、又は装置に取り付けられた記憶装置又はカードからの供給を含む（それらに限定されないが）適切な手段により、装置に使用できるようにされる。次いで、ブロック１３７０において、装置に存在するランチャアプリケーションをランすることができる。そこから、ブロック１３７５において、ＰＩＤＬオブジェクトが装置に使用できるかどうか決定するためのチェックを遂行することができる。このチェックは、ブロック１３１０においてコンパイルされたＰＩＤＬスタブファイルからの情報を使用して、ランチャアプリケーション内の動的リンカー／ローダーにより遂行することができる。ブロック１３７５におけるチェックが、ＰＩＤＬが装置に使用できないことを示す場合には、処理はブロック１３８０へ進み、そこで、ランチャアプリケーションは、出荷時の装置のファンクションと同一のファンクションの範囲（即ち、ＰＩＤＬに含まれた更に別のファンクションを除外する）で実行を継続する。

しかしながら、ブロック１３７５において、チェックが、ＰＩＤＬライブラリが装置に使用できることを示す場合には、処理はブロック１３９０へ進み、そこで、ＰＩＤＬがランチャアプリケーションにロードされ、リンクされ、結合される。このステップにより、ランチャアプリケーションからアクセスできるファンクションの範囲は、ブロック１３９５に示すように、ＰＩＤＬに存在するファンクションを含むように拡張される。

図１４は、ランチャアプリケーションのダウンロードにより付加的なファンクションを与えるときに遂行される処理を示す。このような処理は、開いた環境へダウンロードを行なうか、または、装置の既存のＲＴＥに関連して動作するためにランチャアプリケーションをダウンロードする場合のように、例示的コンピューティング装置が出荷された後に起こり得る。また、このような処理は、ダウンロード動作に対して閉じたままであるか又は他のコンピューティングアプリケーション（例えば、ランチャとは別の）の追加に対して閉じたままである閉じた環境へアプリケーションをダウンロードする独特の事柄としても生じ得る。ランチャは、技術的又は商業的なコントロールの利用により、このように（例えば、ダウンロードするように）動作することができる。

図示されたように、処理はブロック１４００において始まり、ここでは、プログラムが、ランチャアプリケーション及びアドオンファンクションに分割される。ここから、処理は、ブロック１４１５又は１４０５へ分岐する。ブロック１４０５では、アドオンファンクションのための動的ライブラリ（ＤＬ）オブジェクトが生成される。ブロック１４１５では、ランチャアプリケーション、リンカー／ローダー及びスタブファイルがコンパイルされ、構築される。ブロック１４０５から、処理は更に分岐する。ブロック１４０５から、処理はブロック１４１０へ進むことができ、ここでは、ＤＬのスタブファイルがソースコードとして生成される。そこから、処理はブロック１４２５へ進み、そしてそこから更に進む。また、ブロック１４０５から、処理はブロック１４４５へ進むことができ、ここで、ＤＬは、協働する装置（例えば、移動電話）に与えられる。ブロック１４４５から、処理は以下に述べるブロック１４５０へ進む。

ブロック１４１５から、処理はブロック１４２０へ進み、ここで、ランチャアプリケーションが装置へダウンロードされる。次いで、ブロック１４２５において、ダウンロードされたランチャアプリケーションが、それがダウンロードされた装置において動作することが許されるかどうか決定するためにチェックが行われる。ブロック１４２５におけるチェックが、ランチャアプリケーションが許可されなかったことを示す場合には、ブロック１４４０において処理が終了する。しかしながら、ブロック１４２５において、ランチャアプリケーションが装置で動作することが許可されたと決定された場合には、処理がブロック１４３０へ進み、ここで、ランチャアプリケーションがランされる。次いで、ブロック１４３５において、上述したようにブロック１４４５を経て装置にＤＬが使用できるかどうか決定するためのチェックが行われる。ブロック１４３５のチェックが、ＤＬが装置に使用できないことを示す場合には、ランチャアプリケーションの範囲が出荷時のままとされ、ＤＬにより与えられる付加的なファンクションへ拡張されない。しかしながら、ブロック１４３５において、ＤＬが装置に使用できることをチェックが示す場合には、処理がブロック１４５０へ進み、ここで、リンカー／ローダーがＤＬをロードして、ラン中のアプリケーションと結合する。処理はブロック１４５５へ進み、そこから続けられる。次いで、ランチャアプリケーションの範囲が、ブロック１４５５においてＤＬファンクションを含むように拡張される。

図１４に示す処理は、一つのランチャアプリケーションをダウンロードするか又は複数のランチャをダウンロードする際に適用されることが明らかであろう。このようなランチャは、ランチャアプリケーションの構築時に含ませることのできるライブラリスタブファイルに基づいて選択されたファンクションを追加するように動作できる。

要約すれば、ここに述べる装置及び方法は、種々のプラットホームを動作する異種のコンピューティング環境にわたって動作可能なプラットホーム独立のバイナリオブジェクトを提供する。しかしながら、本発明は、種々の変更や別の構造も受け容れることが理解されよう。本発明は、ここに述べる特定の構造に限定されるものではない。逆に、本発明は、本発明の範囲及び精神の中に包含される全ての変更、別の構造及び等効物を網羅するものとする。

また、本発明は、種々のコンピュータ環境（非ワイヤレス及びワイヤレスの両コンピュータ環境を含む）、部分的コンピューティング環境、及び実世界の環境において実施できることにも注意されたい。ここに述べる種々の技術は、ハードウェアでも、ソフトウェアでも、又はその両方の組み合せでも実施できる。好ましくは、これら技術は、プロセッサ、プロセッサにより読み取り可能な記憶媒体（揮発性及び不揮発性メモリ及び／又は記憶エレメントを含む）、少なくとも１つの入力装置、及び少なくとも１つの出力装置を含むプログラム可能なコンピュータを維持するコンピューティング環境において実施される。種々のインストラクションセットと協働するコンピューティングハードウェアロジックは、上述したファンクションを遂行すると共に出力情報を生成するようにデータに適用される。出力情報は、一又は複数の出力装置に適用される。例示的コンピューティングハードウェアにより使用されるプログラムは、コンピュータシステムと通信するために高レベル手順又はオブジェクト指向のプログラミング言語を含む種々のプログラミング言語で実装するのが好ましい。ここに例示する装置及び方法は、もし希望であれば、アッセンブリ言語又はマシン言語で実装することができる。いずれにせよ、言語は、コンパイル又はインタープリトされた言語でよい。このような各々のコンピュータプログラムは、汎用又は特殊目的のプログラム可能なコンピュータにより読み取ることのできる記憶媒体又は装置（例えば、ＲＯＭ又は磁気ディスク）に記憶されて、上述した手順を遂行するようにコンピュータにより記憶媒体又は装置が読み取られたときにコンピュータを構成及び動作するのが好ましい。また、装置は、コンピュータプログラムと共に構成されたコンピュータ読み取り可能な記憶媒体として実装されると捉えることもでき、このように構成される記憶媒体は、特定のそして予め定義された仕方でコンピュータを動作させる。

本発明の実施形態を以上に詳細に述べたが、当業者であれば、本発明の新規な技術及び効果から実質上逸脱せずに複数の別の変形例も可能であることが容易に明らかであろう。従って、このような全ての変形例は、本発明の範囲内に包含されるものとする。本発明は、特許請求の範囲に規定される。

ここに述べるシステム及び方法の実施形態に基づく例示的コンピューティング環境のブロック図である。 例示的データ通信アーキテクチャの例示的コンポーネントの協働を示すブロック図である。 動的リンキングアーキテクチャのブロック図である。 異種のコンピューティングプラットホームを有する第１オペレーティングシステムにわたって同じライブラリをリンクするときの動的リンキングアーキテクチャのブロック図である。 異種のコンピューティングプラットホームを有する第２オペレーティングシステムにわたって同じライブラリをリンクするときの動的リンキングアーキテクチャのブロック図である。 ここに述べるシステム及び方法に基づいて複数のプラットホームをサポートする複数のオペレーティングシステムのブロック図である。 ここに述べるシステム及び方法に基づく例示的プラットホーム独立リンキングアーキテクチャの例示的コンポーネント間の相互作用を示すブロック図である。 ここに述べるシステム及び方法に基づくメインアプリケーションプログラムと動的ライブラリとの間の相互作用を示すブロック図である。 ここに述べるシステム及び方法に基づいて例示的プラットホーム独立リンキングアーキテクチャにより遂行される処理を示すフローチャートである。 動的リンキングを遂行するネイティブなファシリティをもたないコンピューティング環境においてプラットホーム独立のバイナリオブジェクトを使用するときに遂行される処理を示すフローチャートである。 制約のあるコンピューティング環境においてプラットホーム独立のバイナリオブジェクトを使用するときに遂行される処理を示すフローチャートである。 制約のあるコンピューティング環境において協働するコンピューティングアプリケーションの種々のインスタンスを実行するためにプラットホーム独立のバイナリオブジェクトを使用するときに実施される処理を示すフローチャートである。 アドオンファンクションを与える閉じたハードウェア環境で動作するプラットホーム独立のバイナリオブジェクトを使用するときに遂行される処理を示すフローチャートである。 ここに述べるシステム及び方法の実施形態に基づいて制約のあるコンピューティング環境に付加的なファンクションを与えるためにランチャアプリケーションのダウンロードを介して遂行される処理を示すフローチャートである。

符号の説明

１００・・・コンピューティングシステム（コンピューティング環境）、１０５・・・システムバス、１１０・・・中央処理ユニット（ＣＰＵ）、１１２・・・相互接続部、１１５・・・コプロセッサ、１２０・・・メモリコントローラ、１２５・・・ランダムアクセスメモリ（ＲＡＭ）、１３０・・・リードオンリメモリ（ＲＯＭ）、１３５・・・周辺機器コントローラ、１４０・・・プリンタ、１４５・・・キーボード、１５０・・・マウス、１５５・・・データ記憶ドライブ、１６０・・・通信ネットワーク、１６３・・・ディスプレイコントローラ、１６５・・・ディスプレイ、１８０・・・コンピューティングプログラム、２００・・・ネットワーク構成のコンピューティング環境、２０５・・・サーバー、２１０・・・タブレットパーソナルコンピュータ、２１５・・・移動電話、２２０・・・電話、２２５・・・パーソナルデジタルアシスタント、

Claims (77)

1. コンピューティング環境内で動作するソフトウェアプラットホーム上でバイナリオブジェクトファイルを動的にロードしてリンクするためのシステムであって、
   動的ライブラリ（ＤＬ）と、
   前記ＤＬに対してソースコードとして生成されるスタブファイルと、
   前記ソフトウェアプラットホームで実行されるバイナリ実行可能プログラムを生成し、前記プログラムが前記ＤＬにアクセスしてそれと協働するのを許すように、協働するコンピューティングアプリケーションのソースコード及び前記スタブファイルのソースコードでコンパイルされ構築される動的リンカー／ローダーと、
   を備えるシステム。
2. 前記ＤＬは、選択された構造を有するバイナリオブジェクトファイルを含む、請求項１に記載のシステム。
3. 前記ＤＬの選択された構造は、実行可能・リンキングフォーマット（ＥＬＦ）、及びポータブル実行可能（ＰＥ）フォーマットのいずれかを含む、請求項２に記載のシステム。
4. 前記動的リンカー／ローダーは、実行のための協働するコンピューティングアプリケーションを含むバイナリ実行可能プログラムをロードする間に前記ソフトウェアプラットホームにＤＬをロードするようにＤＬに対して動作する、請求項２に記載のシステム。
5. 前記動的リンカー／ローダーは、前記ＤＬオブジェクトファイルのサイズを決定する、請求項４に記載のシステム。
6. 前記動的リンカー／ローダーは、前記ソフトウェアプラットホームにＤＬオブジェクトをロードするようにメモリを割り当てる、請求項５に記載のシステム。
7. 前記動的リンカー／ローダーは、前記バイナリ実行可能プログラムをロードする間に前記協働するコンピューティングアプリケーションにＤＬをリンクするようにＤＬに対して動作する、請求項４に記載のシステム。
8. 前記ＤＬにおいて動作し、前記ＤＬを協働するコンピューティングアプリケーションと動的にリンクするのに使用するために、エクスポートされるシンボル及びプロパティを記述するソースコードとして前記スタブファイルを生成するためのパーザを更に備える、請求項２に記載のシステム。
9. バイナリオブジェクトファイルの再コンパイル又は再構築を必要とせずに、定義されたプロセッサアーキテクチャにおいて実行される複数のソフトウェアプラットホーム及びオペレーティングシステムにわたって単一のバイナリオブジェクトファイルが動的にロードされリンクされる、請求項２に記載のシステム。
10. 前記ＤＬ、ＤＬスタブファイルのソースコード、及び動的リンカー／ローダーのソースコードと協働するコンピューティングアプリケーションのソースコードが、前記複数のソフトウェアプラットホームのうちの選択されたソフトウェアプラットホームに対するバイナリ実行可能プログラムへとコンパイルされリンクされる、請求項９に記載のシステム。
11. 前記ＤＬは、そのＤＬのバイナリフォーマットをネイティブにサポートしないオペレーティングシステムで動作されるコンピューティング環境のコンピューティングアプリケーションへ動的にロードされリンクされる、請求項４又は７に記載のシステム。
12. 前記ＤＬは、バイナリオブジェクトの動的リンキングを遂行するためのネイティブな動的リンキングメカニズムをもたないオペレーティングシステムで動作される制約のあるコンピューティング環境のコンピューティングアプリケーションへ動的にロードされリンクされる、請求項１に記載のシステム。
13. 前記協働するコンピューティングアプリケーションへのＤＬアクセスを与えるインターフェイスモジュールを更に備える、請求項２に記載のシステム。
14. 前記インターフェイスモジュールは、前記ＤＬが前記協働するコンピューティングアプリケーションにおける選択されたファンクションをコールするのを許すソースコードを備える、請求項１３に記載のシステム。
15. 前記インターフェイスモジュールのソースコードは、前記協働するコンピューティングアプリケーションのアプリケーションプログラミングインターフェイスをパーズすることにより生成される、請求項１４に記載のシステム。
16. 前記インターフェイスモジュールのソースコードは、前記ＤＬによりインポートされるシンボルを識別するようにＤＬバイナリオブジェクトファイルをパーズすることにより生成される、請求項１４に記載のシステム。
17. 前記インターフェイスモジュールのソースコード、前記協働するコンピューティングアプリケーションのソースコード、前記スタブファイルのソースコード、及び前記動的リンカー／ローダーのソースコードは、前記ソフトウェアプラットホームに対してコンパイルされる、請求項１４に記載のシステム。
18. 前記動的リンカー／ローダーは、前記協働するコンピューティングアプリケーション及び前記ＤＬを前記ソフトウェアプラットホーム上のラン可能なプロセスに結合するようにシンボルの分析及びリロケーションを取り扱う、請求項７に記載のシステム。
19. 前記ラン可能なプロセスは、複数の動的ライブラリと協働してそれに結合するためのコンピューティングアプリケーションを含む、請求項１８に記載のシステム。
20. 前記動的リンカー／ローダーは、前記ファイルを前記協働するコンピューティングアプリケーションにリンクするときに、ＤＬファイルと非ＤＬファイルとを区別する、請求項１８に記載のシステム。
21. 前記ラン可能なプロセスは、前記協働するコンピューティングアプリケーションを、前記ＤＬにリンクすると共に、前記ソフトウェアプラットホームに対してネイティブな動的にリンクされたライブラリにリンクする、請求項２０に記載のシステム。
22. バイナリコード及び／又はデータを含むＤＬを生成するようにライブラリソースコードがコンパイルされる、請求項１に記載のシステム。
23. 前記ＤＬは、前記ソフトウェアプラットホーム上で実行されるバイナリ実行可能プログラムに動的にロードされリンクされ、更に、前記ライブラリソースコードは、前記ソフトウェアプラットホームのプログラミング制約に違反するコードを含む、請求項２２に記載のシステム。
24. 前記プログラミング制約は、グローバル変数の使用に関する制約、又は書き込み可能な静的変数の使用に関する制約、又はポインタ変数の静的初期化に関する制約を含む、請求項２３に記載のシステム。
25. 前記動的リンカー／ローダーは、前記ＤＬがリンクされるプログラムのロード中に前記ソフトウェアプラットホームに前記ＤＬオブジェクトをロードするようにメモリブロックを割り当てる、請求項２４に記載のシステム。
26. 前記動的リンカー／ローダーは、前記ライブラリにおいて定義されたグローバル変数又は書き込み可能な静的変数の範囲を、前記ＤＬにより占有されるメモリブロックに拘束するように動作する、請求項２５に記載のシステム。
27. 前記ライブラリソースコードは、コードの複数の実行インスタンス又は繰り返し実行を制約する仕方でデータを取り扱い且つデータにアクセスファンクションを与えるためのコードを含み、
    前記動的リンカー／ローダーは、前記ライブラリのインスタンスを、動的に割り当てられたメモリブロックにロードし、ここでは、前記ライブラリコードにおいて定義されたデータ変数の範囲が前記メモリブロックに拘束される、請求項１７に記載のシステム。
28. 同じライブラリの複数の非衝突インスタンスが前記コンピューティング環境において実行可能である、請求項２７に記載のシステム。
29. 前記ＤＬにより使用されるデータは、前記コード内に定義されたグローバル変数又は静的変数により参照される、請求項２７に記載のシステム。
30. 単一のコンピューティング環境プロセス内に複数の実行インスタンスを許すために非オブジェクト指向のコードをロードする、請求項２７に記載のシステム。
31. ライブラリデータの複数のセットが単一のコンピューティング環境プロセス内で同時に動作して、各ライブラリデータセット間で衝突が軽減され及び／又は除去されるようにする、請求項３０に記載のシステム。
32. 単一のコンピューティング環境プロセス内にコードの繰り返し実行を許すために非オブジェクト指向のコードをロードする、請求項２７に記載のシステム。
33. 複数のプロセスをサポートしないコンピューティング環境においてコードの複数の実行インスタンス及び繰り返し実行を許すためにコードをロードする、請求項２７に記載のシステム。
34. 前記コンピューティング環境は、非常駐の実行可能プログラムを前記コンピューティング環境に展開することに関して制約を受け、更に、前記協働するコンピューティングアプリケーションは、前記ＤＬを実行中のランチャアプリケーションに動的にリンクすることにより、前記制約のあるコンピューティング環境に使用できるファンクションを拡張するよう動作できるランチャアプリケーションを備える、請求項２に記載のシステム。
35. 前記制約のあるコンピューティング環境は、前記コンピューティング環境に対しネイティブな実行可能プログラムの追加を許さない、請求項３４に記載のシステム。
36. 前記コンピューティング環境は、前記コンピューティング環境において実行できるプログラムの最大サイズについて制約を課する、請求項３４に記載のシステム。
37. 前記コンピューティング環境は、ランタイム環境（ＲＴＥ）をサポートする、請求項３４に記載のシステム。
38. 前記ＲＴＥ内でランするプログラムは、前記ネイティブなコンピューティング環境に使用できる一又は複数のファンクションへの制約のあるアクセスを有する、請求項３７に記載のシステム。
39. 前記ＲＴＥは、前記ＲＴＥにより認証されたプログラムしかランしないように動作を制約する、請求項３７に記載のシステム。
40. 前記ＲＴＥは、Ｊａｖａ２モバイル・エディション（Ｊ２ＭＥ）ＲＴＥ、及びバイナリ・ランタイム・エンビロンメント・フォー・ワイヤレス（ＢＲＥＷ）ＲＴＥのいずれかを含む、請求項３７に記載のシステム。
41. 前記ランチャモジュールは、前記コンピューティング環境においてネイティブなコンピューティングアプリケーションとして動作するように書き込まれる、請求項３４に記載のシステム。
42. 前記ランチャは、前記コンピューティング環境の前記ランタイム環境内でコンピューティングアプリケーションとして動作するように書き込まれる、請求項３７に記載のシステム。
43. 少なくとも２つのランチャモジュールを更に備える、請求項４１に記載のシステム。
44. 前記ＤＬは、フラッシュメモリユニット、固定メモリユニット、及びマイクロドライブのいずれかを含む前記コンピューティング環境から物理的に離れた記憶媒体に記憶される、請求項３４に記載のシステム。
45. 前記ランチャアプリケーションを含む前記バイナリ実行可能プログラムは、フラッシュメモリユニット、固定メモリ媒体ユニット、及びマイクロドライブのいずれかを含む前記コンピューティング環境から物理的に離れた記憶媒体に記憶される、請求項３４に記載のシステム。
46. 前記ＤＬは、前記制約のあるコンピューティング環境へのコンテンツの安全な配布を促進するようにデジタル権利マネージメント構成で使用される、請求項３４に記載のシステム。
47. コンピューティング環境内で動作するソフトウェアプラットホーム上でバイナリオブジェクトを一体化する方法であって、
    ライブラリソースコードを用意するステップと、
    選択されたフォーマットをもつオブジェクトファイルを含むコードライブラリ（ＣＬ）を生成するように前記ライブラリソースコードをコンパイルするステップと、
    前記ＣＬのためのスタブファイルをソースコードとして生成するステップと、
    動的リンカー／ローダーのソースコードを、前記ライブラリと協働するコンピューティングアプリケーションのソースコード、及び前記スタブファイルのソースコードと一緒にコンパイル及び構築して、前記ソフトウェアプラットホームで実行されるバイナリ実行可能プログラムを生成するステップと、
    前記ソフトウェアプラットホーム上で実行するために前記プログラムがロードされるときに、前記ＣＬを動的にロードして前記協働するコンピューティングアプリケーションとリンクするステップと、
    を備える方法。
48. ＥＬＦファイルフォーマット又はＰＥファイルフォーマットを含むオブジェクトファイルフォーマットを選択するステップを更に備える、請求項４７に記載の方法。
49. 前記ＣＬを協働するコンピューティングアプリケーションと動的にリンクするのに使用するために、エクスポートされるシンボル及びプロパティを記述するソースコードとして前記スタブファイルを生成するように前記ＣＬオブジェクトをパーズするステップを更に備える、請求項４８に記載の方法。
50. 前記ＣＬを、ロード時に、コンピューティング環境のメモリに動的にロードするように、前記動的リンカー／ローダーによりメモリブロックを割り当てるステップを更に備える、請求項４７に記載の方法。
51. 協働するコンピューティングアプリケーションにより使用するためにＣＬシンボルを分析しリロケーションするように前記ＣＬをリンクするステップを更に備える、請求項５０に記載の方法。
52. 前記協働するコンピューティングアプリケーションにおいて選択されたファンクションをコールするためのライブラリアクセスを与えるソースコードとしてインターフェイスモジュールを用意するステップを更に備える、請求項４７に記載の方法。
53. 前記インターフェイスモジュールのソースコード、前記協働するコンピューティングアプリケーションのソースコード、前記スタブファイルのソースコード、及び前記動的リンカー／ローダーのソースコードを、前記ソフトウェアプラットホームで実行されるバイナリ実行可能プログラムへとコンパイルするステップを更に備える、請求項５２に記載の方法。
54. 前記バイナリオブジェクトファイルを再コンパイル又は再構築する必要なく、定義されたプロセッサアーキテクチャで実行される複数のソフトウェアプラットホーム及びオペレーティングシステムにわたって単一のバイナリオブジェクトファイルを一体化するステップを更に備える、請求項４７に記載の方法。
55. 前記ＣＬと協働するコンピューティングアプリケーションのソースコード、スタブファイルのソースコード、及び前記動的リンカー／ローダーのソースコードを、前記複数のソフトウェアプラットホームのうちの選択された１つに対するバイナリ実行可能プログラムへとコンパイルしリンクするステップを更に備える、請求項５４に記載の方法。
56. 前記コンピューティング環境は、前記選択されたオブジェクトフォーマットをネイティブにサポートしない、請求項４７に記載の方法。
57. バイナリオブジェクトの動的リンキングを遂行するためのネイティブな動的リンキングメカニズムをもたないオペレーティングシステムで動作される制約のあるコンピューティング環境において前記ＣＬをロードしてそれをコンピューティングアプリケーションにリンクするステップを更に備える、請求項４７に記載の方法。
58. 前記ライブラリソースコードは、前記ソフトウェアプラットホームのプログラミング制約に違反するコードを含む、請求項５０に記載の方法。
59. 前記プログラミング制約は、グローバル変数の使用に関する制約、書き込み可能な静的変数の使用に関する制約、及びポインタ変数の静的初期化に関する制約のいずれかを含む、請求項５８に記載の方法。
60. 前記ライブラリにおいて定義されたグローバル変数又は書き込み可能な静的変数の範囲を、前記ＣＬにより占有されるメモリブロックに拘束するステップを更に備える、請求項５９に記載の方法。
61. 前記ライブラリソースコードは、コードの複数の実行インスタンス又は繰り返し実行を制約する仕方でデータを取り扱い且つデータへのアクセスファンクションを与えるためのコードを含み、
    前記方法は、更に、前記ライブラリのインスタンスを、前記動的リンカー／ローダーにより、動的に割り当てられたメモリブロックにロードするステップを備え、ここでは、前記ライブラリコードにおいて定義されたデータ変数の範囲が前記メモリブロックに拘束される、請求項４７に記載の方法。
62. 単一のコンピューティング環境プロセス内で実行されるべき同じライブラリの複数の非衝突インスタンスをロードするステップを更に備える、請求項６１に記載の方法。
63. ライブラリデータの複数のセットが単一のコンピューティング環境プロセス内で同時に動作して、各ライブラリデータセット間で衝突が軽減され及び／又は除去されるようにする、請求項６２に記載の方法。
64. 単一のコンピューティング環境プロセス内でコードの実行を繰り返すために、非オブジェクト指向のコードをロードするステップを更に備える、請求項６１に記載の方法。
65. 前記コンピューティング環境は、複数のプロセスをサポートしない、請求項６２又は６４に記載の方法。
66. 前記コンピューティング環境は、非常駐の実行可能プログラムを前記コンピューティング環境に展開することに関して制約を受け、
    前記方法は、更に、前記ＣＬを、前記協働するコンピューティングアプリケーション内に含まれた実行中のランチャアプリケーションと動的にリンクすることにより、前記制約のあるコンピューティング環境に使用できるファンクションを拡張するステップを備える、請求項４７に記載の方法。
67. 前記コンピューティング環境は、一又は複数の制約を受け、これら制約は、
    前記コンピューティング環境がネイティブな実行可能プログラムの追加に対して閉じていること、
    前記コンピューティング環境が、実行を、プログラムサイズ限界内に入るプログラムに制限すること、
    前記コンピューティング環境がランタイム環境（ＲＴＥ）を有し、このＲＴＥ内でランするプログラムが、ネイティブなコンピューティング環境に使用できる一又は複数のファンクションへの制約されたアクセスを有すること、
    前記コンピューティング環境のＲＴＥが、そのＲＴＥに対して認証されたプログラムしかランしないように動作を制約すること、及び
    前記コンピューティング環境が動的リンキングを許さないこと、
    の一又は複数を含む請求項６６に記載の方法。
68. 定義されたプロセッサアーキテクチャで動作する異種のコンピューティングソフトウェア環境にわたって使用するためのコンピューティングライブラリを配布する方法であって、
    選択された構造を有するバイナリオブジェクトファイルとして動的ライブラリ（ＤＬ）を生成するステップと、
    前記ＤＬに対してソースコードとしてスタブファイルを生成するステップと、
    動的リンカーのソースコードを、前記ＤＬスタブファイルのソースコード、及び少なくとも１つのコンピューティング環境で動作できる協働するコンピューティングアプリケーションのソースコードと一緒にコンパイルすることにより、バイナリ実行可能プログラムを構築するステップと、
    通信ネットワーク及び記憶媒体のいずれかを含む入力ソースから前記異種のコンピューティング環境へ前記ＤＬを通信するステップと、
    を備える方法。
69. 少なくとも１つのＤＬと協働する前記コンピューティングアプリケーションの新たなバージョンを通信するステップを更に備える、請求項６８に記載の方法。
70. 前記コンピューティングアプリケーションと協働する前記ＤＬの新たなバージョンを通信するステップを更に備える、請求項６８に記載の方法。
71. コンピューティング環境で使用するためのコンピューティングライブラリを配布するもので、前記コンピューティング環境は、一又は複数の制約を受け、これらの制約は、
    前記コンピューティング環境がネイティブな実行可能プログラムの追加に対して閉じていること、
    前記コンピューティング環境が、実行を、プログラムサイズ限界内に入るプログラムに制限すること、
    前記コンピューティング環境がランタイム環境（ＲＴＥ）を有し、このＲＴＥ内でランするプログラムが、ネイティブなコンピューティング環境に使用できる一又は複数のファンクションへの制約されたアクセスを有すること、
    前記コンピューティング環境のＲＴＥが、そのＲＴＥに対して認証されたプログラムしかランしないように動作を制約すること、及び
    前記コンピューティング環境が動的リンキングを許さないこと、
    の一又は複数を含む請求項６８に記載の方法。
72. プロキシとして動作できるコンピューティング装置に、協働するランチャアプリケーションをダウンロードし、通信ネットワーク及び記憶媒体のいずれかを含む入力ソースからそのコンピューティング装置に使用できる動的ライブラリへの前記ランチャプログラムによるアクセスを許すステップを更に備える、請求項７１に記載の方法。
73. スタブファイルが前記ランチャアプリケーションでコンパイルされる動的ライブラリが前記コンピューティング装置に使用できるようになったときに、前記ランチャアプリケーションの範囲を、協働する動的ライブラリの付加的なファンクションを含むように拡張するステップを更に備える、請求項７２に記載の方法。
74. 前記協働するコンピューティングアプリケーションは、コンピューティング装置をエンドユーザに販売するために出荷する前に、コンピューティング装置のコンピューティング環境に対して展開される、請求項６８に記載の方法。
75. 前記協働するコンピューティングアプリケーションは、コンピューティング装置をエンドユーザに販売するために出荷した後に、コンピューティング装置のコンピューティング環境に対して展開される、請求項６８に記載の方法。
76. 前記コンピューティング装置は、移動電話又はワイヤレスイネーブル型ハンドセットである、請求項７４又は７５に記載の方法。
77. 前記ＤＬは、前記コンピューティング環境へのコンテンツの安全な配布を促進するようにデジタル権利マネージメント構成で使用される、請求項６８に記載の方法。

Images