JP5437455B2 - 代替リソースデータに動的にリダイレクトする方法 - Google Patents

Description

本発明は、概してオペレーティングシステムに関し、さらに特定すると、ユーザインタフェース言語を切り替えるための効率的な機構を提供するオペレーティングシステムに関する。

リソースは、例えばテキストファイルなどのバイナリデータまたは非バイナリデータである。ＷｉｎｄｏｗｓＮＴ（登録商標）およびＷｉｎｄｏｗｓ（登録商標）ファミリのそれ以外のすべてのＯ／Ｓでは、リソースはバイナリデータである。リソースデータは、アプリケーションの実行可能ファイル内に存在することができるため、実行可能ファイルはコードおよびリソースデータがその中にあるバイナリファイルである。コードによって定義されるプロセスは、専用のバイナリ実行ファイルまたはその他の実行ファイルでリソースを使用することができる。このようなプロセスによって使用されるリソースは、リソース専用ファイル、例えばリソース専用の動的リンクライブラリ（ＤＬＬ）内に存在することもできる。リソースは、標準またはユーザ定義のどちらかであってよい。標準リソース内のデータは、アイコン、カーソル、メニュー、ダイアログボックス、ビットマップ、機能拡張メタファイル、フォント、アクセレレータテーブル、メッセージテーブルエントリ、文字列テーブルエントリ、またはバージョンを記述する。

ユーザ定義リソースは、ある特定のアプリケーションによって必要とされる任意のデータを含む。オペレーティングシステムプロセスによって必要とされているリソースは、多様なさまざまなやり方で処理されてよい。これらのリソースの多くは、言語に特殊であるワード、記号、フォーマット化データ等を含む。通常、ある特定の言語は、ユーザによって選ばれるオペレーティングシステムインストールパッケージによって決定される。ソフトウェアの言語が英語である場合、英語に特殊なリソースだけがオペレーティングシステムとともにインストールされる。これは、すべての言語をカバーするためにハードディスク上にコピーされなければならないであろう大量の言語固有のリソースのために便利である。サポートするために、オペレーティングシステムに単一の言語を提供することも、それによって必要が生じた時に、メモリの中に、およびメモリの中からリソースを効率的にロードおよびアンロードすることができるため、便利である。すべてが常にメモリ内に常駐するにははるかに多すぎるリソースが存在する。これらのバイナリファイルが、リソースが不必要にメモリを占有しないようにリソースのロードおよびアンロードを管理するには、これらのバイナリファイルが、必要とされていない時にリソースが不必要にメモリを占有しないようにリソースのロードおよびアンロードを管理するために、このリソースおよびこのプロセスに特殊なこのリソースを必要とするプロセスを生成するこのコードが同じバイナリファイルに組み込まれてよい。プロセスが呼び出されると、このプロセスのためのこのコードを格納するバイナリファイルおよび添付リソースがメモリの中にロードされるか、あるいはそれ以外の場合、このプロセスによってアクセスできるようになってよい。このプロセスが終了すると、このリソースおよびこのようなファイルのコードセクションがメモリからアンロードされるか、あるいはそれ以外の場合アクセスできなくなる。これらのバイナリファイルは実行プログラム、動的リンクライブラリ（ＤＬＬ）、デバイスドライバ等であってよい。それらにすべての代替言語リソースが詰め込まれる場合には、過剰な量のメモリが必要とされるであろう。

１つのオペレーティングシステムがこのようなリソースを処理するという例は以下の通りである。第1に、オペレーティングシステムの機能であるリソースファインダが利用され、指定されたリソースの情報ブロックに対するハンドルを作成する。リソースを必要とするプロセスが、このファインダにリソースモジュールハンドルおよびこのリソース名、タイプおよび、オプションで言語ＩＤを送信する。後者は、このリソースモジュールハンドルで定められているこのリソース内の言語固有のリソースを指定する。このファインダは、この指定されたリソースの情報ブロックに対するハンドルを戻し、このプロセスはメモリにリソースを入れるためにリソースローダを呼び出すことができる。このプロセスは、このリソースハンドルおよびこのリソースモジュールハンドルを、リソースをメモリの中に格納し、このリソースを含むこのメモリブロックに対するハンドルを戻すこのリソースローダに与える。このプロセスはこのリソースを使用できる。このオペレーティングシステムは、それをメモリの中にロードするこのプロセスがもはやそれを必要としなくなり、終了された後に、あるいは他の状況がそれを必要とする場合に、このメモリを解放するために他のデバイスを使用してよい。前記は、例のオペレーティングシステム内のリソースアクセスファシリティの１つのタイプにすぎない。それ以外の機構は、テキストメッセージを出力バッファ内に格納し、単一関数呼出しのリソースデータに対するハンドルをただちにロードして戻すことによる等の他の方法でリソースを使用できるようにする。これらの機構の共通機能とは、それらがメモリの中またはディスクファイルまたはそれ以外の記憶装置システムの中のどちらかでリソースを検出し、このリソースを、それを要求するプロセスが使用できるようにすることである。これは、ディスクからファイルをメモリの中にロードする、あるいはハンドルまたはそれ以外の何らかのデバイスを提供することによって、単にリソースにアクセスを提供することを伴ってよい。このリソースを格納するこのファイル（、デバイス、またはチャネル）は、この要求側プロセスまたは別のファイルを定めるコードと同じファイルの中にあってよい。このそれ以外のファイルはコードを格納するか、あるいはリソース専用ファイルである場合がある。プロセスは、それがもはや必要としないリソースを明示的にアンロードする必要がない場合がある。

