JP2005182790A - 自己記述型ソフトウェアイメージ更新コンポーネント - Google Patents

Abstract

【課題】 更新を含むソフトウェアイメージがパッケージとして提供されるシステムおよび方法を提供すること。
【解決手段】 このパッケージは自己記述型であり、それによってイメージのコンポーネント部分だけの置換を容易にする。ソフトウェア構築プロセスは、（ファイル、メタデータ、構成情報などを含む）オペレーティングシステム機能をそのパッケージ中へとマッピングし、実行可能コードが、再配置の目的のために処理される。この最終的なパッケージは、そのパッケージを記述し、依存情報、および設定の優先順位についての情報（シャドウデータ）を伝えるデバイスマニフェストファイルを含んでいる。
【選択図】 図２

Description

本発明は、一般にコンピューティング装置に関し、より詳細にはコンピューティング装置の不揮発性ストレージを更新することに関する。

携帯情報端末、最新の携帯電話、ハンドヘルドコンピュータ、ポケットサイズコンピュータなどの携帯型のコンピューティング装置が、重要で人気のあるユーザツールになってきている。一般に、これらのコンピューティング装置では、十分小さくなって非常に便利になる一方で、消費する電池電力も少なくなり、また同時により強力なアプリケーションを実行できるようになってきている。

このようなデバイスを製造するプロセス中に、埋込みのオペレーティングシステムイメージが、通常単体のイメージファイルに組み込まれ、各装置の不揮発性ストレージ（例えば、ＮＡＮＤまたはＮＯＲ型のフラッシュメモリ、ハードディスクなど）に記憶される。この結果、このような装置を更新することが、ときどき必要となり、または望ましい。

しかし、単体のオペレーティングシステムには、更新をインストールするために大量のリソース（例えば、一時記憶および処理能力）が、この単体のイメージ全体を置き換えるために必要とされることを含めていくつもの不利な点がある。同時に、このオペレーティングシステムの一部のサブセットコンポーネントをインストールすることは、様々な理由から困難なタスクとなる。オペレーティングシステムイメージのあるサブセットの更新を容易にするメカニズムが必要になっている。

簡潔に言えば、本発明は、各パッケージが、インストレーションの目的で同じに扱われる１組のファイルのカプセル（ｅｎｃａｐｓｕｌａｔｉｏｎ）を含み、このパッケージのフォーマットが、自己記述型（ｓｅｌｆ−ｄｅｓｃｒｉｂｉｎｇ）であり、それによってイメージの構成要素だけの置換を容易にすることができる、インストレーションおよび更新パッケージを提供するシステムおよび方法を対象としている。この目的のために、このシステムおよび方法では、（ファイル、メタデータ、構成情報などを含む）オペレーティングシステムの機能がソフトウェア構築プロセスの一部分としてパッケージ中にマッピングされる。

一実施例では、パッケージングロジック（ｐａｃｋａｇｉｎｇ ｌｏｇｉｃ）は、ユーザが順に選択して異なるパッケージにマッピングする関連した機能（ｆｅａｔｕｒｅ）の間で、特定のファイルおよび／または設定が共有される場合を取り扱う。いくつかの可能性のある、より高レベルのパッケージマッピング要求を前提として、このロジックにより、一般に個別のファイル／設定がこの正しいパッケージにマッピングされるようになる。さらに、パッケージは、オプションとして依存情報を伝え、したがって、パッケージがその依存情報を取得するためのメカニズムが、（機能レベルの依存仕様によって）提供される。ロジックは、この機能レベルより下位の競合および依存性を解決する。

構築プロセス中に、オペレーティングシステムイメージについてのバイナリイメージビルダファイル（ｂｉｎａｒｙ ｉｍａｇｅ ｂｕｉｌｄｅｒ ｆｉｌｅ）と、コンポーネントツーパッケージマッピングファイル（ｃｏｍｐｏｎｅｎｔ ｔｏ ｐａｃｋａｇｅ ｍａｐｐｉｎｇ ｆｉｌｅ）を入力として取り込むことによって、構築マニフェストファイル（ｂｕｉｌｄ ｍａｎｉｆｅｓｔ ｆｉｌｅ）が作成される。この構築マニフェストファイルは、特定のパッケージについてのファイル内容を指定する。これらのファイル内容を再検討し、任意の実行可能コードをそのパッケージへの挿入に先立って処理して、インストール時における装置上での実行可能コードの再配置／修正（ｆｉｘ‐ｕｐ）を可能にする。パッケージ生成プロセスでは、構築マニフェストおよびパッケージ定義ファイル中の情報に基づいてデバイスマニフェストが作成される。

このオペレーティングシステムイメージについてのレジストリは、分割して同様なアルゴリズムに基づいてパッケージに割り当てられ、ＸＭＬファイルも同様に分割して特定のパッケージに割り当てることができる。この結果は、おそらく、パッケージ定義ファイル、コンポーネントマッピングファイル、コンポーネント関係ファイル、構築マニフェストファイル、レジストリファイル、およびＸＭＬ設定ファイルを含めて、構築すべき各パッケージについてのいくつかのファイルとなる。これらのファイルから、パッケージ生成プロセスは、各パッケージをパッケージ定義へマッピングすること、パッケージについての構築マニフェストファイルを読み取ること、およびそのデータからパッケージを生成することを含めて、これらのパッケージからパッケージコレクションを作成することによって最終的なパッケージファイルを構築する。

自己記述型となるパッケージでは、デバイスマニフェストファイルが、このパッケージングプロセス中に作成され、このパッケージ自体に格納される。このデバイスマニフェストファイルは、インストレーションプロセス中に使用される。パッケージの依存性データおよびシャドウ（パッケージ設定優先度）データはまた、例えばこのデータをデバイスマニフェストファイルに書き込むことによってパッケージに付随するデータの一部ともなる。

他の利点についても、図面を併せ参照するときに以下の詳細な説明から明らかになろう。

・例示の動作環境
図１は、プロセッサ１２２、メモリ１２４、ディスプレイ１２６、および（物理的キーボードまたは仮想的キーボードでもよく、またはその両方を表し得る）キーボード１２８を含む、かかるハンドヘルドコンピューティング装置１２０の機能コンポーネントを示すものである。マイクロフォン１２９が、オーディオ入力を受けるために存在することもある。メモリ１２４は、一般に揮発性メモリ（例えば、ＲＡＭ）と不揮発性メモリ（例えば、ＲＯＭ、ＰＣＭＣＩＡカードなど）の両方を含んでいる。マイクロソフト（登録商標）コーポレーション製のＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムまたは別のオペレーティングシステムなどのオペレーティングシステム１３０が、メモリ１２４中に存在し、プロセッサ１２２上で実行される。

