JPH08508594A

JPH08508594A - 共用ライブラリ探索システム

Info

Publication number: JPH08508594A
Application number: JP6522026A
Authority: JP
Inventors: ヘニンガー，アンドリュー，ジー．; ナカノ，ラッセル，ティー．
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-04-05
Filing date: 1994-01-03
Publication date: 1996-09-10
Anticipated expiration: 2020-07-13
Also published as: CA2145671A1; DE69400406D1; EP0679273B1; DE69400406T2; WO1994023360A1; AU6082294A; US5414854A; EP0679273A1; JP3670278B2

Abstract

(57)【要約】共用ライブラリ探索システムに関するもので、プログラムによって開始されたある共用ライブラリとリンクされた共用ライブラリを探索してロードするための方法および装置が開示されている。本発明によれば、その動作は、開始されたプログラムに必要な共用ライブラリ名の名前を判別することから開始される。そのあと、探索オブジェクトが使用されて、判断された名前に対応する物理共用ライブラリのロケーションを探し出し、そこまで到達する。共用ライブラリ名の各々に対応する該当のロケーションに到達すると、共用ライブラリ名の各々はそれぞれに対応する物理ロケーションにマッピングされる。そのあと、各物理共用ライブラリのロケーションの内容はプログラムの目的のためにロードすることができる。

Description

