JP2005129028A - コンポーネント用として言語独立ファイル及び対応する言語特有リソースファイルを作成する方法 - Google Patents

Abstract

【課題】 アプリケーションまたはオペレーティングシステムをより効率的に作成／使用可能とする。
【解決手段】 この二分岐構造は、アプリケーションのより容易な配布及び更新を可能にし、一方、縮小されたファイルの組により、より効率的なファイル管理が実現される。コンパイル段階の間にリソースマニフェストを指定し、言語特有である要素と言語独立のままである要素とを識別する。複数のローカライズ可能要素を単一のファイルの形に圧縮するために、コンパイル後に追加ソフトウェアを使用する。そのような圧縮ソフトウェアは、より大きなファイル群の形に圧縮すべき言語特有リソース群とそれらのより大きなファイル群の識別を指定する入力を受け取る。複数の言語特有リソースを含むことができる、また、関連の言語独立コードによる個々の言語特有リソースの取出し及びアクセスを容易にすることができるファイルフォーマットを使用する。
【選択図】 図５

Description

本発明は、コンポーネント用として言語独立ファイル及び対応する言語特有リソースファイルを作成する方法に関する。より詳細には、一般に、コンピュータアプリケーション及びオペレーティングシステムに関し、機能コード及び言語独立データをローカライズ可能なユーザインタフェース（ＵＩ）リソースから別個に記憶しているアプリケーションまたはオペレーティングシステムをより効率的に作成／使用するための、コンポーネント用として言語独立ファイル及び対応する言語特有リソースファイルを作成する方法、記録媒体、及びコンポーネント所有者がコンポーネントリソースローカライズ情報を提供するための方法に関する。

コンピュータが世界中で普及するにつれて、様々な言語及び／または場所向けに最適化またはローカライズされた様々なバージョンのオペレーティングシステムまたはアプリケーションがますます求められており、同様に、大量のそのような異なるバージョンを制作し、更新し、維持することに伴うオーバーヘッドコストも増加している。オペレーティングシステムは、一般に、コード、データ、言語特有のＵＩリソースを共に単一のバイナリエントリ内に含んでおり、その結果、どの部分を修正することも、全体を更新することを必要とする。したがって、セキュリティパッチに続くものなど、更新は、当該の各言語について提供しなければならない。これは「ローカライズ」と呼ばれ、得られた各バージョンは、「ローカライズ（された）」バージョンと呼ばれる。変更が必要とされる大多数の場合では、言語特有の部分ではなくコード部分で変更が行われ、大抵のフィックス、更新などの別個のローカライズバージョンを制作することは、無駄が多く、またコストがかかる。さらに、セキュリティフィックスを発行する際など迅速な更新応答が必要とされるとき、多数の異なる、特別にローカライズされたバージョンのフィックスを制作することが必要であるために引き起こされる遅延は、許容できない時間の間、ユーザを保護されないままにする可能性がある。そのような状況ではしばしば、一般に、より優先順位の高い場所向けのローカライズバージョンが最初に制作されるため、優先順位の低い場所のユーザに遅延が集中する。

１つの解決策は、言語に依存しないコード及びデータを言語特有のデータから分離し、それにより、セキュリティパッチなどを含めた修正を、その言語に依存しないコード及びデータに対してのみ加えることができるようにすることであろう。このようにして、単一のセキュリティパッチを迅速かつ効率的に開発して世界中に配布する一方、オペレーティングシステムやアプリケーションのローカライズバージョンの製造を変更しないでおくことを可能にすることができるはずである。そのような解決策は、２００３年５月１２日に出願された「Ｂｉｆｕｒｃａｔｅｄ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｈａｖｉｎｇ ａ Ｌａｎｇｕａｇｅ Ｎｅｕｔｒａｌ Ｃｏｍｐｏｎｅｎｔ」という名称の、米国特許出願第１０／４３５，８４８号により詳しく述べられている。

残念ながら、別個の言語独立コンポーネント及び言語特有のコンポーネントを提供する解決策では、比較的少ない市場向けにローカライズされているだけの比較的単純なアプリケーションについても、管理不能なほど大量のファイルがすぐに発生する可能性がある。約５００のコンポーネントファイルを有する単純なアプリケーションでも、欧州市場向けにアプリケーションをローカライズするためだけに５０００を超える対応する言語特有のコンポーネントファイルを必要とする可能性がある。そのような大量のファイルは、新しいバージョンやパッチを効率的にコンパイルし配布する能力を著しく低下させる可能性がある。さらにより重要なことには、大量のファイルは、言語独立ファイルと１つまたは複数の言語特有のファイルという２つ以上のファイルをロードすることを必要とすることにより、アプリケーションまたはオペレーティングシステムの性能に悪影響を及ぼす可能性がある。さらに、セキュリティ侵害や他の悪意あるコードに対して大量のファイルを保護するために、追加のリソースを費やさなければならない。最後に、多数の現代のオペレーティングシステムは、仮想メモリを６４キロバイトの細分性で、また、物理メモリを４キロバイトの細分性で割り振るため、６４キロバイトより小さい多数のファイルをロードすることは、仮想メモリを無駄にし、断片化することになる。４キロバイトより小さいファイルは、仮想メモリにも物理メモリにも影響を及ぼすため、さらに負の作用があることになる。オペレーティングシステムが、少なからぬ量の（すなわち、４００を超える）４キロバイト未満のサイズのファイルを有することは珍しくない。

従来のシステムには上述したような種々の問題があり、さらなる改善が望まれている。
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、アプリケーションまたはオペレーティングシステムをより効率的に作成／使用可能とする、コンポーネント用として言語独立ファイル及び対応する言語特有リソースファイルを作成する方法を提供することにある。

本発明の諸実施形態は、コード及び非ローカライズ可能データに関する言語独立部分と、アプリケーションまたはオペレーティングシステムによって使用される、または使用可能にされるローカライズ可能なリソースに関係する言語特有部分とを有するアプリケーションまたはオペレーティングシステム、ならびにそれらに対する「フィックス（fix）」（たとえば、アプリケーションまたはオペレーティングシステムのリリース後に配布されるパッチ及び更新）の制作を可能にする。言語特有部分に対応するファイルの数を最小限に抑えるために、複数の言語特有部分を記憶し、単一のファイル構造からアクセスすることができる。

一実施形態では、複数の言語特有コンポーネントを単一のバイナリファイルの形に組み合わせるために、リソースツールが提供される。リソースツールは、どの言語特有コンポーネントを単一のファイルの形に組み合わせるべきであるかを指定する構成入力を受け入れることができ、適切な組合せファイルを生成することができる。

他の実施形態では、複数の言語特有コンポーネントを単一のバイナリファイルの形に組み合わせるために、ファイルフォーマットが提供される。このファイルフォーマットは、個々の言語特有コンポーネントに対するアクセスを可能にし、言語特有コンポーネントそれぞれの完全性を維持する。

他の実施形態では、適切なファイルを突き止めること、及びそのファイル内で適切なリソース位置を突き止めることを含めて、言語特有リソースを利用するコードが適切なリソースを突き止めることができるような言語特有リソースロケーションサービスを提供するように、マニフェスト（manifest）が適合される。さらに、マニフェストは、どのリソースをローカライズすることができるか、また、どれが言語独立のままであるべきか判定し、記録する機会を開発者に提供することができる。リソースローディングは、本発明の一実施形態において、リソースを突き止め、ロードするとき、マニフェストを使用するように適合される。

他の実施形態では、ワシントン州レドモンドのマイクロソフトによるＷｉｎｄｏｗｓ（登録商標）リソースコンパイラ（ＲＣ．ＥＸＥ）などが、マニフェスト情報を読み取るように、また、それに応じて言語独立リソースと言語特有リソースを別個のリソースファイル、たとえば．ｒｅｓファイルの形にコンパイルするように更新される。このようにして、次いでリンカは、１つは言語独立データ及び機能コード用、もう１つはローカライズ可能リソース用という別個のＰＥバイナリの形に言語独立リソースと言語特有リソースをリンクすることができる。次いで、ローカライズ可能リソースをさらに単一または複数のファイルの形に組み合わせ、ファイル管理サービス及び動作の効率を高めることを可能にすることができる。

本明細書における説明は、主に二分岐されたオペレーティングシステムの作成及び使用に焦点を合わせるが、本明細書で述べられている二分岐の原理及び利益の多くは、オペレーティングシステムでないアプリケーションにも当てはまることを理解されたい。したがって、本発明の他の諸実施形態では、実質的に言語独立部分とローカライズ可能部分を有する二分岐されたアプリケーションが企図されている。本発明の追加の特徴及び利点は、添付の図を参照しながら進む以下の例示的な実施形態の詳細な説明から明らかになる。

添付の特許請求の範囲は、本発明の特徴について具体的に述べているが、本発明とその目的及び利点は共に、添付の図面と共に取り上げる以下の詳細な説明からよりよく理解することができる。