１つまたは複数のアプリケーションプログラム１３２が、メモリ１２４にロードされ（または、ＲＯＭ中に配置されて実行され）このオペレーティングシステム１３０上で実行される。アプリケーションの例としては、電子メールプログラム、スケジューリングプログラム、ＰＩＭ（個人情報管理）プログラム、ワードプロセッシングプログラム、スプレッドシートプログラム、インターネットブラウザプログラムなどが挙げられる。ハンドヘルドパーソナルコンピュータ１２０は、メモリ１２４にロードされ、プロセッサ１２２上で実行される通知マネージャ１３４を含むこともできる。通知マネージャ１３４は、例えば、アプリケーションプログラム１３２からの通知要求を処理する。また、以下で説明するように、ハンドヘルドパーソナルコンピュータ１２０は、このハンドヘルドパーソナルコンピュータ１２０をネットワークに接続するのに適したネットワーキングソフトウェア１３６（例えば、ハードウェアドライバなど）およびネットワークコンポーネント１３８（例えば、無線およびアンテナ）を含んでおり、電話をかけることを含めることができる。

ハンドヘルドパーソナルコンピュータ１２０は、１つまたは複数のバッテリとして実装される電源１４０を有している。この電源１４０は、ＡＣアダプタや電源ドッキングクレードルなど、内蔵バッテリを無効にするか再充電する外部電源をさらに含むことができる。

図１に示す例示的なハンドヘルドパーソナルコンピュータ１２０は、３種類の外部通知メカニズム、すなわち、１つまたは複数の発光ダイオード（ＬＥＤ）１４２およびオーディオジェネレータ１４４を有するように示されている。これらのデバイスは、この電源１４０に直接に結合され、その結果、駆動されたときに、たとえこのハンドヘルドパーソナルコンピュータプロセッサ１２２および他のコンポーネントがバッテリ電力を節約するために遮断されることがあっても、これらのデバイスは、ある存続期間にわたって通知メカニズムによって指示され続けることができる。このＬＥＤ１４２は、ユーザがアクションを取るまで無期限に状態を維持することが好ましい。オーディオジェネレータ１４４の現在のバージョンは、今日のハンドヘルドパーソナルコンピュータバッテリにとってはあまりにも多すぎる電力を使用し、したがって、このシステムの残りが切断されたときまたは駆動された後ある有限の継続期間後にオフになるように構成されていることに留意されたい。

基本的なハンドヘルドパーソナルコンピュータを示しているが、携帯電話など、データ通信を受信し、プログラムが使用するために何らかの方法でデータを処理することができる実質上どのようなデバイスでも、本発明を実施する目的では等価なものであることに留意されたい。

・自己記述型ソフトウェアイメージ更新コンポーネント
本発明は一般に、初期ソフトウェアまたはソフトウェアの更新が埋込みデバイスの不揮発性メモリ、例えばフラッシュメモリに書き込まれるデバイスを含めて、マイクロソフト（登録商標） Ｗｉｎｄｏｗｓ（登録商標）ＣＥベースの携帯機器など小型のモバイルコンピューティング装置上に記憶されるソフトウェアをインストールおよび／または更新することを対象としている。それにもかかわらず、本発明は一般にコンピューティングに対しても利点を提供するものであり、したがって様々な種類のメモリ、および／またはハードディスクドライブなど他の種類の記憶媒体を含めて、他のコンピューティング装置と他の種類のストレージに適用することもできる。簡潔に説明するために、どのような記憶メカニズムも等価であることが理解されようが、用語「フラッシュ」は、以降ではデバイスの更新可能なストレージに関して使用する場合がある。さらに、用語「イメージ」は一般に、たとえ既存のイメージの一部分しか更新されないときでさえ、初期ソフトウェアインストレーションイメージならびにその後のイメージに対するソフトウェアの更新の概念を含むことになる。

バックグラウンドとして、Ｗｉｎｄｏｗｓ（登録商標）ＣＥオペレーティングシステムなど現在のオペレーティングシステムは、モジュール化（コンポーネント化）されている。しかし、正しいファイルおよび設定を含むその結果イメージ（ｒｅｓｕｌｔａｎｔ ｉｍａｇｅ）は、単体のオペレーティングシステムイメージである。このために、構築時に、機能変数（ｆｅａｔｕｒｅ ｖａｒｉａｂｌｅｓ）を特定のファイルおよび設定に対してマッピングして、この結果としての単体のオペレーティングシステムイメージ中に何が含まれているかが判定される。このマッピングを実施するための機能は、２種類の構築時構成ファイル、すなわちバイナリイメージビルダ（．ｂｉｂ）ファイルおよびレジストリ（．ｒｅｇ）ファイルを使用する。この．ｂｉｂファイルは、結果イメージに含められるファイルのリストを含み、．ｒｅｇファイルは、このイメージに含められるレジストリ（設定）情報のリストを含んでいる。これらのファイルの内容は、機能によってコレクションにグループ分けされ、構築時にオプションで設定することができる条件付き変数にラップ（ｗｒａｐ）される。条件付き機能変数が構築時に設定されるとき、．ｂｉｂファイルおよび．ｒｅｇファイルの関連する内容が、そのイメージ中に含められ、そのようなものとしてこのシステムのユーザは、細分性（ｇｒａｎｕｌａｒ）機能レベルでこの結果イメージが何を含むべきかを選択することができる。

より高レベルのロジックは、機能レベルの依存性が自己満足させるものであるように条件付き変数の選択にも適用される。換言すれば、１つの機能を選択することによって、この選択されたフィーチャが依存している他のフィーチャも選択されるようになる。したがって、この構築システムは、自己矛盾のない単一のオペレーティングシステムイメージが、ユーザの側での任意のランダムな機能の選択によりもたらされることを保証する。しかし、前述のように、単一のオペレーティングシステムイメージは、下位区分のイメージを個々に更新できるように構成されたイメージに対して欠点を有する。

本発明の一態様によれば、ソフトウェアの更新を含むイメージが、自立型の安全（ｓｅｃｕｒｅ）なエンティティから構築される。基本的な更新プリミティブ（ｐｒｉｍｉｔｉｖｅ）は、パッケージと呼ばれ、ここで一般に、パッケージとは、同じものとしてバージョン化されユニットとして更新される１組のファイルのカプセルである。本発明は、イメージを更新する際に自己記述型の顕著な改善をもたらし、イメージの１つのコンポーネント部分だけの置換えを容易にするようなパッケージフォーマットを提供する。