【発明の詳細な説明】共用ライブラリ探索システム関連特許出願の相互参照本出願は、（ｉ）米国特許出願（発明者Debra L.Orton、David B.Goldsmith、 Christopher P.Moeller、およびAndrew G.Heninger、発明の名称「オブジェクト指向フレームワーク・システム」（Object Oriented Framework System）、1992 年12月23日出願、被譲渡人Taligent社）および（ii）米国特許出願（発明者Robe rt Dickinson、発明の名称「オブジェクト指向オペレーティング・システム」（ Object Oriented Operating System）、1993年１月22日出願、被譲渡人Taligent ）の関連出願であり、これらの開示事項は引用により本明細書の一部を構成するものである。発明の分野本発明は、一般的には、共用ライブラリ（sharedlibraries）のローディングに関し、より具体的には、共用ライブラリ名を探索オブジェクト（searchobject ）を使用して物理共用ライブラリのロケーションと対応づける（マッピング）ことに関する。発明の背景ライブラリとは、あるロケーションにストアされたデータとコードの集まりである。ライブラリには古いデータ項目（アイテム）が保存されていると共に、新しいデータ項目が受け入れられる。さらに、既存のデータ項目は動的であり、変更を受ける対象になっている。１つのライブラリは、複数のバージョンがコンピュータ・システムに存在することもできる。ライブラリは共用にすることも可能である。つまり、ライブラリは、複数のアプリケーションやプロセスが同時並行に使用することができる。そのようなライブラリは「共用ライブラリ」（shared library）と呼ばれている。あるアプリケーションまたはプログラムが開始されるとき、そのプログラムを実行するために必要なすべての共用ライブラリを「ロード」する必要がある。プログラムは、一般に、共用ライブラリの名前を参照する。そのために、プログラムの中で参照された共用ライブラリは、その共用ライブラリが従属する他のすべての共用ライブラリと共に、ローディングが行われる前に、探し出さなければならない。現在のコンピュータ・システムは、必要な共用ライブラリのロケーションを、プログラムによって参照された名前から効率よく確かめることができない。このようなことが起こるのは、現在のコンピュータ・システムには、共用ライブラリのロケーションを探し出す複雑な探索（サーチ）を行う能力がないためである。さらに、現在のコンピュータ・システムは、共用ライブラリの複数のバージョンやコピーを区別することができない。さらに、現在のコンピュータ・システムは異なる共用ライブラリの互換性属性（compatibilitya ttributes）を正しく埋め合わせることができない。以上のように、本件出願人が承知している従来技術によるシステムは、共用ライブラリをロードするときの複雑さと効率性が不十分である。発明の概要本発明は、物理共用ライブラリのロケーションを共用ライブラリ名から効率よく探索し、探し出す方法および装置を提供することによって、従来技術の上記欠点を解消している。本発明によれば、操作は、開始されたプログラムにとって必要な共用ライブラリの名前を定めることから開始される。そのあと、探索オブジェクトが使用されて、定められた名前の各々に対応する物理ロケーションが探索されて、突き止められる。チーム内に複数の探索オブジェクトを編成することも可能である。ここでチーム（team）とは、アドレス空間（address space）およびそのアドレス空間内で実行される複数の実行スレッド（thread）のことである。このようにすると、探索オブジェクトの集合を、選択した順次順序で使用することにより、物理ロケーションを探し出すことができる。例えば、探索オブジェクトは、それがチームに追加されたときの順序で連続的に使用することができる。探索オブジェクトが共用ライブラリ名の各々に対応する該当の物理ロケーションに到達すると、共用ライブラリ名の各々は、それぞれに対応する物理ロケーションにマッピングされる。そのあと、到達した物理共用ライブラリ・ロケーションの内容は、プログラムの目的のためにロードすることができる。図面の簡単な説明本発明の上記および他の目的と利点は、添付図面を参照して以下に詳述する本発明の好適実施例の説明から明らかにする。添付図面において、第１図は、本発明によるコンピュータ・システムを示すブロック図である。第２図は、本発明によるロジックの流れを示すフローチャートである。第３図は、本発明による探索オブジェクトのクラス継承階層を示す図である。第４図は、本発明に従って探索オブジェクトがたどっていく、名前付き共用ライブラリの探索を示すフローチャートである。第５図は、本発明による例に従って、異なる互換性番号をもつ共用ライブラリの例を示す図である。発明の好適実施例の詳細説明コンピュータ・システム第１図は代表的なハードウェア環境を示したもので、本発明によるワークステーション40の適切なハードウェア構成を示している。ワークステーション40は、従来のマイクロプロセッサのような中央演算処理ユニット10と、システム・バス 12を介して相互接続された複数の他のユニットとを装備している。第１図に示す図示のワークステーション40は、ランダム・アクセス・メモリ（RAM）14と、リード・オンリ・メモリ（ROM）16と、ディスク・ユニットなどの周辺デバイスをバス12に接続するための入出力（I/O）アダプタ18と、キーボード24、マウス26 、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・インタフェース・デバイスをバス12に接続するためのユーザ・インタフェース・アダプタ22とを備えている。ワークステーション40は、ワークステーション40をデータ処理ネットワーク30に接続するための通信アダプタ34と、バス 12を表示デバイス38に接続するための表示アダプタ36とを装備することも可能である。本発明は、好ましくは、「オブジェクト指向フレームワーク・システム」の名称で1992年12月23日に出願された米国特許出願および「オブジェクト指向オペレーティング・システム」の名称で1993年１月22日に出願された米国特許出願に記載されているオブジェクト指向オペレーティング・システムの下で実施される。両米国特許出願はTaligent社に譲渡されている。本発明のロジック・オペレーション本発明は、プログラムの実行時にコンピュータ・システムと併用されて、共用ライブラリをロードし、共用ライブラリを相互にリンクするためのフレームワークを備えている。かかるフレームワークは、プログラムによって参照された共用ライブラリ名が、そのプログラムの開始時に従属している共用ライブラリとリンクされるときの仕方を提供している。すべての共用ライブラリは指定された名前によって識別され、指定された名前空間内に置かれている。共用ライブラリは任意の数の他の共用ライブラリに従属し、必要ならば、それらの共用ライブラリとリンクされている。特定の共用ライブラリに対応する共用ライブラリ・ロード・モジュールは、（ｉ）特定共用ライブラリの指定された名前と、（ii）その特定共用ライブラリが従属する共用ライブラリの指定された名前を格納する。ある特定共用ライブラリがプログラムに続いてロードされるとき、その特定共用ライブラリが従属するすべての共用ライブラリもロードされなければならない。従って、プログラムに続いてロードされる共用ライブラリの名前を確かめるためには、共用ライブラリ・ロード・モジュールの助けが必要になる。共用ライブラリの名前空間はグローバルであるので、該当する共用ライブラリが一緒にリンクされるためには、各共用ライブラリに異なる名前をつけなければならない。本発明は、各共用ライブラリが一意的（unique）な名前をもっていることを前提としている。プログラムが開始と同時に実行されるためには、共用ライブラリは他の共用ライブラリとリンクされていなければならない。このリンキング・プロセス（link ing process）は、該当の共用ライブラリがロードされると行われる。ローダと呼ばれるメカニズムは、ロードする必要のある共用ライブラリの名前を最初に決める。そのあと、定められた共用ライブラリ名に対応する物理共用ライブラリを、ローダに知らせなければならない。物理共用ライブラリのロケーションには、コンピュータ・ディスク、RAM（「ランダム・アクセス・メモリ」）およびROM（「リードオンリ・メモリ」）が置かれているのが代表的である。しかし、ローダはライブラリがどこに置かれているかを定めない。その代わりに、ローダは探索オブジェクトを使用して共用ライブラリのロケーションを決定する。探索オブジェクトはライブラリ名を物理共用ライブラリ・ロケーションに対応づける（マッピングする）。結果として得たマッピング情報を使用して、ローダは、該当の共用ライブラリをロードすることが可能になる。第２図は、ある共用ライブラリを別の共用ライブラリとリンクするステップを記載したフローチャートを示す図である。プログラムを開始するために、通常は、共用ライブラリをロードし、相互にリンクする必要がある。これは、ボックス 202に示されている。そのあと、開始されたプログラムに必要な共用ライブラリの名前の決定が行われる。これは、ボックス204に示されている。プログラムに必要な共用ライブラリ名には、プログラムによって参照される名前の他に、開始されたプログラムまたは参照された共用ライブラリが従属する共用ライブラリの名前も含まれる。これらの名前は前述した共用ライブラリ・ロード・モジュールから確かめられる。共用ライブラリの名前が確かめられると、次に、探索オブジェクトが使用されて、その名前に対応するそれぞれの物理共用ライブラリ・ロケーションが突き止められる。これは、ボックス206に示されている。クラスTLibrarySearcherは、以下で詳しく説明するように、使用された探索オブジェクトのインタフェースを定義している派生クラス（derived class）である。共用ライブラリの確かめられた名前が与えられているとき、探索オブジェクトは、その探索オブジェクトの探索命令（search instructions）をたどっていくことにより、物理共用ライブラリに到達する。対応する物理共用ライブラリに到達すると、ボックス208に示すように、マッピングが行われる。マッピングは共用ライブラリ名を、到達した共用ライブラリ・ロケーションに対応づけることである。そのあと、到達した物理共用ライブラリはロードされ、相互にリンクされる。これは、それぞれ参照符号210と212で示されている。探索オブジェクトオブジェクト指向（object-orientation）とは、複数のオブジェクトからなるシステム手法である。各オブジェクトは、通常、実世界のエンティティ（実体）に対応しているが、いくつかのオペレーションと、そのオペレーションのステート（状態）を覚えているステート（状態）を提供する。例えば、人物オブジェクト（person object）は年齢、アドレス、電話番号、職業などの、ある人物に対応する情報を所有している。オペレーションは、この情報をアクセスし、あるいは影響を与えるために作成される。さらに、オペレーションは、ウォーキング（wa lking）のような、どの内部情報にも影響を与えない作用（behavior）を実行するために作成することもできる。クラスとは、新しいオブジェクトの作成を可能にする定義、テンプレートまたはモールド（mold）である。従って、クラスは、複数のオブジェクトの共通特性を記述したものである。あるクラスを含むオブジェクトはこのテンプレートを共通にもっている。クラスの特性は、サブクラス（subclass）と呼ばれる別のクラスに継承させることができる。従って、サブクラスはクラスの情報構造と作用を継承する。そのあと、別の情報や作用をサブクラスに追加することが可能である。継承階層において、あるクラスの下位に置かれたクラスは、クラスの子孫と呼ばれる。上位に置かれたクラスは祖先と呼ばれる。子孫とサブクラスの用語は同じ意味で使用されている。第３図は、探索オブジェクト・クラスの階層を示す図である。クラスMCollect ible 300は、すべての探索オブジェクトの基底クラス（base class）を表している。つまり、クラスMColle ctible 300は、他のすべてのクラスがそこから子孫として作成されるクラスである。クラスMCo1lectible 300の主要子孫は２つあり、それは、クラスTLibrarySe archer 302とクラスTTeamHandle 308である。クラスTLibrarySearcher 302は別の子孫を２つもっている。それは、それぞれ参照符号304と306で示すように、クラスTStandardLibrarySearcherとクラスTWorkspaceSearcherである。クラスTStandardLibrarySearcher 304は、単一ディレクトリ内の物理共用ライブラリを探索するデフォルトの探索オブジェクトを定義している。探索する必要があるディレクトリは２つ以上であるのが普通であるので、クラスTStandardLib rarySearcher 304は、通常、システム内のすべての共用ライブラリを探し出すことができない。さらに、クラスTStandardLibrarySearcher 304のオブジェクトは、ライブラリの複数のコピーに遭遇したときの互換性を考慮しない。従って、クラスTStandardLibrarySearcher 304に従って作成された探索オブジェクトに代わって、物理共用ライブラリを探すためのクラスTWorkspaceSearcher 306が用意されている。クラスTWorkspaceSearcher306により、ワークステーションから探索オブジェクトを作成することができる。クラスTWorkspaceSearcher 306によって定義された探索オブジェクトは、２つの以上のディクレトリ内を探索できると共に、必要時に互換性を考慮することができる。クラスTLibrarySearcher 302から派生したオブジェクトは任意的に複雑な探索を実現することができる。例えば、この種のオブジェクトは、（ｉ）ファイル属性を調べ、（ii）ライブラリのディレクトリまたはデータベースを維持し、（ii i）ライブラリ導入プロシージャとやりとりすることができる。TLibrarySearche r302サブクラスである、クラスTStandardLibrarySearcher 304とクラスTWorkspa ceSearcher 306は、共用ライブラリのあるバージョンがすでに使用中であるかどうかをシステムに確かめるために作成されることもある。第４図は、共用ライブラリを探索するときのロジックの流れを示すフローチャートである。初めに、探索オブジェクトが共用ライブラリの名前と一緒に提示される。提示されたこの名前付き共用ライブラリから、共用ライブラリのロケーションの探索が行われる。これは、参照符号400で示されている。名前付きライブラリが探索されると、（ｉ）共用ライブラリに複数のコピーがあること、（ii）共用ライブラリ名に対応するロケーションがないこと、あるいは（iii）共用ライブラリに１つのコピーがあることが明らかになる。これらの結果は、それぞれ参照符号402,410、および420を付けたボックスに示されている。共用ライブラリが見つからないと、ボックス412に示すように、探索オブジェクトから”NIL”が返される。共用ライブラリのコピーが１つだけ見つかったときは、ボックス422に示すように、その共用ライブラリがローダに返される。しかし、共用ライブラリのコピーが複数見つかったときは、コピーが返される前に別の分析が必要になる。この別の分析は、まず、共用ライブラリ・コピーの互換性番号が確認できるかどうかを判断することから始まる。これはボックス40 4に示されている。共用ライブラリ・コピーの互換性番号が確認できれば、最高互換性番号をもつ共用ライブラリ・コピーが返される。これは、ボックス406に示されている。共用ライブラリ・コピーの互換性番号が確認できなければ、別の選択方法が必要になる。この別の選択方法には、共用ライブラリのコピーで、現在別の場所に置かれているコピーがあるかどうかの判断を含めることができる。最終的には、この別の選択方法からは、ボックス416に示すように、共用ライブラリの選択されたコピーが返されるはずである。ボックス406,416,422に示すように、共用ライブラリの返されたコピーは、共用ライブラリ名と対応づけられる（マッピング）。これは、ボックス430に示されている。そのあと、マップ情報がローダに知らされる。互換性は、ファイルである共用ライブラリのファイル・システム属性である。互換性は互換性番号で示され、最高互換性番号をもつ共用ライブリーのコピーが他の従属共用ライブラリと互換性をもつ可能性がある。従って、探索オブジェクトからは、最高互換性番号をもつ共用ライブラリのコピーが返される。共用ライブラリがファイルであるとき、探索オブジェクトが常にそうすることができるのは、ファイルが常に互換性番号へのアクセスを許しているからである。しかるに、ファイルでない共用ライブラリは、コピーの互換性番号をアクセスすることを認められていない。そのような場合は、探索オブジェクトは最高度の互換性をもつコピーを確かめることができない。共用ライブラリは、２つの条件が満足されると連続的にロードされる。第１は、最高互換性番号をもつコピーが探索オブジェクトから返されたときである。第２は、探索オブジェクトが探索した個所のロケーションの間で、一貫性のある共用ライブラリの集合が存在し、それらがロードされるときである。第５図は、異なる互換性番号をもつ３つのライブラリの例を示す図である。Ａ，ＢおよびＣと名づけた３つのライブラリがロードされることを想定している。互換性番号１をもつライブラリＡ（参照符号502で示すように、”library（A,1）”）は、互換性番号２をもつライブラリＢ（参照符号504で示すように、”library（B,2）”）と互換性番号２をもつライブラリＣ（参照符号506で示すように、”library（C,2）”）に従属している。互換性番号３をもつライブラリＢ（参照符号510で示すように、”library（B,3）”）は、互換性番号３をもつライブラリＣ（参照符号508で示すように、”library（C,3）”）に従属している。ライブラリ（B,2）504はライブラリ（C,2）506に従属している。しかし、ライブラリ（C,2）506とライブラリ（C,3）508は他のどのライブラリにも従属していない。ローダがライブラリ（A,1）502のロードを試みるとき、ライブラリ（A,1）502 が従属するライブラリのコピーもロードする必要がある。ロードされるコピーは従属共用ライブラリの互換性番号と等しいか、それより大の互換性番号をもっていなければならない。従って、ローダがロードできるのは、（ｉ）ライブラリ（ B,2）504またはライブラリ（B,3）510および（ii）ライブラリ（C,2）506とライブラリ（C,3）508である。しかし、ライブラリ（B,3）510はライブラリ（C,3）5 08と一緒にロードされなければならない。ライブラリ（B,3）510の従属を満たすには、ライブラリ（C,2）506では不十分である。探索オブジェクトまたは複数の探索オブジェクトはライブラリ（B,2）504、ライブラリ（B,3）510、ライブラリ（C,2）506、およびライブラリ（C,3）508を探し出す。最大互換性番号をもつコピーが探索オブジェクトから返されると、ライブラリ（A,1）502、ライブラリ（B,3）510、およびライブラリ（C,3）508が返される。これらの３ライブラリはすべての従属条件が満たされているので、ロードされる。前記の３ライブラリが探索オブジェクトから返されなかったときは、ローディングはできないであろう。例えば、探索オブジェクトからライブラリ（A,1）502 、ライブラリ（B,3）510、およびライブラリ（C,2）506が返されることがある。そのような場合は、ライブラリ（B,3）510がライブラリ（C,3）508に従属することが満たされないので、これらのライブラリはロードされない。このようなことが起こるのを避けるには、探索オブジェクトは最高互換性番号をもつライブラリのコピーを返さなければならない。もちろん、これが行えるのは、探索オブジェクトが共用ライブラリの互換性番号をアクセスできる場合だけである。探索オブジェクトのチーム属性探索オブジェクトはチーム内に置かれる。各チームは１つまたは２つ以上の探索オブジェクトのリストをもち、このリストは、そのチームに関連する共用ライブラリをロードするときローダによって調べられる。チーム内に置いておくことができる探索オブジェクトの数には制限がない。新しいチームが作られるときは、クラスTTeamHandle内に作られているコンストラクタ・オブジエクト（constructor object）内に探索オブジェクトの集合を渡すことができる（第３図に参照符号308で示されている）。そのあと、探索オブジェクトの集合は新しいチームに加えられる。クラスTLibrarySearcher 302から派生した探索オブジェクトは２種類があり、チーム内に置かれている。第１は、作成されるすべてのチームに追加される探索オブジェクトであり、これは「システム探索オブジェクト」と呼ばれる。第２は、特定のチームにだけ追加するために作成できる探索オブジェクトである。これらはチーム特定オブジェクト（team specfic object）と呼ばれる。あるチームがアクセスされるとき、チーム特定探索オブジェクトとシステム探索オブジェクトの両方がストリーム化されて、そのチームのアドレス空間に入れられる。従って、TLibrarySearcher 302のサブクラスTStandardLibrarySearcher 304とTWorks paceSearcher 306はストリーミング演算子（streaming operators）をもっていないければならない。ローダはチーム内の探索オブジェクトの集合を使用して、ライブラリ名をライブラリ・ロケーションまたはモジュールに対応づける（マッピング）。そのあと、共用ライブラリはチームのアドレス空間内に置かれる。ローダは、好ましくは、探索オブジェクトを「LIFO順」（後入れ先出し）に使用する。つまり、探索オブジェクトは、チームに追加されたときの順序で使用される。従って、最も最近に追加された探索オブジェクトが最初に使用される。探索オブジェクトは共用ライブラリが見つかるまで、LIFO順に連続的に使用される。探索オブジェクトのどれも共用ライブラリを見つけることができないと、ローダは先に進むことができないので例外を引き起こすことになる。例外に応答して、チームにアクセスしてから、探索オブジェクトをチームに追加することができる。しかし、あとで追加された探索オブジェクトが見つけることができるのは、探索オブジェクトの追加のあとでチームのアドレス空間に動的にロードされる共用ライブラリだけである。最近に追加された探索オブジェクトは既存の探索オブジェクトをオーバライド（override）するものと想定されているので、ローダは探索オブジェクトをLIFO 順に使用することが好ましい。従って、チーム探索オブジェクトの集合は、常に、クラスTStandardLibrarySearcher 304によって定義されるようなデフォルトの探索オブジェクトの前に使用される。例えば、共用ライブラリＸは、２つのバージョンがシステムに存在することがある。デフォルト探索オブジェクトはライブラリＸをライブラリＸの第１バージョンにマップする。他方、クラスTWorkspaceSearcher 306によって定義された探索オブジェクトはライブラリＸの第２バージョンにマップする。ワークスペース定義探索オブジェクトがデフォルト探索オブジェクトの前に使用されると、ライブラリＸはライブラリＸの第２バージョンにマップされる。従って、ワークスペース定義探索オブジェクトはシステム探索オブジェクトの前に調べられるので、ライブラリＸの正しいバージョンがチームのアドレス空間にロードされることになる。別の方法として、一時的チーム探索オブジェクトを指定しても同じ効果が得られる。一時的探索オブジェクトは、”TLibrary::LoadLibrary for LibraryX”へのコールの中で指定できる。従って、チームはコールが存続している間一時的探索オブジェクトを使用するので、ライブラリＸの正しいバージョンがロードされることになる。一時的探索オブジェクトは、チームが開始されたあと使用すると特に便利である。その理由は、一時的探索オブジェクトはチーム探索オブジェクトの集合に追加されないためである。これとは逆に、探索オブジェクトをチームに追加すると、他の共用ライブラリに対するチームの使用効率に好ましくない影響を与えることになる。そのために、一時的ライブラリ探索オブジェクトは、ライブラリを稼働中のチームに動的にロードするとき使用するのが望ましい。システム探索オブジェクトはすべてのチームと関係があるので、これがローダによって使用されるのは、すべてのチーム特定探索オブジェクトが使用されたあとだけである。従って、探索オブジェクトは次のような順序で使用される。すなわち、（ｉ）チーム特定探索オブジェクト、（ii）システム探索オブジェクト、（iii）デフォルト探索オブジェクト。さらに、本発明ではシステム・オブジェクトはLIFO順に使用されるので、追加されたシステム探索オブジェクトは、それがシステムに追加されたあと作成された共用ライブラリのローディングだけに影響する。探索オブジェクトは、システム上のすべてのチームに対して適用するためにも、特定のチームに対して適用するためにも追加することが可能である。すべてのチームに対して適用するためにシステム探索オブジェクトが追加されると（”TL ibrarySearcher::AddSystemSearcher”を呼び出すことにより）、そのシステム・オブジェクトはそのあとで作成されたすべてのチームに適用される。これに対して、あるチームに対して適用するために探索オブジェクトが追加されると（” TTeamHandle::AddLibrarySearcher”を呼び出すことにより）、新しく作成された探索オブジェクトは、そのチームによるライブラリ探索だけに適用される。探索オブジェクトは、あるチームにいったん追加されたら、除去できないようにすることが好ましい。これは追加された探索オブジェクトがチーム特定探索オブジェクトであるか、システム探索オブジェクトであるかに関係ない。このような制約を設けたのは、探索オブジェクトがチームのすべてのタスクによって共用されるグローバル資源であるためである。あるタスクに対してチーム探索オブジェクトの除去を認めると、その探索オブジェクトに従属する別のタスクに好ましくない影響を与えることになる。例えば、同じチーム上の２つの従属タスク（「タスク１」と「タスク２」）が同じ追加探索オブジェクトをもっているとする。この場合、探索オブジェクトがタスク１から除去されたとしても、タスク２はその探索オブジェクトがまだ残っているものと思っている。そのために、両方のタスクは探索オブジェクトの同じリストを保持している必要がある。一時的探索オブジェクトは、探索オブジェクトがある特定タスクに対してだけ使用されるときに利用するのが好ましく、そうすれば、その探索オブジェクトをチームに追加しないで済むことになる。また、本発明によれば、あるチームに追加しようとしている探索オブジェクトがすでにそのチームに存在するかどうかを確かめるための分析も行われる。探索オブジェクトと重複するものがすでに置かれているチームに探索オブジェクトが追加されると、探索コピーの二番目のコピーの追加は行われない。しかし、チーム内にすでに置かれている重複探索オブジェクトはチーム・ライブラリ探索オブジェクトのリストの最後に移される。このようにしたのは、チームの探索オブジェクト・リストの最後にある探索オブジェクトがチームによって最初に使用されるためである。本発明によれば、重複探索オブジェクトを見つけるために探索オブジェクトのタイプが分析される。例えば、C++プログラミング言語では、”Is Equal”メソッドを実行することにより比較が行われる。従って、すべてのTLibrarySearcher 302サブクラスは、IsEqua1”メソッドまたは同等のメソッドをオーバライド（o verride）しなければならない。 TLibrarySearcher 302のサブクラスは、共用ライブラリに入れておくことができる。しかし、ローダがある共用ライブラリを見つけるためには、その所定のライブラリには、それを見つけるために必要なTLibrarySearcher 302サブクラスが入っていてはならない。従って、TLibrarySearcher 302サブクラスは、TLibrary Searcher 302サブクラスに探索させる共用ライブラリの外部のロケーションに置いておかなければならない。言い換えれば、TLibrarySearcher 302サブクラスを収めている共用ライブラリは、それを見つけるためにライブラリに置かれているTLibrarySearcher 302サブクラスに頼らなくても、見つけることができるロケーションの場所に置いておかなければならない。 TLibrarySearcher 302サブクラスを収めている所定共用ライブラリを、ローダに確実に見つけさせる１つの方法は、デフォルトのシステム探索オブジェクトがそれを見つけることができる場所に、その所定の共用ライブラリを置いておくことである。クラスTStandardLibrarySearcher 304は、デフォルト探索オブジェクトを定義し、すべてのチームと関連づけられているので、所定の共用ライブラリを常に探し出すことができる。従って、新しく作成されたチームは、クラスTWor kspaceSearcher 306によって定義されたワークスペース探索オブジェクトがチームに追加されてから初めて、デフォルト・システム探索オブジェクトに頼ることができる。ある探索オブジェクトがあるチームに追加されたときは、そのチームはその探索オブジェクトを収めている共用ライブラリをロードしなければならない。これはチームにすでに追加されているシステム・ライブラリ探索オブジェクトと、もしあれば、チーム特定探索オブジェクトだけを使用して行われる。好ましくは、共用ライブラリの１つのコピーだけがチームのアドレス空間にロードされる。従って、ローダは、単一チームを扱っているとき、ある共用ライブラリを２回以上見つけたときは、現在ロードされている共用ライブラリが正しいものと想定する。従って、ローダは重複するライブラリを探すために探索オブジェクトを使用することがない。チームの探索オブジェクトの集合が修正され、チームのアドレス空間にすでに置かれているライブラリをロードするために”Load Library”が呼び出されると、修正されたチームはライブラリの異なるバージョンを返すことになる。従って、LoadLibraryを呼び出しても、ライブラリの旧バージョンはチームのアドレス空間に残っているので、所望とする効果は得られない。同じワークステーションに置かれている異なるチームは、同じ共用ライブラリの異なるコピーを使用することができる。しかし、同じ共用ライブラリの異なるコピーを使用する複数のチームは、オブジェクト・クラスが共用ライブラリ内に定義されていても、共用メモリによって別のチームのオブジェクトを共用することはできない。むしろ、所定のチームが使用できるオブジェクトは、所定のチームに関連するものだけに制限されている。共用ライブラリの異なるバージョンを使用するチームはチーム同士でオブジェクトを共用できないが、そのクラスが共用ライブラリ内に定義されているオブジェクトをストリーム化して相互にやりすることは許される。発明者が開発した本発明の実施例は、本明細書の付録に記載されている。これは、本発明の詳細ロジックを理解しやすくするために示されたものである。実施例の各部分の重要要素も、詳しく解説されている。ソース・コードの注釈： //Class TLibrarySearcher derived from base class MCollectible（//基底クラスMCollectibleから派生されたクラスTLibrarySearcher）〜TLibrarySearcher( )：デストラクタ。 TMappableDataContainer*CreateContainerAndFindLiｂrary（constTText&librar yName,constCompatibilityNumberdesireRelease）：特定の名前をもつライブラリを探索する。そのライブラリのTMappableDataContainerを返す。呼出し側はTM appableDataContainerのための記憶域を所有している。ライブラリ・サーチャは共用ライブラリの複数のコピーを見つけたときは、どのコピーを返すべきかを決定しなければならない。実行中のチームにより現在ロードされたのがどのライブラリであるのかを、その決定には考慮する必要がある。また、共用ライブラリの必要とする互換性番号も考慮する必要がある。サーチャが共用ライブラリの互換性番号をアクセスできる場合は（互換性番号はファイルである共用ライブラリの特性である）、返すことを考慮している共用ライブラリの互換性番号が、必要とする互換性番号より大か、あるいは等しいかをチェックする必要がある。ライブラリが見つからなければ、NILが返される。このメソッドは、すべての TLibrarySearcherサブクラスによって無視しなければならない。 Boolean IsEqual（constMCollectible*）：２つのライブラリ・サーチャが同等のものであれば、TRUEが返され、そうでなければ、FALSEが返される。以下のメソッドは、ワークスペースだけがコールすることが可能である。 static AddSystemLibrarySearcher（const TLibrarySearcher &）：その作成時にチームによって自動的に継承されるライブラリ・サーチャのグローバル・リストにライブラリ・サーチャを追加する。この関数は、コールされたあとに作成されたチームにだけ作用する。既存のチームには作用しない。 static TIterator*CreateSystemLibrarySearcherIterator( )：システム・ライブラリ・サーチャのためのイタレータ（iterator）を生成する。このイタレータは、TLibrarySearcherサブクラス・オブジェクトを指しているポインタを返す。呼出し側はイタレータのための記憶域を所有している。イタレータは返すTLibra rySearcherのための記憶域を所有している。イタレータはシステム・ライブラリ・サーチャを、適用される順に返す。現在のスレッドがシステム・ライブラリ・サーチャを繰り返している途中でシステム・ライブラリ・サーチャが別のスレッドによって追加されると、kIteratorOutOfSync例外が引き起こされる。 //Subclass library searcher used by the run time during system boot． //Not intended for subclassing．（//システム・ブート期間の実行時に使用されるサブクラス・ライブラリ・サーチャ。 //サブクラス化を目的としていない。）TStandardLibrarySearcher( ) ：コンストラクタ。〜TStandardLibrarySearcher( ) ：デストラクタ。TMappableDataContainer*CreateContainerAndFindLibrary（constTText&library Name,const CompabilityNumberdesiredRelease ）：ディスク上の「共用ライブラリ」フォルダに入っている特定名をもつライブラリを探索し、そのライブラリの TMappableDataContainerを返す。ライブラリが見つからなければ、NILが返される。このライブラリ・サーチャはその決定のとき要求された互換性番号を考慮しない。呼出し側はTMappableDataContainerのための記憶域を所有している。 BooleanIsEqual（constMCollectible*）：２つの標準ライブラリ・サーチャが同等のものであればTRUEを返し、そうでなければELSEを返す。特定のシステム環境における好適実施例を参照して本発明を説明してきたが、本発明は、請求の範囲に明確化された本発明の精神と範囲内において、修正を加えることにより他の異なるハードウェアおよびソフトウェア環境において実施することが可能であることはもちろんである。