本発明によれば、アプリケーションまたはオペレーティングシステムをより効率的に作成／使用できる。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。言語特有の機能を提供するためにオペレーティングシステムまたはアプリケーションと共に配布される、またはそれらによって使用される個々の言語特有ファイルの数を最小限に抑えるために、いくつかの要素を使用することができる。まず、言語特有とすることができるデータに関して判定を行うことができる。たとえば、ユーザに提示されるダイアログボックスは言語特有とすることができ、同様に、メニューチョイス、またはスペルチェックオプションを言語特有とすることができる。そのような判断は、マニフェスト内に記載することができ、マニフェストは、コンパイル段階の一部として、言語特有データ及び言語独立コード／データと共に１つまたは複数のオブジェクトファイル及びリソースの形にコンパイルすることができる。

コンパイル段階の後で、リンク用ツールを介してオブジェクトファイル及びリソースを共にリンクし、言語特有リソース／情報を含む移植可能な実行可能ファイル及び個々のリソースファイルを作成することができる。リソースツールは、言語独立コードファイル及び実行可能プログラムが個々の言語独立リソースを依然として参照することができるように、複数の言語特有ファイルを１つまたは複数のより大きなファイルの形に組み合わせることができる。リソースツールはまた、組み合わせるべき正確な言語特有ファイルを指定する、また、得られたより大きなファイルまたはファイル群を識別することができる外部入力を受け取ることができる。

様々な言語特有コンポーネントを単一のファイルの形に圧縮することができる方法は、リソースコンパイラに対する修正など、コンパイル段階に対する修正を含むことができ、また、現在圧縮されている言語特有ファイルを言語独立コード／データが依然として参照することができるように設計された事前定義済み構造を使用して、指定された言語特有コンポーネントを単一のファイルの形に圧縮する圧縮アプリケーションなど、追加のソフトウェアの使用を含むことができる。様々な言語特有コンポーネントを単一のファイルの形に圧縮することができる方法はまた、言語特有コンポーネントを単一のファイルの形に組み合わせるかどうかを含めて、言語独立コード／データと言語特有コンポーネントの間の関係を指定するリソースマニフェストに対する参照を含むことができる。

下記の説明は、コンピューティング環境、コード及びデータを言語独立コンポーネントと言語特有コンポーネントに分割すること、複数の言語特有ファイルを単一のファイルの形に圧縮すること、及び、そのような圧縮を可能にするための様々な機構に対して（これらの機構によって使用されるリソースマニフェストの説明を含めて）提供される情報に関して、さらなる詳細を提供する。

コンピューティング環境
同じ参照番号が同じ要素を指す図面に転じると、本発明が、好適なコンピューティング環境内で実施されて示されている。必要とされてはいないが、本発明について、パーソナルコンピュータによって実行される、プログラムモジュールなどコンピュータ実行可能命令の一般的な状況で述べる。一般に、プログラムモジュールは、特定のタスクを実行する、あるいは特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサをベースとする、またはプログラム可能な家庭用電化製品、ネットワークＰＣ（personal computer）、ミニコンピュータ、メインフレームコンピュータなどを含めて、他のコンピュータシステム構成と共に本発明を実施することができることを、当業者なら理解することができるであろう。本発明は、通信ネットワークを介してリンクされているリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモート双方のメモリ記憶デバイス内に位置する可能性がある。

この説明は、本発明を実施するための例示的なシステムで使用することができる汎用コンピューティングデバイスの説明で始まり、その後で、本発明について、図２と後続の図を参照しながらより詳しく述べる。次に図１に転じると、プロセッサ２１、システムメモリ２２、及びシステムメモリ２２を含めた様々なシステム構成要素をプロセッサ２１に結合するシステムバス２３を含む従来型パーソナルコンピュータ２０の形態で、汎用コンピューティングデバイスが示されている。システムバス２３は、様々なバスアーキテクチャのいずれかを使用する、メモリバスまたはメモリコントローラ、周辺機器バス、及びローカルバスを含むいくつかのタイプのバス構造のいずれかとすることができる。システムメモリは、読出し専用メモリ（ＲＯＭ）２４及びランダムアクセスメモリ（ＲＡＭ）２５を含む。起動中などにパーソナルコンピュータ２０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（Basic Input/Output System）２６は、ＲＯＭ２４内に記憶される。パーソナルコンピュータ２０はさらに、ハードディスク６０との間で読出しまたは書込みをするハードディスクドライブ２７、リムーバブル磁気ディスク２９との間で読出しまたは書込みをする磁気ディスクドライブ２８、ＣＤ−ＲＯＭまたは他の光媒体などリムーバブル光ディスク３１との間で読出しまたは書込みをする光ディスクドライブ３０を含む。

ハードディスクドライブ２７、磁気ディスクドライブ２８、光ディスクドライブ３０は、それぞれハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、光ディスクドライブインタフェース３４によってシステムバス２３に接続される。ドライブ群とそれらの関連コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、及びパーソナルコンピュータ２０用の他のデータの不揮発性記憶を実現する。本明細書に述べられている例示的な環境は、ハードディスク６０、リムーバブル磁気ディスク２９、及びリムーバブル光ディスク３１を使用するが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ、読出し専用メモリ、ストレージエリアネットワークなど、コンピュータによってアクセス可能なデータを記憶することができる他のタイプのコンピュータ可読媒体もまた、この例示的な動作環境内で使用することができることを、当業者なら理解することができるであろう。

いくつかのプログラムモジュールは、ハードディスク６０、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に記憶することができ、オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７、及びプログラムデータ３８を含む。ユーザは、キーボード４０及びポインティングデバイス４２など入力デバイスを介して、パーソナルコンピュータ２０にコマンド及び情報を入力することができる。他の入力デバイス（図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含むことができる。これら、及び他の入力デバイスは、しばしばシステムバスに結合されたシリアルポートインタフェース４６を介してプロセッサ２１に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）、あるいはネットワークインタフェースカードなど、他のインタフェースによって接続することができる。また、モニタ４７または他のタイプのディスプレイデバイスは、ビデオアダプタ４８などのインタフェースを介して、システムバス２３に接続される。また、パーソナルコンピュータは、モニタに加え、図示しないが、スピーカ及びプリンタなど他の周辺出力デバイスを含む。

パーソナルコンピュータ２０は、リモートコンピュータ４９など、１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境内で動作することができる。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることができ、図１では、メモリ記憶デバイス５０が例示されているだけであるが、一般に、パーソナルコンピュータ２０に関連して上述した要素の多数または全部を含む。図１に示されている論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１及び広域ネットワーク（ＷＡＮ）５２を含む。そのようなネットワーク環境は、事務所、全社コンピュータネットワーク、イントラネット及びインターネットで普通である。

パーソナルコンピュータ２０は、ＬＡＮネットワーク環境内で使用されるとき、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。パーソナルコンピュータ２０は、ＷＡＮネットワーク環境内で使用されるとき、典型的には、ＷＡＮ５２を介して通信を確立するためのモデム５４、または他の手段を含む。モデム５４は、内部にあっても外部にあってもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続される。パーソナルコンピュータ２０に関して図示されたプログラムモジュール、またはその一部分は、リモートメモリ記憶デバイスがあれば、その中に記憶することができる。図のネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立する他の手段を使用することができることを理解されたい。

以下の説明では、別段の表示がない限り、本発明について、１つまたは複数のコンピュータによって実行される動き、及び動作を記号で表したものを参照して述べる。したがって、そのような動き及び動作は、「コンピュータによって実行された」と呼ばれることがあり、構造化された形態でデータを表す電気信号がコンピュータのプロセッサによって操作されることを含むことを理解されたい。この操作は、データを変換し、またはコンピュータのメモリシステム内のロケーションでデータを維持し、当業者にはよく理解できる方法で、コンピュータの動作を再構成し、または他の方法で変更する。データが維持されるデータ構造は、データのフォーマットによって規定された特定の特性を有するメモリの物理ロケーションである。しかし、本発明について前述の状況で述べられているが、当業者なら、以下に述べられている動き及び動作の多くはハードウェアでも実施できることを理解することができるので、限定するものではないものとする。さらに、本明細書における説明は、主に二分岐されたオペレーティングシステムの作成及び使用に焦点を合わせるが、本明細書で述べられている二分岐はアプリケーションにも当てはまることを理解されたい。

言語依存性データの分離
図２に転じると、既存のアプリケーションの一例を示すアーキテクチャ図が示されている。具体的には、図のアプリケーション２０１は、コード部分２０３とリソース部分２０５を備える混合式の単一バイナリである。そのような従来型アーキテクチャは、コード部分２０３またはリソース部分２０５に対する更新中に難点が生じる。具体的には、コード部分２０３は一般に言語独立であり、一方、リソース部分２０５は一般に、概ね言語特有である。アプリケーションをリリースした後の大抵の更新は、リソース部分２０５ではなく、そのアプリケーションのコード部分２０３のフィックス及びパッチに関する。したがって、実質的にリリース前には、コード部分２０３とリソース部分２０５を共に変更することができるが、リリース後には、著しく異なるそれぞれの頻度で変更される。

しかし、この従来のアーキテクチャ例では、コード部分２０３に対する変更は、以下の方法でコード部分２０３とリソース部分２０５双方に関する変更及び再インストールを必要とした。最初に、コード部分の基礎となるソースコードに適切な変更が加えられる。次に、所望のフィックスを実施する新しい単一のバイナリを生成するために、新しいソースコードと旧リソースが組み合わされる。リソースの各言語特有バージョンについて、このようにして新しいバイナリファイルを作成しなければならないことに留意されたい。次に、ローカライズされたバイナリが、適切なそれぞれの場所に配布される。複数の言語を使用する会社または団体の場合、一般に複数の別個のバイナリがこの段階で得られることになるであろう。最後に、更新されたバイナリが、フィックスを必要とするマシン（上記のパーソナルコンピュータ２０または他のコンピューティングデバイスなど）にインストールされる。複数の言語を使用する位置では、適切な言語フィックスを各マシンについてインストールしなければならない。