イメージは、パッケージから構築され、ストレージに適用することができる実行可能コードおよびデータを含んでいる。実行可能コードは、インストール時にこの埋込みデバイスの仮想アドレス空間環境にカスタマイズされることに留意されたい。例えば、基礎となるフラッシュメモリ技術に依存して、一部のデバイスでは、実行可能コードがそのフラッシュから直接実行（コードを圧縮フォーマットで記憶することができないことを意味する「その場で実行（ｅｘｅｃｕｔｅ−ｉｎ−ｐｌａｃｅ）」）できるようになるが、一方、他のデバイスでは、実行するためにそのコードを（必要に応じてそのコードを伸張することを含めて）ＲＡＭにコピーする必要がある。本発明の一態様に従って、イメージ更新技術では、コンポーネント間のどのような依存性をも保持しながら、パッケージを使用してそのオペレーティングシステムイメージが、別個に更新することができる更新可能なコンポーネントに分解される。

本発明の一態様によれば、（ファイル、メタデータ、構成情報などを含む）オペレーティングシステム機能をソフトウェア構築プロセスの一部分としてパッケージ中にマッピングするシステムおよび方法が提供される。このパッケージは、初期のデバイスインストレーションのためにも、更新のためにも使用することができる。以下で説明するように、ソフトウェア更新パッケージは、様々な形態をとることができ、例えば、あるものでは、以前の更新に対する変更分（デルタ）しか含まないこともあるが、一方、他のものでは、他のファイルを全部置き換えるファイルを含むこともある。他の種類の１つのパッケージでは、他の複数のパッケージを含むことができる。

本明細書中で説明しているパッケージの概念は、更新プロセスのうちのコンポーネント部分である。オペレーティングシステム機能（一般に、特定のファイル、メタデータ、構成情報などにマッピングする抽象概念）をパッケージ中にマッピングするプロセスにより、オペレーティングシステムイメージの最低レベルのコンポーネントを識別する必要性の代わりに、ユーザが、このオペレーティングシステムイメージの特定の態様についてのフルセットの関連するファイル、メタデータ、構成情報などを記述した、より高レベルのハンドルを参照することができることを含めて、ユーザ（例えば、このイメージのプロバイダ）にとっての使い易さの利点がもたらされる。本明細書中で使用されているように、用語「機能（ｆｅａｔｕｒｅ）」および「コンポーネント（ｃｏｍｐｏｎｅｎｔ）」は、通常、同義的に使用することができる。機能ハンドルを参照することによって、ユーザは、抽象化を介してパッケージングの複雑さを管理する観点での利益を得ることができる。例えば、ブラウジングコンポーネントソフトウェア（例えば、Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ）用の実行可能モジュール、ダイナミックリンクライブラリ（ＤＬＬ）、リソース／データファイル、レジストリ情報などを特別にマッピングし、各部分をパッケージに個々にマッピングする代わりに、本発明では、ユーザが、単一の「Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ」ハンドルを有するこの関連する情報を参照し、したがってその情報をこの機能レベルでパッケージにマッピングすることを可能にする。

本発明では、ユーザが異なるパッケージにマッピングするために次に選択する関連した機能間で、特定のファイル／設定が共有される場合を扱うためのパッケージングロジックも提供する。（以下で説明する）様々なアルゴリズムにおけるロジックにより、一般に、いくつかの可能性がある、より高レベルのパッケージマッピング要求を前提として、個々のファイル／設定が正しいパッケージにマッピングされるようになる。ロジックが、正しい手順を決定できない状況においては、メッセージングがユーザに対して提供されて、解決するためにユーザの介入を必要とする任意の課題が示される。

さらにパッケージは、オプションで依存情報も伝える。
例えばパッケージの内容が、別のパッケージの内容に依存する場合、この関係は、その構築プロセス中に取り込まれ、後で解析するためにそのインストレーションプロセス中にパッケージの中に符号化される。本発明ではまた、パッケージがこの依存情報を獲得するための（機能レベルの依存仕様（ｄｅｐｅｎｄｅｎｃｙ ｓｐｅｃｉｆｉｃａｔｉｏｎｓ）による）メカニズムが提供される。

本発明の一態様によれば、機能の選択をパッケージのアレイ（１つまたは複数のパッケージ）にマッピングすることができ、その結果、特定のファイルおよび設定が、適切なパッケージにマッピングされることになる。これを正しく遂行するために、ロジックは、この機能レベルの下にある競合および依存性の問題を解決する。例えば、２つの機能が同じ特定のファイルを論理的に参照し、これらの機能が異なるパッケージにマッピングされる場合、このロジックは、この共有されたファイルをどのパッケージに配置すべきかを決定する。

一実施例においては、パッケージファイルは、構築時に３つの異なるファイル、すなわちパッケージ定義ファイル（ｐｋｄ）、コンポーネントマッピングファイル（ｃｐｍ）、およびコンポーネント関係ファイル（ｃｒｆ）によって定義される。ｐｋｄファイルは、パッケージの内容のグローバル属性を定義する。このｐｋｄファイルは、構築プロセス中に以下のＸＳＤに対して正当性が確認されるＸＭＬファイルである。

．ｐｋｄファイルの一例を以下に示す。

このグローバルユニークＩＤ（ｇｌｏｂａｌｌｙ−ｕｎｉｑｕｅ ＩＤ）（ＧＵＩＤ）およびパッケージ名の定義ファイルの存在に留意されたい。このＧＵＩＤは、パッケージを別のパッケージと区別するために参照することができるこのパッケージについての一意的な名前を提供する。このパッケージ名は、オペレーティングシステム機能／コンポーネントをこのパッケージにマッピングする際に使用されるハンドルを提供する役割を果たす。

一実施例では、ｃｐｍファイルは、コンポーネントツーパッケージマッピング情報（ｃｏｍｐｏｎｅｎｔ−ｔｏ−ｐａｃｋａｇｅ ｍａｐｐｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を含むＣＳＶ（ｃｏｍｍａ−ｓｅｐａｒａｔｅｄ ｖａｌｕｅ）ファイルである。このファイルは、以下の形式となる。
＜コンポーネント変数＞，＜パッケージ名＞
または
＜コンポーネントファイル名＞，＜パッケージ名＞。

以下は、一部のコンポーネントツーパッケージマッピング情報の例を提供するものである。

コンポーネント関係ファイル（ｃｒｆ）は、コンポーネント間の依存関係とシャドウ関係（シャドウとは、設定についての優先順位を意味する）を示す。このコンポーネント関係ファイルは、以下の形式となる。
＜コンポーネント変数＞ ＤＥＰＥＮＤＳＯＮ ＜コンポーネント変数＞
または
＜コンポーネント変数＞ ＳＨＡＤＯＷＳ ＜コンポーネント変数＞
この一例を以下に示す。
ＡＰＰＳ＿ＭＯＤＵＬＥＳ＿ＯＭＡＤＭＣＬＩＥＮＴ ＳＨＡＤＯＷＳ ＡＰＰＳ＿ＭＯＤＵＬＥＳ＿ＭＭＳ

以下の表は、本明細書中で説明している一部の用語およびファイル形式についての一般的な非限定的な定義を要約したものである。