【手続補正書】特許法第１８４条の８【提出日】１９９５年３月２９日【補正内容】請求の範囲１．関連する共用ライブラリがストアされているコンピュータ中の記憶装置のアドレスに、複数の共用ライブラリ名をマッピングするロジックを有する少なくともひとつのライブラリ探索（searcher）オブジェクトを含み、特別なファンクションを実行するためのロジックとデータとをもつオブジェクトを含んだオブジェクト指向オペレーティング・システムにおける共用ライブラリを位置づける（lo cating）方法において、（ａ）前記コンピュータの前記記憶装置に位置づけられた複数のライブラリ名を確認し、（ｂ）前記少なくともひとつのライブラリ探索オブジェクトの前記ロジックを使い、前記共用ライブラリ名に対応する複数のロケーションを探索すると共に獲得し、（ｃ）前記複数の共用ライブラリ名を前記コンピュータの前記記憶装置に位置している前記複数の共用ライブラリへマッピングするステップを具備することを特徴とする方法。２．複数のディレクトリが探索されることを特徴とする請求の範囲第１項に記載の方法。４．デフォルトの場合には、前記複数の探索オブジェクトの１つまたは２つ以上が使用されることを特徴とする請求の範囲第１項に記載の方法。５．前記複数の探索オブジェクトの１つまたは２つ以上がチーム内に置かれることを特徴とする請求の範囲第１項に記載の方法。６．前記チーム内に置かれた前記探索オブジェクトは後入れ先出し（LIFO）順番に連続的に格納されることを特徴とする請求の範囲第５項に記載の方法。７．後入れ先出し（LIFO）の順番は、前記探索オブジェクトの各々がいつ前記チームに追加されたかに基づくことを特徴とする請求の範囲第６項に記載の方法。８．前記複数の共用ライブラリ名の各々について、前記複数のロケーションの１つだけが選択的に獲得されることを特徴とする請求の範囲第１項に記載の方法。 11．コンピュータに置かれていて、特定のライブラリとリンクされた共用ライブラリを探索する方法であって、（ａ）複数の探索オブジェクトを形成し、（ｂ）複数の探索オブジェクトをストリーム化して特定のロケーションに送り込み、（ｃ）特定のライブラリとリンクされた複数の共用ライブラリ名を識別し、（ｄ）［ストリーム化して］特定のロケーションに送り込まれた複数の探索オブジェクトを連続的に使用して、複数の共用ライブラリ名に対応する複数のロケーションを獲得し、（ｅ）複数の共用ライブライ名を獲得した複数のロケーションにマッピングするステップからなることを特徴とする方法。 13．複数の探索オブジェクトの１つまたは２つ以上は特定のロケーションに置かれているプロシージャを呼び出すことを特徴とする請求の範囲第11項に記載の方法。 14．プロシージャは変更可能であることを特徴とする請求の範囲第13項に記載の方法。 15．複数の探索オブジェクトの１つまたは２つ以上の複製コピーが特定のロケーションにすでに存在するとき、複数の探索オブジェクトの１つまたは２つ以上がストリーム化されて特定のロケーションに送り込まれるのを禁止するステップを含むことを特徴とする請求の範囲第13項に記載の方法。 16．複数の探索オブジェクトの１つまたは２つ以上はストリーム化されて複数の特定のロケーションに送り込まれることを特徴とする請求の範囲第11項に記載の方法。 17．複数の探索オブジェクトは、複数の探索オブジェクトがストリーム化されて特定のロケーションに送り込まれたときの順序に基づいて連続的に使用されることを特徴とする請求の範囲第11項に記載の方法。 20．関連する共用ライブラリがストアされているコンピュータ中の記憶装置のアドレスに、複数の共用ライブラリ名をマッピングするロジックを有する少なくともひとつのライブラリ探索（searcher）オブジェクトを含み、特別なファンクションを実行するためのロジックとデータとをもつオブジェクトを含んだオブジェクト指向オペレーティング・システムにおける共用ライブラリを位置づける（lo cating）装置において、（ａ）オブジェクト指向オペレーティング・システムと、（ｂ）前記オペレーティング・システムに制御されたコンピュータと、（ｃ）前記コンピュータに付属し、制御下にある記憶手段と、（ｄ）共用ライブラリの複数の名前を前記記憶手段のアドレスにマッピングする少なくとも１つのライブラリを含む特別なファンクションを実行するためのロジックとデータとをもつ複数のオブジェクトと、（ｅ）前記コンピュータの前記記憶装置に位置づけられた複数のライブラリ名を確認する手段と、（ｆ）前記少なくともひとつのライブラリ探索オブジェクトの前記ロジックを使い、前記共用ライブラリ名に対応する複数のロケーションを探索すると共に獲得する手段と、（ｇ）前記複数の共用ライブラリ名を前記コンピュータの前記記憶装置に位置している前記複数の共用ライブラリヘマッピングする手段とを具備することを特徴とする装置。 21．複数のディレクトリが探索されることを特徴とする請求の範囲第20項に記載の装置。 23．デフォルトの場合には、複数の探索オブジェクトの１つまたは２つ以上が使用されることを特徴とする請求の範囲第20項に記載の装置。 24．複数の探索オブジェクトの１つまたは２つ以上はチーム内に置かれることを特徴とする請求の範囲第20項に記載の装置。 25．チーム内に置かれた探索オブジェクトは後入れ先出し（LIFO）順番に連続的にストアされることを特徴とする請求の範囲第24項に記載の装置。 26．後入れ先出し（LIFO）順番は、探索オブジェクトの各々がいつチームに追加されたかに基づくことを特徴とする請求の範囲第25項に記載の装置。 27．複数の共用ライブラリ名の各々ついて、複数のロケーションの１つだけを選択的に獲得することを特徴とする請求の範囲第20項に記載の装置。 29．特定のライブラリとリンクされた複数の共用ライブラリ名は、定義されたロケーションを参照することにより確認されることを特徴とする請求の範囲第20項に記載の装置。 30．特定のライブラリとリンクされた共用ライブラリを探索する装置であって、（ａ）複数の探索オブジェクトを形成する手段と、（ｂ）複数の探索オブジェクトをストリーム化して特定のロケーションに送り込む手段と、（ｃ）特定のライブラリとリンクされた複数の共用ライブラリ名を確認する手段と、（ｄ）ストリーム化して特定のロケーションに送り込まれた複数の探索オブジェクトを連続的に使用して、複数の共用ライブラリ名に対応する複数のロケーションを獲得する手段と、（ｅ）複数の共用ライブライ名を獲得した複数のロケーションにマッピングする手段とを具備することを特徴とする装置。 31．到達した複数のロケーションをストリーム化して特定のロケーションに送り込む手段を含むことを特徴とする請求の範囲第30項に記載の装置。 32．複数の探索オブジェクトの１つまたは２つ以上は特定のロケーションに置かれているプロシージャを呼び出すことを特徴とする請求の範囲第30項に記載の装置。 33．プロシージャは変更可能であることを特徴とする請求の範囲第32項に記載の装置。 34．複数の探索オブジェクトの１つまたは２つ以上の複製コピーが特定のロケーションにすでに存在するとき、複数の探索オブジェクトの１つまたは２つ以上がストリーム化されて特定のロケーションに送り込まれるのを禁止するプロセッサを含むことを特徴とする請求の範囲第33項に記載の装置。 35．複数の探索オブジェクトの１つまたは２つ以上はストリーム化されて複数の特定のロケーションに送り込まれることを特徴とする請求の範囲第30項に記載の装置。 36．複数の探索オブジェクトは、複数の探索オブジェクトがストリーム化されて特定のロケーションに送り込まれたときの順序に基づいて連続的に使用されることを特徴とする請求の範囲第30項に記載の装置。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．コンピュータに置かれていて、特定のライブラリとリンクされた共用ライブラリを探索する方法であって、（ａ）特定のライブラリとリンクされた複数の共用ライブラリ名を確認し、（ｂ）複数の共用ライブラリ名に対応する複数のロケーションを探索して、そこまで到達し、（ｃ）複数の共用ライブラリ名を複数のロケーションにマッピングするステップからなることを特徴とする方法。２．複数のディレクトリが探索されることを特徴とする請求の範囲第１項に記載の方法。３．複数のディレクトリは複数の探索オブジェクトを使用して探索されることを特徴とする請求の範囲第２項に記載の方法。４．デフォルトの場合には、複数の探索オブジェクトの１つまたは２つ以上が使用されることを特徴とする請求の範囲第３項に記載の方法。５．複数の探索オブジェクトの１つまたは２つ以上はチーム内に置かれることを特徴とする請求の範囲第３項に記載の方法。６．チーム内に置かれた探索オブジェクトは順番に連続的に格納されることを特徴とする請求の範囲第５項に記載の方法。７．順番は、探索オブジェクトの各々がいつチームに追加されたかに基づくことを特徴とする請求の範囲第６項に記載の方法。８．複数の共用ライブラリ名の各々ついて、複数のロケーションの１つだけに選択的に到達することを特徴とする請求の範囲第１項に記載の方法。９．到達した１つのロケーションは、互換性の程度に基づいて選択されることを特徴とする請求の範囲第８項に記載の方法。 10．特定のライブラリとリンクされた複数の共用ライブラリ名は、定義されたロケーションを参照することにより確認されることを特徴とする請求の範囲第１項に記載の方法。 11．コンピュータに置かれていて、特定のライブラリとリンクされた共用ライブラリを探索する方法であって、（ａ）複数の探索オブジェクトを形成し、（ｂ）複数の探索オブジェクトをストリーム化して特定のロケーションに送り込み、（ｃ）特定のライブラリとリンクされた複数の共用ライブラリ名を識別し、（ｄ）ストリーム化して特定のロケーションに送り込まれた複数の探索オブジェクトを連続的に使用して、複数の共用ライブラリ名に対応する複数のロケーションに到達し、（ｅ）複数の共用ライブライ名を到達した複数のロケーションにマッピングするステップからなることを特徴とする方法。 12．到達した複数のロケーションをストリーム化して特定のロケーションに送り込むステップを含むことを特徴とする請求の範囲第11項に記載の方法。 13．複数の探索オブジェクトの１つまたは２つ以上は特定のロケーションに置かれているプロシージャを呼び出すことを特徴とする請求の範囲第11項に記載の方法。 14．プロシージャは変更可能であることを特徴とする請求の範囲第13項に記載の方法。 15．複数の探索オブジェクトの１つまたは２つ以上の複製コピーが特定のロケーションにすでに存在するとき、複数の探索オブジェクトの１つまたは２つ以上がストリーム化されて特定のロケーションに送り込まれるのを禁止するステップを含むことを特徴とする請求の範囲第13項に記載の方法。 16．複数の探索オブジェクトの１つまたは２つ以上はストリーム化されて複数の特定のロケーションに送り込まれることを特徴とする請求の範囲第11項に記載の方法。 17．複数の探索オブジェクトは、複数の探索オブジェクトがストリーム化されて特定のロケーションに送り込まれたときの順序に基づいて連続的に使用されることを特徴とする請求の範囲第11項に記載の方法。 18．時間的に早くストリーム化された探索オブジェクトは、時間的に遅くストリーム化された探索オブジェクトのあとで使用されることを特徴とする請求の範囲第17項に記載の方法。 19．コンピュータに置かれていて、特定のライブラリとリンクされた複数の共用ライブラリをロードする方法であって、（ａ）特定のライブラリを必要とするプログラムを開始し、（ｂ）特定のライブラリとリンクされた複数の共用ライブラリ名を識別し、（ｃ）確認された複数の名前に対応する複数のロケーションを探索して、そこまで到達し、（ｄ）複数の共用ライブラリ名を複数のロケーションにマッピングし、（ｅ）複数のロケーションをロードするステップからなることを特徴とする方法。 20．特定のライブラリとリンクされた共用ライブラリを探索する装置であって、（ａ）特定のライブラリとリンクされた複数の共用ライブラリ名を確認する手段と、（ｂ）複数の共用ライブラリ名に対応する複数のロケーションを探索してそこまで到達する手段と、（ｃ）複数の共用ライブラリ名を複数のロケーションにマッピングする手段とを具備することを特徴とする装置。 21．複数のディレクトリが探索されることを特徴とする請求の範囲第20項に記載の装置。 22．複数のディレクトリは複数の探索オブジェクトを使用して探索されることを特徴とする請求の範囲第21項に記載の装置。 23．デフォルトの場合には、複数の探索オブジェクトの１つまたは２つ以上が使用されることを特徴とする請求の範囲第22項に記載の装置。 24．複数の探索オブジェクトの１つまたは２つ以上はチーム内に置かれることを特徴とする請求の範囲第22項に記載の装置。 25．チーム内に置かれた探索オブジェクトは順番に連続的にストアされることを特徴とする請求の範囲第24項に記載の装置。 26．順番は、探索オブジェクトの各々がいつチームに追加されたかに基づくことを特徴とする請求の範囲第25項に記載の装置。 27．複数の共用ライブラリ名の各々ついて、複数のロケーションの１つだけに選択的に到達することを特徴とする請求の範囲第20項に記載の装置。 28．到達した１つのロケーションは、互換性の程度に基づいて選択されることを特徴とする請求の範囲第27項に記載の装置。 29．特定のライブラリとリンクされた複数の共用ライブラリ名は、定義されたロケーションを参照することにより確認されることを特徴とする請求の範囲第20項に記載の装置。 30．特定のライブラリとリンクされた共用ライブラリを探索する装置であって、（ａ）複数の探索オブジェクトを形成する手段と、（ｂ）複数の探索オブジェクトをストリーム化して特定のロケーションに送り込む手段と、（ｃ）特定のライブラリとリンクされた複数の共用ライブラリ名を確認する手段と、（ｄ）ストリーム化して特定のロケーションに送り込まれた複数の探索オブジェクトを連続的に使用して、複数の共用ライブラリ名に対応する複数のロケーションに到達する手段と、（ｅ）複数の共用ライブライ名を到達した複数のロケーションにマッピングするステップからなることを特徴とする装置。 31．到達した複数のロケーションをストリーム化して特定のロケーションに送り込む手段を含むことを特徴とする請求の範囲第30項に記載の装置。 32．複数の探索オブジェクトの１つまたは２つ以上は特定のロケーションに置かれているプロシージャを呼び出すことを特徴とする請求の範囲第30項に記載の装置。 33．プロシージャは変更可能であることを特徴とする請求の範囲第32項に記載の装置。 34．複数の探索オブジェクトの１つまたは２つ以上の複製コピーが特定のロケーションにすでに存在するとき、複数の探索オブジェクトの１つまたは２つ以上がストリーム化されて特定のロケーションに送り込まれるのを禁止するプロセッサを含むことを特徴とする請求の範囲第33項に記載の装置。 35．複数の探索オブジェクトの１つまたは２つ以上はストリーム化されて複数の特定のロケーションに送り込まれることを特徴とする請求の範囲第30項に記載の装置。 36．複数の探索オブジェクトは、複数の探索オブジェクトがストリーム化されて特定のロケーションに送り込まれたときの順序に基づいて連続的に使用されることを特徴とする請求の範囲第30項に記載の装置。 37．時間的に早くストリーム化された探索オブジェクトは、時間的に遅くストリーム化された探索オブジェクトのあとで使用されることを特徴とする請求の範囲第36項に記載の装置。 38．特定のライブラリとリンクされた複数の共用ライブラリをロードする装置であって、（ａ）特定のライブラリを必要とするプログラムを開始するプロセッサと、（ｂ）特定のライブラリとリンクされた複数の共用ライブラリ名を確認するプロセッサと、（ｃ）確認された複数の名前に対応する複数のロケーションを探索してそこまで到達するプロセッサと、（ｄ）複数の共用ライブラリ名を複数のロケーションにマッピングするプロセッサと、（ｅ）複数のロケーションをロードするプロセッサとを具備することを特徴とする装置。