ディスク記憶装置のコストが低い場合、いくつかの例では、オペレーティングシステムの同じインストールが、ユーザにトランスペアレントに、多数の言語にとって適切なリソースを提供することが望ましい場合がある。これにより、多様な言語のユーザは、同じコンピュータを共用できるようになるであろう。ユーザは、ログオンし、所望の言語を選択し、このコンピュータを使用し、その後で選ばれた言語の中のすべてのリソースをベースにしたオペレーティングシステム機能を見るであろう。しかしながら、前記リソース管理体制の回りに構築されたオペレーティングシステムにとって、このオペレーティングシステムを修正し、選択可能な言語に対処するために使用できるオプションは、後述されるように極めて問題があると考えられる。

多言語サポートを提供するためには、あるオプションは、言語ごとにバイナリファイルの異なるセットを提供することである可能性がある。複雑なオペレーティングシステムに、言語固有のリソースを格納する約数千のバイナリファイルがある可能性があり、多くの異なる言語をサポートすることが所望される可能性があることを考えると、インストールされるバイナリファイルの数は実際に大きくなるであろう。ユーザによる言語の選択に備えるために必要とされる労力に加え、ファイルの結果的に生じる質量の冗長性は、すべての言語に特殊ではないリソースが、サポートされている言語ごとに重複されるためにはなはだしいものとなるであろう。言語に特殊ではないリソースが重複を必要とするだけではなく、すべてのコードセクションも必要とするであろう。

別のオプションは、異なる言語を必要とする新規ユーザがログオンするたびに、オペレーティングシステムバイナリファイルを新規にインストールすることである可能性がある。このオプションは、それがかなりの量の時間を要するため魅力的ではない。

依然として別のオプションは、各バイナリファイルに異なった言語に固有のリソースを提供することである可能性がある。これは、各バイナリファイルが言語固有のリソースを追加するだけであるため、第1のオプションの冗長性を排除するであろう。しかしながら、このオプションは、各バイナリファイルの再コード化を必要とするであろうため、それはやはり精密で簡潔なオプションではない。これに類似したものが現在非常に限定的に実行されている。いくつかのバイナリファイルは、それぞれがユーザの言語または国に応じて好ましい代替リソースを格納する。これらのバイナリファイルのこのコードセクションは、リソースの好ましい言語に関する「推測」に基づいて異なったリソースをアドレス指定するプロセスを定義する。この「推測」は、例えば、日付フォーマットが選択されているシステムパラメータの設定値に基づいて行われる。したがって、例えば、ロシア様式の日付が選択されると、ロシア語としてタグが付けられたリソースがロードされる可能性がある。

現在、限られた根拠に基づいた言語選択を実現する少なくとも１つの種類のオペレーティングシステムがある。このオペレーティングシステムは、それぞれの言語に別個のテキストファイルを提供する。プロセスがある特定の言語でのテキストファイルリソースを必要とすると、オペレーティングシステムは適切なファイルをアドレス指定する。ユーザは、システム変数を通して選択の自分のデフォルト言語を選択することができる。簡略に言及されるように、少なくとも１つのカレントオペレーティングシステム（Ｗｉｎｄｏｗｓ（登録商標））は、例えばテキストメッセージなどの言語固有のライブラリの作成に何らかのサポートを提供する。オペレーティングシステムインストールの現地（ｌｏｃａｌｅ）（システムの現地とは言語の設定値ではないことに注意する。現地とは、言語と場所の混合である）を示すシステム変数が定義され、この変数は、特にカレント言語用のフォーマットメッセージをフォーマットするために、オペレーティングシステム上で実行しているアプリケーションによって使用することができる。しかしながら、これには、プロセス（アプリケーション）が適切な言語リソースおよびそれがどこに位置しているのかを正確に特定することが必要となる。変換のためのモデルとして、それは広範囲な再コード化を伴うであろう。

従来の技術のオペレーティングシステム制度のどれも、非常に自動的にオペレーティングシステムによって多言語サポートを提供する方法を示唆するモデルを提供しない。また、誰も、同じファイル内にコードおよびリソースのセクションを持つバイナリファイルの固有の節約の工夫のいくつかを保存する手段を示唆していない。所望される機能性を提供するために前記に示唆された簡略な変換は、冗長なデータが必要とされるという点で不当に高価、および／またはかさばっていると考えられている。容易に実現できる変換は、従来の技術のシステムのどれかから著しく離れたシステムでなければならないであろう。

図１を参照すると、従来の技術のオペレーティングシステムでの共通動作において、バイナリファイル２０がロードされる。このバイナリファイル２０は、コードセクション１０およびリソースセクション３０を含み、オペレーティングシステムの任意のファイルユニットまたはサードパーティによって供給されるものであってよい。例えば、このバイナリファイル２０は、実行可能バイナリ、動的ライブラリ（ＤＬＬ）またはデバイスドライバであろう。このリソースセクション３０は、このコードセクションによって使用されるリソース、特にこのコードセクション１０によって生成されるプロセスの要件に特定であり、このコードセクション１０に定められているプロセスがもはや必要とされない時にメモリからアンロードされてよいそれらのリソースのいくつかを含んでよい。言い換えると、このリソース３０とは、このコードセクション１０で符号化されるプロセスによって必要とされることのあるリソースであり、いったんそれらのプロセスが終了されると、メモリ内のリソースセクション３０に格納されているこのリソースを維持する必要性はなくなる。例えば、バイナリファイル１０は、コアリソースまたは剥奪されたテキストエディタなどのオペレーティングシステムが供給されるアプリケーションであろう。例えば、エディタにとっては、ユーザがエディタプログラムを終了すると、このテキストエディタによって必要とされるリソースはもはや必要とされないであろう。コード１０およびリソース３０を含むバイナリファイル２０は、メモリから削除されるであろう。言うまでもなく、このコードセクション１０は、他のファイルからその他のリソースを使用し、その他のプロセスも使用することができる。