図面のうち図２を参照すると、全体的なパッケージ生成プロセスの一部分として、構築プロセス中に、このオペレーティングシステムイメージ、およびコンポーネントツーパッケージマッピングファイル２０６についてのバイナリイメージビルダファイル２０４（．ｂｉｂファイル、パッケージマニフェストファイルとも呼ばれる）を入力として取り込むことによって、構築マニフェストファイル２０２が作成される。上述のようにこの構築マニフェストファイル２０２は、特定のパッケージについてのファイル内容を指定する。

図３は、バイナリイメージビルダファイル２０４からこの構築マニフェストファイル２０２を作成するための構築マニフェストファイル作成プロセス２０８の一例を一般的に示すものである。図３から分かるように、一般に、このバイナリイメージビルダファイル２０４中の各行が解析（ｐａｒｓｅ）される。したがって、（ＸＩＰ（その場で実行）テーブル（ステップ３１０および３１２）中で調べられる）有効なタグを有する．ｂｉｂファイルエントリとして解析される行は、要求どおりに圧縮し（ステップ３１８）、この構築マニフェストファイル２０２に書き込むことができる（ステップ３２０）。

結果の構築マニフェストファイル２０２は、以下のＸＳＤを用いて正当性が確認されるＸＭＬファイルである。

この構築マニフェストファイル２０２を作成した方法と同様にして、このオペレーティングシステムイメージについてのレジストリは、（ＲＧＵファイルと呼ばれることもあるものに）分解され、同様なアルゴリズムに基づいてパッケージに割り当てられる。かかるプロセス２１０（図２）の一例が図４に示され、ここで、適宜それらのレジストリキーネーム（ｒｅｇｉｓｔｒｙ ｋｅｙ ｎａｍｅ）を含めて有効なタグ（ステップ４１４）に関連するレジストリ設定２１２（図２）が、このパッケージＲＧＵファイルに書き込まれる（ステップ４２２）。処理されているパッケージが変化する（ステップ４１８および４２０）ときはいつでも、このレジストリキーネームは、このパッケージＲＧＵファイルに書き込まれることに留意されたい。

さらに、（図２の、例えば他の設定を含めて）ＸＭＬファイル２１８は、分解し特定のパッケージに割り当てることができる。これを行うためのプロセス２２０の一例が、図５に示され、ここで、（ステップ５０８で評価される）子ノードについての有効なタグがこのパッケージのノードに割り当てられる（ステップ５１４）。

このパッケージ作成プロセスのこの中間ステップの結果は、構築されるパッケージごとの図２に示したいくつかのファイルであり、以下のものを含んでいる。

これらのファイルから、（例えば、ＸＳＤ２０３およびＸＳＤ２２５を介した正当性の確認を含めて）パッケージ生成プロセス２３０は、一般的に図６に示すフローチャートに従って最終的なパッケージファイル２３２を構築する。図６に一般的に示されるように、何らかのチェックおよび正当性確認（ステップ６００〜６１０）の後に、各パッケージをこのパッケージ定義にマッピングすること、このパッケージについての構築マニフェストファイル２０８を読み取ること、およびそのデータからこのパッケージを生成すること（ステップ６１８〜６２２）を含めて、パッケージコレクションがこれらのパッケージから作成される（ステップ６１２）。

この構築マニフェストファイルを最終的なパッケージファイルリスト形式へと変換し、（図８を参照して以下で説明するように再配置情報を実行可能ファイルに挿入するツール）ｒｅｌｍｅｒｇｅツール２５０を用いて各実行可能ファイルを処理するプロセスが、図７Ａおよび７Ｂに一般的に示されている。図７Ａおよび７Ｂのステップ７００〜７１４により一般的に示すように、（エラーが発生しなかったと想定すると）指示ファイルが作成され、その構築マニフェストファイルの位置が特定され解析される。その解析が、成功したには（ステップ７１６）、ステップ７２０でデバイスマニフェストオブジェクトが作成され、このプロセスは図７Ｂのステップ７２６へと続行され、これによって、このデバイスマニフェストオブジェクトが、適切に作成されるようになる。

ステップ７３２および７５６により、この構築マニフェストファイル中のリストアップされた各ファイルが処理される。このために、ステップ７３４でこのファイルが見つけられ、ステップ７３８で実行可能かどうかが判定される。実行可能でない場合、このファイルは、そのまま一時構築ディレクトリにコピーされ、実行可能な場合には、このファイルは（ステップ７４０によりテストされたときまだ処理されていない場合には）インストール時にそのデバイス上で実行可能コードの再配置／修正を可能にする（図２で、例えばｒｅｌｍｅｒｇｅ．ｅｘｅと称される）ツール２５０によって処理する必要がある。このファイルが、図８を参照して以下で説明するｒｅｌｍｅｒｇｅ処理を必要とする場合には、ステップ７４４でこのツールが呼び出され、またこれが順調に実行される場合には、このファイル名がこのデバイスマニフェストに追加される。

したがって、図７Ａおよび７Ｂを参照して以上で説明したように、構築マニフェストファイル２０８中にリストアップされた、パッケージ用のファイル内容が検討され、どのような実行可能コードでもそのパッケージに挿入するのに先立って処理して、インストール時にそのデバイス上で実行可能コードの再配置／修正が可能となる。構築マニフェストファイルを最終的なパッケージファイルリスト形式へと変換するために、各実行可能ファイルは、そのファイル中にすでにある再配置情報を圧縮し、（．ＲＥＬファイルが提供される場合には）オプションで、そのオペレーティングシステムがそのコードおよびデータセクションを隣接していないメモリ領域に分離できるようにする、より詳細な再配置情報を提供するｒｅｌｍｅｒｇｅツール２５０を用いて処理される。

このｒｅｌｍｅｒｇｅツールの動作は、図８の流れ図に一般的に示されている。これをまた実行することにより入力ファイルが修正されるので、ステップ８０２に示されるように、入力ファイルのコピーが行われる。したがって、このｒｅｌｍｅｒｇｅツール２５０は、この入力ファイルのコピーを行い、このコピーから作業を行い、このプログラムが終了するとこのコピーは削除される。