次に図３を参照すると、本発明の一実施形態による二分岐されたアプリケーションアーキテクチャが示されている。具体的には、図では、アプリケーション３０１が、２つの別個のバイナリ、すなわち、コード及び言語独立データを備える言語独立バイナリ３０３と、ローカライズされた、または言語特有のバイナリ３０５のうち１つとを備える。言語独立バイナリ３０３は、ローカライズ可能でない材料、たとえば、アプリケーションの１つの言語バージョンから次のバージョンに変換することを必要としない材料を備える。言語特有のバイナリ３０５は、ローカライズされる、すなわち、特定の言語で表示するように適合された材料を備える。典型的なローカライズ可能材料の非包括的な諸例には、ＵＩテキスト及びグラフィクス、ならびにアプリケーションヘルプドキュメントが含まれる。

例示的な例では、言語特有のバイナリ３０５は、図では、米国英語（３０７）、日本語（３０９）、フランス語（３１１）に対応する複数のリソースパック３０７、３０９、３１１を備え、本発明の一実施形態によるものであるが、本発明の諸実施形態では、単一のリソースパックがアプリケーションと共に提供されることになり、提供されるリソースパックは、ユーザまたは購入者の、あるいは別の方法で選択された言語に合致する。図の特定のリソースパック（英語、日本語、フランス語）は例示的なものにすぎず、リソースパックは、図３に特に示されているもの以外に、当該の任意の言語で提供することができる。ローカライズ可能なリソースと非ローカライズ可能リソースの間で示されている分離は、システムＰＥバイナリ（ＤＬＬ、ＥＸＥ、ＯＣＸ、ＳＹＳなど）で実施されるだけでなく、任意のデータ、または他の形態のバイナリ、たとえば、ＸＭＬ（Extensible Markup Language）データまたはＨＴＭＬ（HyperText Markup Language）データでも実施されることが好ましいことに留意されたい。

インストールされたとき、図３のアーキテクチャは、本発明の一実施形態によれば、オペレーティングシステムが適切なリソースを突き止めることを容易にするマニフェストまたは他のレコード３１３を含む。具体的には、マニフェストは、取り出されるリソースの識別子を、適切なリソースパック内のリソースのロケーションにマッピングすることによってローカライズを可能にする。たとえば、アプリケーションが常駐するマシンが日本人ユーザによって使用される可能性があり、したがって、日本語リソースパックを有することができる。システム設定は、複数のリソースパックが存在する場合、どのリソースパックを使用すべきかを示すことが好ましい。ダイアログボックスなどリソースが取り出されるとき、アプリケーション３０１のコード部分３０３のインスタンス化されたものが、所望のダイアログボックスに関連付けられた識別子を有するマニフェスト３１３を制御するコードを呼び出す。マニフェストを制御するコードは、リソースを突き止めた後でその呼出しを転送することも、その代わりに、呼び出しているエンティティにロケーションの指示を返すこともできる。

複数の言語特有ファイルの圧縮
図１に示されているコンピューティングシステム２０などのシステム上では、図３に示されているアプリケーション３０１など多数のアプリケーションをインストールすると、言語特有のバイナリファイル３０５など、扱いにくい数の言語特有バイナリファイルが生じる可能性がある。多数のファイルは、アプリケーションがインストールされるたびに多数のファイル入力／出力動作を必要とすることにより、コンピューティングシステム２０の性能を低下させる可能性がある。当業者には周知のように、Ｉ／Ｏ動作は加速するのが困難であり、それにより、実行されるＩ／Ｏ動作の数の削減は、コンピューティングシステムの効率を高めるための最も実行可能な選択肢として残されている。さらに、言語特有バイナリファイル３０５は、一般に小さく、サイズが６４キロバイトより小さいことがしばしばである。したがって、多数の現代のオペレーティングシステムは、仮想メモリを６４キロバイト刻みで予約するため、言語特有バイナリファイル３０５のローディングに起因するメモリ使用は、各ファイルがそのファイル自体よりはるかに大きい可能性のあるメモリセグメント内にロードされつつあるために、言語特有バイナリファイルの総サイズより著しく大きくなる可能性がある。システム内で開かれる各ファイルは、システムファイルハンドル、ならびに他のリソースを取るため、アプリケーション内で開かれたファイルが多すぎると、システム性能が低下し、また、全システムのリソース消費が増大する可能性がある。

わかるように、メモリ使用の削減及びファイルＩ／Ｏ動作の削減による効率は、１つまたは複数の言語特有バイナリファイル３０５が単一のファイルの形に圧縮された場合に実現することができる。図４に転じると、図では、圧縮リソースファイル４０１が、２つのリソースファイル、すなわちリソースファイルＡ（４０９）とリソースファイルＢ（４１１）とを含む。リソースファイルＡ及びＢは、米国英語リソースパック４０７及び日本語リソースパック４０９など、言語特有バイナリファイル３０５のいずれかとすることも、複数のアプリケーションに対応する言語特有バイナリファイル群、すなわち、ファイル４０１など、単一のファイルの形に圧縮されている各言語特有バイナリファイルが特定の言語に対応する言語特有バイナリファイル群とすることもできる。所与のユーザは、１つの言語だけを主に使用する可能性が高いため、圧縮された言語特有バイナリファイル群がすべて同じ言語用であり、すべて異なるアプリケーションに対応する場合、より多数のファイルＩ／Ｏ動作をなくすることができる。したがって、さらに下記で述べるようにして、２つ以上の異なるアプリケーション用の言語特有リソースが同じファイル内に含まれている場合、そのファイルを１回ロードすることが必要とされるだけであり、１回または複数回のファイルＩ／Ｏ動作が節約される。

圧縮リソースファイル４０１は、圧縮リソースファイル４０１全体に関する情報を提供することができる圧縮リソースファイルヘッダ４０３を含むことができる。たとえば、ヘッダ４０３は、圧縮リソースファイル４０１が実際にそのようなファイルであることを検証するために使用することができる署名を含むことができる。そのような署名は、ファイル４０１を言語特有バイナリファイル群を含むものとして識別するための特徴的な文字列で始まり、圧縮された各リソースファイルを一意に識別するためのグローバル識別子がそれに続く。圧縮リソースファイルヘッダ４０３はまた、圧縮リソースファイル内に含まれるいくつかのリソースファイルを指定するエントリを含むことができる。また、任意選択で、ヘッダ４０３は、圧縮リソースファイル内のそのリソースファイルの冒頭を一意に識別するために、各リソースファイルについてオフセットアドレスを指定することができる。たとえば、ヘッダ４０３は、２つのリソースファイル、すなわちリソースファイルＡ（４０９）とリソースファイルＢ（４１１）が、圧縮リソースファイル４０１内に含まれていることを指定するエントリを含むことができ、また、ヘッダ４０３は、リソースファイルＡ（４０９）が、ファイル４０１の冒頭から５１２バイトのメモリロケーションで始まることや、リソースファイルＢ（４１１）が、ファイル４０１の冒頭から８０９６バイトのメモリロケーションで始まることを指定することもできる。別法として、ヘッダ４０３内に含まれる個々のリソースアドレスは、実際のメモリオフセット識別子ではなく、含まれているリソースファイル４０９及び４１１の冒頭に対する任意のタイプのインデックスとすることができる。圧縮リソースファイルヘッダ４０３はまた、ヘッダ４０３を読み取る、またはファイル４０１をメモリ内にロードするとき他のプロセスを助けるために、ヘッダ４０３のサイズ、及び圧縮リソースファイル４０１のサイズを指定することもできる。

圧縮リソースファイル４０１内に含まれている各リソースファイルは、そのリソースファイルについて関連情報を提供するために、それ自体のヘッダを有することができる。このヘッダ情報は、図４に示されているように、圧縮リソースファイル４０１内で、圧縮リソースファイルヘッダ４０３の直後に続くことができる。リソースファイルＡヘッダ４０５及びリソースファイルＢヘッダ４０７など、図４のリソースファイルヘッダは、ファイル４０１のローディングを容易にするために、互いに隣接して位置する。代替実施形態では、ヘッダ４０５及び４０７が、ファイル４０９及び４１１など、それぞれのリソースファイルに隣接して位置することができる。リソースファイルヘッダは、それぞれのリソースファイルのファイル名を含むことができ、また、適正なリソースがロードされつつあることをロードするソフトウェアが保証することができる情報を提供するために、リソースファイルのバージョンと、チェックサムとを含むこともできる。好ましい一実施形態では、チェックサムがＭＤ５リソースチェックサムである。リソースファイルヘッダはまた、リソースファイルヘッダを読み取る、またはリソースファイルをメモリ内にロードするとき他のプロセスを助けるために、ヘッダのサイズ、及びリソースファイルのサイズを指定することもできる。

