第1リソースデータを実行可能バイナリファイル内でアドレス指定するための機能を有するオペレーティングシステムに多言語機能を追加する方法であって、選択された言語識別子を記憶するために選択可能なユーザ設定値を追加するステップと、それぞれが、前記第1リソースデータのそれぞれ1つに対応するリソースデータを格納する少なくとも1つの代替言語リソースファイルを追加するステップと、前記第1リソースデータのそれぞれに対する要求を、前記選択された言語識別子に記憶される選択された言語に応じて、前記代替言語リソースデータのそれぞれ1つにリダイレクトするためにリソースローダを修正するステップと、を有する方法。請求項1記載の方法において、前記少なくとも1つの代替言語律ソースファイルは、前記オペレーティングシステムによりテーブル内に維持される、方法。請求項1記載の方法において、要求をリダイレクトするためにリソースローダを修正するステップは、前記代替言語リソースデータへの代替パスを動的に生成するステップを含む、方法。請求項3に記載の方法において、前記代替パスは、言語固有のサブディレクトリを含む、方法。請求項1に記載の方法であって、前記リソースローダは、前記代替言語リソースデータを要求側プロセスのアドレス空間中にマッピングすることにより、要求をリダイレクトする、方法。請求項1に記載の方法において、前記第1リソースデータは、アイコン、カーソル、メニュー、ダイアログボックス、ビットマップ、機能拡張済みメタファイル、フォント、アクセレレータテーブル、メッセージテーブルエントリ、文字列テーブルエントリ、または、バージョンを定義するデータの1つである、方法。オペレーティングシステムにおいて、第1バイナリファイルに格納された第1データに対する要求側プロセスによる要求に応えて、データをアドレス指定する方法であって、前記第1データに対応する代替言語ファイルの存在を判断するステップと、前記判断するステップの結果が、前記代替言語ファイルが存在することを示す時に、言語識別子及び前記第1データに基づき前記代替言語ファイルへのパスを動的に生成するとともに、前記第1バイナリファイルからではなく前記代替言語ファイルから前記要求側プロセスに少なくとも1つのデータを戻すステップと、前記判断するステップの結果が、前記代替言語ファイルが存在しないことを示す時に、前記要求側プロセスに前記第1データを戻すステップとを有する前記方法。請求項7記載の方法において、前記少なくとも1つの代替言語律ソースファイルは、前記オペレーティングシステムによりテーブル内に維持される、方法。請求項7に記載の方法において、前記代替パスは、言語固有のサブディレクトリを含む、方法。請求項7に記載の方法において、前記第1リソースデータは、アイコン、カーソル、メニュー、ダイアログボックス、ビットマップ、機能拡張済みメタファイル、フォント、アクセレレータテーブル、メッセージテーブルエントリ、文字列テーブルエントリ、または、バージョンを定義するデータの1つである、方法。図5を参照すると、図3に図示されている従来の技術によるプロセスの修正において、オペレーティングシステムを通してリソースデータを要求するプロセスが図示されている。図3に関して説明されているリソースローダ130およびリソースファインダ135内のプロセスが、図5に示されているようなプロセスを作成するために修正される。すべてを包含する用語では、図5のプロセスが、プロセスがプロセス用のデフォルトのリソースの代わりに、選択されたユーザインタフェース言語に対応するリソースを受け取るように、ある特定のリソースに対する要求を代替言語リソースにリダイレクトする。実施態様においては、代替リソースのロードは、プロセスが、それがロードを希望する言語を指定しなかった場合に動き出すだけである。言い換えると、プロセスは、リソースをロードしようとし、どの言語かについては実際には気にしていない。従来のシステムにおいては、リソースローダは、モジュール自体のリソースセクション、またはプロセスがその中からリソースをロードするように指定される外部モジュールのどちらかからリソースを戻すであろう。多言語ユーザインタフェースシステムの現在の実施態様においては、リソースローダは、プロセスがある特定の言語またはリソースに対するそれ以外の特定の分類を指定しなかった場合には、代替リソースをロードするであろう。このプロセスは、まさに図3の従来の技術の実施態様でのように、リソースファインダ320からメモリハンドルを要求する。しかしながら、この場合、このハンドルは代替言語リソースを参照するハンドルである。リソースファインダは、選択されたユーザインタフェース言語ID335によって示されるリソースを識別しようとする。選択されたユーザインタフェース言語ID335は、ユーザ設定値である。この選択されたユーザインタフェース言語ID335は、例えば、ユーザがログインし、オプションのリストから任意の言語を選択することによって確立できるであろう。それから、このユーザインタフェース言語ID335は、変更されるまで記憶されている。プロセス310は、リソースファインダ320にリソース名およびタイプを送信することによってリソースのメモリハンドルを要求する。リソースが、この要求側プロセス310を定義するモジュール以外のモジュールの中にあると、リソースモジュールハンドルもリソースファインダ320に送信されるであろう。モジュールハンドルが送信されない場合、このモジュールはこのリソースを要求するプロセスを生成するモジュールと同じであるため、リソースファインダはすでにローダデータテーブルからモジュールハンドルに対するアクセスを得ている背景の項に説明されたように、リソースファインダおよびリソースローダは、多くの場合、要求側プロセスを生成するコードと同じバイナリファイル内のリソースにアクセスするために使用される。プロセスが、言語に特殊であるリソースを要求することも可能であり、このような要求を満たすプロセスは、本発明に関する、および従来の技術による方法によって満たされるステップの外にあってよい例えば、http://www.microsoft.com/msdn/に説明されているLoadResourceの説明の例を参照すること。後者の場合、言語IDはリソースファインダに渡されてよい。オペレーティングシステムは、過去にリソースファインダ320に対する呼出しによって生成された、代替リソースモジュールハンドルのテーブル323を維持するために修正される。したがって、別のプロセスがすでに同じモジュールからリソースを要求しており、モジュールがすでに代替リソースモジュールに相互に関連付けられている場合には、この代替モジュールハンドルは代替リソースモジュールテーブル323から迅速に入手できる。このリソースに対しエントリがない場合には、オペレーティングシステムは代替モジュールパスを動的に生成する。代替モジュールパスを動的に生成するために、アルゴリズム325が利用される。このアルゴリズム325は、リソースファイルの何らかの仮定された編成に基づいてよく、代替言語リソースファイルが指定されたリソースに存在するかどうかを示す。本実施態様においては、この代替言語リソースファイルは、要求されたモジュールのパスのサブディレクトリ内に位置し、それぞれが言語識別子に一意に相互関連付けられているファイル名で区別される。各言語のサブディレクトリ内には、それぞれが元のモジュールの名前を取って名前が指定された代替言語リソースファイルが記憶される。<module_path>\mui\<language_ID>\<module_name>言い換えると、オペレーティングシステムは、元のモジュールのロードパスの言語固有のサブディレクトリから代替言語リソースモジュールをロードする。この元のモジュールが、多言語イネーブルされていなかったシステムの場合に<path1>\<filename1>であった場合、代替言語モジュールに対するパスは、選択されたユーザインタフェース言語ID335で示されるが言語ID1であると仮定すると<path1>\mui\<languageID1>\<filename1>であろう。代替言語リソースの編成は、多様な代替方法で実行できる。それらを、それぞれが通例のモジュール通常、単一言語オペレーティングシステムで要求されるものに対応する言語固有のモジュールに分けると、それぞれのりソースモジュールごとに多様な言語のリソース単一モジュールに結合される場合に発生するように、追加メモリに対するニーズが回避される。モジュールを記憶するために使用されるパス構造を考えると、選択されたユーザインタフェース言語ID335および元の要求されたパスとモジュールによって示される言語に対応する代替言語モジュール用のパスを構築することは容易である。このパスは、リソースハンドルを提供するためにリソースファインダ320によって使用される。リソースハンドルの作成は、従来の技術と同じように実行される。相違点は、この例のリソースハンドルがプロセスを、元のモジュールパスのサブディレクトリ内で識別されたリソースデータ350に向けるという点である。図5では、リソースデータ350は、選択されたユーザインタフェース言語IDが言語ID2であったバイナリファイル2用の代替リソースモジュール内にあった。パスおよびモジュール名は、呼出し側プロセスによって供給される元のモジュール名と同じ名前を使用して動的に生成される。要素<language_ID>は、言語を表すコンパクトコードであってよい。例えば、それは、ISO639言語標準省力に副言語記述子または一次構成要素と二次構成要素を加えたものを含むWin32言語idに基づくことができるであろう。本発明の好ましい実施態様においては、アルゴリズムは、それが、要求されたデータに対する代替言語リソースが存在すると仮定して、単にパスを構築する以上のことを行うという点で堅牢である。代替言語は、多様な特性の度合いで要求されてよい。また、代替言語リソースが使用可能ではない、あるいは代替リソースが使用可能であると考えられ、このリソースは言語以外の何らかの点と基本リソースと異なっている。このアルゴリズムおよび対応するプロセスは、図5に描かれている率直なシナリオだけではなくこれらの状況に対処し、利用するにも十分堅牢である。選択されたユーザインタフェース言語は非常に特殊である。例えば、ユーザはフランス語、スイスのフランス語またはカナダのフランス語を要求することがある。このアルゴリズムは、それがユーザインタフェース言語に対するシステムレベル要求をある特異性の度合い、および別の特異性の度合いが与えられる代替言語リソースの可用性と調整をつけることができるようにするための複数のステップを含んでよい。ユーザが、オペレーティングシステムにログインした時にフランスのフランス語を要求すると、要求された言語に対する近似だけが使用可能となってよい。このような状況と対処するため、このアルゴリズムおよび関連するプロセスは、以下のように、ステップの内蔵された階層に従って動作してよい。第1に、このアルゴリズムは、<module_path>\mui\によって指定されるモジュールパスの中に、カレントユーザ言語IDに同等な識別子が付いた、つまり名前\<language_ID>\が付いたサブディレクトリが存在するかどうかを判断してよい。この第1試験が不合格となると、このアルゴリズムは、カレントユーザ言語IDに対応する一次言語IDに同等な識別子の付いた、つまり名前\primary_language_ID\が付いた<module_path>\mui\のサブディレクトリが存在するかどうかを判断してよい。システムユーザ言語IDが指定されない場合、このアルゴリズムはサブディレクトリを解決するために代用物、例えば日付または通貨フォーマット規約に関する好みなどのユーザの場所を示唆する何らかの好みを使用することができてよい。代わりに、言語に中立な代替リソースモジュールが呼び出されてよい。所望の優先順位で設けられてよいそれ以外のステップは、例えばカナダのフランス語がユーザ言語IDで要求され、英語が使用できる場合など、デフォルトの代替言語リソースサブディレクトリ、ユーザ言語IDによって指定された言語が使用できないが、所定の代替言語が多くの場合、考えられる現地で話される代替言語の選択であろう。好ましい代替リソースを優先順位システムに従って識別する前記プロセスによって、代替言語リソースの特異性を高めることができる。オペレーティングシステムに一次言語例えば、英語であるが、英国英語、カナダ英語等ではないだけが添付される場合、ユーザは、後に、さらに多くの特定の言語を追加し、ユーザの選択はトランスペアレントかつ自動的に実現されてよい。前記機能性が、Windows登録商標のFindResourceEx機能で行われるある特定の言語のリソースに対する通常の要求と干渉しないことに注意する。指定された言語IDは要求側プロセスによって提供され、前記代替言語リソース方式は要求を別のリソースモジュールに再送しないであろう。パスを形成するアルゴリズム325がリソースパスを決定した後、バージョンチェックおよびそれ以外のあらゆる完全性チェックは、それに要求側プロセスがアクセスできるようにする前に実行することができる。図5に関して説明されるプロセスの結果として代替言語モジュール370がメモリ内に新規に格納された、あるいはそれ以外の場合、リソースファインダ320への呼出しによってアクセスできるようになった場合、新しいエントリが代替リソースモジュールテーブル323の中に入れられてよい。最後に、ハンドルは、このプロセスが要求されたリソースにアクセスできるようにするために要求側プロセスに戻されてよい。後者は、データをメモリの中にロードし、プロセスがデータにアクセスするために使用できるハンドルを提供するために、別の機能に対するステップ、リソースローダ330を必要とすることがある。図5および付随する説明が、モジュールがメモリの中にロードされ、これがリソースファインダまたはリソースロードによっても明示的に実行される必要がないことに注意する。唯一の要件は、適切なデータをプロセスが使用できることである。オペレーティングシステムは、そのI/Oファシリティおよびメモリ管理ファシリティを通したデータの実際の移動を処理してよい。図5に関して前述されたことの重要性とは、その内容がさまざまな言語に関して異なるリソースに対するプロセスによる要求が、要求側プロセスにトランスペアレントに自動的にリダイレクトさせられるという点である。プロセスを定義するコードは、オペレーティングシステムが多言語イネーブルされるために修正される必要はない。図5および添付説明は、実行可能コードも格納するバイナリファイル内に組み込まれるリソースというコンテキストでデータに対する要求をリダイレクトするプロセスを説明する。同じ基本的な公式は、リソース専用ファイル、例えばDLL内でデータのアクセスを包含するように拡張することができる。プロセスがメモリの中にロードされるまたはメモリからアンロードされるデータを要求する前記説明においては、このようなステップは、プロセスのアドレス空間の中にマッピングされるというより広義に考えられる必要がある。これは、マッピングされたI/Oのためのオペレーティングシステムファシリティが、ディスクからメモリの中にデータをロードすることに関連する具体的な概念を不鮮明にするためである。言い換えると、現在のオペレーティングシステムは、この具体的なステップはオペレーティングシステムのI/Oシステムおよび仮想メモリ管理機能によってトランスペアレントに処理できるため、必ずしもデータをメモリの中にロードするという明示的なステップに含まれなくても、プロセスが、ステップに従ってディスク上のデータにアクセスできるようにすることを可能にする。前記プロセスは、代替リソースモジュールを単一データファイルとしてこの要求側プロセスのアドレス空間の中にマッピングしてよい。このプロセスの基礎となる詳細は従来の技術で既知であり、例えばWindows登録商標においては、これはLoadLibraryと呼ばれるオペレーティングシステム機能を定義するコードによって実行される。