署名（ｓｉｇｎａｔｕｒｅ）は、ステップ８０４で取り除かれる。というのは、この署名が、プロセスの後の部分（以下で説明するスペースアカウンティングチェック（ｓｐａｃｅ ａｃｃｏｕｎｔｉｎｇ ｃｈｅｃｋ））を失敗させるからである。このツール２５０は完全に異なるファイルを出力していることになるので、この署名は、どのようなイベントにおいてもこの出力ファイルに対する何の関連性ももたないことに留意されたい。ポータブルな実行可能ファイル（．ＥＸＥファイルおよび．ＤＬＬファイルについてのファイルフォーマット）においては、その署名は、ファイル中の任意のセクションの外側にあるこのファイルの末尾に格納され、ここで、各セクションは、ローダがメモリにデータをロードするために用いるユニットに対応する。各セクションには、Ｏ３２ヘッダと呼ばれ、またはＩＭＡＧＥ＿ＳＥＣＴＩＯＮ＿ＨＥＡＤＥＲ構造を用いて識別されるヘッダがある。ステップ８０６によって一般的に示されるように、このファイルの操作を容易にするために、このツール２５０は、このＰＥファイルについてのＰＥファイルヘッダとそのセクションを解析して適切な内部データ構造に入れる。このＩＭＡＧＥ＿ＳＥＣＴＩＯＮ＿ＨＥＡＤＥＲ構造は、イメージセクションヘッダフォーマットを表す（このＩＭＡＧＥ＿ＳＥＣＴＩＯＮ＿ＨＥＡＤＥＲについてのさらなる詳細については、ｍｓｄｎ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍで見出すことができる）。

ファイルが、新しいヘッダを付けてパッディングを除去して再配置されることになるので、スペースアカウンティングチェック（ステップ８０８）を実施してこのファイルのセクション内に含まれないファイル中には情報がないことを検証する。（ツール２５０によって処理される）ファイル署名およびコードビュー（Ｃｏｄｅｖｉｅｗ）デバッグディレクトリエントリを含めて、データが、このセクションの外側の．ＥＸＥファイルまたは．ＤＬＬファイルに格納される状況も存在することに留意されたい。抽出すべきデータを．ＥＸＥ自体の後に格納する自己抽出実行可能ファイル（ｓｅｌｆ−ｅｘｔｒａｃｔｉｎｇ ｅｘｅｃｕｔａｂｌｅ ｆｉｌｅ）などセクションの外側にデータを格納することができる他のアプリケーションも存在する。圧縮されたデータは、セクション内には格納されず、そうでなければ、ローダは、この圧縮されたデータをメモリにロードしようと試みるがこれは、どのようにして自己抽出実行可能ファイルが動作すべきかということではない。このツールは、これらのインスタンスをサポートしない。

スペースアカウンティング（Ｓｐａｃｅ Ａｃｃｏｕｎｔｉｎｇ）は、それぞれがこのファイル中のデータブロックからなるスペースブロック（ＳｐａｃｅＢｌｏｃｋ）構造のアレイを保持するＣＳｐａｃｅＡｃｃｏｕｎｔｉｎｇクラスのインスタンスによって実装される。スペースアカウンティングを実装するために、占めることが可能なファイル中の領域が、個々のブロックとしてこのＳｐａｃｅＡｃｃｏｕｎｔｉｎｇに追加される。これは、（Ｅ３２ヘッダおよびＯ３２ヘッダを含めて）ファイルヘッダおよびファイル中のセクションごとに行われる。ＣｏｄｅＶｉｅｗデバッグエントリを受け入れることができるようにするために、これらのそれぞれも別個のブロックとして追加される。次いでこれらのブロックは、ファイル内でオフセットによってソートされる。（例えば、ブロック２は、ブロック１の最後のバイトの直後のバイト上から開始される）新しい順序で隣接するブロックがマージされる。このプロセスの終わりで、ファイル中のすべての空間を占有することができる場合には、このリストは、オフセット０から開始され、全体ファイル長の長さを有するたった１つのブロックのみを含むようにしなくてはならない。この条件が真である場合には、このテストはパスする。そうでない場合には、エラーが報告されこのツールは終了する。

このスペースアカウンティングチェックがパスする場合には、ステップ８１０で示されるように、このツール２５０は、この入力ファイルが指定される同じディレクトリ中の．ＲＥＬファイルを探索する。存在する場合には、このプロセスは、ステップ８１２で処理され、そうでない場合には、このＰＥファイルの再配置セクションがステップ８１４で処理される。より詳細には、この再配置解析ツールは、２つの異なる種類の再配置情報、すなわち、宛先セクション情報を含む．ＲＥＬファイル中の再配置情報と、宛先セクション情報を含まないＰＥファイルの．ｒｅｌｏｃセクション中の再配置情報とを解析することができる。この目的のために、再配置解析は、ＰＥファイル中の．ＲＥＬファイルまたは内部再配置のどちらかを解析することに対応する２つのエントリポイントを有する。しかし現在の実装においては、一方または他方のいずれかを呼び出すことは正当であるが、両方を呼び出すことは正当ではない。

この再配置を記憶するためにＣＲｅｌｏｃＤａｔａクラスの２次元アレイが保持され、ここで、２次元のこのアレイは、該当する再配置についてのソースセクションおよび宛先セクションである。再配置についてのソースセクションは、その再配置が配置されるセクションであり、ここで、再配置は、このファイルを修正して特定のアドレスにロードするときにこのファイル中の特定のデータの一部分を更新するための命令である。したがって、このソースセクションは、データの一部分がどのセクション内で存在するかを識別する。ソースセクションは、再配置の相対仮想アドレスを調べ、これをこのファイル中のセクションの相対仮想アドレス範囲と比較することによって推論される。

再配置についての宛先セクションは、どのセクションがこの再配置が指しているデータの一部分を含んでいるかを識別する。オプティマイザはこの再配置が他のセクションを指すように見えるようにしてコードを最適化することが知られているので、検査技術が常に機能するわけではない。例えば、オプティマイザは、加算または減算を最適化し、それをコード中ではなくリファレンス中に配置することになる。この理由から、この宛先セクションは、データから推論されない。この２つの再配置フォーマット（．ＲＥＬまたは．ｒｅｌｏｃ）の間の差は、この再配置についての宛先セクションが知られているかどうかである。この．ＲＥＬファイルは、明示的にこの宛先セクションを識別するが、この．ｒｅｌｏｃセクションは、そうではない。

その結果、この．ｒｅｌｏｃセクション中の再配置情報しかもたないファイルでは、その全体ファイルを一緒に再配置する必要がある。宛先セクション情報なしには、２つのセクションを分離しそれらを異なる量だけ再配置することはできない。したがって、このツールでは、再配置ごとにソースセクションと宛先セクションの両方を追跡し、これらの宛先セクションが有効であるかどうかを追跡する必要がある。

これを行うために、このプロセスは、ＣＲｅｌｏｃＤａｔａクラスの２次元アレイを保持し、各ＣＲｅｌｏｃＤａｔａクラスは、再配置データのそれ自体のストリームを構築する。このアレイは、両次元でサイズが固定されており、これは、このツールがある最大の（例えば、１６の）セクションをもつＰＥファイルしか処理できないことを意味している。この制限により、再配置を持続するためのデータフォーマットは、ソースセクションおよび宛先セクションごとに８ビットを格納し、２５６セクション用のデータフォーマットでは可能性が残される。次いで、他の２つの関数（ＣａｌｃｕｌａｔｅＲｅｌｏｃＳｉｚｅおよびＷｒｉｔｅＲｅｌｏｃａｔｉｏｎｓＴｏＦｉｌｅ）が、少なくとも１つの再配置を有するソースセクションと宛先セクションの組合せごとにブロックヘッダを書き出すことによって、これらの個別のストリームを組み合わせる。