圧縮リソースファイル４０１内におけるリソースファイル４０９などリソースファイルのロケーションが、圧縮リソースファイルヘッダ４０３内に指定されていなかった場合には、ヘッダ４０５などリソースファイルヘッダが、その関連する個々のリソースファイルのロケーションを含むことができる。この場合も、上記のように、ロケーション情報は、ファイル４０１の冒頭からなど実際のメモリオフセットとすることも、リソースファイルに対する任意の他のインデックスとすることもできる。ある種のオペレーティングシステムまたは他のローディング機構は、リソースの開始メモリアドレスが偶数であることを必要とする可能性があるため、リソースファイルＡ（４０９）とリソースファイルＢ（４１１）の間などリソース間でパディングを使用することができる。そのような場合には、ヘッダ４０５などリソースファイルヘッダにより、パディングの存在を示すことができ、パディングの長さを指定することもできる。

リソースファイルＡ（４０９）またはリソースファイルＢ（４１１）など、リソースファイルは、主にリソースファイル自体を含むことができる。しかし、そのファイルをロードする、または要求するシステムを助けるために、リソースファイル内に追加情報が含まれることもあり得る。たとえば、リソースファイルは、上述のファイル４０１の署名と類似の署名を含むことができる。さらに、リソースファイルは、上述のようにリソースヘッダ内に含まれるバージョン情報が、要求元アプリケーションのバージョンと異なる場合、リソースファイルを妥当性検査するために使用することができるリソースチェックサムを含むことができる。リソースファイルはまた、現在のリソースファイルが適正なリソースでないと判定された場合、適切なリソースを見つける際に助けとなる情報を含むことができる。

圧縮リソースファイル４０１のアーキテクチャは、複数のリソースファイルを単一のファイル構造内に容れることを可能にし、ファイルＩ／Ｏ動作の数を削減し、メモリの効率的な利用を高める。様々な戦略を使用し、一緒に使用される可能性が非常に高いリソースファイルが、確実に単一の圧縮リソースファイル内に格納されるようにすることができる。たとえば、アプリケーション３０１は、より大きなアプリケーションのコンポーネントとすることができる。そのような場合には、アプリケーション３０１は、より大きなアプリケーションを構成する他のコンポーネントと共にインストールされる可能性が高いはずである。したがって、米国英語リソースパック３０７と、より大きなアプリケーションを構成する他のコンポーネントの米国英語リソースパックとを含む単一の圧縮リソースファイルは、メモリ内にロードする必要がある唯一の言語特有リソースファイルとなる一方、複数のコンポーネントのそれぞれは、それぞれの言語特有リソースにアクセスすることができるはずである。同様に、アプリケーション３０１がオペレーティングシステムファイルであるならば、リソースパック３０７と、概してアプリケーション３０１と共にロードされる他のオペレーティングシステムファイルの同等なリソースパックとを含む単一の圧縮リソースファイルもまた、アプリケーション３０１と共にロードされるオペレーティングシステムファイルすべてに言語特有リソースを提供するためにメモリ内にロードする必要がある唯一のリソースとなるはずである。わかるように、圧縮リソースファイル４０１の形に圧縮された、リソースファイル４０９及び４１１などリソースファイルが、同じ言語用の言語特有ファイルである場合、また、これらの言語特有ファイルが、概して一緒にインスタンス化される、または使用されるコンポーネントやシステムファイルを含むアプリケーションに対応する場合、より大きな効率を得ることができる。

他のコンポーネントまたはファイルがアプリケーションと同時に使用されるように、他のコンポーネントまたはファイルに関係しないことがあり得るアプリケーションも存在する可能性がある。そのような場合には、アプリケーションの言語特有リソースファイルを個々のファイルとして存在させるのでなく、圧縮後のリソースファイルが６４キロバイトまたは６４キロバイトの倍数となるように、そのような言語特有リソースファイルを任意の他の言語特有リソースファイルと共に圧縮することができる。上述のように、オペレーティングシステムは、しばしば、サイズが６４キロバイトのメモリセグメント内にファイルをロードすることになるため、それぞれが６４キロバイトより小さい複数のリソースを６４キロバイトまたはそれよりわずかに小さい圧縮ファイルの形に圧縮することにより、追加のメモリ使用が生じない。逆に、圧縮リソースファイルにより、少なくとも１回のファイルＩ／Ｏ動作が節約されるチャンスがある。というのは、圧縮リソースファイルが依然としてメモリ内にロードされている間に、圧縮リソースファイルの形に圧縮された別のリソースが呼び出される可能性が常に存在するからである。したがって、言語特有リソースファイルなど複数のリソースファイルを、１つまたは複数の圧縮リソースファイルの形に圧縮することは、一般に有益である。

リソースマニフェスト
先に論じたように、ユーザインタフェースリソースは、言語独立を促進するために、ますます外部サテライトリソースファイル内に記憶されている。この二分岐式記憶方式は、外部リソースを突き止める複雑さを増す可能性があり、ローカライズ可能なリソースを識別する必要性を高める。したがって、本発明の他の態様は、開発者がどのように、また、どのリソースをローカライズすべきか制御することを可能にするシステム及び方法を開示し、さらに、リソースファイルのロケーション、バージョン、チェックサムなどに関する必要情報をシステムに提供する。その結果、アプリケーションプログラム実行可能バイナリのビルドプロセスは、正しい言語独立イメージを作成することができ、リソースローダは、実行時にリソースを要求するモジュールのために、外部リソースを効率的にバインドすることができる。

プログラミングコードとそのリソースの間の密接な結び付きを生み出すために、前述のリソースマニフェストを使用することができる。本発明では、リソースマニフェストは、コンポーネント所有者がリソースのバージョン付け、ファイルパス、リソースタイプ／項目など、リソース情報を記述することを可能にする公開フォーマットである。好ましい一実施形態では、宣言型の（declarative）ＸＭＬをベースとする方式により、開発者は、ローカライズされた、または言語特有のリソースファイルと、その関連リソース情報を記述し、さらに、リソースのローカライズ可能性を制御することができる。次いで、ツールとプロセスを開発し、リソースマネージャが効率的かつ正確にコンポーネントリソース情報を追跡することを可能にするフォーマットの埋込みデータとして、リソースマニフェストをバイナリの形にビルドすることができる。

リソースマニフェストは、ソース形態とバイナリ形態の２つの形態を取る。そのソース形態では、リソースマニフェストは、コンポーネントのソースコードを伴うＸＭＬベースの宣言型のソースファイルである。そのバイナリ形態では、リソースマニフェストは、コンポーネントバイナリのリソースセクション内に埋め込むことができるバイナリフォーマットを有する新しいリソースタイプである。ソース形態から見ると、リソースマニフェストは、ビルド／ローカライズプロセスならびに実行時リソースローディングによってリソースをどのように処理すべきか、コンポーネント所有者が制御することができるようにする。バイナリ形態から見ると、リソースマニフェストは、リソースローダがより直接的かつ正確なリソース情報を有することを可能にし、したがって、リソースローダ内における余分なリソースフォールバック探索の必要性を大いに削減し、それによりリソースローダ及び管理全体の性能を改善する。リソースマニフェストはまた、ローカライズされたリソースタイプ、所与のリソースタイプのローカライズされたリソース項目、ロケーション、リソース管理を改善する言語など、より強力なローカライズ可能情報を説明することを可能にする。しかし、リソースマニフェストはソースレベルで必須ではないことに留意されたい。すなわち、リソースマニフェストがソース内に存在しない場合、デフォルトのリソースマニフェストをビルドプロセス中に得ることができる。

リソースマニフェストを使用することにより、いくつかの利点、主に言語独立が提供される（すなわち、リソースマニフェスト要素がローカライズ可能なデータまたは属性を含むことを必要としない）。さらに、ＸＭＬベースのスキーマを使用することにより、オープンで効率的かつ柔軟な管理及び維持が実現される。すなわち、特殊なツールを使用することが必要とされないため、開発者は、Ｎｏｔｅｐａｄアプリケーションや任意のＸＭＬエディタを用いてリソースマニフェストを容易に扱うことが可能である。最大限に柔軟かつ効率的にマニフェストを規定するために、添付の図５の例示と共に、例示的な構造化されたＸＭＬベースのスキーマの記述が続く。

リソースマニフェストのルート要素は、ｌｏｃａｌｉｚａｔｉｏｎ５００であり、あらゆるローカライズされたソースコードファイル及びリソースバイナリ内に存在することが好ましい。ｌｏｃａｌｉｚａｔｉｏｎ要素は、単純に、管理型と非管理型という異なるアーキテクチャを有する大きいリソースタイプを含む。ソースレベルでは、１つのマニフェストファイルを複数のコンポーネントによって共用することができ、したがって、非管理リソース記述と管理リソース記述を共に含むことができる。バイナリレベルでは、通常、非管理型または管理型となることになる。

非管理リソース用のマークアップの始まりは、ｕｎｍａｎａｇｅｄＲｅｓｏｕｒｃｅｓ５０２である（要素タイプｍａｎａｇｅｄＲｅｓｏｕｒｃｅｓ５０４は、管理リソースタイプ用に予約されている）。非管理リソースはすべて、ｕｎｍａｎａｇｅｄＲｅｓｏｕｒｃｅｓ５０２要素の下に記述することができ、ファイルパス、フォルダタイプ、バージョンなど基本ローカライズ情報を含む。