図２を参照すると、リソース８５およびそれを使用するコード５５は、別個のそれぞれのファイル２５と２２に位置していてもよい。例えば、１個のコード５０に定義されるアプリケーション５５によってアドレス指定されるリソース８５は、リソース専用ＤＬＬまたはコード７０およびリソース６０を含む別個のファイル２５に含まれてよい。このアプリケーション５５は、やはりリソース４０を含むファイルに存在してよい。リソースタイプおよび名前でファイルを検索するために、別のオペレーティングシステムデバイスが使用されてよい。リソースの管理（ロードおよびアンロード）は、リソースローダによって処理されてよい。

図３を参照すると、リソースは、リソースローダ１３０およびリソースファインダ１３５を使用してプロセス１１０によって指定されている。このリソースローダは、リソースモジュールハンドルおよびリソースハンドルを与えられるリソースデータ１２５へアクセスを提供するオペレーティングシステムファシリティである。リソース名で指定されるリソースデータがどこで検索できるのかを示すこのリソースモジュールハンドルは、このリソースファインダによって作成される。リソース名、タイプおよび言語（後者はオプション）が、メモリハンドルを返すリソースファインダ１３５に提供される。リソースが要求側プロセスを生成したモジュール以外のモジュール内にある場合には、そのモジュールのハンドルもこのリソースファインダに提供されなければならない。このリソースタイプは、例えば、ビットマップ、動画カーソル、フォントリソース、メニューリソース、文字列テーブルエントリ等を指定してよい。

このリソースローダは、指定されたリソースをメモリの中にロードする。それは、リソースモジュールハンドルおよびリソースハンドルを必要とする。このリソースモジュールハンドルは、その実行可能ファイルにリソースが入っている。このリソースハンドルはロードされるリソースを識別する。このリソースローダ１３０は、このリソースに関連するデータを含むこのメモリブロックへのハンドルを返す。図３に示されている説明は、図１または図２に図示されている状況のどちらかと一貫性がある。前記機能の例が、Ｗｉｎｄｏｗｓ（登録商標）ＡＰＩＦｉｎｄＲｅｓｏｕｒｃｅおよびＬｏａｄＲｅｓｏｕｒｃｅに関係するマイクロソフト社のウエブページ等において定められていることに注意する。また、リソースが前述されたようにリソースに対する呼出しの一部だけではなく従来の動作においてもロードされてよいことにも注意する。例えば、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムでは、ＬｏａｄＬｉｂｒａｒｙに対する呼出しは、モジュールのメモリ内へのロードを生じさせるであろう。

図４を参照すると、リソースがオペレーティングシステム内でどのようにアドレス指定されてよいのかに関する一般化された概略が図示されている。リソースハンドラ２３０は、リソースデータ２２０へのアクセスを得るためにプロセス２１０によって使用される。このリソースハンドラ２３０は、例えば、図３に関して前述されたように、オペレーティングシステムによって提供される複数の異なるデバイスから成り立ってよい。このプロセスは、このハンドラ２３０に対して要求されたリソースを特定し、このハンドラに、ファイル名、モジュール２５０の識別子、または他の何らかの情報などのこのリソースがどこで検出できるのか教えることができる。このリソースハンドラ２３０は、おそらくモジュール２５０の中に含まれているリソース２２０を、メモリあるいはデータをアクセス可能にし２４０、プロセス２１０へのアクセスを提供するためのそれ以外の何らかの手段の中にロードする必要がある場合がある。該プロセス２１０には、リソース２２０にアクセスするためにハンドル、アドレス、ポインタ等が与えられる。図４によって記述されるプロセスの重要な特徴とは、プロセスが必要とされるリソースを特定し、オペレーティングシステムがプロセスにそのリソースに対するアクセスを提供することである。このリソースは、通信ポート、あるいはコンピュータ上のプロセスにデータを転送するための任意のそれ以外の機構を通して提供される、ネットワークによって接続される別のコンピュータ上のディスクに存在してよい。オペレーティングシステムは、要求の一部として、さまざまな媒体、例えば、ディスクからメモリへ、プロセスによるリソースへのアクセスが可能になる前にリソースを転送してよい。

オペレーティングシステム方式は、リソースを要求するプロセスからあらゆる特定の命令を必要としないで、複数言語リソースを処理するための機能を提供するリソースハンドリング構成要素を提供する。これにより、オペレーティングシステムは、これらの要素を修正しなくても、既存のリソースおよび実行可能バイナリファイルを使用しながら多言語サポートを提供できるようになる。すなわち、ユーザは、ユーザインタフェース用の言語を選択できるようになり、リソースローダは、リソースに対する要求を自動的に適切なリソースにリダイレクトするであろう。

以下の説明を通して、データをメモリにロードするという概念は、実際にデータをファイルから取り、それをメモリの中に入れるとして文字通り解釈されることは意図されていない。本発明によって熟慮されるオペレーティングシステムのコンテキストでは、データを物理メモリの中に実際にロードすることが、低レベルのオペレーティングシステム機能によって実行される。各プロセスは、実際の物理メモリと一致しない仮想メモリ空間を有してよい。以下の説明の中で、データをメモリの中からロードしたり、アンロードするというステップが語られる時、それはデータにプロセスがアクセスできるようにする任意のオペレーティングシステム機能として幅広く解釈されることが意図されている。