再配置符号化（Ｒｅｌｏｃａｔｉｏｎ ｅｎｃｏｄｉｎｇ）は、ＣＲｅｌｏｃＤａｔａクラスにおいて実装される。このクラスは、再配置アドレスのストリームを（このＣＲｅｌｏｃＤａｔａ：：ＡｄｄＲｅｌｏｃメソッドに対する個別の呼び出しとして）取得し、これらの再配置を符号化するために必要なコマンドを表すバイトストリームを作成する。そのバイトストリームは、後で取り出すことができる。これを実装するために、このクラスは事実上１コマンド後にとどまり、常に「シングル（Ｓｉｎｇｌｅ）」コマンドを用いて開始され、単一の再配置を表す。次いで、（ＡｄｄＲｅｌｏｃメソッドで）新しい再配置が到達するときに、これらの再配置を分析して、前のコマンドおよび新しいロケーションを使用して、パターンを形成することができるかどうかを調べる。この前のコマンドが「シングル」コマンドである場合には、この前のコマンドは、この新しい再配置アドレスがＤＷＯＲＤ整列され、パターンコマンドの（３ＤＷＯＲＤとなる）最大スキップ範囲内にある場合には、この前のコマンドを「シングル」コマンドから「パターン（Ｐａｔｔｅｒｎ）」コマンドへと変換することによってしか拡張できない。この前のコマンドがパターンコマンドである場合には、そのパターンはすでに、確立済みの形式を有しており、このパターン中の次の要素を演繹することができる。その新しいアドレスが、そのパターン中の次のエレメントとたまたまマッチングする場合には、そのパターンは、１サイクルで拡張される。そうでない場合には、新しいシングルコマンドが開始される。

図８の全体フローに戻ると、このファイルのセクションがヘッダに続くファイル中で線形的に生じるので、ファイル全体を再配置して新しいヘッダフォーマット、およびこれらセクション間のすべてのパディングの除去に対応できるようにする必要がある。このためには、ステップ８１８によって表されるように、（存在する場合には）古い．ＲＥＬＯＣセクションが除去され、追加すべき再配置が何か存在する場合には、新しい．ＣＲＥＬＯＣセクションが末尾に追加される。ステップ８１８において完成されたファイルレイアウトを使用して、ステップ８２０でこの出力ファイルが最終的に作成され、この出力ファイルに対してセクションごとにヘッダ、次いでそのデータが書き込まれる。

ステップ８２２で、ここでｒｅｌｍｅｒｇｅ．ｅｘｅは、ターゲット出力ファイルがｎｋ．ｅｘｅであるかどうかをテストし調べる。この出力ファイルがｎｋ．ｅｘｅである場合には、ｒｅｌｍｅｒｇｅツール２５０は、２つのファイルの内容を処理して（以下で説明する）ｐＴＯＣ情報およびＲｏｍＥｘｔ情報を書き出す。ｒｅｌｍｅｒｇｅツール２５０は、デバッグ設定に基づいて異なるファイルをコピーすることによってｎｋ．ｅｘｅが作成されるので、その出力ファイルを調べる。処理される第１のファイルは、ｃｏｎｆｉｇ．ｂｓｍ．ｘｍｌである。このファイルは、イメージ更新（Ｉｍａｇｅ Ｕｐｄａｔｅ）処理中にＭａｋｅＰｋｇ．ｅｘｅによって生成される。このファイルは、システムカーネル中のＦＩＸＵＰＶＡＲについての名称および所望の値のテキスト表現を含んでいる。このファイルの内容は、後で使用するために解析され記憶される。第２のファイルは、入力ファイルについてのマップファイルである。このファイルは、ＰｒｏｃｅｓｓＦｉｘｕｐＶａｒによって処理される。このファイルは、ソースファイルパス（ｓｏｕｒｃｅ ｆｉｌｅ ｐａｔｈ）を取得し、それをコピーし、．ｅｘｅを．ｍａｐで置き換え、このマップファイルをオープンしようと試みる（マップファイルは、ＰＥファイル内のファンクションおよび変数の物理アドレスおよび仮想アドレスについての大量の情報を含むテキストファイルである）。このマップファイルが正常にオープンされる場合には、この第１の行を解析してこのマップファイルのタイムスタンプが取り出される。次いで、このタイムスタンプは、ＰＥファイル中のタイムスタンプと比較される。これらが異なる場合には、警告が作成され、マップファイル処理が停止される。これらのタイムスタンプが一致する場合には、このファイルの各行が読み取られ、正規表現ストリングを使用して各ＦＩＸＵＰＶＡＲが探索される。マッチが見出される場合、アドレス情報がそのマップファイルから取得され、このアドレス情報を使用して（ｃｏｎｆｉｇ．ｂｓｍ．ｘｍｌからの）この新しい変数値が正しい位置のソースファイル中に書き込まれる。同時に、ＰｒｏｃｅｓｓＦｉｘｕｐＶａｒはまた、後で処理するためにｐＴＯＣ（ここで、ＴＯＣは、内容テーブルを表す）およびＲｏｍＥｘｔ変数も探索する。ｐＴＯＣが見出されると、新しい．ｃｒｅｌｏｃヘッダが、（１ベースから０ベースに調整された）マップファイルから取り出されたセクションに対して設定されたｂＳｒｃＳｅｃｔｉｏｎ、２５４に設定されたｂＤｓｔＳｅｃｔｉｏｎ、および４という長さを用いて作成される。このヘッダは、４バイトのＲＶＡ＋Ｂａｓｅアドレス情報が続くターゲットファイルに書き込まれる。ＲｏｍＥｘｔについては、ヘッダは、ｂＳｒｃＳｅｃｔｉｏｎが２５３に設定される点以外は同じである。

このｐＴＯＣ／ＲｏｍＥｘｔ解析動作は、オペレーティングシステムカーネルが、ｐＴＯＣ変数を通じて提供されるＲＯＭ中のファイルについての情報を必要とするので使用される。この変数は、デバイス上で実行されるＤｉｓｋＩｍａｇｅツールおよび更新アプリケーションによって更新する必要がある。この変数についての情報は、システム構築のコンパイルおよびリンクのフェーズ中に作成される．ＭＡＰファイルを介してのみ取り出すことができる。このファイルを解析してこの情報が取り出される。