ｆｉｌｅＰａｔｈ属性は、ローカライズファイルパスを指定する。リソースローダは、ローカライズファイルを求めてこのパスを探索してから、デフォルトの探索論理を実行することができる。ファイルパスは、完全な絶対ファイルパス、または事前定義されたローカライズ後ファイルパスと組み合わせられた相対パスとすることができる（たとえば、％ＳｙｓｔｅｍＲｏｏｔ％、％ｗｉｎｄｉｒ％、％ＣｕｒｒｅｎｔＤｉｒ％、％ＰｒｏｇｒａｍＦｉｌｅｓ％、％ｍｕｉＦａｌｌｂａｃｋ％）。

ｆｉｌｅＰａｔｈＴｙｐｅ属性は、ローカライズファイルフォルダ編成規則を指定する。ディレクトリ規則とファイル命名規則も共に指定される。ディレクトリ規則の諸例には、ＤＩＲ＿ＬＡＮＧ＿ＩＤ（従来のＷｉｎ３２言語ＩＤ）、ＤＩＲ＿ＬＡＮＧ＿ＮＡＭＥ（ＩＳＯ６３９準拠言語名）、ＤＩＲ＿ＬＡＮＧ＿ＣＵＬＴＵＲＥ（ＲＦＣ１７６６準拠言語カルチャ名）が含まれる。好ましい一実施形態では、ＤＩＲ＿ＬＡＮＧ＿ＣＵＬＴＵＲＥがデフォルトの属性である。ＬＡＮＧ＿ＮＡＭＥ及びＬＡＮＧ＿ＣＵＬＴＵＲＥを選択すると、ローカライズされた言語ファイルに対するローカライズファイル探索順序が指定される（たとえば、ＬＡＮＧ＿ＮＡＭＥが指定されたとき、英語について「ｅｎ−ｕｓ」の前に「ｅｎ」が探索されることになり、一方、ＬＡＮＧ＿ＣＵＬＴＵＲＥは「ｅｎ−ｕｓ」を最初に探索することになる）。ファイル命名規則の諸例には、ＦＩＬＥ＿ＮＡＭＥ＿ＷＩＮ３２（＜ｆｉｌｅｎａｍｅ＞．＜ｆｉｌｅ ｅｘｔｅｎｓｉｏｎ＞．ｍｕｉ）及びＦＩＬＥ＿ＮＡＭＥ＿ＭＡＮＡＧＥＤ（＜ｆｉｌｅｎａｍｅ＞．ｒｅｓｏｕｒｃｅｓ．ｄｌｌ）が含まれる。

ａｐｐｌｙＤｅｆａｕｌｔＭａｎｉｆｅｓｔ属性は、０（いいえ）または１（はい）の値を含むことができる。好ましい一実施形態では、ａｐｐｌｙＤｅｆａｕｌｔＭａｎｉｆｅｓｔが指定されない場合、値が１となる。１のとき、コンポーネントのマニフェスト内に指定されていないリソースタイプが、デフォルトの共通リソースマニフェストファイルを用いて構文解析されることになる。

ｆｉｌｅＴｙｐｅ属性は、１（ローカライズ）、２（圧縮ローカライズフォーマット）、４（システム）、８（アプリケーション）の値を含むことができる。システムファイルタイプは、コンポーネントが、リソース言語をシステムローカライズと合致させるシステムファイルであることを示す。

ｃｍｆＦｉｌｅＮａｍｅ属性は、圧縮ローカライズフォーマットファイルのファイル名を含む。ｃｍｆＩｎｄｅｘ属性は、圧縮ローカライズフォーマットファイル内部のローカライズファイルのインデックス値を含む。ｃｍｆＦｉｌｅＶｅｒｓｉｏｎ属性は、圧縮ローカライズフォーマットファイルのバージョンを含む。

ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓ要素は、言語独立バイナリ内に含まれることになるリソースタイプ情報を含み、ｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓは、ローカライズバイナリ内に含まれることになるリソースタイプ情報を含む。

いくつかの項目について指摘しておく必要がある。第１に、ローカライズリソースバイナリと言語独立コードバイナリは、ソースレベルで同じリソースマニフェストファイルを共用する。いくつかの属性及び要素は、１つのバイナリに当てはまるだけである可能性がある（たとえば、ｆｉｌｅＰａｔｈ及びｆｉｌｅＰａｔｈＴｙｐｅは、言語独立バイナリに当てはまるだけである）。第２に、圧縮ローカライズフォーマットファイル属性（すなわち、ｃｍｆＩｎｄｅｘ、ｃｍｆＦｉｌｅＶｅｒｓｉｏｎ、ｃｍｆＦｉｌｅＮａｍｅ）は、ｆｉｌｅＴｙｐｅがＣＭＦであるとき使用されることになる。好ましい一実施形態では、ｆｉｌｅＴｙｐｅが指定されていない場合、デフォルトタイプが非ＣＭＦである。第３に、ビルド後プロセス（下記で詳しく扱う）は、コンポーネントのＣＭＦ情報を上書きする可能性がある。ＣＭＦファイルバージョンは、ローカライズファイルバージョンに依存しない可能性があるＣＭＦファイルの独立のバージョンである。必要な場合、ＣＭＦファイルバージョンは、よりよいセキュリティのために公開鍵／秘密鍵によって置き換えることができる。第４に、好ましい一実施形態では、ａｐｐｌｙＤｅｆａｕｌｔＭａｎｉｆｅｓｔ属性が１であり、デフォルトマニフェストとコンポーネントのマニフェストの間で衝突があるとき、コンポーネントのマニフェスト内部の情報がデフォルト情報を上書きすることになる。

ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓ要素５０６は、言語独立コードバイナリ内のリソース項目の説明を開始する。好ましい一実施形態では、ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓがコンポーネントのソースマニフェスト内で使用されていない場合、そのデフォルト値は、ｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓの下で指定されていない残りのリソース項目となる。ｆｉｌｅＶｅｒ属性及びｃｈｅｃｋｓｕｍ属性は、ソースレベルにおいて使用されない。言語独立バイナリでは、ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓが実際のリソース項目を含むことになり、したがって、ｆｉｌｅＶｅｒ属性及びｃｈｅｃｋｓｕｍ属性は値を有するべきである。これらの値は、ビルド時の間に、ローカライズツールまたはＲＣ．ｅｘｅコンパイラによって生成される。ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓとｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓの下のリソース項目が互いに衝突する場合、ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓがより高い優先順位を有することになる、あるいは、エラーが発せられることになることに留意されたい。

ｆｉｌｅＶｅｒ属性は、ファイルバージョンを指定する。ローカライズファイルを検証するためにファイルバージョンに依拠するが、バージョンを探索し、ロードすることはコストがかかる可能性があり、したがって、バージョンをマニフェスト内に有することにより、性能が改善される。ｃｈｅｃｋｓｕｍ属性は、従来のＭＤ５ローカライズチェックサムを指定する。作成されるチェックサムは、ｕｎｍａｎａｇｅｄＲｅｓｏｕｒｃｅｓ／ｍａｎａｇｅｄＲｅｓｏｕｒｃｅｓ要素内のリソースタイプの１つに基づくものである。この属性は、ソースレベルマニフェストから隠され、バイナリ内で示されるだけである。ｒｅｓｏｕｒｃｅｓＴｙｐｅ要素は、リソースタイプを指定する。

好ましい一実施形態では、ｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓが開発者のソース内で使用される場合、ローカライズ可能なリソースタイプまたはリソース名について、ｒｅｓｏｕｒｃｅｓＴｙｐｅとして値が存在するべきである。ｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓがローカライズバイナリ内で使用されている場合、その値は、ローカライズバイナリ内の実際のリソース項目である。属性ｆｉｌｅＶｅｒ及びｃｈｅｃｋｓｕｍは、値を有するべきである。これらの値は、ビルド時にローカライズツールによって埋められる（下記で詳しく扱う）。

好ましい一実施形態では、ｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓが開発者のソース内で使用され、ｒｅｓｏｕｒｃｅｓＴｙｐｅの値を有し、その値がｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓ内のものと重なり合う場合、言語独立バイナリ内のタイプからの項目だけが抽出されることを指摘しておく必要がある。また、開発者がリソースマニフェストファイルを提供する場合、ｎｅｕｔｒａｌＲｅｓｏｕｒｃｅｓまたはｌｏｃａｌｉｚｅｄＲｅｓｏｕｒｃｅｓ内に少なくとも１つのｒｅｓｏｕｒｃｅｓＴｙｐｅ要素を有するべきである。

ｒｅｓｏｕｒｃｅｓＴｙｐｅ要素は、リソースタイプを表し、複数回使用することができる。ｔｙｐｅＮａｍｅ属性は、文字列タイプを指定する。ｔｙｐｅＩｄ属性は、ＩＤタイプを指定する。ｉｔｅｍＮａｍｅ属性は、リソース項目名文字列を指定する。ｉｔｅｍＩｄは、リソース項目ＩＤを指定する。

ｔｙｐｅＮａｍｅとｔｙｐｅＩｄのエントリが１つだけ必要とされることに留意されたい。好ましい一実施形態では、ｉｔｅｍＮａｍｅ及びｉｔｅｍＩｄが複数の項目を含むとき、それらをスペース文字によって分離すべきである。