リソースを要求するプロセスという観点から、オペレーティングシステムデバイスとの対話は単一言語のリソースを処理するためと同じである。リソースを見つけ、それらを要求側プロセスに戻すためのオペレーティングシステムリソース処理構成要素は、代替言語リソースモジュールへのパス（ｐａｔｈ）を動的に生成するために修正される。このパスのこの生成は、リソース識別子およびリソースを要求しているプロセスによって提供されるオプションのモジュールハンドルに応えて、およびユーザインタフェース用に選ばれた言語を指定するシステム全体で動作するユーザ設定に応えてでもあってよい。代替言語リソースへのこのパスは、あるのであれば、プロセスによって供給されるモジュールハンドルの代わりに使用される。

このモジュールハンドルを動的に生成することにより、このオペレーティングシステムは、基本モジュールハンドル（呼出し側プロセスによって使用されるハンドル）と代替言語リソースモジュールを相互に関連付けるために任意の恒久的なファシリティに修正を加えなくても拡張されてよい。ルックアップテーブルが動的に生成されるため、それはステップを節約する目的で自動的に作成される。新しいモジュールがオペレーティングシステムに追加されると、代替言語モジュールを追加し、アルゴリズムを使用し、代替モジュールハンドルを生成することができる。新しいモジュール名と既存のモジュール名の間に不調和がない限り、このモジュールおよびそれを使用している任意のコード、あるいはコードおよびリソースを格納している任意のバイナリファイルが、あらゆる集中化された変更を加えないでオペレーティングシステムに追加されてよい。システムは、必要に応じて、およびユーザおよびリソースを要求するプロセスにはトランスペアレントに、代替言語モジュールを自動的にロード、解放し、処理する。代替言語リソースはモジュール（好ましいインプリメンテーションにおいて、Ｗｉｎｄｏｗｓ（登録商標）用語で定められるように、動的リンクライブラリつまりＤＬＬ）内に存在し、それぞれが、パスおよびモジュール名によって以下のように一意に指定されている。

＜ｍｏｄｕｌｅ＿ｐａｔｈ＞＼ｍｕｉ＼＜ｌａｎｇｕａｇｅ＿ＩＤ＞＼＜ｍｏｄｕｌｅ＿ｎａｍｅ＞
言い換えると、オペレーティングシステムは、元のモジュールのロードパスの言語固有のサブディレクトリから代替言語リソースモジュールをロードする。パスおよびモジュール名は、要求側プロセスによって供給されている元のモジュール名と同じ名前を使用して動的に生成される。要素＜ｌａｎｇｕａｇｅ＿ＩＤ＞は、言語を表すコンパクトコードであってよい。例えば、それはＩＳＯ６３９言語規格省略語に、おそらく復言語指定子つまり一次構成要素および二次構成要素を含むＷｉｎ３２言語ｉｄを追加したものに基づくであろう。

代替言語は、変化する特異性の度合いに伴い要求されてよい。すなわち、ある人は特異性のあるレベルで（フランスの）フランス語、スイスのフランス語またはカナダのフランス語を要求するか、特異性の低い方のレベルでフランス語だけを要求してよい。堅牢であるために、代替言語リソースモジュールハンドルを生成するプロセスの場合、アルゴリズムは、それが、ユーザインタフェース言語に対するシステムレベルの要求を、ある特異性の度合い、および別の度合いの特性が与えられている代替言語リソースの可用性と調整が付くようにすることができるために複数のステップを含んでよい。例えば、ユーザがオペレーティングシステムにログした時にスイスのフランス語を要求すると仮定する。これは、準拠することができるすべてのプロセスに対し、そのスイスのフランス語のリソースが使用されることを命令するユーザ変数を指定する。代替言語リソースを生成するリソースローダ（つまりライブラリローダ）アルゴリズムは、要求された言語に対する近似だけが使用できる状況に対処することができなければならない。前記例において、特にスイスのフランス語だけではなく、フランス語および多様なそれ以外の一次代替言語だけが使用できると仮定する。アルゴリズムが、システムユーザ言語ＩＤに示されているシステムレベル命令に近くない何らかのそれ以外のデフォルトの選択を行うよりむしろ、要求時にフランス語代替言語リソースをロードすることが望ましい。このようにして、例えば、以下のように、複数のレベルの近似がアルゴリズムに対して定められてよい。

第１に、このアルゴリズムは、「＜ｍｏｄｕｌｅ＿ｐａｔｈ＞＼」によって指定されるモジュールパス内に、カレントユーザ言語ＩＤに同等な識別子が付いた、つまり名前「＼ｍｕｉ＼＜ｌａｎｇｕａｇｅ＿ＩＤ＞＼」が付いたサブディレクトリが存在しているかどうかを判断してよい。この第１試験が不合格となると、このアルゴリズムは、カレントユーザ言語ＩＤに一致する一次言語ＩＤに同等な識別子が付いた、つまり名前「＼ｍｕｉ＼＜ｐｒｉｍａｒｙ＿ｌａｎｇｕａｇｅ＿ＩＤ＞＼」が付いた「＜ｍｏｄｕｌｅ＿ｐａｔｈ＞＼」のサブディレクトリが存在するかどうかを判断してよい。システムユーザ言語ＩＤが指定されない場合、このアルゴリズムはサブディレクトリを解決するために代用物（ｓｕｒｒｏｇａｔｅ）、例えば、日付または通貨フォーマット規約に関する好みのようなユーザの場所（ｌｏｃａｌｉｔｙ）を示唆する何らかの好みを使用することができる。代わりに、言語中立代替リソースモジュールが呼び出されてよい。所望の優先順位で設けられてよいそれ以外のステップは、デフォルト代替言語リソースサブディレクトリ、ユーザ言語ＩＤによって指定されている言語が使用できないが、ありそうな現場で話されている公正な代替言語が使用できる代替言語の選択であろう。例えば、カナダのフランス語がユーザ言語ＩＤで要求され、カナダのフランス語もフランス語も使用できないがカナダの英語が使用できる場合には、後者が使用されるであろう。好ましい代替リソースを優先システムに従って識別する前記プロセスによって、代替言語リソースの特異性を高めることができる。オペレーティングシステムに一次言語（例えば、英語であるが、英国英語、カナダ英語等ではない）だけが添付されている場合には、ユーザは、後にさらに多くの特定の言語を追加し、ユーザの選択はトランスペアレントかつ自動的に実現されてよい。