ある種の実行時ツールは、カーネルデータ構造内で宣言される変数にアクセスする必要がある。この変数は、ＲｏｍＥｘｔと名づけられている。この変数は、このデバイス上で実行されるＤｉｓｋＩｍａｇｅツールおよび更新アプリケーションによって更新する必要がある。この変数についての情報は、システム構築のコンパイルおよびリンクのフェーズ中に作成される．ＭＡＰファイルを介してしか取り出すことができず、したがって、このファイルを解析してこの情報が取り出される。

本発明の一態様によれば、パッケージを自己記述型にするために、（図２に、より詳細には図９に示される）デバイスマニフェストファイル２６０が、そのパッケージングプロセス中に作成され、そのパッケージ自体に格納される。このデバイスマニフェストファイル２６０は、そのインストレーションプロセス中に使用される。このデバイスマニフェストファイル中に含まれるフォーマットおよび情報は、図９に示され、また以下に示すこの構造定義を用いて記述される。

一実施例においては、上述のように、デバイスマニフェストファイルの内容がそのｐｋｄファイル情報、および（処理された後にｐｓｆファイル２８０と呼ばれる）処理済みのｃｒｆファイル情報、ならびに（例えば、ファイルリストおよび属性情報についての）構築マニフェストファイルから導き出される。このｃｒｆファイルは、コンポーネントレベルの依存性を記述し、パッケージレベルの依存性を記述する形式へと処理される。

さらに、コンポーネント設定（構成情報）は、互いに他方をシャドウすることができる（換言すれば、２つの関連する設定が一方しか勝ち残らないようにそのシステム上に存在するイベント中における優先順序がある）。このコンポーネントレベルでの依存情報およびシャドウ情報は、シャドウ順序ツールを介してパッケージレベル関係へと変換される。

このシャドウ順序ツールは、コンポーネント関係ファイル２２６（図２）に従って他のパッケージをシャドウする、パッケージごとのパッケージシャドウファイル（ｐａｃｋａｇｅｎａｍｅ．ｐｓｆ）を作成する。あるパッケージについての．ｐｓｆファイルは、シャドウされたパッケージの（行当たり１つの）ＧＵＩＤをリストアップする。このシャドウ順序ツールの入力は、パッケージマッピングファイル（．ｃｐｍ）へのマージされたコンポーネント、マージされたコンポーネント関係ファイル（．ｃｒｆ）、およびマージされたパッケージ定義ファイル（．ｐｋｄ）である。この出力は、以下に示す形式のフォーマットされたテキスト行を含むテキストファイルである。
＜シャドウされたｐｋｇ ＧＵＩＤ＞，＜シャドウされたｐｋｇ名＞，＜ルール＞
（ここで、ルール＝ＳＨＡＤＯＷＳまたはＤＥＰＥＮＤＳＯＮ）．
行の一例を以下に示す。
２７３ｃｅ４ｂｆ−ｄ４ｅｆ−４７７１−ｂ２ｃｅ−６ｆｅ２ｆａ２ｂ２６６６， ＳＭＡＲＴＦＯＮ， ＳＨＡＤＯＷＳ

この情報から、このパッケージジェネレータは、デバイスマニフェストファイル生成プロセス２６２によって、図２に示され、図１０Ａおよび１０Ｂに一般的に説明されるデバイスマニフェストファイルを作成する。この目的を達成するために、図１０Ａのステップ１０１０で一般的に表されるように、．ｐｓｆファイル中の各ＧＵＩＤが、このデバイスマニフェストファイルに追加される。一実施例においては、これは、ＧＵＩＤが依存性ＧＵＩＤであるかまたはシャドウＧＵＩＤであるかどうか判断し、デバイスマニフェストオブジェクト上で適切な追加ファンクションを呼び出す工程を含んでいることに留意されたい。このＧＵＩＤが、追加されたときには、そのデバイスマニフェストオブジェクトは、図１０Ｂのステップ１０３０で一般的に表されるように、デバイスマニフェストファイルをその一時ディレクトリに書き込む。

図１１に説明しているように、パッケージファイル２３２は、ＣＡＢファイルＡＰＩ（ＣＡＢＡＰＩ）などのパッケージファイル作成プロセスを使用して他のパッケージ内容２８２とともに、この指示ファイル中に記述された処理済みのファイル、すなわちｒｇｕファイル２１４、ｘｍｌファイル２１８およびデバイスマニフェストファイル２６０を含めて作成される。このＣＡＢＡＰＩでは、イメージ更新プロセスの一部分としてのイメージ更新中に含まれるファイルについてのトランスポートメカニズムとして使用されるキャビネットファイル（Ｃａｂｉｎｅｔ ｆｉｌｅ）の内容に対するアクセスを実現することが意図されている。

このパッケージを作成するために、ＰａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎクラスは、パッケージの全体的な作成を管理する役割を果たす。この作成プロセスの一部分として、このＰａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎオブジェクトは、「＿ＦＬＡＴＲＥＬＥＡＳＥＤＩＲ」環境変数が指定するディレクトリの下の新しいサブディレクトリを作成する。このディレクトリ名は、それにストリング「＿ＰＡＣＫＡＧＥ＿ＦＩＬＥＳ」が付加されたパッケージ名であり、例えば、「ＬＡＮＧ」と名付けられたパッケージを想定すると、「ＬＡＮＧ＿ＰＡＣＫＡＧＥ＿ＦＩＬＥＳ」と名付けられたディレクトリが生成されるであろう。ＳｅｔＤｉｒｅｃｔｏｒｙＢａｓｅメソッドがこのオブジェクト上で呼び出されるとき、このディレクトリが作成される。このＰａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎオブジェクトがパッケージを作成するとき、その結果得られるパッケージファイルの名前は、「．ＰＫＧ」拡張子をもつパッケージの分かりやすい名前である。このパッケージファイルは、マイクロソフトＣＡＢファイル仕様のＣＡＢバージョン１．３に準拠している。

このＰａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎクラスは、以下のパブリックメソッド（ｐｕｂｌｉｃ ｍｅｔｈｏｄ）を提供する。
・ＰａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎ（ ＸｉｐＰａｃｋａｇｅ ｐｋｇ ）−ＸｉｐＰａｃｋａｇｅオブジェクトに基づいてパッケージを作成するコンストラクタ（ｃｏｎｓｔｒｕｃｔｏｒ）。
・ＳｅｔＤｉｒｅｃｔｏｒｙＢａｓｅ（ ｓｔｒｉｎｇ ｐａｔｈ ）−指定されたディレクトリの下に新しいサブディレクトリを作成する。
・Ｖａｌｉｄａｔｅ（ ）−パッケージが、２つの必要なフィールド、すなわち名前およびＧＵＩＤを有するかどうかを判定する。
・ＲｅａｄＭａｎｉｆｅｓｔ（ ）−このパッケージに関連するＢｕｉｌｄＭａｎｉｆｅｓｔに適切な構築マニフェストファイルを解析させる。
・ＭａｋｅＰａｃｋａｇｅ（ ）−このパッケージ定義についての実際のパッケージファイルを作成する。