ビルド時
図６及び図７に転じると、言語独立バイナリをビルドするためのプロセスが示されている。ビルドプロセスは、ビルドユーティリティ（ｂｕｉｌｄ．ｅｘｅならびにｍａｋｅｆｉｌｅ．ｄｅｆビルドフロー制御ファイル）６０６にコンポーネントソースファイル６００、６０２、６０４が入力されて、ステップ７００で始まる。ステップ７０２を続行して、このビルドが言語独立か否かについて、ビルドユーティリティ６０６によって判定される。好ましい一実施形態では、ビルドユーティリティ６０６は、パラメータ（たとえば、図示しないＬＡＮＧ＿ＮＥＵＴＲＡＬ）を受け入れることができ、このパラメータは、開始されたビルドプロセスが言語独立であるかどうか（すなわち、ＬＡＮＧ＿ＮＥＵＴＲＡＬ＝１→言語独立ビルド）、それとも言語独立でないかどうか（すなわち、ＬＡＮＧ＿ＮＥＵＴＲＡＬ＝０→非言語独立ビルド）を示す。言語独立パラメータが指定されていない場合、デフォルトは、非言語独立ビルドである。

ビルドが言語独立でない場合、ビルドプロセスは、ステップ７０４、７０６、７０８で続行する。ステップ７０４で、ビルドユーティリティ６０６は、リソースコンパイラ（ＲＣ．ｅｘｅ）６０８を呼び出す。次いで、ステップ７０６で、リソースコンパイラ６０８は、リソースファイル（．ｒｅｓ）６１０を作成する。最後に、ステップ７０８で、ビルドユーティリティ６０６は、リンカユーティリティ（ｌｉｎｋ．ｅｘｅ）６１４を呼び出し、非言語独立ＰＥファイル６１６を作成する。

一方、ビルドが言語独立と指定されている場合、ビルドプロセスはステップ７１２で続行し、リソースマニフェストファイル６０４が指定されているかどうか、ビルドユーティリティ６０６によって判定される。一実施形態では、ビルドユーティリティ６０６は、マニフェスト６０４のファイル名を示すパラメータ（たとえば、図示しないＲＣ＿ＭＡＮＩＦＥＳＴ）を受け入れることができる。このパラメータが指定されていない場合、デフォルトのマニフェストファイル名が使用されることになる。マニフェストファイル６０４がソース６００、６０２のフォルダ内で見つかった場合には、ビルドプロセスがステップ７１６で続行する。マニフェストファイル６０４がソース６００、６０２のフォルダ内で見つからない場合には、マニフェストファイル６０４が存在するかどうか確かめるために、ソースファイル６００、６０２の親及び祖父フォルダを探索することができる。マニフェストファイル６０４が見つからない場合、ビルドユーティリティ６０６は、ステップ７１４でデフォルトのリソースマニフェストファイルを作成してからステップ７１６に進むことができる。

ステップ７１６を続行して、ビルドユーティリティ６０６は、マニフェストファイル６０４からリソースタイプ情報を得る。ステップ７１８で、ビルドユーティリティ６０６は、リソース圧縮方式が利用されていることをマニフェストファイル６０４が示すと判定された場合、圧縮リソースファイルからリソースファイル情報を得ることができる。ステップ７２０に進み、ビルドユーティリティ６０６は、ソースファイル６００、６０２、６０４をコンパイル及びリンクすべきかどうかについて判定する。

ソースファイル６００、６０２、６０４をコンパイル及びリンクすべきでない（すなわち、それらが既存のバイナリである）場合、ビルドユーティリティ６０６は、ローカライズリソースコンパイルツール（ＭＵＩＲＣＴ．ｅｘｅ）を呼び出し、言語独立ＰＥファイルとローカライズＰＥファイルを作成し、両ＰＥファイル内にリソースマニフェストタグ及びチェックサムを挿入する。

一方、ソースファイル６００、６０２、６０４をコンパイル及びリンクすべきである場合には、ビルドプロセスはステップ７２４を続行し、ビルドユーティリティ６０６がリソースコンパイラ（ＲＣ．ｅｘｅ）６０８を呼び出す。一実施形態では、リソースコンパイラ６０８を、別個のリソース（．ｒｅｓ）ファイル６１０、６１２の形にコンパイルされることになるタイプ／名前付きリソースを含むマニフェストファイル６０４の名前を示すスイッチ（たとえば、図示しない／ｑ ｍａｎｉｆｅｓｔ＿ｆｉｌｅ＿ｐａｔｈ）を受け入れるように修正することができる。したがって、次いでステップ７２６で、ビルドユーティリティ６０６は、コンポーネントのソースマニフェストファイル６０４を構文解析し、また、リソースコンパイラ（ＲＣ．ｅｘｅ）６０８を呼び出し、マニフェストファイル６０４内のマニフェストリソースタイプ／名前リストに従って、ローカライズ可能なリソースを、言語独立ファイル（．ｒｅｓ）６１０とローカライズファイル（．ｍｕｉ．ｒｅｓ）６１２に分割する。さらに、リソースコンパイラ（ＲＣ．ｅｘｅ）６０８は、マニフェストファイル６０４のリソース要素５０６、５０８内のｃｈｅｃｋｓｕｍ属性を更新し、マニフェストファイル６０４を言語独立ファイル（．ｒｅｓ）６１０とローカライズファイル（．ｍｕｉ．ｒｅｓ）６１２双方に挿入する。最後に、ステップ７２８で、ビルドユーティリティ６０６は、リンカユーティリティ（ｌｉｎｋ．ｅｘｅ）６１４を２回呼び出し、言語独立イメージ６１６と言語特有のリソースイメージ６１８という２つの別個のイメージをビルドする。

ビルドプロセスは、ビルドユーティリティ６０６がビンプレイス（ｂｉｎｐｌａｃｅ）ユーティリティ（ｂｉｎｐｌａｃｅ．ｅｘｅ）を呼び出し、言語独立ＰＥ６１６をビン（ｂｉｎ）フォルダ内に、また、ローカライズＰＥ６１８をｂｉｎ＼＜ｌａｎｇｉｄ＞フォルダ内に配置して、ステップ７３０で終わる。

ビルド後
言語特有のリソースファイルなど複数の個々のリソースファイルは、上記で詳しく述べられている構造に従って、ビルド後リソースツールにより、１つまたは複数の圧縮リソースファイルの形に圧縮することができる。そのようなリソースツールは、リソースファイル群のグループを指定することができる制御ファイルの存在を示すスイッチを受け入れるように修正することができる既存のリソースツールとすることも、リソースファイルを圧縮するようにだけ設計された新しいリソースツールとすることもできる。

制御ファイルは、一緒にグループ化されるリソースファイルを指定することができ、得られる圧縮リソースファイルを指定することができる。一実施形態では、一緒にグループ化されるリソースファイルと得られる圧縮リソースファイルとを順序付けられたｎ個組とすることができ、したがって、常に最後のエントリ、または最初のエントリが得られる圧縮リソースファイルであり、残りのエントリが一緒にグループ化されるリソースファイルである。別法として、制御ファイルは、一緒にグループ化されるリソースファイルを指定するために、また、得られる圧縮リソースファイルを指定するために識別子に依拠することができる。いずれの場合にも、制御ファイルは、単純なテキストファイル以上のものであることを必要としないが、当業者には自明であるように、より複雑なデータフォーマットを使用することもできる。多数の制御ファイルを必要とすることを回避するために、単一の制御ファイルがリソースファイルの複数のグループを指定できることが企図されている。一実施形態では、エラーその他により、制御ファイルが１つまたは複数のリソースファイルグループについて得られる圧縮ファイルを指定していない場合、リソースツールは、これらのリソースファイルについて圧縮ステップを迂回し、圧縮されないままとすることができる。

図８に転じると、図３に示され、上記で詳しく述べられているアプリケーション３０１と同様なアプリケーション８１０及び８２０が示されている。アプリケーション８１０及び８２０は、それぞれ言語独立バイナリ部分８１９及び８２９を、また、アプリケーション８１０について言語依存性リソース部分８１２、８１４、８１６、アプリケーション８２０について言語依存性リソース部分８２２、８２４、８２６を有する。また、言語依存性リソースのそれぞれは、言語依存性リソース８１２用のヘッダ８１１など、ヘッダを含む。アプリケーション８１０及び８２０は、上述のビルドプロセスの結果とすることも、異なる会社または開発者のグループから受け取ることができるものなど、未知のビルドプロセスから導出されたバイナリファイルとすることもできる。

図８に示されているリソースツール８０１などリソースツールは、制御ファイル８０３など制御ファイルから入力を受け入れ、指定されたリソースを圧縮リソースファイルフォーマットの形に圧縮することができる。たとえば、制御ファイル８０３は、米国英語リソースが１つの圧縮リソースファイルの形に組み合わされるようにアプリケーション８１０及び８２０の言語特有のリソースを組み合わせることができることを指定することができる。図８には示されていないが、制御ファイル８０３はまた、たとえば、日本語リソースを第２の圧縮リソースファイルの形に組み合わせるべきであり、フランス語リソースを第３の圧縮リソースファイルの形に組み合わせるべきであることを指定することができる。