処理を加速するために、各代替モジュールパスを動的に生成することによって得られるマッピングがルックアップテーブルに保存される。要求側プロセスが同じリソースを呼び出すと、この代替リソースモジュールが、パスおよびハンドルを動的に生成する代わりに、このルックアップテーブルから得られてよい。代替リソースモジュールＩＤの動的生成の結果を保存することによって、前述された堅牢なアルゴリズムのステップは、リソースに対する要求がなされるたびに反復される必要がない。

加えて、クリーンアップテーブルが生成され、修正されたリソースローダが、システム要件が許すようにメモリをロードし、解放するのを助ける。このクリーンアップテーブルは、ロード済みの代替リソースモジュールおよびそれらを要求したプロセスを一覧表示する。例えば、リソースを要求しているプロセスが終了されると、この終了したプロセスによって要求されていたリソースモジュールはメモリからアンロードされてよい。

オペレーティングシステムが、ローダデータテーブル内でエントリを生成することによってロードおよびアンロードされるリソースを追跡調査することに注意する。このローダデータテーブルは、このプロセスが終了した時、またはそれ以外のシステム要件が示す時、これらのモジュールをアンロードできるように、リソースモジュールのロードを必要としたプロセスを示す。例えば、ＷｉｎｄｏｗｓＮＴ（登録商標）内でＬｏａｄＬｉｂｒａｒｙＥｘ機能を直接的に使用することによってロードされるモジュールの場合、このモジュールのアイデンティティは、前述されたリソースローダには「既知」でない場合がある。すなわち、ローダデータテーブルエントリは生成されない。この場合、リソースモジュール（例えば、ＬｏａｄＬｉｂｒａｒｙ）をロードするファシリティは、代替言語リソースの存在に関して照会し、アプリケーションによって要求されたモジュールの代わりにそれをロードしてよい。アプリケーションまたはプロセスが、実際にローダデータテーブルエントリを生成するオペレーティングシステムファシリティを実際に使用する場合は、このモジュールは、アプリケーションまたはその他のプロセスによってリソースローダからリソースに対する要求がなされるまで、モジュールがロードされる必要はないであろう。

実施態様によると、本発明は、オペレーティングシステムによって実行される方法である。方法は、第１バイナリファイル内に存在する第１データに対する要求側プロセスによる要求をリダイレクトする。次に示すステップが実行される。つまり、（１）言語識別子および第１データまたは第１バイナリファイルのどちらかの識別子にも一致する第２バイナリファイルが存在する時に、オペレーティングユーザ設定内にこの要求側プロセスとは無関係に、言語識別子を記憶するステップと、（２）第１バイナリファイルを識別するプロセスモジュール識別子と、第２バイナリファイルを識別する代替モジュール識別子とを相互に関連付けるルックアップテーブルの中にパスを記憶するステップと、（３）第２バイナリファイル内の代替データを、第１データの代わりにこの要求側プロセスがアクセスできるようにするステップのことである。

別の実施態様によると、本発明は、オペレーティングシステムにより実行される方法でもある。方法は、この要求側プロセスを定義する実行可能コードとリソースデータの両方を格納する第１バイナリファイル内に存在する第１リソースデータに対する要求側プロセスによる要求をリダイレクトする。この要求側プロセスは、コード内で定義されている。この方法は、以下のステップを有する。つまり、言語識別子に、および変数の中に、この要求側プロセスとは無関係に言語識別子を記憶するステップと、第１リソースデータまたは第１バイナリファイルのどちらかにも一致する第２バイナリファイルが存在する時に、（１）言語識別子および第１リソースデータまたは第１バイナリファイルのどちらかに応じて第２バイナリファイルへのパスを動的に生成するステップと、（２）第１リソースデータの代わりに、第２バイナリファイル内の代替リソースデータにこの要求側プロセスがアクセスできるようにするステップである。

さらに別の実施態様によると、本発明は、実行可能バイナリファイル内の第１リソースデータをアドレス指定するために、多言語機能をオペレーティングシステムに追加する方法である。方法は、以下のステップを含む。つまり、選択された言語識別子を記憶するために選択可能なユーザ設定値を追加するステップと、それぞれが第１リソースデータのそれぞれ１つに対応するリソースデータを格納する少なくとも１つの代替言語リソースファイルを追加するステップと、選択された言語識別子内に記憶される選択された言語に応えて、代替言語リソースデータのそれぞれ１つへ、第１リソースデータのそれぞれに対する要求をリダイレクトするために、コンピュータが、前記オペレーティングシステムに含まれるプロセスを修正するステップである。

実施態様によると、本発明は、オペレーティングシステムによって実行される方法である。方法は、第１データに対する要求側プロセスによる要求に応じてデータをアドレス指定する。方法は、以下のステップを有する。つまり、第１データに対応する代替言語ファイルの存在を判断するステップと、判断するステップの結果が、代替言語ファイルが存在することを示す時に、この呼出しプロセスに代替言語ファイルから少なくとも１つのデータを戻すステップと、判断するステップの結果が、代替言語ファイルが存在しないことを示す時に、この呼出しプロセスに第１データを戻すステップである。

