(57)【特許請求の範囲】
【請求項１】
コンピュータ・システムであって、
多数の言語に対応する複数のリソース・モジュール（４１１−４１６）であって、各々、対応する言語に対して言語特有のリソースを収容する、リソース・モジュールと、
複数の実行可能モジュール（４０１−４０４）と、
言語特有のリソースの要求を受け取る（４３０）手段と、要求に応答して、リソース・ハンドラに対する前記要求とは無関係に得られる言語識別子（３３５）に従ってリソース・モジュールを選択する手段と、前記リソース・モジュールのうちの選択した１つから、要求された言語特有のリソースを与える（４３４）手段とを含むリソース・ハンドラ（２３０、３２０、３３０）を実行するプロセッサと、
から成り、
前記実行可能モジュールの少なくとも一部（４０３、４０４）が共有リソース・リファレンス（４２０）を収容し、各共有リソース・リファレンスが、異なる言語に対応するリソース・モジュール集合（４１９）を識別し、
前記受け取る手段は、識別された実行可能モジュールから前記要求を受け取る手段を含み、
前記選択する手段は、共有リソース・リファレンスを有する実行可能モジュールを識別する要求に応答して、前記無関係に得られる言語識別子に従って、前記共有リソース・リファレンスによって識別される前記リソース・モジュール集合から前記リソース・モジュール（４１５、４１６）を選択するように構成される、コンピュータ・システム。
【請求項２】
請求項１記載のコンピュータ・システムにおいて、前記実行可能モジュールの異なる１つ１つが、同じ共有リソース・リファレンスを収容する、コンピュータ・システム。
【請求項３】
請求項１又は２のいずれか１項記載のコンピュータ・システムにおいて、前記共有リソース・リファレンスは、ファイル識別子であり、前記リソース・ハンドラは、前記ファイル識別子及び前記言語識別子に従ってリソースのファイル名を構築する（４３２）ことによって、前記リソース・モジュール集合のうちの１つを選択する、コンピュータ・システム。
【請求項４】
請求項１乃至３のいずれか１項記載のコンピュータ・システムにおいて、各リソース・モジュールがリソース・ファイル識別子を有し、各共有リソース・リファレンスが１つ以上の前記リソース・モジュールの前記リソース・ファイル識別子の第１の部分を示し、前記１つ以上の前記リソース・モジュールの前記リソース・ファイル識別子はすべて前記第１の部分で始まる、コンピュータ・システム。
【請求項５】
請求項１乃至４のいずれか１項記載のコンピュータ・システムにおいて、前記共有リソース・リファレンスは、前記実行可能モジュールに含まれるリソースで命名される、コンピュータ・システム。
【請求項６】
請求項１乃至５のいずれか１項記載のコンピュータ・システムであって、更に、オペレーティング・システムを備え、前記リソース・ハンドラが前記オペレーティング・システムの一部であり、前記言語識別子を、アプリケーション・プログラムとは独立して、前記オペレーティング・システムによって維持するようにした、コンピュータ・システム。
【請求項７】
請求項１乃至６のいずれか１項記載のコンピュータ・システムにおいて、前記共有リソース・リファレンスによって識別された前記リソース・モジュール集合のいずれもが前記言語識別子に一致しない場合、前記選択する手段及び前記与える手段は、以下の言語にしたがって、
前記言語識別子によって示された言語の一次言語、
システムのデフォルト言語、
前記システムのデフォルト言語の一次言語、
降順の優先順位で、前記共有リソース・リファレンスによって識別された前記リソース・モジュール集合から、代わりのリソース・モジュールを選択するように構成される、コンピュータ・システム。
【請求項８】
請求項１乃至６のいずれか１項記載のコンピュータ・システムにおいて、前記共有リソース・リファレンスによって識別された前記リソース・モジュール集合のいずれもが前記言語識別子に一致しない場合、前記選択する手段及び前記与える手段は、以下の言語にしたがって、
前記言語識別子によって示された言語の一次言語、
システムのデフォルト言語、
前記システムのデフォルト言語の一次言語、
英語、
降順の優先順位で、前記リソース・モジュール集合から、代わりのリソース・モジュールを選択するように構成される、コンピュータ・システム。
【請求項９】
請求項１乃至８のいずれか１項記載のコンピュータ・システムにおいて、前記リソース・ハンドラは、実行可能モジュールを識別する前記要求に応答して、前記識別された実行可能モジュールに関連付けられるリソース・モジュール集合を識別し、前記識別された実行可能モジュールからではなく、前記リソース・モジュールのうちの前記選択された１つから、前記要求された言語特有のリソースを与える手段をさらに含む、コンピュータ・システム。
【請求項１０】
請求項９記載のコンピュータ・システムにおいて、実行可能モジュールを識別する前記要求に応答して、前記識別された実行可能モジュールに関連付けられるリソース・モジュール集合を識別し、前記識別された実行可能モジュールからではなく、前記リソース・モジュールのうちの前記選択された１つから、前記要求された言語特有のリソースを与える前記手段は、前記識別された実行可能モジュールの前記共有リソース・リファレンスを参照して、前記識別された実行可能モジュールに関連付けられる前記リソース・モジュール集合を識別するように構成される、コンピュータ・システム。
【請求項１１】
複数のリソース・モジュール（４１１−４１６）及び複数の実行可能モジュール（４０１−４０４）を含むコンピュータ・システムにおいてリソースを提供する方法であって、
プロセッサが、識別された言語特有のリソースに対する要求を受け取るステップと、
前記要求を受け取ったことに応答して、プロセッサが、前記要求とは無関係に得られる言語識別子（３３５）に基づいて、リソース・モジュールを選択し、前記選択したリソース・モジュールから、前記要求された言語特有のリソースを与えるステップ（４３４）と、
から成り、
前記実行可能モジュールの少なくとも一部（４０３、４０４）が共有リソース・リファレンスを収容し、各共有リソース・リファレンスが、異なる言語に対応するリソース・モジュール集合（４１９）を識別し、
前記受け取るステップは、実行可能モジュールを識別するモジュール識別子を含む要求を受け取るステップを含み、
前記選択するステップは、
前記モジュール識別子により識別される前記実行可能モジュールから共有リソース・リファレンス（４２０）を得るステップであって、前記共有リソース・リファレンスは異なる言語に対応するリソース・モジュール（４１５、４１６）集合（４１９）を識別する、ステップと、
前記共有リソース・リファレンスによって識別された前記リソース・モジュール集合から、前記言語識別子により示される言語の言語特有のリソースを有するリソース・モジュールを選択するステップと
を含む方法。
【請求項１２】
請求項１１記載の方法において、前記選択するステップは、前記共有リソース・リファレンス及び前記言語識別子に従ってリソースのファイル名を構築するステップ（４３２）をさらに含む、方法。
【請求項１３】
請求項１１又は１２のいずれか１項記載の方法において、前記選択するステップは、以下の言語にしたがって、
前記言語識別子によって示された言語、
前記言語識別子によって示された言語の一次言語、
システムのデフォルト言語、
前記システムのデフォルト言語の一次言語、
を降順の優先順位で、前記リソース・モジュールを選択するステップをさらに含む、方法。
【請求項１４】
請求項１１乃至１３のいずれか１項記載の方法において、前記選択するステップは、以下の言語にしたがって、
前記言語識別子によって示された言語、
前記言語識別子によって示された言語の一次言語、
システムのデフォルト言語、
前記システムのデフォルト言語の一次言語、
英語、
を降順の優先順位で、前記リソース・モジュールを選択するステップをさらに含む、方法。
【請求項１５】
コンピュータ・システム上で実行されると、前記コンピュータ・システムに、請求項１１乃至１４のいずれか１項記載の方法を実行させる、コンピュータ実行可能プログラムを収容した、コンピュータ読み取り可能記憶媒体。
【発明の詳細な説明】
【０００１】
【関連出願】
本願は、発明者Edward S.Miller、Bjorn C.Retting、Gregory Wilson、およびShan Xuによる、”Multilingual User Interface for an Operating System”（オペレーティング・システム用多言語ユーザ・インターフェース）と題する、１９９８年８月１４日に出願された米国特許出願第09/134,559号の一部継続出願である。。
【０００２】
【発明の属する技術分野】
本発明は、一般的に、オペレーティング・システムに関し、更に特定すれば、ユーザ・インターフェースの言語を切り替える効率的な機構を備えたオペレーティング・システムに関する。
【０００３】
【従来の技術】
リソースは、二進データまたは非二進データ、例えば、テキスト・ファイルのいずれかである。WindowsNT（登録商標）およびWindows（登録商標）ファミリのその他のＯ／Ｓ全てでは、リソースは二進データである。リソース・データはアプリケーションの実行可能ファイル内に常駐することができるので、実行可能ファイルは、その中にコードおよびリソース・データを有する二進ファイルである。コードによって定義するプロセスは、それら自体の二進実行可能ファイルまたはその他の実行可能ファイル内のリソースを用いることができる。このようなプロセスが用いるリソースも、リソースのみのファイル、例えば、リソースのみのダイナミック・リンク・ライブラリ（ＤＬＬ）内に常駐することができる。標準的なリソース内のデータは、アイコン、カーソル、メニュー、ダイアログ・ボックス、ビットマップ、拡張メタファイル（enhanced metafile）、フォント、アクセレレータ・テーブル、メッセージ・テーブル・エントリ、単一テーブル・エントリ、またはバージョンを記述する。ユーザ定義リソースは、特定のアプリケーションが要求するあらゆるデータを収容する。オペレーティング・システムのプロセスが要求するリソースは、種々の異なる方法で処理することができる。これらのリソースの多くは、単語、シンボル、フォーマット・データ等を含み、これらは言語に特定的である。大抵の場合、ユーザが選択するオペレーティング・システム・インストール・パッケージによって、特定の言語が決定される。ソフトウエアの言語が英語であれば、英語特定のリソースのみがオペレーティング・システムにインストールされることになる。全ての言語に対応するには、ハード・ディスクまたはその他の不揮発性メモリに大量の言語特定リソースをコピーしなければならないので、これは便利である。
【０００４】
オペレーティング・システムに対応する言語を１つだけ与えるようにすると、必要性が生じるに応じて、リソースを効率的にメモリにロードしたり、メモリからアンロードすることが可能になるという理由からも便利である。全てを常時メモリ内に常駐させるには、リソースは多過ぎる。リソースのロードおよびアンロードを管理し、リソースを必要としないときにメモリを不必要に占有しないようにするためには、リソースを必要とするプロセスを生成するコード、および当該プロセスに固有のリソースを、同じ二進ファイル内に組み込めばよい。プロセスを呼び出すとき、当該プロセスのコードおよび付随のリソースを収容した二進ファイルを、メモリにロードするか、それ以外の方法でプロセスにアクセス可能にすることができる。プロセスが終了したとき、リソースおよびこのようなファイルのコード部をメモリからアンロードするか、あるいはその他の方法でアクセス不能にする。これらの二進ファイルは、実行可能なプログラム、ダイナミック・リンク・ライブラリ（ＤＬＬ）、デバイス・ドライバ等とすることができる。これらを代替言語リソース全てで膨張させると、必要なメモリ量が過度に多くなる。
【０００５】
１つのオペレーティング・システムがこのようなリソースをどのように処理するかについて、以下に一例を示す。最初に、オペレーティング・システムの機能であるリソース・ファインダを用いて、指定されたリソースのインフォ・ブロックに対するハンドルを作成する。リソースを要求するプロセスが、ファインダにリソース・モジュール・ハンドル、ならびにリソース名、タイプ、およびオプションとして言語ＩＤを送る。後者は、リソース・モジュール・ハンドルが定義するリソースにおける言語特定リソースを指定する。ファインダは、指定されたリソースのインフォ・ブロックにハンドルを返し、プロセスはリソース・ローダを呼び出し、メモリ内にリソースを置くことができる。プロセスは、リソース・ハンドルおよびリソース・モジュール・ハンドルをリソース・ローダに与え、リソース・ローダはリソースをメモリ内に置き、リソースを収容するメモリ・ブロックにハンドルを返す。こうして、プロセスはリソースを使用することが可能になる。次に、オペレーティング・システムは、それをメモリにロードしたプロセスがもはやそれを必要としなくなった後、プロセスが終了した後、またはその他の条件のためにそれが必要となった場合に、別のデバイスを用いてメモリを開放することができる。
【０００６】
以上は、一例のオペレーティング・システムにおけるリソース・アクセス・ファシリティの一形式に過ぎない。他の機構では、テキスト・メッセージを出力バッファ内に置き、単一の関数コールでリソース・データに対するハンドルを直ちにロードし返す等によって、他の方法でリソースを使用可能とすることができる。これらの機構に共通な特徴は、これらはメモリ内あるいはディスク・ファイルまたはその他の記憶システム内のいずれかにおいてリソースを発見し、そのリソースを必要とするプロセスがそれを使用できるようにすることである。これには、ファイルをディスクからメモリにロードするか、あるいはハンドルまたはその他の何らかのデバイスを与えることによってリソースに対するアクセスを与える必要がある。リソースを収容するファイル（、デバイス、またはチャネル）は、要求元のプロセスまたはその他のファイルを定義するコードと同じファイル内にある場合がある。他のファイルは、コードを収容するか、またはリソースのみのファイルである可能性もある。プロセスは、それがもはや必要としないリソースを明示的にアンロードする必要がない場合もある。
【０００７】
ディスク・ストレージは低価格であるので、場合によっては、同じオペレーティング・システムをインストールして、多数の言語に対して適切なリソースを、ユーザに透過的に、備えることが望ましいこともある。しかしながら、前述のリソース管理体制を中心に構築したオペレーティング・システムでは、選択可能な言語に対応するようにオペレーティング・システムを変更するために使用可能なオプションは、非常に問題があると思われる。これについて以下に論ずる。
【０００８】
多言語に対応するには、各言語毎に、異なる二進ファイル集合を備えることが、１つの選択肢となる。複雑なオペレーティング・システムでは言語特定リソースを収容する二進ファイルが約１０００個あり、多くの異なる言語に対応することが望ましいことを考慮すると、インストールすべき二進ファイル数は、実際には膨大となる。ユーザによる言語選択を可能にするために必要な労力に加えて、結果的に作成される大量のファイルにおける冗長性は膨大である。何故なら、同じ言語非特定リソースが全て、対応する各言語毎にコピーされるからである。言語非特定リソースだけでなく、全てのコード部分もコピーが必要である。
【０００９】
別の選択肢として、新たなユーザが異なる言語のログ・オンを要求する毎に、新規にオペレーティング・システムの二進ファイルをインストールすることが考えられる。この選択肢は、大量の時間を要するので、魅力的ではない。
【００１０】
更に別の選択肢として、各二進ファイル毎に異なる言語特定資源を備えることが考えられる。これは、最初の選択肢の冗長性をなくす。何故なら、各二進ファイルは言語特定リソースのみを追加するからである。しかしながら、この選択肢は、各二進ファイルの記録を必要とするので、これも好ましい選択肢ではない。これに似たことが、現在非常に限られた範囲で行われている。二進ファイルの一部は代替リソースを収容し、各々がユーザの言語または国に応じて優先される。これらの二進ファイルのコード部は、リソースの優先言語に関する「ゲス」（guess）に基づいて、異なるリソースにアドレスするプロセスを定義する。このゲスは、あるシステム・パラメータの設定、例えば、どのデータ・フォーマットを選択したか、に基づいて行われる。したがって、例えば、ロシア語型データが選択された場合、ロシア語と明記されたリソースをロードすることができる。
【００１１】
限られた範囲で言語選択を可能にするオペレーティング・システムが、現在少なくとも１種類ある。このオペレーティング・システムは、各言語毎に別個のテキスト・ファイルを備えている。プロセスが特定の言語のテキスト・ファイル・リソースを要求すると、オペレーティング・システムは適切なファイルにアドレスする。ユーザは、システム変数を通じて、彼のデフォルト選択言語を選択することができる。
【００１２】
【発明が解決しようとする課題】
端的に述べたように、少なくとも１つの現行のオペレーティング・システム（Windows（登録商標））が、言語特定ライブラリ、例えば、テキスト・メッセージの作成に、何らかの形で対応している。システム変数を定義すると、オペレーティング・システム・インストールのロカールが示され（システムのロカールは言語設定値ではないことを注記しておく。ロカールは言語およびロケーションの混合である）、オペレーティング・システム上で走るアプリケーションがこの変数を用いて、現行の言語に対して特定的にメッセージをフォーマットすることができる。しかしながら、このために、プロセス（アプリケーション）は適切な言語リソース、およびそれがどこに位置するかを正確に特定しなければならない。変換用モデルのように、これは長時間の記録を伴う。
【００１３】
従来技術のオペレーティング・システムはいずれも、非常に自動化された方法でオペレーティング・システムによる多言語対応をいかにして与えるか示唆したモデルを提供していない。また、いずれも、同じファイル内にコードおよびリソース部を有する二進ファイルの本来的な経済性の一部を保存する手段を示唆していない。先に示唆した、所望の機能性を与えるための単純な変換は、必要な情報データに関しては、不当に費用がかかり扱いにくいと思われる。容易に実施されるいずれの変換も、従来技術のシステムのいずれからも大幅に逸脱したシステムにならざるを得ないという可能性が高い。
【００１４】
図１を参照すると、従来技術のオペレーティング・システムにおける一般的な動作において、二進ファイル２０をロードする。二進ファイル２０は、コード部１０およびリソース部３０を収容し、オペレーティング・システムのいずれかのファイル・ユニット、または第三者から供給されたファイル・ユニットと考えればよい。例えば、二進ファイル２０は、実行可能二進、ダイナミック・リンク・ライブラリ（ＤＬＬ）、またはデバイス・ドライバとすることができる。リソース部３０は、コード部が用いるリソースの一部、特に、コード部１０が生成したプロセスの要件に対して特異なリソースを収容する。これらは、コード部１０内で定義したプロセスがもやは不要となったときに、メモリからアンロードすることができる。言い換えると、リソース３０は、コード部１０内にエンコードされたプロセスが要求し、一旦これらのプロセスが終了したなら、もはやリソース部３０内に収容されているリソースをメモリ内に維持しておく必要は全くない。例えば、二進ファイル１０は、ストリップ・ダウン（stripped-down）テキスト・エディタのように、オペレーティング・システムと共に供給されるコア・リソースまたはアプリケーションとすることができる。例えば、エディタでは、ユーザがエディタ・プログラムを終了すると、このテキスト・エディタが必要としたリソースはもはや不要となる。コード１０およびリソース３０を含む二進ファイル２０は、メモリから除去されることになろう。勿論、コード部１０は、他のファイルからの他のリソースを用いる可能性もあり、同様に他のプロセスを用いる場合もある。
【００１５】
図２を参照すると、リソース８５およびこれを用いるコード５５も、別個のファイル２５および２２にそれぞれ位置することができる。例えば、コード片５０において定義されたアプリケーション５５によってアドレスされたリソース８５は、リソースのみのＤＬＬまたはコード７０およびリソース６０を収容する別個のファイル２５内に収容することができる。アプリケーション５５は、同様にリソース４０を収容するファイル内に常駐することができる。他のオペレーティング・システム・デバイスを用いて、リソース・タイプおよび名称でファイルを見つけることができる。リソースの管理（ロードおよびアンロード）は、リソース・ローダによって処理することができる。
【００１６】
図３を参照すると、プロセス１１０は、リソース・ローダ１３０およびリソース・ファインダ１３５を用いて、リソースにアドレスする。リソース・ローダは、リソース・モジュール・ハンドルおよびリソース・ハンドルが与えられると、リソース・データム１２５に対するアクセスを与えるオペレーティング・システム・ファシリティである。リソース・モジュール・ハンドルは、リソース名で指定されたリソース・データムをどこで見つけることができるかを示し、リソース・ファインダによって作成される。リソース名、タイプ、および言語（後者はオプション）は、リソース・ファインダ１３５に供給され、リソース・ファインダ１３５は、リソース・モジュール・ハンドルを返す。リソースが、コール元プロセスを生成したモジュール以外にある場合、そのモジュールのハンドルをリソース・ファインダにも供給しなければならない。リソース・タイプは、例えば、ビットマップ、移動カーソル（animated cursor）、フォント・リソース、メニュー・リソース、ストリング・テーブル・エントリ等を指定することができる。
【００１７】
リソース・ローダは、指定されたリソースをメモリにロードする。これは、リソース・モジュール・ハンドルおよびリソース・ハンドルを必要とする。リソース・モジュール・ハンドルは、モジュールであり、その実行可能ファイルがリソースを収容する。リソース・ハンドルは、ロードするリソースを特定する。リソース・ローダ１３０は、当該リソースに関連するデータを収容するメモリ・プロックに対するハンドルを返す。図３に示す記述は、図１または図２に示す状況のいずれとも一致する。尚、前述の機能の例は、Windows（登録商標）  API FindResourceおよびLoadResourceに関する文書において見られることを注記しておく。また、リソースは、前述のように、リソースに対するコールの一部だけでなく、以前の動作においてもロードできることを注記しておく。例えば、Windows（登録商標）オペレーティング・システムでは、LoadLibraryに対するコールの結果、メモリにモジュールがロードされる。
【００１８】
図４を参照して、どのようにしてオペレーティング・システムにおいてリソースにアドレスするかに関する、一般化した構成を示す。プロセス２１０がリソース・ハンドラ２３０を用いて、リソース・データム２２０に対するアクセスを得る。リソース・ハンドラ２３０は、例えば、図３を参照して論じたように、オペレーティング・システムが与える異なるいくつかのデバイスで構成することができる。プロセスは、要求されたリソースをハンドラ２３０に対して特定し、ファイル名、モジュール２５０の識別子、またはその他の何らかの情報によって、ハンドラに、リソースをどこで見つけることができるか知らせることができる。リソース・ハンドラ２３０は、モジュール２５０に含まれている可能性があるリソース２２０を、メモリまたはその他の手段にロードし、データ２４０をアクセスできるようにして、プロセス２１０に対するアクセスを与えるようにする必要がある場合もある。リソース２２０をアクセスするために、プロセス２１０には、ハンドル、アドレス、ポインタ等が与えられる。図４で記載するプロセスの重要な特徴は、このプロセスが必要なリソースを特定し、オペレーティング・システムは、このプロセスに当該リソースに対するアクセスを与えることである。リソースは、ディスク、またはネットワークによって接続された別のコンピュータ上に常駐する場合もあり、通信ポートまたはその他の何らかの機構によって、データをコンピュータ上のプロセスに転送する。オペレーティング・システムは、要求の一部として、リソースを異なる媒体、例えば、ディスクからメモリに転送し、その後に、プロセスによるリソースに対するアクセスが可能となる。
【００１９】
【課題を解決するための手段】
オペレーティング・システム方式は、リソースを要求するプロセスを処理する機能（feature）を備えることなく、リソース処理コンポーネントを提供する。これによって、オペレーティング・システムは、既存のリソースおよび実行可能二進ファイルを用いながら、これらのエレメントの変更なく、多言語に対応することが可能となる。即ち、ユーザは、ユーザ・インターフェースの言語を選択することができ、リソース・ローダは自動的にリソースの要求を適切なリソースに再送出する。
【００２０】
尚、以下の説明全体を通じて、メモリにデータをロードするという観念は、実際にファイルからデータを取り出し、これをメモリに入力するという文字通りの解釈を意図している訳ではないことを注記しておく。本発明が想定しているオペレーティング・システムの文脈では、データを物理的メモリに実際にロードすることは、下位のオペレーティング・システム機能が実行する。各プロセスは、仮想メモリ空間を有することができ、これは実際の物理的メモリとは一致しない。以下の論述において、データをメモリにロードし、メモリからアンロードするステップについて言及する場合、データをプロセスにアクセス可能にするあらゆるオペレーティング・システムの機能として広く解釈することとする。
【００２１】
リソースを要求するプロセスの観点からは、オペレーティング・システム・デバイスとの相互作用は、単一言語のリソースを処理する場合と同一である。リソースを発見しこれらを要求元プロセスに返すためのオペレーティング・システムのリソース処理コンポーネントを変更し、代替言語リソース・モジュールに対するパスを動的に生成する。パスの生成は、リソース識別子、および当該リソースを要求するプロセスが与えるオプションのモジュール・ハンドルに応答して、更にまたユーザ・インターフェースに対して選択した言語を指定する、システム全域のオペレーティング・ユーザ設定に応答して行なうことができる。プロセスによって供給されるモジュール・ハンドルがある場合は、これに代わって代替言語リソースへのパスを用いる。
【００２２】
動的にモジュール・ハンドルを生成することによって、ベース・モジュール・ハンドル（コール元プロセスによって用いられるハンドル）および代替言語リソース・モジュールを相関付ける永続的ファシリティのいずれも変更することなく、オペレーティング・システムを拡張することができる。ルックアップ・テーブルを動的に生成するので、遅れることは決してなく、ステップを節約する目的でこれを自動的に作成する。新たなモジュールをオペレーティング・システムに追加する場合、代替言語モジュールを追加し、アルゴリズムを用いて、中央のデータ・ハウスキーピングが全くなくても、代替モジュール・ハンドルを生成することができる。新たなモジュール名と既存のモジュール名との間に衝突がない限り、モジュールおよびこれを用いるあらゆるコード、またはコードおよびリソースを収容するあらゆる二進ファイルも、集中的な変化を全く行なうことなく、オペレーティング・システムに追加することができる。
【００２３】
システムは、必要に応じて、ユーザおよびリソースを要求するプロセスに対して透過的に、代替言語モジュールを自動的にロードし開放する。代替言語リソースは、モジュール（好適な実施態様では、Windows（登録商標）パーランス（parlance）において定義されているような、ダイナミック・リンク・ライブラリ即ちＤＬＬ）に常駐し、次のように、パスおよびモジュール名によって一意に指定される。
【００２４】
【数１】
<module path>＼mui＼<language ID>＼<module name>
言い換えると、オペレーティング・システムは、元のモジュールのロード・パスの言語特定サブディレクトリから代替言語リソース・モジュールをロードする。パスおよびモジュール名は、コール元プロセスによって供給される元のモジュール名と同じ名称を用いて、動的に生成する。エレメント<language ID>は、言語を表す何らかのコンパクトなコードである。例えば、これは、ＩＳＯ６３９言語規格の省略および、恐らくは、副言語指定部または一次および二次コンポーネントを含むWin32言語idに基づくことができる。
【００２５】
代替言語は、種々の特定度で要求することもできる。即ち、（フランスの）フランス語、スイスのフランス語、カナダのフランス語を、１レベルの特定度で、または更に低い特定度でフランス語だけを要求することができる。代替言語リソース・モジュール・ハンドルを生成するプロセスがロバストであるためには、アルゴリズムは、システム・レベルのユーザ・インターフェース言語に対する要求を、特定度１、およびその他の特定度で与えられる代替言語リソースの可用性と調和させることができるようにする多数のステップを含むことができる。例えば、オペレーティング・システムにログ・インするとき、ユーザがスイスのフランス語を要求したと仮定する。これは、従うことができる全てのプロセスに対して、スイスのフランス語リソースを用いることを命令するユーザ変数を指定する。代替言語リソースを生成するリソース・ローダ（またはライブラリ・ローダ）アルゴリズムは、要求された言語の近似のみが入手可能な状況に対処できなければならない。先の例において、フランス語および種々のその他の一次代替言語のみが使用可能であるが、具体的にスイスのフランス語は使用できないと仮定する。アルゴリズムは、要求時に、システム・ユーザ言語ＩＤにおいて示されたシステム・レベルの命令にさほど近くない別の何らかのデフォルト選択を行なうのではなく、フランス語の代替言語リソースをロードすることが望ましい。したがって、多レベルの近似を、アルゴリズムに対して、例えば、以下のように定義するとよい。
【００２６】
最初に、アルゴリズムは、「<module path>＼」によって指定されたモジュール・パスにおいて、現ユーザ言語ＩＤと同等の識別子、即ち、名称「＼mui＼<language ID>＼」を有するサブディレクトリが存在するか否か判定することができる。この最初の検査が不合格の場合、アルゴリズムは、現ユーザ言語ＩＤに対応する一次言語ＩＤと同等の識別子、即ち、名称「＼mui＼<primiary language ID>＼」を有する「<module path>＼」のサブディレクトリが存在するか否か判定することができる。システム・ユーザ言語ＩＤが指定されていない場合、アルゴリズムは、代理（surrogate）を用いてサブディレクトリ、例えば、日付または貨幣形式規則（monetary format convention）に対する好みのように、ユーザの局在性を示唆する何らかの好みを解明することもできる。あるいは、言語中性代替リソース・モジュールを呼び出すこともできる。他のステップは、いずれの所望の優先順位に置いてもよく、ユーザ言語ＩＤによって指定された言語が得られないが、公式な代用言語が同様のロカールで話されていることが多い場合、デフォルトの代替言語リソース・サブディレクトリ、即ち、代替言語の選択とすることができる。例えば、ユーザ言語ＩＤにおいてカナダのフランス語が要求されており、カナダのフランス語もフランス語も使用可能でないが、カナダの英語が使用可能である場合、後者を用いることができる。前述の優先順位システムにしたがって優先的な代替リソースを特定するプロセスによって、代替言語リソースの特定性を高めることができる。オペレーティング・システムが一次言語のみ（例えば、英語はあるが、イギリス英語、カナダ英語等はない）で出荷されている場合、ユーザは、後に更に特定した言語を追加し、ユーザの好みを透過的かつ自動的に実現することもできる。
【００２７】
処理を高速化するために、動的に各代替モジュール・パスを生成することによって得られるマッピングを、ルックアップ・テーブルに保存する。コール元プロセスが同じリソースをコールする場合、代替リソース・モジュールは、パスおよびハンドルを動的に生成する代わりに、これらをルックアップ・テーブルから得ることができる。尚、代替リソース・モジュールＩＤの動的な生成の結果を保存することによって、先に論じたロバストなアルゴリズムのステップを、リソースに対する要求を行なう毎に繰り返す必要はなくなる。
【００２８】
加えて、クリーンアップ・テーブルを生成して、システム要件が許す場合に、変更したリソース・ローダがメモリをロードおよび開放するのを助ける。クリーンアップ・テーブルは、ロードされた代替リソース・モジュール、およびこれらを要求したプロセスを掲示する。例えば、リソースを要求するプロセスが終了した場合、終了したプロセスが要求したリソース・モジュールを、メモリからアンロードすることができる。
【００２９】
代替実施形態では、代替言語リソース・モジュールは、異なるディレクトリ内に異なる言語のリソース・モジュールを置くことによってではなく、単一のディレクトリ内における異なるファイル名によって区別される。更に具体的には、異なる拡張子をファイル名に追加し、リソース・モジュールの言語を示す。
【００３０】
尚、オペレーティング・システムは、ローダ・データ・テーブル内にエントリを生成することによって、ロードおよびアンロードされたリソースを追跡することを注記しておく。ローダ・データ・テーブルは、リソース・モジュールのロードを必要としたプロセスを示すので、プロセスが終了したとき、または他のシステム要件の指示にしたがって、これらのモジュールをアンロードすることができる。例えば、WindowsNTにおいてLoadLibraryEx関数を直接用いるアプリケーションによってロードされるモジュールでは、モジュールのアイデンティティは、前述のリソース・ローダには「知らせる」ことができない。即ち、ローダ・データ・テーブル・エントリは生成されない。この場合、リソース・モジュールをロードするファシリティ（例えば、LoadLibrary）は、代替言語リソースの存在について問い合わせを行い、アプリケーションが要求するモジュールに代わって、それをロードすることができる。アプリケーションまたはプロセスが、ローダ・データ・テーブル・エントリを生成するオペレーティング・システム・ファシリティを用いない場合、アプリケーションまたはその他のプロセスによってリソース・ローダからリソースの要求が行われるまで、モジュールをロードする必要はない。
【００３１】
一実施形態では、本発明は、オペレーティング・システムによって実行する方法である。この方法は、第１二進ファイル内に常駐する第１データムに対するコール元プロセスによるコールを再送出する。以下のステップを実行する。コール元プロセスとは無関係に、オペレーティング・ユーザ設定値に、言語識別子を格納し、言語識別子、および第１データムまたは第１二進ファイルのいずれかの識別子に対応する二進ファイルが存在する場合、（１）言語識別子および第１データムまたは第１二進ファイルに応答して、第２二進ファイルに対するパスを動的に生成し、（２）第１二進ファイルを特定するプロセス・モジュール識別子と、第２二進ファイルを特定する代替モジュール識別子とを相関付けるルックアップ・テーブル内にパスを格納し、（３）第１データムの代わりに、コール元プロセスにアクセス可能な代替データムを、第２二進ファイル内に作成する。
【００３２】
本発明の別の実施形態によれば、本発明は、オペレーティング・システムによて実行する方法でもある。この方法は、コール元プロセスを定義する実行可能コードおよびリソース・データ双方を収容する第１二進ファイル内に常駐する第１リソース・データムに対するコール元プロセスによるコールを再送出する。コール元プロセスは、コード内に定義されている。この方法は、コール元プロセスとは無関係に、言語識別子を変数に格納するステップと、言語識別子および第１リソース・データムまたは第１二進ファイルのいずれかに対応する第２二進ファイルが存在する場合、（１）言語識別子および第１リソース・データムまたは第１二進ファイルのいずれかに応答して、第２二進ファイルに対するパスを動的に生成し、（２）第１リソース・データムの代わりに、第２二進ファイル内にコール元プロセスにアクセス可能な代替リソース・データムを作成するステップとを有する。
【００３３】
更に別の実施形態によれば、本発明は、実行可能二進ファイル内の第１リソース・データにアドレスする機能を有するオペレーティング・システムに多言語能力を追加する方法である。この方法は、選択した言語識別子を格納するための、選択可能なユーザ設定値を追加するステップと、各々第１リソース・データのそれぞれ１つに対応するリソース・データを収容する、少なくとも１つの代替言語リソース・ファイルを追加するステップと、選択した言語識別子に格納されている、選択された言語に応答して、リソース・ローダを変更し、第１リソース・データの各々に対するコールを、代替言語リソース・データの各１つに再送出するステップとを含む。
【００３４】
一実施形態によれば、本発明は、オペレーティング・システムによって実行する方法である。この方法は、第１データムに対するコール元プロセスによるコールに応答して、データにアドレスする。この方法は、第１データムに対応する代替言語ファイルの存在を判定するステップと、判定するステップの結果が、代替言語ファイルが存在することの指示である場合、代替言語ファイルから、少なくとも１つのデータムをコール元プロセスに返すステップと、判定するステップの結果が、代替言語ファイルが存在しないことの指示である場合、第１データムをコール元プロセスに返すステップとを有する。
【００３５】
一実施形態によれば、本発明はオペレーティング・システムによって実行する方法である。この方法は、第１二進ファイル内に常駐する第１データムに対するコール元プロセスによるコールを再送出する。以下のステップを実行する。各ユーザ毎に、コール元プロセスとは無関係に、オペレーティング・システム変数に言語識別子を格納するステップと、言語識別子、および第１データムまたは第１二進ファイルのいずれかの識別子に対応する第２二進ファイルの検出に応答して、（１）言語識別子、および第１データムまたは第１二進ファイルのいずれかに応答して、第２二進ファイルに対するパスを動的に生成し、第１二進ファイルを特定するプロセス・モジュール識別子と、第２二進ファイルを特定する代替モジュール識別子とを相関付けるルックアップ・テーブルに前述のパスを格納するステップと、（３）第１データムの代わりに、コール元プロセスにアクセス可能な代替データムを第２二進ファイル内に作成するステップである。
【００３６】
オプションとして、個々のモジュールは、共有リソース・リファレンスを収容することができる。このようなリファレスは、各々、１組または１群のリソース・モジュールに対するポインタである。このようなリファレンスを収容するモジュールからのリソースに対する要求は、共有リソース・リファレンスによって参照されるリファレンス・モジュール集合に再送出される。この集合の中において、オペレーティング・システムが維持する現言語識別子に基づいて、特定のモジュールを選択する。これによって、複数のモジュールが同じリソース・モジュール集合を用いることが可能となり、供給する別個のリソース・モジュールの数を削減する。更に具体的には、これによって、単一リソース・モジュールにおいて全てのシステム・リソースを指定することができ、システム内の他のモジュール全てによって共有することができる。これによって、リソース・オーバーヘッドが減少し、オペレーティング・システムはリソースのロードを高速化することができる。
【００３７】
【発明の実施の形態】
図５を参照し、図３に示した従来技術のプロセスの変更において、オペレーティング・システムを通じてリソース・データムを要求するプロセスを示す。図３を参照して説明したリソース・ローダ１３０およびリソース・ファインダ１３５内のプロセスを変更し、図５に示すようなプロセスを生成する。何よりも大切なのは、図５のプロセスは、プロセッサによる特定のリソースに対するコールを、代替言語リソースに再送出し、プロセスに対するデフォルト・リソースの代わりに、選択されたユーザ・インターフェース言語に伴うリソースをプロセスが受け取ることである。一実施形態では、代替リソースのロードは、プロセスがロードしたい言語を指定しなかった場合、単に「キック・イン」（kick in）するだけである。言い換えると、プロセスはリソースをロードしようとするが、実際にはどの言語かについては関与しない。従来技術のシステムでは、リソース・ローダは、プロセスがリソースをロードするように指定した、それ自体のモジュールのリソース部または外部モジュールのいずれかからリソースを返す。多言語ユーザ・インターフェース・システムの本実施形態では、リソース・ローダは、プロセスが特定の言語またはリソースに対する他の特定分類を指定しなかった場合、代替リソースをロードする。プロセスは、図３の従来技術の実施形態におけると同様に、リソース・ファインダ３２０からメモリ・ハンドルを要求する。しかしながら、この場合、ハンドルは、使用可能であれば、代替言語を参照するハンドルである。リソース・ファインダは、選択されたユーザ・インターフェース言語ＩＤ３３５によって示されたリソースを特定しようとする。
【００３８】
選択されたユーザ・インターフェース言語ＩＤ３３５は、ユーザ設定値である。選択されたユーザ・インターフェース言語ＩＤ３３５は、例えば、ユーザがログ・インし、選択肢のリストからある言語を選択することによって、確定することができる。すると、選択されたユーザ・インターフェース言語ＩＤ３３５は、変更されるまで、格納されている。
【００３９】
プロセス３１０が、リソース・ファインダ３２０にリソース名およびタイプを送ることによって、リソースに対するメモリ・ハンドルを要求する。リソースが、コール元プロセス３１０を規定したモジュール以外にある場合、リソース・モジュール・ハンドルもリソース・ファインダ３２０に送られる。モジュール・ハンドルが送られない場合、リソース・ファインダは、既に、ローダ・データ・テーブルからモジュール・ハンドルにアクセスすることができる。何故なら、このモジュールは、リソースを要求したプロセスを発生したモジュールと同一であるからである。（背景部で論じたように、リソース・ファインダおよびリソース・ローダは、多くの場合、要求元プロセスを生成したコードと同じ二進ファイル内にあるリソースにアクセスするために用いられる。）また、プロセスが、言語特定のリソースを要求することも可能であり、このような要求を満たすプロセスは、本発明に関係するステップの範囲外であり、従来技術の方法によって満たされる。（例えば、http://www.microsoft.com/msdn/.に記載されているLoadResourceの説明を参照のこと）。後者の場合、言語ＩＤをリソース・ファインダに渡せばよい。
【００４０】
オペレーティング・システムを変更し、代替リソース・モジュール・ハンドル３２３のテーブルを維持するようにする。これらは、リソース・ファインダ３２０に対するコールによって既に生成されている。したがって、別のプロセスが既に同じモジュールからのリソースを要求しており、このモジュールが既に代替リソース・モジュールに相関付けられている場合、代替モジュール・ハンドルを素早く代替リソース・モジュール・テーブル３２３から得ることができる。リソースに対するエントリがない場合、オペレーティング・システムは、代替モジュール・パスを動的に生成する。
【００４１】
代替モジュール・パスを動的に生成するために、アルゴリズム３２５を用いる。アルゴリズム３２５は、リソース・ファイルのある想定した編成に基づくことができ、指定されたリソースに対して代替言語リソース・ファイルが存在するか否か示す。本実施形態では、代替言語リソース・ファイルは、要求されたモジュールのパスのサブディレクトリ内に位置する。サブディレクトリの各々は、言語識別子に一意に相関付けられたファイル名によって識別する。各言語のサブディレクトリ内には、代替言語リソース・ファイルが格納されており、各々、元のモジュールにちなんで命名されている。
【００４２】
【数２】
<module path>＼mui＼<language ID>＼<module name>
言い換えると、オペレーティング・システムは、元のモジュールのロード・パスの言語特定サブディレクトリから代替言語リソース・モジュールをロードする。多言語イネーブルされていないシステムに対して、元のモジュールが"<path1>＼<filename 1>"であった場合、代替言語モジュールのパスは、選択されたユーザ・インターフェース言語ＩＤ３３５が「言語ＩＤ１」であると仮定すると、"<path1>＼mui＼<language ID 1>＼<filename 1>"となる。
【００４３】
代替言語リソースの編成は、種々の代用方法で行なうことができる。これらを言語特定モジュールに分解すると、規則的モジュール（単一言語オペレーティング・システムにおいて通常要求されるモジュール）に対応する各々は、各リソース・モジュール毎に、種々の言語のリソースを単一モジュールに結合する場合に生ずるような、追加のメモリの必要性を全て回避する。
【００４４】
モジュールを格納するために用いられるパス構造が与えられていれば、選択されたユーザ・インターフェース言語ＩＤ３３５および元の要求されたパスおよびモジュール名によって示されるいずれの言語に対応する代替言語モジュールに対するパスでも、構築するのは簡単である。このパスは、リソース・ファインダ３２０が用いてリソース・ハンドルを供給する。リソース・ハンドルの作成は、従来技術におけると同じ方法で行われる。その相違点は、この場合のリソース・ハンドルは、元のモジュール・パスのサブディレクトリにおいて特定された、リソース・データム３５０にプロセスを送出することにある。図５において、リソース・データム３５０は、「二進ファイル２」に対する代替リソース・モジュールであり、選択されたユーザ・インターフェース言語ＩＤは言語ＩＤ２であって。
【００４５】
パスおよびモジュール名は、コール元プロセスが供給する元のモジュール名と同じ名称を用いて動的に生成される。エレメント<language ID>は、言語を表すコンパクトなコードと考えられる。例えば、これは、ＩＳＯ６３９言語規格の省略および、恐らくは、副言語指定部または一次および二次コンポーネントを含むWin32言語idに基づくことができる。
【００４６】
本発明の好適な実施形態では、アルゴリズムは、要求データに対して代替言語リソースが存在すると仮定すると、パスを単に構築することを遥かに超えることから、ロバストである。代替言語は、種々の特定度で要求することができる。また、使用可能な代替言語リソースがなくても、または代替リソースが使用可能であってもよく、このリソースは、言語以外の何らかの観点において、ベース・リソースとは異なる。アルゴリズムおよび関連するプロセスは、非常にロバスト性が高いので、図５に示した単純なシナリオだけでなく、これらの状況も処理し利用することができる。
【００４７】
選択されたユーザ・インターフェース言語は非常に特定的にすることもできる。例えば、ユーザは、フランス語、スイスまたはカナダのフランス語を要求することもできる。アルゴリズムは、システム・レベルのユーザ・インターフェース言語に対する要求を、特定度１、およびその他の特定度で与えられる代替言語リソースの可用性と調和させることができるようにする多数のステップを含むことができる。オペレーティング・システムにログ・インするとき、ユーザがフランスのフランス語を要求した場合、要求された言語に対する近似のみが使用可能になる場合もある。この状況に対処するために、アルゴリズムおよび関連するプロセスは、以下のように、組み込んだステップ階層に応じて動作することができる。
【００４８】
最初に、アルゴリズムは、"<module path>＼mui＼"によって指定されたモジュール・パスにおいて、現ユーザ言語ＩＤと同等の識別子、即ち、名称"＼<language ID>＼"を有するサブディレクトリが存在するか否か判定することができる。この最初の検査が不合格の場合、アルゴリズムは、現ユーザ言語ＩＤに対応する一次言語ＩＤと同等の識別子、即ち、名称"＼<primiary language ID>＼"を有する"<module path>＼mui＼"のサブディレクトリが存在するか否か判定することができる。システム・ユーザ言語ＩＤが指定されていない場合、アルゴリズムは、代理（surrogate）を用いてサブディレクトリ、例えば、日付または貨幣形式規則（monetary format convention）に対する好みのように、ユーザの局在性を示唆する何らかの好みを解明することもできる。あるいは、言語中性代替リソース・モジュールを呼び出すこともできる。他のステップは、いずれの所望の優先順位に置いてもよく、ユーザ言語ＩＤが得られないが、予め定義されている代用言語が同様のロカールで話されていることが多い場合、例えば、ユーザ言語ＩＤにおいてカナダのフランス語が指定されていて、英語が使用可能な場合、デフォルトの代替言語リソース・サブディレクトリ、即ち、代替言語の選択とすることができる。前述の優先順位システムにしたがって優先的な代替リソースを特定するプロセスによって、代替言語リソースの特定性を高めることができる。オペレーティング・システムが一次言語のみ（例えば、英語はあるが、イギリス英語、カナダ英語等はない）で出荷されている場合、ユーザは、後に更に特定した言語を追加し、ユーザの好みを透過的かつ自動的に実現することもできる。
【００４９】
尚、前述の機能性は、Windows（登録商標）におけるFindResourceEx関数で行われるような、特定の言語のリソースに対する通常の要求とは干渉しないことを注記しておく。指定された言語ＩＤが要求元プロセスによって与えられる場合、前述の代替言語リソース方式は、別のリソース・モジュールに要求を再導出することはない。
【００５０】
パスを形成するアルゴリズム３２５がリソース・パス上で静定した後、要求元プロセスにアクセスできるようにする前に、特定したファイル上で、バージョン・チェックおよびその他の保全性チェックを実行するとよい。図５を参照して説明したプロセスの結果として、代替言語モジュール３７０がメモリ内に新たに置かれたのであった場合、またはそれ以外でコールによってリソース・ファインダ３２０に対してアクセス可能にされたのであった場合、新たなエントリを代替リソース・モジュール・テーブル３２３内に置けばよい。最後に、コール元のプロセスにハンドルを返し、プロセスが要求したリソースにアクセスできるようにする。後者は、別の関数、即ち、データをメモリにロードし、プロセスに対するハンドルを与えてデータにアクセスするために用いるために、リソース・ローダ３３０へのステップを伴う場合がある。
【００５１】
尚、図５および付随する論述は、モジュールをメモリにロードすることを示すが、これは、リソース・ファインダまたはリソース・ローダによっても明示的に行なう必要はない場合もあることを注記しておく。唯一必要なのは、適切なデータをプロセスに使用可能にすることである。オペレーティング・システムは、そのＩ／Ｏおよびメモリ管理ファシリティによって、データの実際の移動を処理することができる。図５を参照して先に説明したことの重要性は、プロセスによるリソースに対する要求は、その核心（gut）が別の言語とは異なる場合、要求元プロセスには透過的に、自動的に再送出されることである。プロセスを定義するコードは、オペレーティング・システムを多言語イネーブルにするために、変更する必要はない。図５および付随する論述は、実行可能コードを収容した二進ファイル内に組み込まれているリソースの文脈で、データの要求を再送出するプロセスについて説明した。同じ基本的形式を拡張し、リソースのみのファイル、例えば、ＤＬＬ内のデータのアクセスを含むようにすることができる。
【００５２】
尚、以上の論述では、プロセスがデータをコールしてメモリにロードするかあるいはメモリからアンロードする場合であったが、このようなステップは、広い意味では、プロセスのアドレス空間にマップすることと見なされることを注記しておく。これは、マップしたＩ／Ｏのためのオペレーティング・システムのファシリティが、ディスクからメモリへのデータ・ロードに接続される具体的な観念をぼかすからである。言い換えると、現オペレーティング・システムは、データをメモリにロードする明示的なステップに必ずしも関わることなく、ステップにしたがってディスク上のデータにアクセスすることを、プロセスに許している。何故なら、この具体的なステップは、オペレーティング・システムのＩ／Ｏシステムおよび仮想メモリ管理機能によって明示的に処理することができるからである。
【００５３】
前述のプロセスは、代替リソース・モジュールを、単純なデータとして、コール元プロセスのアドレス空間にマップすることができる。このプロセスの基礎となる詳細は、従来技術、例えば、Windows（登録商標）において、公知であり、これは、LoadLibraryと呼ばれる、オペレーティング・システム関数を定義するコードによって行われる。
【００５４】
前述のように、異なる言語に対応するリソース・ファイル間で差別化を行なうには種々の方法がある。例えば、ファイル・システム・パスを操作する代わりに、状況によっては、ファイル名自体を操作することが望ましい場合がある。本発明の一実施形態によれば、リソース・ファイルは２つの部分で構成されている。即ち、リソース・モジュールが対応付ける実行可能モジュールと同一の初期部分、およびリソース・モジュール内における局在化リソースの言語を示す言語拡張子である。
【００５５】
図６は、本発明にしたがって、いかにしてリソース・モジュールを対応する実行可能モジュールと関連付けるかについて示す。背景として、多くのモジュールは、「Ｃ」または「Ｃ＋＋」プログラム言語のいずれかを用いて書かれている。容認されている現実にしたがって、一般に、別個のソース・ファイル内においてリソースを定義する。このソース・ファイルは、「リソース・スクリプト・ファイル」と呼ばれ、別の実行可能モジュールに用いられている".c"拡張子ではなく、".rc"拡張子を有する。リソース・スクリプト・ファイルは、".res"ファイル（".res"拡張子を有するファイル）を生成する、リソース・コンパイラ（通常、"RC.EXE"と名付けられる）によって、コンパイルされる。
【００５６】
リソース・モジュールは、典型的に、通常の実行可能ファイルと対をなす。実行可能モジュールは実行可能コードを収容し、一方リソース・モジュールは、実行可能コードによって用いられるリソースを収容する。リンクの時点で、リソース・ファイルを実行可能ファイルの終端に連結し、リソース・スクリプト・ファイル内で定義されているリソースの全ては、実行可能ファイルの一部となり、実行の間用いられる。前述のように、"FindResource"および"LoadResource"関数が、実行可能モジュールによって用いられ、実行可能モジュール自体からまたは別の特定された実行可能モジュールからリソースをロードする。"FindResource"関数を呼び出す場合、コール元のモジュールは、所望のリソースが定義されている実行可能モジュールを特定する。
【００５７】
本発明の一実施形態によれば、コンピュータ・システムは、複数の実行可能モジュール４０１，４０２，４０３，および４０４を備えている。論述の目的のために、これらの実行可能モジュールを"myapp1.dll",  "myapp2.dll",  "myapp3.dll",  および"myapp4.dll"と命名することにする。加えて、コンピュータ・システムは、複数のリソース・モジュール４１１，４１２，４１３，４１４，４１５，および４１６を備えており、多数の言語に対応する。各リソース・モジュールは、対応する言語に対する局在化リソースを収容する。尚、これらのリソース・モジュールは、実際には、実行可能コードを収容しておらず、単に定義されたリソースのみを収容することを除いて、通常の実行可能モジュールであることを注記しておく。また、実行可能モジュール４０１〜４０４は、リソース定義を収容することもある（これらは本発明のこの実施形態では通常用いられない）。
【００５８】
リソース・モジュール４１１〜４１６は、集合４１７，４１８，および４１９を形成するように、命名される。所与の集合におけるリソース・モジュールの全ては、同じ実際のリソースを定義するが、集合内の各モジュールは、異なる言語におけるそのリソースを定義する。所与の集合におけるリソース・モジュールの全ては、２つの部分で命名される。ファイル名の第１部分は、従来からの".dll"ファイル名である。ファイル名全体のこの部分は、集合内のモジュール全てに対して同一であり、モジュールが集合の一部であることを示す。ファイル名の最後の部分は、言語コードおよびそれに続く".mui"拡張子から成る拡張子である。ファイル名のこの部分は、含まれているリソースの言語を示す。図６では、言語コードは、言語の記述的テキスト指定から成る。実際の実施形態では、言語コードは、特定の言語を示す数値コードである。
【００５９】
本発明によれば、オペレーティング・システムのリソース・マネージャに対するリソースの要求は、モジュール４０１，４０２，４０３，または４０４のような、特定のモジュールを識別する。しかしながら、当該モジュールにおいて定義されるリソースを用いるのではなく、リソース・マネージャは、リソース要求において特定されているモジュールに対応するリソース・モジュール集合を特定し、その集合内のリソース・モジュールの１つからリソースを与える。
【００６０】
図６は、実行可能モジュールとリソース・モジュール集合との間でどのように対応を設定するかについて示す。これは、２つの方法で行なうことができる。最初の対応形式を、モジュール４０１および４０２ならびに対応するリソース・モジュール集合４１７および４１８によって例示する。この対応形式を用いる場合、各実行可能モジュールは、対応する一意のリソース・モジュール集合を有する。この場合、"myapp1.dll"と命名されている実行可能モジュール４０１は、対応するリソース・モジュール集合４１７を有し、一方、この集合は、"myapp1.dll.french.mui"および"myappl.dll.english.mui"と命名されているリソース・モジュール４１１および４１２を収容する。リソース・モジュールのファイル名の第１部分は、対応する実行可能モジュールのファイル名と同一である。これは、リソース・モジュール４１１および４１２を、実行可能モジュール４０１に対応する集合に属することを識別する。
【００６１】
同様に、"myapp2.dll"と命名されている実行可能モジュール４０２は、対応するリソース・モジュール集合４１８を有し、一方この集合は、"myapp2.dll.french.mui"および"myapp2.dll.english.mui"と命名されているリソース・モジュール４１３および４１４を収容する。
【００６２】
アプリケーション・プログラムまたは実行可能モジュールがリソース・マネージャからリソースを要求し、リソースを得ようとするモジュール４０１のような、特定の実行可能モジュールを特定すると、オペレーティング・システムのリソース・ハンドラは、最初に、特定された実行可能モジュールと関連するリソース・モジュール集合を特定する。これを行なうには、"myapp1.dll"のような特定された実行可能モジュールのファイル名に注目する。このストリングで始まるファイル名を有するいずれのリソース・モジュールも、特定された実行可能モジュールと関連するリソース・モジュール集合に属する。この場合、リソース・モジュール４１１および４１２が、"myapp1.dll"で始まるファイル名を有しており、したがって、特定されたモジュール４０１に対応する所望のリソース・モジュール集合に属する。
【００６３】
次に、リソース・ハンドラは、リソース・ハンドラに対する要求とは無関係に得られた言語識別子にしたがって、リソース・モジュールの集合の中から１つの集合を選択する。これを行なうには、特定されたモジュールのファイル名（"myapp1.dll"）で始まり、現言語識別子に対応する言語コードによって形成された拡張子が続き、その後に".mui"が続くリソース・モジュール・ファイル名を構築する。したがって、現言語識別子および対応する言語コードが「フランス語」である場合、リソース・ハンドラは、ファイル名"myapp1.dll.french.mui"を構築する。次いで、リソース・マネージャは、このファイルから要求されたリソースを検索し、要求元のアプリケーション・プログラムまたは実行可能モジュールにこれを供給する。
【００６４】
実行可能モジュールおよびリソース・モジュール間の第２の対応形式を、実行可能モジュール４０３および４０４、ならびにリソース・モジュール集合４１９によって例示する。本発明によれば、実行可能モジュールは共有リソース・リファレンスを収容している場合もある。各共有リソース・リファレンスは、異なる言語に対応するリソース・モジュール集合を特定する。記載中の実施形態では、共有資源リファレンスは、ファイル名またはファイル識別子の一部を示す。図６に示す例では、実行可能モジュール４０３および４０４は、各々、共有リソース・リファレンス４２０を収容する。適切なリソース・モジュール集合が、この例では"shared.dll"のようなリソース・ファイルのファイル名の最初の部分を指定するストリングによって特定される。この場合、異なる実行可能モジュール４０３および４０４は、同じ共有リソース・リファレンス"shared.dll"を収容している。したがって、これら２つの実行可能モジュールの各々は、単一の共有リソース・モジュール集合４１９を示す。
【００６５】
アプリケーション・プログラムまたは実行可能モジュールがリソース・マネージャからリソースを要求し、実行可能モジュール４０３または４０４のようなモジュールを特定してここからリソースを得ようとした場合、リソース・ハンドラは、関連するリソース・モジュールの集合を特定することによって応答する。これを行なうには、共有リソース・リファレンス、およびオペレーティング・システムによって維持されている現言語識別子双方にしたがって、ファイル名を選択または構築する。即ち、ファイル名を構築するには、共有リソース・リファレンス（この場合、"shared.dll"）に拡張子".language.mui"を添付する。ここで、"language"は現言語識別子に対応する言語コードである。次いで、リソース・ハンドラは、構築したファイル名を有するリソース・ファイルから、要求されたリソースを供給する。
【００６６】
この方式によって、リソース・モジュールを、多数の実行可能モジュールを有するプロジェクトに統合することができる。単一の実行可能モジュール毎に異なる英語リソース・モジュールを有する代わりに、単一の英語リソース・モジュールが複数の実行可能モジュールに対応することができる。これにより、複雑なアプリケーションにおいて必要とされる別個のリソース・モジュール数を大幅に削減する。
【００６７】
図７は、本発明のこの実施形態において実行するステップを示す。ステップ４３０は、リソース要求の受信から成る。この要求は、典型的に、アプリケーションまたは実行可能モジュールから、前述の"FindResource"および"LoadResourc"関数を介して、リソース・ハンドラに対してなされる。要求の一部として、アプリケーションは、要求したリソースの名称またはＩＤを指定し、更に、モジュールを示すモジュール識別子も与え、ここからリソースを得ようとする。モジュール識別子は、所望のモジュールに対応するオペレーティング・システム・ハンドルである。所望のモジュールは、オペレーティング・システムにはわかっているファイル名を有する。
【００６８】
ステップ４３１は、モジュール識別子によって特定されたモジュールが共有リソース・リファレンスを含むか否か判定することから成る。ここで記載中の実施形態では、共有リソース・リファレンスは、既定の名称または解明されている名称を有するリソースとして実装されている。記載中の実施形態は、リソース名"RT MUI"を用いる。このリソースの値は、リソース・モジュール・ファイル名の最初の部分を指定する、キャラクタまたはユニコード・ストリングにセットされる。例えば、"RT MUI"リソースは、図６におけるように、"shared.dll"にセットする場合もある。
【００６９】
ステップ４３１において、リソース要求において特定されたモジュール内の"RT MUI"リソースの存在を発見した場合、ステップ４３２を実行し、"RE MUI"リソース値によって特定されるリソース・モジュール集合から適切な言語のリソース・モジュールを選択する。記載中の実施形態では、"RT MUI"値は、ファイル名の最初の部分から成り、したがって、全て同じ値で始まるファイルの集合を特定する。拡張子を"RT MUI"共有リソース・リファレンスに添付することによって、適切な言語のモジュールを選択する。拡張子は、ストリング".language.mui"から成り、ここで"language"は、オペレーティング・システムの言語識別子によって示される言語に対応する言語コードである。
【００７０】
ステップ４３１において、リソース要求によって特定されたモジュール内において共有リソース・インディケータが発見されなかった場合、ステップ４３３を実行し、特定されたモジュールのファイル名によって特定されるリソース・モジュールの集合から、適切な言語のリソース・モジュールを選択する。特定されたモジュールのファイル名を、リソース・モジュール・ファイル名の最初の部分として用い、したがって、全て同じストリングで始まるファイル集合を特定する。ストリング".language.mui"から成る、特定されたモジュールのファイル名に、拡張子を添付することにより、特定のモジュールを選択する。ここで、"languageは、オペレーティング・システムの言語識別子によって示される言語に対応する言語コードである。
【００７１】
ステップ４３４の後に、ステップ４３２または４３３が続き、構築したファイル名によって特定されたリソース・モジュールから、要求された局在化リソースを与える。
【００７２】
このように、要求元モジュールによる、特定の言語を選択するための公然の作用なく、適切な言語のリソースを与える。
場合によっては、現言語識別子が示す言語が、特定のリソース・モジュール集合の中のリソース・モジュールによって表されないこともある。これに対処するために、リソース・ハンドラは、フォールバック機構を備え、言語識別子によって示された言語自体が得られない場合であっても、できる限り最良の言語選択を行なおうとする。即ち、リソース・モジュールのいずれもが言語識別子に一致しない場合、リソース・ハンドラは、以下の言語にしたがって、代わりのリソース・モジュールを降順の優先順位で選択する。
【００７３】
言語識別子によって示された言語の一次言語、
システムのデフォルト言語、
システムのデフォルト言語の一次言語、
米国英語
一次英語
「一次」という用語は、複数の部分集合を含む一般的な言語を意味する。例えば、「カナダのフランス語」を利用するシステムがある可能性もある。カナダのフランス語の一次言語は、単にフランス語である。「システム・デフォルト」言語は、コンピュータのコンフィギュレーションを最初に決めるときにセットされ、オペレーティング・システムの言語識別子によって現在示されている言語とは異なる場合もある。
【００７４】
以上、構造的特徴および／または方法論的ステップに特定した言葉で本発明を説明したが、添付の特許請求の範囲に規定した本発明は、必ずしも、ここに記載した具体的な特徴やステップに限定される訳ではないことは理解して当然である。逆に、特定の特徴およびステップは、特許請求する発明を実施する好適な形態として開示したのである。
【図面の簡単な説明】
【図１】同じ二進ファイルのリソース部にあるリソースを要求するプロセスを定義するコード部を収容した二進ファイルの概略図である。
【図２】２つの二進ファイルにおいて、一方がコードを収容し、あるリソースを収容するかまたはしない場合もあり、他方がリソースを収容しコードを収容するかまたはしない場合もあり、最初のファイルのコードが、２番目のファイルにおけるリソースをコールするプロセスを定義する場合を示す概略図である。
【図３】従来技術の一実施形態にしたがってリソースを検索するプロセスが用いるリソース・ローダおよびリソース・ファインダの概略図である。
【図４】コンピュータ上のプロセスによってリソースを検索するプロセスの一般化した記述において、リソース・ハンドラを示す概略図である。
【図５】図３に示す従来技術の変更において、オペレーティング・システムを通じてリソース・データムを要求するプロセスを示す概略図である。
【図６】本発明の一実施形態によるモジュールの編成を示すブロック図である。
【図７】本発明の一実施形態にしたがって実行するステップを示すフローチャートである。
【符号の説明】
１２５    リソース・データム
１４５    リソース・モジュール
３１０    プロセス
３２０    リソース・ファインダ
３２３    代替リソース・モジュール・テーブル
３２５    代替モジュール・パス
３３０    リソース・ローダ
３３５    選択した言語ＩＤ
３５０    リソース・データム
４０１，４０２，４０３，４０４    実行可能モジュール
４１１，４１２，４１３，４１４，４１５，４１６    リソース・モジュール
４１７，４１８，４１９    集合
【図１】
0004975222.tif 000002
【図２】
0004975222.tif 000003
【図３】
0004975222.tif 000004
【図４】
0004975222.tif 000005
【図５】
0004975222.tif 000006
【図６】
0004975222.tif 000007
【図７】
0004975222.tif 000008