次いで、リソースツールは、それぞれアプリケーション８１０及び８２０の米国英語リソース８１２及び８２２を読み取り、ヘッダ８１１及び８２１を、それぞれ圧縮リソースファイル８３０のセグメント８３２及び８３３として格納することができる。米国英語リソース８１２及び８２２からの残りの情報は、それぞれ圧縮リソースファイル８３０のセグメント８３４及び８３５として格納することができる。上述のように、セグメント８３４及び８３５は、リソースデータ自体の本体を含むことができる。やはり上述のように、圧縮リソースファイル８３０は、個々のリソースファイルヘッダが、メモリオフセット情報、またはヘッダ８１１内で元々見つからない情報を容れることを必要とするフォーマットを使用し、そのような情報は、リソースツール８０１によって圧縮リソースファイル８３０を作成する時点で追加することができる。

リソースツール８０１は、読取り、評価、ならびに、おそらくは編集、またはリソース８１２及び８２２内に含まれた情報に添付することによってセグメント８３２、８３３、８３４、８３５を作成した後で、圧縮リソースファイルヘッダ４０３を参照しながら上述した情報の一部またはすべてを含むヘッダ８３１を作成することができる。次いで、リソースツール８０１は、同様な方法を使用し、圧縮リソースファイルを作成することができる。この圧縮リソースファイルは、本例では、制御ファイル８０３によって指定されているように、日本語リソース８１４及び８２４、ならびにフランス語リソース８１６及び８２６を圧縮することによって得られるファイルとすることができる。別法として、リソースツール８０１は、指定された圧縮ファイルのすべてをほぼ同時に作成するために、周知の並行処理技法に依拠することができる。

実行時
今や、言語特有リソースなど、リソースを単一のファイル内に容れることができるため、もはや言語特有リソースと言語独立バイナリの間に１対１マッピングは存在しない。言語特有リソースと言語独立バイナリの間に１対１マッピングがないことにより、言語独立バイナリのインスタンス化が複雑になる可能性がある。

１対１マッピングが存在しないときの実行時方法をよりよく対比するために、言語特有バイナリファイル３０５のそれぞれと、言語独立バイナリ３０３の間に１対１マッピングがある、図３に示されているアプリケーション３０１を考えてみる。そのような場合には、言語特有バイナリファイルのそれぞれは、言語独立バイナリファイル３０３だけに関係するものとして命名し、格納し、他の方法で識別することができる。たとえば、フォルダ内に含まれる言語特有ファイルの言語の名称またはコードを有する一連のフォルダが作成されることがあり得る。したがって、図３に示されている米国英語リソースパック３０７など、米国英語データを含む言語特有バイナリファイルのすべてを含むであろう「米国英語」または「０４０４」という名称のフォルダが存在する可能性がある。この例示的な実施形態では、フォルダ内に含まれる言語特有バイナリのそれぞれについて、言語独立バイナリに対するその関係を反映するように命名することができるであろう。たとえば、言語独立バイナリが「ｆｏｏ．ｅｘｅ」と命名されているならば、米国英語の言語特有バイナリファイルは、「ｆｏｏ．ｍｕｉ」と呼ばれる可能性があり、米国英語フォルダ内に格納される可能性がある。そのような場合には、言語特有リソースが、事前定義されたフォルダ内に含まれ、言語独立バイナリに対するその関係が明らかであるように命名されるため、言語特有リソースを突き止めるのは非常に簡単である。

しかし、わかるように、上記のプロセスは、言語独立ファイルと言語特有ファイルの間に１対１対応がない場合には実際的でない。したがって、圧縮リソースファイル設計に付随する、上記でより詳しく列挙されていた効率を提供するように設計された新しいローディングプロセスが、図９に示されている。当業者なら理解できるように、図９に示されているステップは、リソースをロードする１つまたは複数のコンポーネントによって実行することができる。そのようなコンポーネントは、オペレーティングシステム３５の一部、アプリケーションプログラム３６など様々なアプリケーションプログラム、または他のソフトウェアもしくはユーティリティとすることができる。さらに、やはり当業者ならわかるように、図９に示されているステップは、インスタンス化または他の方法でメモリ内にロードされつつあるコンポーネントが追加のリソースを必要とするため、一般的に実行することができる。一例として、アプリケーション３０１の言語独立バイナリ３０３は、言語特有バイナリファイル３０５のうち少なくとも１つが存在することを必要とする可能性が高い。

図９に戻ると、ステップ９０１は、リソースが要求されたこと、また、リソースローディング機能が、ロードされるリソースの名前及びロケーション、たとえばパスを判定することができることを示す。上記で詳しく述べられているように、そのような情報は、要求元コンポーネントなど、コンポーネントと共に格納されるマニフェスト内に容れることができる。ロードされるリソースの名前及びロケーションが判定された後で、ステップ９０３でリソースをロードすることができ、ステップ９０５で、リソースローディング機能は、リソースが独立のファイル内に含まれるかどうか、あるいは、リソースが、おそらくは現在要求されているものとすることも、しないこともできる追加のリソースと共に、圧縮ファイル内にあるかどうか判定することができる。ローディング機能がファイルのタイプを判定することができる１つの方法は、ヘッダを調べることである。上記で詳しく述べられているように、圧縮リソースファイルヘッダは、ファイルのタイプを識別するために使用することができる特徴的な文字列を有する署名を含むことができる。代替実施形態では、ローディング機能は、たとえば、上記で詳しく述べられているような方法で要求元コンポーネントと共に格納されるマニフェスト内に含まれるファイル名または他の識別用情報を調べることにより、ステップ９０３の前にステップ９０５の判定を実行することができる。

ステップ９０５で、要求されたリソースが圧縮ファイル内にない場合、そのリソースのローディングは、周知の方法で進むことができる。たとえば、依然として必要な場合、ステップ９２１に示されているように、ローディング機能は、独立の、または「未圧縮の」ファイルを突き止めることができる。その後で、ステップ９２３に示されているように、ローディング機能は、ロードされるリソースを要求したプロセスのアドレス空間内に、独立のファイルをメモリマップすることができる。そのようなプロセスは、言語特有リソースを要求した、バイナリ３０３など実行用言語独立バイナリとなる可能性がある。要求されたリソースは、要求元プロセスのアドレス空間内にマップされた後で、ステップ９２５で引き続きロードされ、それにより、言語特有リソースなどそのリソースを要求元プロセスに提供することができる。

しかし、ステップ９０５で、ローディング機能が、要求されたリソースが実際に圧縮ファイルであると判定した場合には、ステップ９０７で、ローディング機能は、要求元リソースのバージョンブロックから圧縮ファイル情報を参照することができる。下記でより詳しく述べるように、要求元リソースのバージョンブロック内に含まれる情報は、正しいリソースファイルが圧縮リソースファイル内に含まれているかどうか判定するために使用することができる。

ステップ９０９で、ローディング機能は、圧縮ファイルがすでに別のプロセスによってロードされているかどうか判定することができる。上記で詳しく述べられているように、圧縮リソースファイルを使用することによって効率を得ることができる。というのは、そのようなファイルは、ファイルＩ／Ｏ動作の数を削減することができるからである。したがって、不必要なファイルＩ／Ｏ動作が実行されないようにするために、ローディング機能は、最初に、圧縮リソースファイルがすでにロードされているかどうか判定することができる。ステップ９０９の検査を実行するための１つの機構は、たとえば、要求された圧縮ファイル内に含まれている要求された言語特有リソースの言語または言語識別子と組み合わせられた、要求された圧縮ファイルのフルパス名からなるものとすることができるハッシュキーを使用することである。そのようなハッシュキーを、同様に得られた、すでにロード済みの圧縮リソースファイルのハッシュキーに比較することができる。２つのハッシュキーが同等である場合、要求された圧縮ファイルは、すでにロードされている。当業者なら理解することができるように、要求された圧縮リソースファイルがすでにメモリ内にロードされているかどうか判定する検査を実行するための多数の他の方法が存在する。そのような方法には、ファイルの開始ビット、ファイルＧＵＩＤなどの比較が含まれる可能性があり、ステップ９０９を実行するために同様に使用することができる。

ステップ９０９により、要求された圧縮リソースファイルがすでに別のプロセス内にロードされていると判定された場合、ローディング機能はステップ９１５を実行し、要求されたリソースのオフセット情報を得ることができ、また、要求されたリソースのバージョン及びチェックサムをも得ることができる。上記で詳しく述べられているように、オフセット情報は、リソースを要求したコードの一部であるマニフェスト、圧縮リソースファイルのヘッダ、個々のリソースそれ自体の中を含めて、様々な位置に含まれている可能性がある。オフセット情報が得られた後で、ローディング機能は、所与のオフセット部に位置するリソースのバージョン情報及びチェックサム情報を、上記で述べられているようにマニフェスト内に格納することができる被要求バージョン及び被要求チェックサムと比較することができる。

ステップ９１７で、所与のオフセット部のリソースのバージョン及びチェックサム情報が、要求されたバージョンまたはチェックサムと合致しないと判定された場合、ローディング機能は、上記で述べられているように、要求されたリソースが圧縮ファイル内にないと判定された場合に実行することができるステップ９２１に戻ることができる。したがって、バージョン及びチェックサム情報のどちらか、または両方が合致しないと、ローディング機能は、周知の方法に頼ることになり得る。しかし、バージョンまたはチェックサム情報、あるいはその両方が正しい場合、ローディング機能はステップ９１９に進むことができ、圧縮リソースファイルの形に圧縮された被要求リソースは、ステップ９１９で、要求元プロセスのプロセスアドレス空間内にマップされ、ステップ９２５でリソースのローディングを続行することができる。