実施態様によると、本発明は、オペレーティングシステムによって実行される方法である。方法は、第１バイナリファイル内に存在する第１データに対する要求側プロセスによる要求をリダイレクトする。次に示すステップが実行される。つまり、オペレーティングシステム変数の中に、ユーザごとのこの要求側プロセスとは無関係に、言語識別子を記憶するステップと、言語識別子に対応する第２バイナリファイルの検出に応えて、および第１データまたは第１バイナリファイルのどちらかの識別子にも応えて（１）言語識別子および第１データまたは第１バイナリファイルのどちらかに応えて第２バイナリファイルへのパスを動的に生成するステップと、（２）第１バイナリファイルを識別するプロセスモジュール識別子と第２バイナリファイルを識別する代替モジュール識別子を相互関連するルックアップテーブルの中にパスを記憶するステップと、（３）第１データの代わりに、第２バイナリファイル内の代替データにこの要求側プロセスがアクセスできるようにするステップである。

同じバイナリファイルのリソースセクション内のリソースを要求するプロセスを定義するコードセクションを含むバイナリファイルの概略図である。 その内の一方が、コードを格納し、リソースを格納しても、格納しなくてもよく、その内の他方がリソースを格納し、コードを格納しても、格納しなくてもよい２つのバイナリファイルの、第１ファイルのコードが、第２ファイル内のリソースを要求するプロセスを定義する概略図である。 従来の技術の１つの実施態様に従ったリソースを検索するためにプロセスによって使用されているリソースローダおよびリソースファインダの概略図である。 コンピュータ上のプロセスによってリソースを検索するプロセスの一般化した説明の中のリソースハンドラの概略図である。 図３に図示されている従来のプロセスの修正の中のオペレーティングシステムを通して、リソースデータを呼び出すプロセスの概略図である。

図５を参照すると、図３に図示されている従来の技術によるプロセスの修正において、オペレーティングシステムを通してリソースデータを要求するプロセスが図示されている。図３に関して説明されているリソースローダ１３０およびリソースファインダ１３５内のプロセスが、図５に示されているようなプロセスを作成するために修正される。すべてを包含する用語では、図５のプロセスが、プロセスがプロセス用のデフォルトのリソースの代わりに、選択されたユーザインタフェース言語に対応するリソースを受け取るように、ある特定のリソースに対する要求を代替言語リソースにリダイレクトする。実施態様においては、代替リソースのロードは、プロセスが、それがロードを希望する言語を指定しなかった場合に「動き出す」だけである。言い換えると、プロセスは、リソースをロードしようとし、どの言語かについては実際には気にしていない。従来のシステムにおいては、リソースローダは、モジュール自体のリソースセクション、またはプロセスがその中からリソースをロードするように指定される外部モジュールのどちらかからリソースを戻すであろう。多言語ユーザインタフェースシステムの現在の実施態様においては、リソースローダは、プロセスがある特定の言語またはリソースに対するそれ以外の特定の分類を指定しなかった場合には、代替リソースをロードするであろう。このプロセスは、まさに図３の従来の技術の実施態様でのように、リソースファインダ３２０からメモリハンドルを要求する。しかしながら、この場合、このハンドルは代替言語リソースを参照するハンドルである。リソースファインダは、選択されたユーザインタフェース言語ＩＤ３３５によって示されるリソースを識別しようとする。

選択されたユーザインタフェース言語ＩＤ３３５は、ユーザ設定値である。この選択されたユーザインタフェース言語ＩＤ３３５は、例えば、ユーザがログインし、オプションのリストから任意の言語を選択することによって確立できるであろう。それから、このユーザインタフェース言語ＩＤ３３５は、変更されるまで記憶されている。

プロセス３１０は、リソースファインダ３２０にリソース名およびタイプを送信することによってリソースのメモリハンドルを要求する。リソースが、この要求側プロセス３１０を定義するモジュール以外のモジュールの中にあると、リソースモジュールハンドルもリソースファインダ３２０に送信されるであろう。モジュールハンドルが送信されない場合、このモジュールはこのリソースを要求するプロセスを生成するモジュールと同じであるため、リソースファインダはすでにローダデータテーブルからモジュールハンドルに対するアクセスを得ている（背景の項に説明されたように、リソースファインダおよびリソースローダは、多くの場合、要求側プロセスを生成するコードと同じバイナリファイル内のリソースにアクセスするために使用される）。プロセスが、言語に特殊であるリソースを要求することも可能であり、このような要求を満たすプロセスは、本発明に関する、および従来の技術による方法によって満たされるステップの外にあってよい（例えば、ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｍｓｄｎ／に説明されているＬｏａｄＲｅｓｏｕｒｃｅの説明の例を参照すること）。後者の場合、言語ＩＤはリソースファインダに渡されてよい。

オペレーティングシステムは、過去にリソースファインダ３２０に対する呼出しによって生成された、代替リソースモジュールハンドルのテーブル３２３を維持するために修正される。したがって、別のプロセスがすでに同じモジュールからリソースを要求しており、モジュールがすでに代替リソースモジュールに相互に関連付けられている場合には、この代替モジュールハンドルは代替リソースモジュールテーブル３２３から迅速に入手できる。このリソースに対しエントリがない場合には、オペレーティングシステムは代替モジュールパスを動的に生成する。