さらに、そのパッケージ中に含めるために様々なファイルを用いて作業をする際には、実行可能コードおよびデータを別々のファイルに配置することができることに留意されたい。その１つの重要な利点は、多言語システムを容易にすることであり、ここで、機能の言語特有の部分は、言語特有な別々のパッケージに配置される。これは、このシステムの実行可能コードを含むパッケージがこのシステムの言語特有のコンポーネントを含むパッケージから分離されるシステムを作る。その結果、デバイス上にインストールされる言語のどのような組合せからも独立して、機能の実行可能コードについてのパッチを任意のデバイスに対して適用することができる。

より詳細には、構築によってある機能が構築されるとき、その実行可能コード（および言語に独立なデータ）は、１組のファイルの中に分離され、その言語依存のデータは（および場合によってはコードも）別の組のファイルの中に分離される。これらのファイルは、機能の一部分であるものとしてタグ付けされるが、言語依存のデータファイルは、さらに言語依存のものとしてタグ付けされる。次いで、このシステムは、（例えば、そのｐｋｄファイル中のＬｏｃＢｕｄｄｙタグによって記述される）別のパッケージへこれらのファイルを移動させる。

一例として、電話ベースの機能が、言語に独立のライブラリ（例えば、ｔｐｃｕｔｉｌ．ｄｌｌ）中に存在することもある。この電話機能についてのこの言語依存のリソースは、言語ごとにさらにローカライズされた、例えばｔａｐｒｅｓ．ｄｌｌと名付けられる別のリソースｄｌｌ中に構築され、例えば、それは、（米国英語についての）ｔａｐｒｅｓ．ｄｌｌ．０４０９．ｍｕｉ、（ドイツ語についての）ｔａｐｒｅｓ．ｄｌｌ．０４０７．ｍｕｉなどとなる。これらのファイルは、電話機能の一部分としてタグ付けされるが、これらの言語特有のファイルはさらに言語特有なものとして適切なファイル名を用いてタグ付けされる。例えば、ファイル名は、ｔａｐｒｅｓ．ｄｌｌ．％ＬＯＣＩＤ％．ｍｕｉによって表されるものなど、その名前の中のロケーションベースの変数に適切な言語タグを置き換えることによって構築することができる。次いで、このファイルは、サポートされる言語ごとに処理され、複数のＬＡＮＧＰＨＯＮＥ（ｌｏｃｂｕｄｄｙ）パッケージ、例えば、（米国英語についての）ＬＡＮＧＰＨＯＮＥ＿０４０９、（ドイツ語についての）ＬＡＮＧＰＨＯＮＥ＿０４０７などが生成される。その結果、このシステムでは、どの言語が、（異なるＬＡＮＧＰＨＯＮＥ＿ｘｘｘｘパッケージによって）その電話にインストールされるかとは独立に、ｔｐｃｕｔｉｌ．ｄｌｌ中のバグ取りをするなどＬＡＮＧＰＨＯＮＥ領域を後で更新することができる。

さらにこのシステムの柔軟性は、言語特有の実行可能コードが必要なところで可能となるようなものである。例えば、異なる言語および場所（ｌｏｃａｌｅ）は、その言語でテキストを取り込むために使用される異なる入力方式エディタ（ＩＭＥ）を有する。これらのＩＭＥは、言語ごとに特別のコードを必要とし、したがってＬＡＮＧ領域のうちの１つの内部に配置される。

最後に、キャビネット検証を実施できることに留意されたい。このキャビネット検証モジュールは、最終的なパッケージファイル２３２（キャビネットファイル）からデバイスマニフェストファイル２６０を抽出し、デバイスマニフェスト２６０の内容に対してこのキャビネットファイルを検証する。

前述の詳細な説明から分かるように、オペレーティングシステムイメージの何らかのサブセットの更新を容易にする様々なメカニズムが提供される。自己記述型のパッケージファイルは、直接的にイメージを更新し訂正する、依存性、シャドウおよび他の機能を含めて提供される。

本発明は、様々な変更および代替的な構成を受け入れることが可能であるが、本発明の特定の例示的な実施形態について図面中で示し、以上で詳細に説明してきた。しかし、本発明を開示の特定の形態に限定する意図はなく、それとは逆に、本発明は、本発明の趣旨および範囲内に含まれるすべての変更形態、代替構成形態、および等価形態を包含することを意図していることを理解されたい。

本発明を組み込むことができるコンピュータシステムを一般的に示すブロック図である。 本発明の一態様による、自己記述型更新パッケージを構築するための様々なコンポーネントを表すブロック図である。 本発明の一態様による、バイナリイメージファイルから構築マニフェストファイルを作成するためのロジックを表す流れ図である。 本発明の一態様による、レジストリ設定からレジスト設定関連ファイルを作成するためのロジックを表す流れ図である。 本発明の一態様による、ＸＭＬ形式ファイルを処理してそのファイルからのデータをパッケージに書き込むためのロジックを表す流れ図である。 本発明の一態様による、パッケージを生成するためのロジックを表す流れ図である。 本発明の一態様による、パッケージを記述するデバイスマニフェストファイルを作成するためのロジックを表す流れ図の一部である。 本発明の一態様による、パッケージを記述するデバイスマニフェストファイルを作成するためのロジックを表す流れ図の一部である。 本発明の一態様による、実行可能ファイルのための再配置情報を挿入するツール（ｒｅｌｍｅｒｇｅ）が実行するロジックを表す流れ図である。 本発明の一態様による、パッケージを記述するデバイスマニフェストファイルのフォーマットを表すブロック図である。 本発明の一態様による、パッケージを記述するデバイスマニフェストファイルを構築するための流れ図である。 本発明の一態様による、パッケージを記述するデバイスマニフェストファイルを構築するための流れ図である。 本発明の一態様による、パッケージの作成を表す流れ図である。

符号の説明

１２０ ハンドヘルドコンピューティング装置
１２２ プロセッサ
１２４ メモリ
１２６ タッチスクリーン付きディスプレイ
１２８ キーボード
１２９ マイクロフォン
１３０ ＯＳ
１３２ アプリケーションプログラム
１３４ 通知マネージャ
１３６ ネットワークＳＷ
１３８ ネットワークコンポーネント
１４０ 電源
１４２ ＬＥＤ
１４４ オーディオジェネレータ

Claims (32)

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. 前記パッケージ生成プロセスは、少なくとも一部の実行可能コードが任意の言語から独立であるように少なくとも一部の実行可能コードとデータの間で区別を可能とすることを特徴とする請求項２４に記載のシステム。

Images