(57)【特許請求の範囲】
【請求項１】
ストレージと、
複数のロード・モジュールを前記ストレージの１次アドレス空間にロードする手段であって、このロードが完了した後、前記複数のロードモジュールをそれぞれ、本手段により決定した再配置アドレスに再配置するロード手段と、
前記ロード・モジュール内の参照を、対応するアドレスと置換して、当該参照を解決するため、前記各ロード・モジュールをパースするパース手段と
を有するコンピュータにおいて、複数のロードモジュールをロードしリンキングする装置において、
前記パース手段は、プログラムコード関数項目と、データ項目と、クラス項目と、項目名参照を受け取り受け取った項目名参照に基づき参照した項目のアドレスを返すオブジェクト・メソッドとを含むソフトウェアプログラムオブジェクトであるロード・モジュールを、それぞれパースして、各ロード・モジュールからプログラムコード関数項目についての項目名参照を獲得し、獲得した項目名参照に基づき当該ロード・モジュール以外の別のロード・モジュールにおける項目が参照されていると判断した場合に、該別のロード・モジュールにおけるオブジェクト・メソッドを当該項目名参照を用いてコールし、該オブジェクト・メソッドにより項目名参照に基づき参照された項目のアドレスを獲得し、獲得したアドレスを前記当該モジュールにおけるプログラムコード関数項目にパッチする
ことを特徴とする装置。
【請求項２】
請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目を指し示すポインタを返すオブジェクト・メソッドを含むことを特徴とする装置。
【請求項３】
請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目のアドレスを返すオブジェクト・メソッドを含むことを特徴とする装置。
【請求項４】
請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目を指し示すポインタを返すオブジェクト・メソッドを含むことを特徴とする装置。
【請求項５】
請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目のアドレスを返すオブジェクト・メソッドを含むことを特徴とする装置。
【請求項６】
請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるクラス項目に対する名前参照を受け取り、該クラス項目のハンドル識別子を返すオブジェクト・メソッドを含むことを特徴とする装置。
【請求項７】
請求項１において、前記ロード・モジュールは、
当該ロード・モジュールにより参照される項目である関数項目とデータ項目とクラス項目とを含む他のロード・モジュールの名前のリストと、
該名前のリストをスキャンし得られた他のロード・モジュールの名前を返す反復子と
を含むことを特徴とする装置。
【請求項８】
請求項７において、前記ロード手段は、ロード・モジュールの反復子をコールし、得られた参照のセットを用いて、ロードされなければならない他のロード・モジュールを判定することを特徴とする装置。
【請求項９】
請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールが前記ロード手段によりロードされているとき、該ロード・モジュールの必須のアドレス空間を指定するパラメータであって、前記アドレス空間のアドレス空間要件と、前記ロード・モジュールにより占有されるアドレスとを指定するパラメータを含むことを特徴とする装置。
【請求項１０】
請求項９において、前記ロード・モジュールは、それぞれ、ロード・モジュールにより必要とされるアドレス空間を指定するパラメータであって、該ロード・モジュールに含まれているアドレス空間パラメータを、前記ロード手段に返して、該ロード手段が前記ロード・モジュールをロードできるようにするオブジェクト・メソッドを含むことを特徴とする装置。
【請求項１１】
請求項１において、前記ストレージは、ロード・モジュールをリンキングしている間にコンピュートされたデータを、同一ロード・モジュールを再リンキングするときに再使用するためにセーブするためのキュッシュ領域を含むことを特徴とする装置。ほへ
【請求項１２】
請求項11において、前記ロード・モジュールは、それぞれ、セーブされたデータが有効であるかどうかを示す情報を含むことを特徴とする装置。
【請求項１３】
ストレージと、
複数のロード・モジュールを前記ストレージの１次アドレス空間にロードする手段であって、このロードが完了した後、前記複数のロードモジュールをそれぞれ、本手段により決定した再配置アドレスに再配置するロード手段と、
前記ロード・モジュール内の参照を、対応するアドレスと置換して、当該参照を解決するため、前記各ロード・モジュールをパースするパース手段と
を有するコンピュータにおいて、前記複数のロード・モジュールをロードしリンキングする方法において、
プログラムコード関数項目と、データ項目と、クラス項目と、項目名参照を受け取り受け取った項目名参照に基づき参照した項目のアドレスを返すオブジェクト・メソッドとを含むソフトウェアプログラムオブジェクトであるロード・モジュールを前記パース手段によりそれぞれパースさせるステップと、
各ロード・モジュールからプログラムコード関数項目についての項目名参照を前記パース手段により獲得させるステップと、
獲得した項目名参照に基づき当該ロード・モジュール以外の別のロード・モジュールにおける項目が参照されていると判断した場合に、前記パース手段により、該別のロード・モジュールにおけるオブジェクト・メソッドを当該項目名参照を用いてコールさせ、該オブジェクト・メソッドにより項目名参照に基づき参照された項目のアドレスを獲得させ、獲得したアドレスを前記当該モジュールにおけるプログラムコード関数項目にパッチさせるステップと
備えたことを特徴とする方法。
【請求項１４】
請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目を指し示すポインタを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
【請求項１５】
請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目のアドレスを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
【請求項１６】
請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目を指し示すポインタを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
【請求項１７】
請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目のアドレスを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
【請求項１８】
請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるクラス項目に対する名前参照を受け取り、該クラス項目のハンドル識別子を返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
【請求項１９】
請求項13において、前記ロード・モジュールは、
該ロード・モジュールにより参照される項目である関数項目とデータ項目とクラス項目とを含む他のロード・モジュールへの参照のリストと、
該参照のリストをスキャンし得られた他のモジュールの名前を返す反復子と
を含むようにコンストラクトされることを特徴とする方法。
【請求項２０】
請求項19において、ロード・モジュールの反復子を前記ロード手段によりコールさせ、得られた参照のセットを用いて、ロードされなければならない他のロード・モジュールを判定するステップをさらに備えたことを特徴とする方法。
【請求項２１】
請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールが前記ロード手段によりロードされているとき、該ロード・モジュールにより必要とされるアドレス空間を指定するパラメータであって、該アドレス空間におけるアドレス空間要件と、前記ロード・モジュールにより占有されるアドレスとを指定するパラメータによりコンストラクトされることを特徴とする方法。
【請求項２２】
請求項21において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれているアドレス空間パラメータを、前記ロード手段に返して、該ロード手段が前記ロード・モジュールをロードできるようにするオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
【請求項２３】
請求項13において、ロード・モジュールをリンキングしている間にコンピュートされたデータを、同一ロード・モジュールを再リンキングするときに再使用するためにセーブするためのキュッシュ領域を前記ストレージに割り当てることを特徴とする方法。
【請求項２４】
請求項23において、前記ロード・モジュールは、それぞれ、セーブされたデータが有効であるかどうかを示す情報を含むようにコンストラクトされることを特徴する方法。
【発明の詳細な説明】
著作権保有表記
本特許出願には、著作権保護の対象となる内容を含む。情報提供を目的とする限り、その内容の複製を妨げるものではないが、その他の全ての権利、特に、その内容を商業上利用する権利は留保する。
技術分野
本発明は、オブジェクト指向アプリケーションに関し、特に、オブジェクト指向アプリケーションのための新規なロード・アーキテクチャに関する。
背景技術
ワークステション・ソフトウェアのディベロパの間では、柔軟性のあるソフトウェア環境を提供し、その上、ユーザインタフェースの一貫性を維持することがますます重要になっている。この種のオペレーティング環境を提供しようとする初期の頃の試みは、米国特許第4,686,522号（Hernandez他）に開示されている。この特国には、グラフィックとテキストを結合した処理システムであって、ユーザがカーソル位置に動的メニューをインボークして、その動的メニューから種々の機能をインボークすることができる処理システムが記述されている。このようなユーザとの自然な対話により、ユーザ・インタフェースが改善され、アプリケーションが非常に直観的なものになった。オブジェクト指向アプリケーションは、どのアプリケーションが現在アクティブであるかとか、多数のユーザがアプリケーションを並行してどのように使っているかに関係なく、ユーザとの一貫したインタフェースを反映していなければならない。
An Approach to Genuine Dynamic Linking Software−Practice and Experience,Vol.21（４）,pp.375−390（April 1991）には、オブジェクト・モジュール（ライブラリ・ファイルまたは個々のファイルのいずれかに位置する）を実行プログラムに動的にリンクするためのアプローチが開示されている。この文献は、アセンブリまたはコンパイルにより得られる「オブジェクト・モジュール」について記載されている。オブジェクト・モジュールはコンパイルの結果として用いられるものであって、OOP（object−oriented programming）でいうところのオブジェクトではない。この文献は、プログラミング言語ソースファイルをアセンブリまたはコンパイルして得られるオブジェクト・モジュールをどのように動的にリンクするかを教示している。
Relocating loader for MS−DOS.EXE executable files,vol.17,no.7,Microprocessors and Microsystems（Sept.1990）には、オブジェクト・ファイルをリンクし、ロード・モジュール（この文献でいうところの、バイナリ・ローダおよび再配置ローダ）を作成する２つの方法が開示されている。バイナリ・ローダは、特定のメモリ・アドレスに駐在するために、予めリンクされたロード・モジュールをメモリに読み込む。この開示によれば、ロード・モジュールは同一のメモリ・アドレスにロードしなければならない。再配置ローダは特定のフォーマットのロード・モジュールをメモリの任意の領域に読み込む。そのプロセスでは、再配置ローダは特定のアドレス・フィールドを再配置し、ロード・モジュール内に含まれたプログラムを、プログラムがロードされたメモリ領域で適正に実行することになる。この文献には、ローダ・プログラム、すなわち、実行可能なロード・モジュールをストリッジから読み出し、アドレシング・リンクを分析解決（resolve）し、そのプログラムの実行を開始するために用いられたローダ・プログラムのインプリメントが記載されている。このプログラムの目的は、MS−DOSを活用しないで、デベロップ・システム上で.EXEプログラムをロードし実行するための手段を提供することにある。
Run−Time Type Identification for C＋＋（Revised）,Usenix C＋＋ Technical Conference Proceedings,pp.313−339（August 1992）には、ランタイム型識別を行ない、チェックされた型キャストを行なう手段が記載され、オブジェクトのランタイム型識別をインプリメントするために、可能な限りＣ＋＋言語を拡張することが記載されている。この文献にも、ランタイム型識別を、Ｃ＋＋の異なる環境に対して行なうことができる方法が説明されている。しかし、この文献には、ロード・モジュールさえも説明されていない。
A Trip to Object−Oriented Land,Microprocessing and Microprogramming,vol.35,pp.195−202（1992）には、OOPパラダイムに関する概念が開示されており、オブジェクト技法に関連する種々の高レベルな機能が説明されている。しかし、この文献では、クレームされた発明の構成要素を教示していないし、示唆していない。
Cross−Address space Dynamic Linking,Proceedings 2nd International Workshop Object Orientation in Operating Systems,pp.250−56（Sept.1992）には、カーネルモードで実行を必要としないクロス・アドレス空間動的リンクのインプリメントが開示されている。この文献では、個々にコンパイルされたモジュールを第１のメモリ・アドレス空間でリンクする方法を、第２のメモリ・アドレス空間で実行しているリンク・プログラムから利用する。このリンクは、カーネル実行状態にしないで行われる。これらの機能は、オブジェクト指向OS（operating system）、spring OS（operationg system）によりサポートされている。この文献には、コードを、第２のメモリ・アドレス空間に動的に挿入し、実行スレッドを第２のメモリ・アドレス空間でアクティブする方法が開示されている。本質的には、第１アドレス空間のプログラムによりパフォームされている第２アドレス空間でランタイム・リンクする手段を提供する。
GA−Ａ−2 242 293（Apparatus and method for dynamic linking of computer software components）には、オブジェクトを動的にリンクする方法が開示されている。この文献では、本出願で用いているようなロード・モジュールには言及されていないが、オブジェクト指向のオブジェクトを動的にリンクすることには言及されている。オブジェクト環境のオブジェクトは、メッセージ・ストリームまたは通知を利用する情報を共有するように設計されている。しかし、オブジェクトはコンパイルされないし、クレームされた本発明のように、リンク・エディットしてロード・モジュールを作成しない。
本出願人が挙げた従来例では、新規なハードウェアも提供されないし、オブジェクト指向アプリケーションが一貫して機能することができるソフトウェア・システム機構も提供されていない。種々の開発環境と、ツールにより、種々のフォーマットとレイアウトを有するロード・モジュールが作成される。これらの環境では、オブジェクト指向技法を用いて、ロード・モジュールを単一のアプリケーションに統合することはできない。
発明の開示
本発明は、ラインタイムに、ロード・モジュールを動的にリンクするシステムおよび方法を提供することにより、従来例の問題点を解決する。好ましい実施態様では、異なる物理的なフォーマットを有するロード・モジュールのコレクションを採用しており、ロード・モジュールは、それぞれ、関数、静的データ、クラスを含み、ロード・モジュールが静的にリンクされたようにロード・モジュールを見せている。しかし、第１のロード・モジュールで実行するコードは、第２のロード・モジュール・コードに対するオペレーション、例えば、関数をコールするようなオペレーションをパフォームするか、あるいは、ある関数を指すポインタを得ることができ；静的データにアクセスするか、あるいは、その静的データを指すポインタを得ることができ；あるクラスの任意のパブリックまたはプロテクト・メンバ関数をコールして、ポインタを得るか、あるいは、そのクラスのパブリックまたはプロテクト・データ・メンバにアクセスすることができ；あるいは、あるクラスのオブジェクトの任意の基本クラスにキャストすることができる。
【図面の簡単な説明】
第１図は本発明の好ましい実施態様に係るパーソナル・コンピュータ・システムを示すブロック図である。
第２図は本発明の好ましい実施態様において、TLoadModuleがどのように関数、静的データ項目、クラスのコレクションとしてアクトするかを説明するための説明図である。
第３図は本発明の好ましい実施態様に係るコンピュータのメモリにアプリケーションのTLoadModuleが現れるとき、アプリケーションのTLoadModuleのメモリマップを示す図である。
第４図および第５図は、本発明の好ましい実施態様に係るロード・モジュールであって、オープンし、ロードし、アンロードし、クローズするロード・モジュールの論理的処理を示すフローチャートである。
第６図、第７図および第８図は、本発明の好ましい実施態様に係る処理であってフローチャートで実行される処理の概要を示す図である。
第９図は本発明の好ましい実施態様に係る、LibAによってエキスポートされた関数の再配置アドレスに対するシステム・ストリッジのメモリ・マップを示す図である。
発明の詳細な説明
本発明の好ましい実施態様は、パーソナルコンピュータ、例えば、IBM（登録商標）社のPS/2（登録商標）、またはアップル（登録商標）社のマッキントッシュ（登録商標）コンピュータ上に駐在するオペレーティング・システムのコンテキストで実施されるのが好ましい。代表的なハードウェア環境は第１図に示す。第１図は本発明の好ましい実施態様に係るワークステーションのハードウェア構成を示す。このハードウェア構成は、従来のマイクロプロセッサのようなCPU（central processing unit）10と、システム・バス12で相互に接続された数多くの他のユニットを有する。第１図に示すワークステーションは、RAM（random access memory）14、ROM（read only memory）、ディスク・ユニット20などの周辺デバイスをバスに接続するためのI/Oアダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などの他のユーザ・インタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプタ22と、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ34と、バスをディスプレイ・デバイス38に接続するためのディスプレイ・アダプタ36とを含む。ワークステーションには、IBM OS/2（登録商標）オペレーティング・システムまたはアップルのSystem/7（登録商標）オペレーティング・システムが駐在しているのが典型的である。
ロード・モジュールは、関数と、静的データと、クラスを実装したものである。TLoadModule、すなわち、抽象クラスは、ロード・モジュールをロードしアクセスするプロトコルを定義する。TLoadModuleにより、サブクラスは大幅に異なるアプローチを用いて、関数と、静的データと、クラスを、表現し実装することができる。例えば、NuBusカード上のROMか、ディスク上のブート・パーティション（boot partition）か、あるいはディスク・ファイルは、いずれも、ロード・モジュールとして見ることができる。同様に、異なるプログラミング言語および開発環境は、事前に存在するTLoadModuleサブクラスを使用するか、あるいは、カスタム・サブクラスを設計して、特殊な要求に適合させることができる。TLoadModuleクラスは共通のプロトコルをローダに提供して、正反対の開発環境で構築された根本的に異なるデータ・コンテナをミックス・アンド・マッチさせることができる。
TIncrementalLoadModuleとTPublishedLoadModuleというクラスについて考察する。これらのサブクラスはTLoadModuleの実装とは全く異なって具現化され、目的も異なっている。TIncrementalLoadModuleは、コード開発時に、アプリケーションの実行が可能なまま、高速にインクリメンタル・リンクを行い、その上、ロード・モジュールを開発環境に繋ぎ止めておくように最適化されているが、サイズが大きくなるという犠牲を伴う虞がある。これに対して、TPublishedLoadModuleは実行速度を高速化し、ファイルサイズを最小化するように最適化されている。
ローダはロード・モジュールを使用する。ローダはロード・モジュールの仲介役の働きをする。ローダは関数と、静的データと、クラスを含むロード・モジュールのコレクションを受け取り、ロード・モジュールが相互に静的にリンクされているように見せる働きをする。あるロード・モジュールで実行されているコードは、それ自体の関数と、静的データと、クラスに対する同様のオペレーションと区別せずに、別のロード・モジュールからのエクスポートに対して次のオペレーションをパフォームすることができる。すなわち、
・  関数をコールするか、あるいはその関数を指すポインタを取得すること。
・  エクスポートされた静的データをアクセスするか、あるいはそのデータを指すポインタを取得すること。
・  あるクラスのパブリックまたはプロテクトメンバ関数をコールするか（仮想的または非仮想的に）、あるいは、プロテクトメンバ関数を指すポインタ取得するか、あるいはそのクラスのパブリックまたはプロテクトデータメンバをアクセスすること。
・  あるクラスのあるオブジェクトが与えられているときに、任意の基本クラスにキャストすること（仮想的または非仮想的に）。
TLoadModuleは、関数と、静的データと、クラスからなる３つのコレクションと同じようにアクトする。ローダのようなクライアントは、第２図に示すように、名前によって（by name）これらの集合をインデックスすることになる。第２図は、TLoadModuleが、関数と、静的データ項目と、クラスのコレクションのようにどのようにアクトするかを示す。さらに、ロード・モジュールにより、クライアントはその関数とクラスのエクスポートを、全て、反復子により調べることができる。
好ましい実施態様では、「ローダ」とは、アプリケーションのグローバル状態に対してオペレートする少数のメソッドをいう。これらのメソッドが保証していることであるが、ロード・モジュールを明示的または暗示的にロードするタスクの数に関係なく、所定のロード・モジュールは１アプリケーションに対して１回だけロードされる。例えば、２つのタスクが同一のフラットオブジェクト（flattened object）を同時に復元するものとする。オブジェクトを復元することにより、好ましい実施態様では、フラットオブジェクトがメモリにロードされ、適正なリンケージが次に説明するローダに従って準備される。
各タスクに復元オペレーションを実装するコードは、ローダをインボークすることができるが、最初のインボークだけがTLoadModuleでのオペレーションをインボークする。２番目のタスクにおける制御のスレッドは、所望のロード・モジュールが既にロードされていることを確かめ、参照カウントをバンプ（bump）するだけである。ローダは、次のステップにより、ロード・モジュールの集合が静的に相互にリンクされているかのように見せる。まず、ディベロパが外部依存を解決するゼロ以上の他のロード・モジュールで、所定のロード・モジュールを構築するとき、この所定のロード・モジュールはロード・モジュールの直接必須セット（direct required set）になる。このロード・モジュールは、この直接必須セットから使用する、特定関数と、静的データ項目と、クラスをストアする。ロードタイムに、ローダはその直接必須セット内にロード・モジュールが存在するか否かを、名前で（by name）ロード・モジュールに照会する。ローダは、互換性をとるために課せられた制約を逸脱しないように、このようなセットを計算する。
ローダはロード・モジュールＡをロードする必要がある場合、ロード・モジュールＡに対する直接必須セットの他動のクロージャ（transitive closure）を計算する。ローダはこのクロージャ内の各ロード・モジュールの初期化を行って実行する。例えば、ローダは、全てのロード・モジュール上で外部リンケージを解放するメソッドをコールし、その後、全てのロード・モジュール上で静的コンストラクタをコールするメソッドをコールする。同様のシーケンスは、逆順であるが、アプリケーションがシャットダウンするときに生じる。
好ましい実施態様では、共用ライブラリであるロード・モジュールと、慣用の意味でのアプリケーションは交換可能である。「アプリケーション」はwell−known入口点、例えば、メインプログラムを定義するmainを持っているのが典型的である。「入口点」の概念はTTaskProgramクラスに抽象化されている。TLoadModuleRefはヘルパ・クラスである。これはインタフェースであり、そのインタフェースにより、TLoadModuleは、ローダが依存するのは他のどのロード・モジュールかをそのローダに通知する。TLibrarysearcherは、ロード・モジュールを構築するために使用されることになる特定のデータコンテナに、ライブラリ名をマッピングするフレームワークを提供する。
第３図は、アプリケーションのTLoadModuleがコンピュータのメモリにストアされたときのメモリマップである。アプリケーションは、特定の関数または静的データエクスポートのアドレスに関する照会に応答することができる。クライアントはエクスポートされるクラスと、関数と、静的データをブラウジングすることができる。
オープンし、ロードし、アンロードし、クローズするロード・モジュールから見たイベントの基本的シーケンスを、次に説明し、第４図および第５図のフローチャートに示す。後程、TLoadModuleサブクラスのディベロパが、どのようにキャッシング最適化をハンドルしているかを詳しく説明する。クローズされたロード・モジュールは、TLibrarySearcherから返された１次データコンテナから作られる。データコンテナとは、アプリケーション・プログラム用のファイルか、ROMか、メモリか、あるいは他のストリッジ機構をいう。ローダは１次データコンテナを、リードオンリモードで、アドレス空間にマッピングする。規則により、１次データコンテナは、TLoadModuleのフラット表現を含む一定サイズのストリームを、データ・コンテナの最初の部分に対して事前に定義されたロケーション（kFlattenedLoadModuleOffset）に収めてある。
Closed−−〉Opened
a.第１ステップにて、第４図の機能ブロック410に示すように、空のコンストラクタを用いてアプリケーションを構築する。
b.（operator〈〈＝）そして、アプリケーションは、機能ブロック420にて、ストリームインされる。このストリームは、サイズの要件か、メタデータ用のフラットTFileか、コード用のTFileか、あるいはどのデータ・コンテナを使用すべきかを示す他のオブジェクトを含む。そのストリームはGetNameおよびGetContentIDコールに応えられるだけの情報を含むか、あるいはこの情報を収めているデータ構造を指している。
c.このアプリケーションが所定のデータコンテナをオープンする最初のアプリケーションである場合は、このアプリケーションは、機能ブロック430にて、次のような情報を提供しなければならない。このアプリケーションが所定のデータコンテナをオープンする最初のアプリケーションでない場合は、ローダはそのアプリケーションより前のアプリケーションにより提供された返答を使用する。従って、この返答は、データコンテナの内容のみに依存するか、あるいは、データコンテナの内容に関連するキャッシュにのみ依存する。
第３図のロードマップに示すように、アプリケーションは、（例えば、データ構造が前もって計算されキャッシュされたため、）最初に、アプリケーションの固定空間の所要量と、特定の再配置アドレスの優先権を示さなければならない。また、アプリケーションは、その１次データコンテナの上下にあるアドレス空間のブロックもそれぞれ要求する。それらのブロックは、それぞれ上位サイズ300および下位サイズ310という。１次データコンテナ315に、上位サイズと下位サイズを加えたものは、このロード・モジュールの１次アドレス空間という。アプリケーションは上位サイズと下位サイズの一方または両方をゼロに指定することができる。上位サイズと下位サイズの両方がゼロということは、アプリケーションは、１次データコンテナをマッピングするのに必要な最小空間を超えるアドレス空間を追加する必要がないということである。
d.（再配置）
アプリケーションは、機能ブロック440にて、再配置アドレス330を割り当て、その再配置アドレスに割り当てられた仮想アドレス空間を割り当てなければならない。これは注意すべきことであるが、アプリケーションは、アプリケーションに割り当てられたアドレス空間をどのように使用するかを選択することができる。特に、１次アドレス空間320内の１つ以上のセグメントをオープンすることは自由であり、選択された場合は、セグメント間にギャップを存在させることができる。可能であれば、当該ローダは、ステップＣで要求されたアドレスを割り当てる。しかしながら、仮にメモリ管理制限によりこのようなアドレス割り当てが阻止される場合には、当該ローダは、代替アドレスを割り当てることになる。次に、アプリケーションは、ロードされる場合、ステップｅへ進むことができ、クローズされる場合は、ステップｎへ進むことができる。
e.Opened−−〉Loaded
（CreateDirectRequiredLoadModuleRefIterator）は他のどのロード・モジュールを必要とするかを示す。というのは、アプリケーションは、クラスか、関数か、あるいは静的データに対して、他のロード・モジュールに依存するからである。TLoadModuleRefは、第４図の機能ブロック450にて、リンケージのために必要な各ロード・モジュールの名前で作成され、反復子によりローダに渡される。ローダはロード・モジュールの他動のクロージャを計算し、ロード・モジュールをオープンし、モジュールに、TLoadModuleメソッドコールを行うためアクセスする。
f.（静的データの初期化）
第５図の機能ブロック510に示すようにアプリケーションの静的データを初期化する。
g.（リンク）
第５図の機能ブロック520に示すように、アプリケーションを、ステップｆにて指定されたロード・モジュールとリンクさせる。例えば、アプリケーションが別のロード・モジュール内の関数への外部ジャンプを含んでいる場合は、そのロード・モジュールにその関数のアドレスが存在するか否かを照会し、結果に応じてアプリケーションにパッチを当てる。同様に、別のロード・モジュールによってエクスポートされたグローバル・データ項目を参照するコードが存在する場合は、そのロード・モジュールにそのアドレスが存在するか否かを照会する。最後に、アプリケーションが、別のロード・モジュールによってエクスポートされたクラスから直接または間接的に継承するクラスを含んでいる場合は、そのロード・モジュールに、そのクラスに対応するTClassHandleが存在するか否かを照会する。さらに、直接または間接必須とされるロード・モジュールに依存する計算を行う。
h.（静的コンストラクタのコール）
機能ブロック530に示すように、アプリケーションの静的コンストラクタをコールする。
i.（CallEnterProcs）
機能ブロック540に示すように、実行された静的コンストラクタに依存するが、ユーザ・コードの前に生じるプロシージャはどのプロシージャもコールする。アプリケーションはこの処理のこの時点でロードされる。クライアントは、アプリケーションがエクスポートするクラスか、関数か、あるいは静的データはどれでも使用することができる。アプリケーションはエクスポートについての参照をハンドルするためにレディになるが、それは、これらエクスポートの１つが存在するか否かを名前で（by name）直接に照会されるときか、あるいは、反復子が供給されることにより、クライアントが各エクスポートをテストすることができるときのいずれかである。
Loaded−−−〉Opened
j.（CallExitProcs）
そして、アプリケーションは、ユーザ・コードが完了した後で、静的デストラクタがランする前に、ランする必要のあるプロシージャはどのプロシージャもコールする。
k.（CallStaticDestructors）
ついで、アプリケーションは、機能ブロック550に示すように、そのアプリケーションに特定された静的デストラクタをコールする。
l.（アンリンク）
そして、機能ブロック560に示すように、アプリケーションはアンリンクする。実際には、このことは、アプリケーションを再ロードすることはできないにもかかわらず、再ロードの準備をすることを指している。アプリケーションは同一の再配置アドレスを保持しているが、そのアプリケーションが依存する他のロード・モジュールは変化する。例えば、アプリケーションがライブラリＡに依存している場合は、ローダはアプリケーションに「アンリンク」するか否かを照会し、オープンを維持するだけの内部状態を保存するが、ライブラリＡがアプリケーションに通知したものに依存する状態はどの状態も破壊するか否かを照会する。これには、関数と静的データのアドレスが含まれる。キャッシングの実装では、この点に注意する必要がある。さらに、アプリケーションは、ローダが直接および間接ロード・モジュールを切断する前に、オペレーションをパフォームする。
m.（FinalizeStaticData）
そして、アプリケーションは、機能ブロック570に示すように、その静的データを最終化する。今、アプリケーションは、オープン・ロード・モジュールに対して有効な任意のメソッドを処理できる。アプリケーションの処理は、第４図の機能ブロック450に示すステップｅに移行するか、第５図の機能ブロック580に示すステップｎに移行する。ステップｅでは、アプリケーションは再ロードされ、ステップｎでは、アプリケーションはクローズされる。
0003550151.tif 000002
n.自身の破壊
アプリケーションは機能ブロック580にてクローズされ、処理は機能ブロック590にて完了する。このフローチャートに示すステップは、第６図と、第７図と、第８図に示すテーブルに要約してある。
このセクションでは、TLoadModuleサブクラスの設計者が利用できる設計ラチチュードの例を挙げる。ロード・モジュールは１次アドレス空間がどれだけ必要であるかをローダに伝え、ローダはその要求をlibserverに渡す。ローダは連続ブロックを返す。そのブロックのサイズはGetRequiredLowerSpaceSizeおよびGetRequiredUpperSpaceSizeのサイズと、１次データ・コンテナのサイズとの総和と同じである。（例えば、以前に計算され、キャッシュされたデータ構造を再使用するために）ロード・モジュールも特定の再配置アドレスを要求することができるかもしれないが、ローダは異なるアドレスを割り当てることができる。再配置アドレスの割当てはRelocateメソッドにより生じる。
同一マシン上の２つのアプリケーションが、「同一の」データ・コンテナによってバックされたモジュールをロードする場合は、ロード・モジュールに同一の再配置アドレスを割り当てることを、ローダは保証する。さらに、ロード・モジュールの実装は、割り当てられたアドレス範囲を、異なるインスタンス間で一貫して使用する必要がある。（例えば、アプリケーションがロード・モジュールＡをロードし、しかも、libseverがロード・モジュールＡに再配置アドレスｘを割り当てた場合は、所定の静的データ項目を、どのアプリケーションでも、「同一の」アドレスｘ＋ｓに置くには、好ましい実施態様の約束により、TLoadModuleの全インスタンスが必要である。ロード・モジュールが上位サイズと下位サイズの両方に対してゼロを要求しても、それは有効である。この約束に違わなければ、ロード・モジュールには、１次データ・コンテナをマッピングできるだけの空間が割り当てられることになる。TLoadModuleを簡単に実装するには、このようにすることができる。
上位エリアと下位エリアがあるため、ロード・モジュールの設計者は、再配置アドレスに対して、正負の両方向に、アドレス範囲を柔軟に割り振ることができる。例えば、１つには、静的データ・エリアを下位エリアに割り当て、コードを１次データ・コンテナの一部としてマッピングするというアプローチがある。このようにした場合、ロード・モジュール（例えば、リンカ）の作成者は、再配置アドレスからの正のオフセットにコードを置くことができ、静的データ・アドレスを負のオフセットに割り当てることができる。コードと、静的データアドレスは、作成時に、互いに衝突することなく、無関係に大きくなる。
ゼロ個、１個、または多数のセグメント
割り当てられたアドレス空間内においては、ロード・モジュールは、上述したように一貫している限り、自由に、無制限に、セグメントを作成しマッピングすることができる。例えば、ある実装は、コード、静的データ、リンケージ、等々に対して別々のセグメントを使用することができる。ある実装は、より多くのセグメントをマッピングするか、あるいは、１つもマッピングしないかを選択することができる。特定の例では、静的データが含まれる。１つのロード・モジュールの実装は、前に存在し完全に初期化されたセグメントまたはファイルをマッピングすることを選択することができる。静的データ・エリアの非ゼロ部分用のセグメントをマッピングし、静的データ・エリアのゼロ部分をカバーする別のセグメントを作成することを選択することもできる。第３の実装により、初期化されていないセグメントを作成し、しかも、その内容を入れるためにDataInitスタイルのプログラムをコールすることが選択できる。
絶対アドレス
幾つかの言語（例えば、FORTRAN）では、メイン・ロード・モジュールを絶対アドレスにロードする方法が必要になることがある。言語がこの機能を必要とする場合や、リンカがこのことを想定している場合は、必須のTLoadModuleサブクラスはロードタイムにアドレスにパッチを当てる。これは、本発明の好ましい実施態様では、特定の再配置アドレスに割当てることを保証することができないからである。
キャッシングによる最適化
後続のロードで再使用できる１つのロードに対する計算結果をセーブすることにより、ロード・モジュールの実装には、パフォーマンスを向上させるだけの機会がある。前のロードからのキャッシュ情報が有効か否かの判断を援助するため、ロード・モジュールは次の質問に答える。
a.  GetContentIDはロード・モジュールの内容に対応するIDを返す。２つのロード・モジュールが同一の内容IDを有する場合は、これら２つのロード・モジュールに対して、リードオンリコードと、初期化された静的データとが、ビット単位で等しいことを保証する。この保証は、Linkステップ時に、他のロード・モジュールからインポートされたアドレスにより後で埋められることになる静的データに対して行う必要はない。
b.  GetRelocationIDは後でロード・モジュールからクライアントに返すことができるアドレスであって、全ての関数アドレスと、静的データ・アドレスからなるアドレスに対応するIDを返す。これらのアドレスはRelocateメソッドに渡されたIoadAddressに依存するのが典型的である。再配置IDがその前に返されていて、アドレスが同一である場合は、同一の再配置IDを再度返すことができる。逆に、仮に同一のIDが返された場合には、他のロード・モジュールは、再び当該アドレスを要求する代わりに、前に返されたアドレスを使用する。これは次のことを暗に示している。すなわち、ロード・モジュールというのは、自分が保証し続けられないアドレスは決して返さない。これらアドレスとしては、Link（）メソッドを処理中にコールされているGetFunctionAddress（）メソッド及びGetDataAddress（）メソッドが返す関数及びスタチックデータアドレスが含まれる。すなわち、この保証を維持することができないアドレスであって、ロード・モジュールによりLinkステップ時に取得されたアドレスを含むアドレスを、ロード・モジュールは決して返さないことを暗に示している。要するに、再配置IDの目的はLinkステップ全体に関係する作業の大部分を完全に最適化することにある。次の点を考察する。
・  内容ID
ロード・モジュールの内容IDが変わった場合は、内容IDを別にリリースするために構築されたキャッシュを再使用しても、おそらく意味がないであろう。
・  再配置アドレス
ロード・モジュールの再配置アドレスが変わっていない場合は、そのロード・モジュールによってエクスポートされたアドレスの計算値を再使用することができる。同様に、再配置アドレスに依存する初期化済み静的データを使用することができる。内部に供給されたクラスのみから継承するクラスに対するvtablesは誰でも使用することができる。vtablesには、ライブラリ内のコードのみを参照するメンバ関数ポインタも入っている。
・  必須または使用ロード・モジュールの内容ID
全ての必須ロード・モジュールが、他動のクロージャの意味において、前のロードで見られたような同一の内容IDである場合は、ロード・モジュールのアドレスには依存せず、ロード・モジュールの内容に依存するフィックスアップ（fixup）またはパッチを再使用することができる。例えば、仮想関数コールの実装に対する１つのアプローチでは、コードの小断片（"thunks"）を用いる。コードの小断片は仮想関数テーブルのインデックスである。ただし、インデックスはロードタイムに計算され、コードにパッチされる。これらのインデックスはクラス階層およびメンバ関数の数に依存するが、必須ロード・モジュールの再配置アドレスには依存しない。階層内のクラスに対する全てのロード・モジュールが同一内容IDをもっている場合は、メンバ関数の数は変更されず、パッチを当てた小断片（thunk）を再使用することができる。
・  必須または使用ロード・モジュールの再配置ID
さらに、必須ロード・モジュールの再配置アドレスも同一である場合は、他のロード・モジュールからインポートされた関数と静的データに基づいて、リンケージを再使用することができる。これには、関数を指すポインタを含むvtableがある。次の典型的な場合では、ロード・モジュールのキャッシュ情報は、有効なものと仮定する。すなわち、ｉ）ロード・モジュール自体が以前と同一の内容と再配置IDを持つ場合であって、しかも、ii）ロード・モジュールが使用するロード・モジュールに対して、ii.a）ロード・モジュールが同一再配置IDを持ち、ii.b）ロード・モジュールが同一内容IDを持つ場合。次のアルゴリズムは、Link時にコールされるものであり、次の条件を満足しているかどうかを判定する。
0003550151.tif 000003
0003550151.tif 000004
その他の種類のキャッシュは、好ましい実施態様で説明するIDプリミティブを用いて、キャッシュ自体の有効性をチェックすることができる。例えば、直接必須ロード・モジュールの再配置アドレスだけに依存するキャッシュは、その条件が存在するか否かを正確にチェックすることができる。これらの考え方を分かりやすく説明するため、関数fooをエクスポートするロード・モジュールLibAを考察する。ロード・モジュールLibBは関数fooをコールする。前のロード上に、LibBは関数fooのアドレスをセーブした。関数fooはLibAの１次データ・コンテナに駐在するので、このアドレスは、
ａ）Ａ内の関数fooのオフセットの関数
ｂ）LibAの再配置アドレスの関数
になる。
関数fooのアドレスがその後のロードにおいて再使用できるか否かを判断するためには、LibAが返したコンテント及び再配置IDを一時的にストアし、しかも、LibAが再ロードされたとき、これらストアされた値をチェックするだけで充分である。
第９図は、本発明の好ましい実施態様に従ってLibAによってエクスポートされた関数の再配置アドレスのシステム記憶機構におけるメモリ・マップである。再配置IDが再配置アドレスの概念をどのように一般化したかに注意されたい。再配置アドレスを知れば、１次アドレス空間に含まれた項目を知ることができ、再配置IDは１次アドレス範囲や、他のアドレス範囲、例えば、アプリケーションの大きさの静的データ・プールに駐在する項目にまで及ぶ。
キャッシュ
TLoadModuleのサブクラスはそのリンケージ・エリアのコピーをファイルとしてキャッシュするものとする。ただし、同一のロード・モジュールをロードする別のアプリケーションは、そのリンケージ・エリアの再使用を試みることができるものとする。このように共用には潜在能力があるので、キャッシュされたリンケージ・エリアは、共用書込み可能状態を表し、しかも、マルチアプリケーション・セーフになるように設計しなければならない。アプリケーションが異なると、異なるライブラリ・サーチャ（library searcher）を使用することができる。このことは、あるアプリケーションで有効なキャッシュされたリンケージ・エリアも、あるアプリケーションにとって、有効でないかもしれないことを暗に示している。このことから、TLoadModuleサブクラスは次のような状況をハンドルする必要があることが分かる。すなわち、ａ）  複数のアプリケーションがセーブされたリンケージ・エリアを同時に書き出そうとする。ｂ）  あるアプリケーションが、セーブされたリンケージ・エリアが有効か否かをチェックしようとし、それに並行して、別のアプリケーションがセーブされたリンケージ・エリアを無効にし、更新されたコピーを書き出そうとする。ｃ）  ２つ以上のアプリケーションが、（例えば、低レベル・ユーティリティ・ロード・モジュールの異なるリリースを使用しているため、）何かが有効なリンケージ・エリアを構成しているという衝突する概念を持ち、このため、キャッシュが「スラッシング」される。
追加のアドレス空間
ロード・モジュールは、その１次アドレス空間として獲得したアドレス空間より大きいアドレス空間を発見することができることもある（例えば、このようなことは、Linkフェーズで起こる）。TLoadModuleのアプリケーションは、再配置IDの保証を認識していなければならない。ロード・モジュールはLinkフェーズでその再配置IDが存在するか否かが照会されるのが典型的である。ここで、Linkフェーズとは、CreateDirectRequiredLoadModuleRefsの後で、しかも、CallStaticConstructorsの前のことである。ロード・モジュールは、Link時を含めて、CreateDirectRequiredLoadModuleRefsの後で獲得した追加のアドレス空間を、エクスポートアドレスとして供給することができない。追加のアドレス空間を、エクスポートアドレスとして供給することができる場合は、再配置IDの保証を維持することができない。
異種言語間のオペラビリティ
同一のCPUアーキテクチャ内では、異種言語によってまた異種開発環境によって作成されたロード・モジュールがミックス・アンド・マッチ（mix−and−match）される。本発明の好ましい実施態様では、エクスポートされた関数と静的データ項目に対応するアドレスは、特定のCPUのコール規則に従う必要がある。この特定のCPUのコール規則には、本発明のコール規則の好ましい実施態様と、規則の異なる内部セットとの間での変換に対応するアドレスを供給することを含むことができる。例えば、非ネィティブＣ＋＋環境（例えば、Lisp）によって作成されたロード・モジュールは、次の場合には、自由にミックス・アンド・マッチすることができる。すなわち、
１）  エクスポートされた関数の関数アドレスに対応するロード・モジュールへのコールは、コール規則が一貫しているコードを指している。
２）  ロード・モジュールからのコールは、内部規則から、本発明の好ましい実施態様に対応する規則に変換するグルー・コード（glue code）を渡り歩く。
３）  エクスポートされた静的データ項目の静的データアドレスに対するreadが行われたとき、正しい値がある特定のデスティネーションに現れる。
４）  エクスポートされた静的データ項目の静的データアドレスに対するwriteが行われたとき、データ項目は、ある特定のソースから正しい値を獲得する。
５）  さらに派生された派生クラスへのキャスティングと、基本クラスへのキャスティングは、階層内のクラスが全て同一のプログラミング言語によって定義されていなくても、共に実行する。
６）  パブリック・データメンバまたはクラス静的データメンバへのアクセスがある場合は、そのアクセスを実行する。
７）  エクスポートされたクラスか、関数か、あるいは静的データ項目のTClassHandleまたはTFunctionHandleオブジェクトへの仮想関数コールは、それぞれ、クラスのプロトコルに従っている。
例えば、TLoadModuleのサブクラスは、Ｃ＋＋以外の環境と、任意の共用ライブラリ（例えば、RunTime,LowLevelToolbox）から作成されたものと仮定する。開発環境が充分に頑強であり、個々の宣言が元の共用ライブラリを構築するために使用された場合は、その共用ライブラリを他の開発環境で再実装することができる（勿論、開発環境の中には、選択により、それらのクラスを他の環境によってサブクラスにできる能力を制限することができるものもある。このような環境は、この定義によれば、「充分に頑強な環境」でない。）。この考察により、キャスティングと、仮想関数コールと、非仮想関数コールと、パブリック・データメンバへのアクセスに対して、共通オブジェクト・レイアウトを定義する各CPUアーキテクチャの重要性が強調される。
ロードタイムまたはランタイムのバインディング
効率を高くするため、大部分のロード・モジュールは、ロード時に、関数と静的データ名のバインディングをLinkステップで解決する。このストラテジは、関数と静的データ項目の数が、これらの使用回数に比べて少ないときか、あるいはキャッシングが生じたときに、最適である。
別のストラテジィも可能である。例えば、ロード・モジュールは別のロード・モジュールに、関数または静的データ項目名に対応するアドレスが存在するか否かを照会するのを、ランタイムまで延期することができる。関数の数が非常に多く、しかも、コールする可能性が低い場合には、名前とアドレスのバインディングを最初のコール時に解決することが、より良いストラテジである。このような状態は、１つ以上の中型から大型までのロード・モジュールを構築する開発環境のコンテクストで生じる。その場合、編集−再コンパイル−再ラウンチ−デバックのループでまとまった時間が費される。
並行性（concurrency）
TLoadModuleのサブクラスは再入可能性を必要としない。というのは、TLoadModuleオブジェクトがアプリケーション上の全てのタスクによって共用され、複数のタスクがローディングを並行して行うにも関わらず、ローダが「ローダ・セマフォア」に従ってオペレーションをパフォームするからである。
パック静的データ（packed static data）
幾つかのパフォーマンス測定で明らかになったことであるが、ロード・モジュール当たりのwrite可能な静的データの量が、１ページよりもはるかに少なくなることがよくある。このため、各ロード・モジュールがその静的データと無関係になると、フラグメント化が非常に多くなる。所定のマシン上のwrite可能な静的データ量は、アプリケーション当たりのロード・モジュール数にアプリケーションの数を掛けた積である。フラグメント化により、物理メモリに対する要求が大きくなり、パフォーマンスが損なわれる。この問題に対する１つの解決方法には、静的データを、アプリケーション上の全てのロード・モジュールから、１アプリケーションに対するメモリ・セグメントにパックする方法がある。
静的データ・アドレスはエクスポートとして渡されるので、パック静的データ技法を実装する人は再配置ID保証を遵守しなければならない。１つの技法には、共用システム空間メモリの所定のブロックが存在するか否かを、InitializeStaticDataステップで、登録する技法がある。前と同一のアドレスが獲得され、しかも、Relocateステップが以前と同一のロード・アドレスで渡す場合は、GetRelocationIDが前と同一のIDを返すことは有効である。
8.クラス記述
次のＣ＋＋コードは、クラス記述の好ましい実施態様によるロジック（論理）を示す。
0003550151.tif 000005
0003550151.tif 000006
0003550151.tif 000007
0003550151.tif 000008
TLoadModule基本クラスをストリーム・アウトする。サブクラスは自身のスタッフ（stuff）をストリーム・アウトする前に、TLoadModule基本クラスをコールする必要がある。
0003550151.tif 000009
TLoadModule（）；
空のコンストラクタはストリーミングに適したオブジェクト状態を初期化する。
TStream＆ operator＜＜＝（TStream＆ fromwhere）；
TLoadModule基本クラスをストリームインする。サブクラスは自身のスタッフをストリームインする前に、TLoadModule基本クラスをコールする必要がある。
const void＊GetPreferredRelocationAddress（）；
const size_t GetRequiredLowerSpaceSize（）；
const size_t GetRequiredUpperSpaceSize（）；
ロード・モジュールは、追加の１次アドレス空間のニーズを示す。優先アドレスは、ローダに、キャッシュを再使用するのに有利なアドレスが存在するか否かのヒントを供給する。ローダは優先アドレスに一致させようとすることになる。
void Relocate（const void＊relocationAddress,const TSurrogateMemory＆ primaryAddressSpace）；
ローダは１次アドレス空間の起点とロケーションを示す。
Open−−−〉Loaded
ローダは、現在のバッチでロードされている全てのロード・モジュールに重ねてこれらのコールをインタリーブする。すなわち、全てのロード・モジュールには、各自の静的データを初期化する機会が与えられ、その後、各自の直接必須ロード・モジュール名が存在するか否かが、全てのロード・モジュールに照会され、その後、リンクするか否かが、全てのロード・モジュールに照会される。以下、同様に行われる。
void InitializeStaticData（）；
静的データを初期化する。
TIterator＊CreateDirectRequiredLoadModuleRefIterator（）；
他のどのロード・モジュールにリンクする必要があるかを示している。反復子はTLoadModuleRefオブジェクトを返し、必須ロード・モジュールの名前をローダに通知する。
void Link（）；
TLoadModuleRef::GetLoadModuleメソッドを使用して、前のステップで供給された名前に対応する実ロード・モジュールを指すTLoadModule＊ポインタを獲得する。TLoadModule::GetFunctionAddressまたはTLoadModule::GetStaticDataAddressのようなコールを行って、エクスポートアドレスを獲得する。
void CallStaticConstructors（）；
Call static constructors.
void CallEnterProcs（）；
入口プロシージャ（enter procedure）が存在する場合は、入口プロシージャをコールする。現在では、幾つかのセマフォアまたは他の初期化がここで行われるが、これらのオペレーションは結果的にはなくなることになる。
Loaded−−−〉Open
void CallExitProcs（）；
出口プロシージャ（exit procedure）が存在する場合は、出口プロシージャをコールする。入口プロシージャで獲得することができる資源の割振りを解除する。
void CallStaticDestructors（）；
静的デストラクタをコールする。
void Unlink（）；
これは、他のロード・モジュールを使用するか、あるいは、他のロード・モジュールが破壊される前にクリーンアップする、最後のチャンスである。
void FinalizeStaticData（）；
静的データを最終化する。これに伴い、セグメントをクローズすることができる。（デストラクタ以外では、ここで、静的データに対して使用されたセグメントをクローズするのは意味がある。というのは、ブラウジングはオープン状態で可能であり、しかも、ロード・モジュールをブラウジングするのは都合がよい。オープン・セグメントのオーバヘッドはない。）
情報のget
TMappableDataContainer＊CreateMappableDataContainer（）const;
呼出し側によって削除されるオブジェクトを返す。このオブジェクトは、このロード・モジュールが作られたときの基礎となるデータ・コンテナを記述している。
voidGetName（TText＆ name）const＝0;
このロード・モジュールの名前を返す。Plutoデータ・コンテナに基づくロード・モジュールの場合は、この名前はLibraryNameプロパティに対応している。
TGlobalID GetContentID（）const;
ロード・モジュールの内容に対応するIDを返す。２つのロード・モジュールが同一の内容IDを持っている場合は、これらのロード・モジュールは、リードオンリコードと、初期化された静的データとがビットごとに等しいことが保証される。この保証は、Linkステップで、他のロード・モジュールからインポートされたアドレスで後で満たされることになる静的データに適用する必要はない。
TGlobalID GetRelocationID（）const;
ロード・モジュールが後でクライアントに返すことができるアドレスに対応するIDを返す。これらのアドレスは、全ての関数アドレスと、静的データ・アドレスよりなる。典型的には、これらのアドレスは、Relocateメソッドに渡されたloadAddressに依存する。再配置IDが前に返され、しかも、アドレスが同一である場合は、同一の再配置IDを再び返すことができる。
void＊GetFunctionAddress（const TText＆ export）const;
名前エクスポートにより指定された関数のアドレスを返す。
void＊GetStaticDateAddress（const TText＆ export）const;
名前エクスポートにより指定された静的データ項目の開始アドレスを返す。
TRecyclingIterator＊CreateAddressRangeIterator（）；
このロード・モジュールにより使用されるアドレス範囲に対応するTSurrogatedMemoryオブジェクトを返す反復子を返す。TSurrogatedMemoryオブジェクトはヒープ割振済み記憶機構を指すポインタを含むことができる。（これを、GarbageFinderのルートのソースとして使用することができる。）
Boolean DoesContainAddress（void＊addr）const;
仮に当該指定されたアドレスが１次アドレス範囲にある場合か、あるいは仮に当該指定されたアドレスが、当該ロード・モジュールがコントロールする別のアドレス範囲にある場合には、TRUEを返す。例えば、仮にthunkが、当該１次アドレス領域外に割り振られ、しかもデバッガが当該thunkにブレークポイントを設定した場合には、当該デバッガは、自身が当該thunkの名前を判断するために当該ロード・モジュールにケリーすることができるように、当該thunkがどのモジュールに属しているか否かを判断しようとすることができる。
CompatibilityNumber GetRelease（）const;
互換性番号を返す。他のロード・モジュールはこの番号を使用して、このロード・モジュールと互換性をもってランできるかどうかを判断する。
Boolean IsCompatibleWith（const CompatibilityNumber requiredRelease）const;
このロード・モジュールが、特定のリリースまたはそれ以前のリリースと互換性がある場合は、TRUEを返す。
TClassHandle＊CreateClassHandle（const TText＆ exportName）；
TClassHandleを返す。
TFunctionHandle＊CreateFunctionHandle（const TText＆ functionSignatureName）；
TFunctionHandleを返す。
TRecyclingIterator＊CreateClasIterator（）；
TRecyclingIterator＊CreateFunctionIterator（）；
クラスおよび関数ハンドルの反復子を返す。TRecyclingIteratorはTIteratorとは異なっている。ある反復から次の反復までの間に使用された記憶機構をリサイクルする権利を留保しているからである。例えば、Firstおよび連続するNextにより返されたTClassHandleの場合は、同一の記憶機構の可能性があるが、そこに書かれたデータは異なっている。そのため、コピーをキープしておきたいクライアントはそれをクローンにすべきである。
MCollectibleスタッフ
long Hash（）const;
Boolean IsEqual（const MCollectible＊other）const;
MCollectibleオブジェクトをベースオブジェクトとする２つのロード・モジュールは、仮にそれらを指し示すポインタが一致しているときは、等しいものと考えられる。というのは、同一アプリケーションの２つのロード・モジュールを、当該ローダがオープンしたりロードすることは、同一のデータコンテナである以上、エラーとなるからである。
TLoadModuleRefのメソッド記述
コンストラクタ、デストラクタ、割当て演算子
TLoadModuleRef（）；
復元のためにだけ使用する。
TLoadModuleRef（TText＆ name）；
ロード・モジュールは、指定のされた名前を持つTLoadModuleRefオブジェクトを、当該ローダに供給する。これは、当該ロード・モジュールが、指定された名前を持つ別のロード・モジュールに動的にリンクしなければならないことを、当該ローダに知らせるためである。
TLoadModuleRef（const TLoadModuleRef＆ other）；
コンストラクタをコピーする。
TLoadModuleRef＆ operator＝（const TLoadModuleRef＆ other）；
割当て演算子。
〜TLoadModuleRef（）：
デストラクタ
必須ロード・モジュールを識別する。
void GetName（TText＆ name）const＝0;
ローダはこのメソッドを使用して、必須ロード・モジュールの名前を見け出す。
TLoadModule＊GetLoadModule（）const;
TLoadModuleRefをローダに与え、しかも、ローダが必須ロード・モジュールの他動のクロージャを計算した後、このコールを使用して実ロード・モジュールを獲得する。
CompatibilityNumer GetRequiredRelease（）const;
このTLoadModuleRefを配分したロード・モジュールで、正しく実行するのに必要な最小の互換性番号を返す。
【図１】
0003550151.tif 000010
【図２】
0003550151.tif 000011
【図４】
0003550151.tif 000012
【図３】
0003550151.tif 000013
【図５】
0003550151.tif 000014
【図６】
0003550151.tif 000015
【図７】
0003550151.tif 000016
【図８】
0003550151.tif 000017
【図９】
0003550151.tif 000018