代替モジュールパスを動的に生成するために、アルゴリズム３２５が利用される。このアルゴリズム３２５は、リソースファイルの何らかの仮定された編成に基づいてよく、代替言語リソースファイルが指定されたリソースに存在するかどうかを示す。本実施態様においては、この代替言語リソースファイルは、要求されたモジュールのパスのサブディレクトリ内に位置し、それぞれが言語識別子に一意に相互関連付けられているファイル名で区別される。各言語のサブディレクトリ内には、それぞれが元のモジュールの名前を取って名前が指定された代替言語リソースファイルが記憶される。

＜ｍｏｄｕｌｅ＿ｐａｔｈ＞＼ｍｕｉ＼＜ｌａｎｇｕａｇｅ＿ＩＤ＞＼＜ｍｏｄｕｌｅ＿ｎａｍｅ＞
言い換えると、オペレーティングシステムは、元のモジュールのロードパスの言語固有のサブディレクトリから代替言語リソースモジュールをロードする。この元のモジュールが、多言語イネーブルされていなかったシステムの場合に「＜ｐａｔｈ１＞＼＜ｆｉｌｅｎａｍｅ １＞」であった場合、代替言語モジュールに対するパスは、選択されたユーザインタフェース言語ＩＤ３３５で示されるが「言語ＩＤ１」であると仮定すると「＜ｐａｔｈ１＞＼ｍｕｉ＼＜ｌａｎｇｕａｇｅ ＩＤ１＞＼＜ｆｉｌｅｎａｍｅ１＞」であろう。

代替言語リソースの編成は、多様な代替方法で実行できる。それらを、それぞれが通例のモジュール（通常、単一言語オペレーティングシステムで要求されるもの）に対応する言語固有のモジュールに分けると、それぞれのリソースモジュールごとに多様な言語のリソース単一モジュールに結合される場合に発生するように、追加メモリに対するニーズが
回避される。

モジュールを記憶するために使用されるパス構造を考えると、選択されたユーザインタフェース言語ＩＤ３３５および元の要求されたパスとモジュールによって示される言語に対応する代替言語モジュール用のパスを構築することは容易である。このパスは、リソースハンドルを提供するためにリソースファインダ３２０によって使用される。リソースハンドルの作成は、従来の技術と同じように実行される。相違点は、この例のリソースハンドルがプロセスを、元のモジュールパスのサブディレクトリ内で識別されたリソースデータ３５０に向けるという点である。図５では、リソースデータ３５０は、選択されたユーザインタフェース言語ＩＤが言語ＩＤ２であった「バイナリファイル２」用の代替リソースモジュール内にあった。

パスおよびモジュール名は、呼出し側プロセスによって供給される元のモジュール名と同じ名前を使用して動的に生成される。要素＜ｌａｎｇｕａｇｅ＿ＩＤ＞は、言語を表すコンパクトコードであってよい。例えば、それは、ＩＳＯ６３９言語標準省力に副言語記述子または一次構成要素と二次構成要素を加えたものを含むＷｉｎ３２言語ｉｄに基づくことができるであろう。

本発明の好ましい実施態様においては、アルゴリズムは、それが、要求されたデータに対する代替言語リソースが存在すると仮定して、単にパスを構築する以上のことを行うという点で堅牢である。代替言語は、多様な特性の度合いで要求されてよい。また、代替言語リソースが使用可能ではない、あるいは代替リソースが使用可能であると考えられ、このリソースは言語以外の何らかの点と基本リソースと異なっている。このアルゴリズムおよび対応するプロセスは、図５に描かれている率直なシナリオだけではなくこれらの状況に対処し、利用するにも十分堅牢である。

選択されたユーザインタフェース言語は非常に特殊である。例えば、ユーザはフランス語、スイスのフランス語またはカナダのフランス語を要求することがある。このアルゴリズムは、それがユーザインタフェース言語に対するシステムレベル要求をある特異性の度合い、および別の特異性の度合いが与えられる代替言語リソースの可用性と調整をつけることができるようにするための複数のステップを含んでよい。ユーザが、オペレーティングシステムにログインした時にフランスのフランス語を要求すると、要求された言語に対する近似だけが使用可能となってよい。このような状況と対処するため、このアルゴリズムおよび関連するプロセスは、以下のように、ステップの内蔵された階層に従って動作してよい。

第１に、このアルゴリズムは、「＜ｍｏｄｕｌｅ＿ｐａｔｈ＞＼ｍｕｉ＼」によって指定されるモジュールパスの中に、カレントユーザ言語ＩＤに同等な識別子が付いた、つまり名前「＼＜ｌａｎｇｕａｇｅ＿ＩＤ＞＼」が付いたサブディレクトリが存在するかどうかを判断してよい。この第１試験が不合格となると、このアルゴリズムは、カレントユーザ言語ＩＤに対応する一次言語ＩＤに同等な識別子の付いた、つまり名前「＼ｐｒｉｍａｒｙ＿ｌａｎｇｕａｇｅ＿ＩＤ＼」が付いた「＜ｍｏｄｕｌｅ＿ｐａｔｈ＞＼ｍｕｉ＼」のサブディレクトリが存在するかどうかを判断してよい。システムユーザ言語ＩＤが指定されない場合、このアルゴリズムはサブディレクトリを解決するために代用物、例えば日付または通貨フォーマット規約に関する好みなどのユーザの場所を示唆する何らかの好みを使用することができてよい。代わりに、言語に中立な代替リソースモジュールが呼び出されてよい。所望の優先順位で設けられてよいそれ以外のステップは、例えばカナダのフランス語がユーザ言語ＩＤで要求され、英語が使用できる場合など、デフォルトの代替言語リソースサブディレクトリ、ユーザ言語ＩＤによって指定された言語が使用できないが、所定の代替言語が多くの場合、考えられる現地で話される代替言語の選択であろう。好ましい代替リソースを優先順位システムに従って識別する前記プロセスによって、代替言語リソースの特異性を高めることができる。オペレーティングシステムに一次言語（例えば、英語であるが、英国英語、カナダ英語等ではない）だけが添付される場合、ユーザは、後に、さらに多くの特定の言語を追加し、ユーザの選択はトランスペアレントかつ自動的に実現されてよい。