ステップ９０９に戻ると、要求されたリソースが、先にロードされていない圧縮リソースファイル内にあると、ローディング機能が判定した場合、ローディング機能は、ステップ９１１に示されているように、それを突き止め、圧縮リソースファイルにバインドすることができる。同じ圧縮リソースファイル内に含まれているものなど、リソースの共用を容易にするために、ローディング機能は、ステップ９１３に示されているように、実行中プロセス全体にわたって圧縮リソースファイルをメモリマップすることができる。ステップ９１３は、圧縮リソースファイルをメモリページングエリア内で作成すること、及び開くこと、ならびに永続オブジェクトを作成することを含めて、プロセス全体にわたってファイルを共用するための任意の様々な方法を企図している。当業者なら理解することができるように、ファイルが複数のプロセスによって共用されているとき、一方のプロセスがファイルにアクセスしている間に、別のプロセスによってファイルへのアクセスが終了されないようにするために、カウンタを維持することができる。同様に、圧縮リソースファイルが共用されているとき、カウンタまたは同様のコンストラクトを使用し、現在圧縮リソースファイルにアクセスしているプロセスの数を追跡することができる。したがって、図９には具体的に示されていないが、ステップ９１５は、他のプロセスによる圧縮リソースファイルの使用を追跡するカウンタを増分することを含むことができる。

わかるように、圧縮リソースファイル構造、ならびにリソースマニフェストは、ファイルの数を削減し、ファイルＩ／Ｏ動作の数を削減することにより、また、そのようなリソースファイルがロードされたとき無駄にされるメモリを減らすことにより、効率を高める。改良されたオペレーティングシステムアーキテクチャ、ならびに改良されたオペレーティングシステムアーキテクチャを作成し、インストールし、使用する方法について述べたことは理解されるであろう。本発明の原理を適用することができる多数の可能な実施形態に鑑みて、図面に関連して本明細書に述べられている実施形態は、例示的なものにすぎないものとし、本発明の範囲を制限するものと考えるべきでないことを理解されたい。たとえば、ソフトウェアで示されている例示された実施形態のいくつかの要素をハードウェアで実施することができ、逆もまた同様であること、あるいは、本発明の趣旨から逸脱することなしに、例示された実施形態の構成及び詳細を修正することができることを、当業者なら理解することができるであろう。したがって、本明細書に述べられている本発明は、特許請求の範囲とその均等物の範囲内に入る可能性のある実施形態すべてを企図している。

本発明の諸実施形態を実施することができる例示的なデバイスアーキテクチャを一般的に示すブロック図である。 単一のバイナリ内にコード部分とリソース部分を有する例示的なアプリケーションバイナリを示すアーキテクチャ図である。 アプリケーションが別個のバイナリ内で言語独立コードバイナリ部分と言語依存性のリソース部分とを有するアプリケーション構成を示すアーキテクチャ図である。 本発明の一実施形態によるリソース圧縮方式のためのファイルフォーマットを示すアーキテクチャ図である。 本発明のリソースマニフェストの例示的な構造を示す関係図である。 別個のバイナリ内で言語独立コードバイナリ部分と言語依存性のリソース部分とを作成するための、本発明の一実施形態によるデータフローを示す概略図である。 別個のバイナリ内で言語独立コードバイナリ部分と言語依存性のリソース部分とを作成するための、本発明の一実施形態に従って取られるステップを示す流れ図である。 実行時に言語依存性のリソースをロードするための、本発明の一実施形態によるデータフローを示す概略図である。 実行時に言語依存性のリソースをロードするための、本発明の一実施形態に従って取られるステップを示す流れ図である。

符号の説明

５００ ルート要素
５０２、５０４、５０６、５０８、５１０ 要素

Claims (21)

1. コンポーネント用として言語独立ファイル及び対応する言語特有リソースファイルを作成する方法であって、
   リソースマニフェストファイルを得るステップと、
   前記リソースマニフェストファイル内に含まれているローカライズ可能リソース情報に従って、言語独立ファイル及び言語特有リソースファイルを作成するステップと、
   チェックサムデータを作成するステップと、
   前記リソースマニフェストファイル内のフィールドを前記チェックサムデータで更新するステップと
   を備えることを特徴とする方法。
2. 前記リソースマニフェストファイルが指定される
   ことを特徴とする請求項１に記載の方法。
3. 前記リソースマニフェストファイルが指定されず、デフォルトリソースマニフェストファイルが使用される
   ことを特徴とする請求項１に記載の方法。
4. 前記リソースマニフェストファイルは、ＸＭＬをベースとする宣言型ファイルである
   ことを特徴とする請求項１に記載の方法。
5. 前記ローカライズ可能リソース情報は、圧縮リソースファイル内に常駐する
   ことを特徴とする請求項１に記載の方法。
6. コンポーネント用として、言語独立ファイルと、対応する言語特有リソースファイルとを作成する方法を実行するための命令を含むコンピュータ読み取り可能な記録媒体であって、前記方法は、
   リソースマニフェストファイルを得るステップと、
   前記リソースマニフェストファイル内に含まれているローカライズ可能リソース情報に従って、言語独立ファイル及び言語特有リソースファイルを作成するステップと、
   チェックサムデータを作成するステップと、
   前記リソースマニフェストファイル内のフィールドを前記チェックサムデータで更新するステップと
   を備えることを特徴とするコンピュータ読み取り可能な記録媒体。
7. リソースマニフェストスキーマデータ構造を記憶しているコンピュータ読み取り可能な記録媒体であって、前記データ構造は、
   前記スキーマがリソースローカライズ情報を含むことを示す要素を表すデータを含む第１のデータフィールドと、
   ユーザインタフェースリソースに関連付けられた要素を表すデータを含む第２のデータフィールドと、
   前記第２のデータフィールドの前記ユーザインタフェースリソース要素の言語依存性を表すデータを含む第３のデータフィールドと、
   ユーザインタフェースリソースタイプに関連付けられた要素を表すデータを含む第４のデータフィールドと
   を備えたことを特徴とするコンピュータ読み取り可能な記録媒体。
8. 前記第２のデータフィールドは、非管理型リソースを表す
   ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
9. 前記第２のデータフィールドは、管理型リソースを表す
   ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
10. 前記第３のデータフィールドは、言語独立リソースを表す
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
11. 前記第３のデータフィールドは、ローカライズされたリソースを表す
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
12. 前記データ構造は、
    前記第２のデータフィールドの前記ユーザインタフェースリソース要素のリソースファイルのファイルパスを表すデータを含む第５のデータフィールドと、
    前記ファイルパスのファイルパスタイプを表すデータを含む第６のデータフィールドと、
    前記リソースファイルのファイルタイプを表すデータを含む第７のデータフィールドとをさらに備えた
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
13. 前記データ構造は、デフォルトリソースマニフェストを参照するかどうかの指示を表すデータを含む第８のデータフィールドをさらに備えた
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
14. 前記データ構造は、
    圧縮リソースファイルのファイル名を表すデータを含む第９のデータフィールドと、
    前記圧縮リソースファイルのファイルバージョンを表すデータを含む第１０のデータフィールドと、
    前記圧縮リソースファイル内のリソースローカライズファイルのインデックス値を表すデータを含む第１１のデータフィールドとをさらに備えた
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
15. 前記データ構造は、
    リソースファイルのファイルバージョンを表すデータを含む第１２のデータフィールドと、
    チェックサム値を表すデータを含む第１３のデータフィールドとをさらに備えた
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
16. 前記データ構造は、
    前記第４のデータフィールドの前記ユーザインタフェースリソースタイプに関連付けられた前記要素の名前を表すデータを含む第１４のデータフィールドと、
    前記第４のデータフィールドの前記ユーザインタフェースリソースタイプに関連付けられた前記要素の識別子を表すデータを含む第１５のデータフィールドと、
    リソース項目の名前を表すデータを含む第１６のデータフィールドと、
    前記リソース項目の識別子を表すデータを含む第１７のデータフィールドとをさらに備えた
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
17. 前記スキーマは、ＸＭＬをベースとする宣言型ファイルである
    ことを特徴とする請求項７に記載のコンピュータ読み取り可能な記録媒体。
18. コンポーネント所有者がコンポーネントリソースローカライズ情報を提供するための方法であって、
    ローカライズ可能リソースを決定するステップと、
    ローカライズ可能リソースフォルダ規則を決定するステップと、
    リソースマニフェストファイルを作成するステップと
    を備えることを特徴とする方法。
19. 前記リソースマニフェストファイルのパスをリソースコンパイラプログラムに指定するステップ
    をさらに備えることを特徴とする請求項１８に記載の方法。
20. リソースマニフェストファイルは、ＸＭＬをベースとする宣言型ファイルである
    ことを特徴とする請求項１８に記載の方法。
21. ローカライズ可能リソース情報は、圧縮リソースファイル内に常駐する
    ことを特徴とする請求項１８に記載の方法。
    

Images