前記機能性が、Ｗｉｎｄｏｗｓ（登録商標）のＦｉｎｄＲｅｓｏｕｒｃｅＥｘ機能で行われるある特定の言語のリソースに対する通常の要求と干渉しないことに注意する。指定された言語ＩＤは要求側プロセスによって提供され、前記代替言語リソース方式は要求を別のリソースモジュールに再送しないであろう。

パスを形成するアルゴリズム３２５がリソースパスを決定した後、バージョンチェックおよびそれ以外のあらゆる完全性チェックは、それに要求側プロセスがアクセスできるようにする前に実行することができる。図５に関して説明されるプロセスの結果として代替言語モジュール３７０がメモリ内に新規に格納された、あるいはそれ以外の場合、リソースファインダ３２０への呼出しによってアクセスできるようになった場合、新しいエントリが代替リソースモジュールテーブル３２３の中に入れられてよい。最後に、ハンドルは、このプロセスが要求されたリソースにアクセスできるようにするために要求側プロセスに戻されてよい。後者は、データをメモリの中にロードし、プロセスがデータにアクセスするために使用できるハンドルを提供するために、別の機能に対するステップ、リソースローダ３３０を必要とすることがある。

図５および付随する説明が、モジュールがメモリの中にロードされ、これがリソースファインダまたはリソースロードによっても明示的に実行される必要がないことに注意する。唯一の要件は、適切なデータをプロセスが使用できることである。オペレーティングシステムは、そのＩ／Ｏファシリティおよびメモリ管理ファシリティを通したデータの実際の移動を処理してよい。図５に関して前述されたことの重要性とは、その内容がさまざまな言語に関して異なるリソースに対するプロセスによる要求が、要求側プロセスにトランスペアレントに自動的にリダイレクトさせられるという点である。プロセスを定義するコードは、オペレーティングシステムが多言語イネーブルされるために修正される必要はない。図５および添付説明は、実行可能コードも格納するバイナリファイル内に組み込まれるリソースというコンテキストでデータに対する要求をリダイレクトするプロセスを説明する。同じ基本的な公式は、リソース専用ファイル、例えばＤＬＬ内でデータのアクセスを包含するように拡張することができる。

プロセスがメモリの中にロードされるまたはメモリからアンロードされるデータを要求する前記説明においては、このようなステップは、プロセスのアドレス空間の中にマッピングされるという広義の形で考えられる必要がある。その理由として、マッピングされたＩ／Ｏのためのオペレーティングシステムファシリティが、ディスクからメモリの中にデータをロードすることに関連する具体的な概念にすっきり当てはまるものではないことが挙げられる。言い換えると、具体的なステップはオペレーティングシステムのＩ／Ｏシステムおよび仮想メモリ管理機能によってトランスペアレントに処理できるため、現行のオペレーティングシステムでは、必ずしもデータをメモリの中にロードするという明示的なステップに関連しなくても、プロセスが、ステップに従ってディスク上のデータにアクセスできるようにすることができるものである。

前記プロセスは、代替リソースモジュールを単一データファイルとしてこの要求側プロセスのアドレス空間の中にマッピングしてよい。このプロセスの基礎となる詳細は従来の技術で既知であり、例えばＷｉｎｄｏｗｓ（登録商標）においては、これはＬｏａｄＬｉｂｒａｒｙと呼ばれるオペレーティングシステム機能を定義するコードによって実行される。

Claims (3)

1. コンピュータオペレーティングシステムにおいて、第１バイナリファイルに格納された第１リソースデータに対する要求側プロセスによる要求を、第２バイナリファイルに格納された代替リソースデータに動的にリダイレクトする方法であって、
   前記オペレーティングシステムが前記代替リソースデータを発見するステップであって、前記代替リソースデータは、事前に格納されたユーザインターフェース言語識別子、及び、前記第１リソースデータまたは前記第１バイナリファイルの一方の識別子の両者に対応するものである、ステップと、
   前記オペレーティングシステムが、前記代替リソースデータを発見したときに、前記ユーザインターフェース言語識別子、及び、前記第１リソースデータまたは前記第１バイナリファイルの一方の識別子、を使用して前記代替バイナリファイルへのパスを動的に生成するステップと、
   前記オペレーティングシステムが、前記代替バイナリーファイルへの前記パスを使用して、前記第１リソースデータの代わりに、前記代替リソースデータを前記要求側プロセスに対してアクセス可能にすることにより、前記要求側プロセスによる要求を前記代替リソースデータにリダイレクトするステップと、
   を含む方法。
2. 請求項１に記載の方法において、前記第２バイナリファイルは、前記第１バイナリファイルが格納されるディレクトリのサブディレクトリに格納され、前記サブディレクトリは前記ユーザインターフェース言語識別子に対応する、方法。
3. 請求項１に記載の方法において、前記第１リソースデータは、アイコン、カーソル、メニュー、ダイアログボックス、ビットマップ、機能拡張済みメタファイル、フォント、アクセレレータテーブル、メッセージテーブルエントリ、文字列テーブルエントリ、または、バージョンを定義するデータの１つである、方法。

Images