JP3550151B2 - ロード・リンキング装置および方法 - Google Patents
ロード・リンキング装置および方法 Download PDFInfo
- Publication number
- JP3550151B2 JP3550151B2 JP52202494A JP52202494A JP3550151B2 JP 3550151 B2 JP3550151 B2 JP 3550151B2 JP 52202494 A JP52202494 A JP 52202494A JP 52202494 A JP52202494 A JP 52202494A JP 3550151 B2 JP3550151 B2 JP 3550151B2
- Authority
- JP
- Japan
- Prior art keywords
- load
- load module
- item
- address
- modules
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Devices For Executing Special Programs (AREA)
Description
著作権保有表記
本特許出願には、著作権保護の対象となる内容を含む。情報提供を目的とする限り、その内容の複製を妨げるものではないが、その他の全ての権利、特に、その内容を商業上利用する権利は留保する。
技術分野
本発明は、オブジェクト指向アプリケーションに関し、特に、オブジェクト指向アプリケーションのための新規なロード・アーキテクチャに関する。
背景技術
ワークステション・ソフトウェアのディベロパの間では、柔軟性のあるソフトウェア環境を提供し、その上、ユーザインタフェースの一貫性を維持することがますます重要になっている。この種のオペレーティング環境を提供しようとする初期の頃の試みは、米国特許第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に示すステップｎに移行する。ステップｅでは、アプリケーションは再ロードされ、ステップｎでは、アプリケーションはクローズされる。
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時にコールされるものであり、次の条件を満足しているかどうかを判定する。
その他の種類のキャッシュは、好ましい実施態様で説明する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.クラス記述
次のＣ＋＋コードは、クラス記述の好ましい実施態様によるロジック（論理）を示す。
TLoadModule基本クラスをストリーム・アウトする。サブクラスは自身のスタッフ（stuff）をストリーム・アウトする前に、TLoadModule基本クラスをコールする必要がある。
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を配分したロード・モジュールで、正しく実行するのに必要な最小の互換性番号を返す。
本特許出願には、著作権保護の対象となる内容を含む。情報提供を目的とする限り、その内容の複製を妨げるものではないが、その他の全ての権利、特に、その内容を商業上利用する権利は留保する。
技術分野
本発明は、オブジェクト指向アプリケーションに関し、特に、オブジェクト指向アプリケーションのための新規なロード・アーキテクチャに関する。
背景技術
ワークステション・ソフトウェアのディベロパの間では、柔軟性のあるソフトウェア環境を提供し、その上、ユーザインタフェースの一貫性を維持することがますます重要になっている。この種のオペレーティング環境を提供しようとする初期の頃の試みは、米国特許第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に示すステップｎに移行する。ステップｅでは、アプリケーションは再ロードされ、ステップｎでは、アプリケーションはクローズされる。
アプリケーションは機能ブロック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時にコールされるものであり、次の条件を満足しているかどうかを判定する。
ａ）Ａ内の関数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.クラス記述
次のＣ＋＋コードは、クラス記述の好ましい実施態様によるロジック（論理）を示す。
空のコンストラクタはストリーミングに適したオブジェクト状態を初期化する。
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を配分したロード・モジュールで、正しく実行するのに必要な最小の互換性番号を返す。
Claims (24)
- ストレージと、
複数のロード・モジュールを前記ストレージの１次アドレス空間にロードする手段であって、このロードが完了した後、前記複数のロードモジュールをそれぞれ、本手段により決定した再配置アドレスに再配置するロード手段と、
前記ロード・モジュール内の参照を、対応するアドレスと置換して、当該参照を解決するため、前記各ロード・モジュールをパースするパース手段と
を有するコンピュータにおいて、複数のロードモジュールをロードしリンキングする装置において、
前記パース手段は、プログラムコード関数項目と、データ項目と、クラス項目と、項目名参照を受け取り受け取った項目名参照に基づき参照した項目のアドレスを返すオブジェクト・メソッドとを含むソフトウェアプログラムオブジェクトであるロード・モジュールを、それぞれパースして、各ロード・モジュールからプログラムコード関数項目についての項目名参照を獲得し、獲得した項目名参照に基づき当該ロード・モジュール以外の別のロード・モジュールにおける項目が参照されていると判断した場合に、該別のロード・モジュールにおけるオブジェクト・メソッドを当該項目名参照を用いてコールし、該オブジェクト・メソッドにより項目名参照に基づき参照された項目のアドレスを獲得し、獲得したアドレスを前記当該モジュールにおけるプログラムコード関数項目にパッチする
ことを特徴とする装置。 - 請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目を指し示すポインタを返すオブジェクト・メソッドを含むことを特徴とする装置。
- 請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目のアドレスを返すオブジェクト・メソッドを含むことを特徴とする装置。
- 請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目を指し示すポインタを返すオブジェクト・メソッドを含むことを特徴とする装置。
- 請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目のアドレスを返すオブジェクト・メソッドを含むことを特徴とする装置。
- 請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるクラス項目に対する名前参照を受け取り、該クラス項目のハンドル識別子を返すオブジェクト・メソッドを含むことを特徴とする装置。
- 請求項１において、前記ロード・モジュールは、
当該ロード・モジュールにより参照される項目である関数項目とデータ項目とクラス項目とを含む他のロード・モジュールの名前のリストと、
該名前のリストをスキャンし得られた他のロード・モジュールの名前を返す反復子と
を含むことを特徴とする装置。 - 請求項７において、前記ロード手段は、ロード・モジュールの反復子をコールし、得られた参照のセットを用いて、ロードされなければならない他のロード・モジュールを判定することを特徴とする装置。
- 請求項１において、前記ロード・モジュールは、それぞれ、該ロード・モジュールが前記ロード手段によりロードされているとき、該ロード・モジュールの必須のアドレス空間を指定するパラメータであって、前記アドレス空間のアドレス空間要件と、前記ロード・モジュールにより占有されるアドレスとを指定するパラメータを含むことを特徴とする装置。
- 請求項９において、前記ロード・モジュールは、それぞれ、ロード・モジュールにより必要とされるアドレス空間を指定するパラメータであって、該ロード・モジュールに含まれているアドレス空間パラメータを、前記ロード手段に返して、該ロード手段が前記ロード・モジュールをロードできるようにするオブジェクト・メソッドを含むことを特徴とする装置。
- 請求項１において、前記ストレージは、ロード・モジュールをリンキングしている間にコンピュートされたデータを、同一ロード・モジュールを再リンキングするときに再使用するためにセーブするためのキュッシュ領域を含むことを特徴とする装置。ほへ
- 請求項11において、前記ロード・モジュールは、それぞれ、セーブされたデータが有効であるかどうかを示す情報を含むことを特徴とする装置。
- ストレージと、
複数のロード・モジュールを前記ストレージの１次アドレス空間にロードする手段であって、このロードが完了した後、前記複数のロードモジュールをそれぞれ、本手段により決定した再配置アドレスに再配置するロード手段と、
前記ロード・モジュール内の参照を、対応するアドレスと置換して、当該参照を解決するため、前記各ロード・モジュールをパースするパース手段と
を有するコンピュータにおいて、前記複数のロード・モジュールをロードしリンキングする方法において、
プログラムコード関数項目と、データ項目と、クラス項目と、項目名参照を受け取り受け取った項目名参照に基づき参照した項目のアドレスを返すオブジェクト・メソッドとを含むソフトウェアプログラムオブジェクトであるロード・モジュールを前記パース手段によりそれぞれパースさせるステップと、
各ロード・モジュールからプログラムコード関数項目についての項目名参照を前記パース手段により獲得させるステップと、
獲得した項目名参照に基づき当該ロード・モジュール以外の別のロード・モジュールにおける項目が参照されていると判断した場合に、前記パース手段により、該別のロード・モジュールにおけるオブジェクト・メソッドを当該項目名参照を用いてコールさせ、該オブジェクト・メソッドにより項目名参照に基づき参照された項目のアドレスを獲得させ、獲得したアドレスを前記当該モジュールにおけるプログラムコード関数項目にパッチさせるステップと
備えたことを特徴とする方法。 - 請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目を指し示すポインタを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
- 請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるプログラムコード関数項目に対する名前参照を受け取り、該プログラムコード関数項目のアドレスを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
- 請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目を指し示すポインタを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
- 請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるデータ項目に対する名前参照を受け取り、該データ項目のアドレスを返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
- 請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれるクラス項目に対する名前参照を受け取り、該クラス項目のハンドル識別子を返すオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
- 請求項13において、前記ロード・モジュールは、
該ロード・モジュールにより参照される項目である関数項目とデータ項目とクラス項目とを含む他のロード・モジュールへの参照のリストと、
該参照のリストをスキャンし得られた他のモジュールの名前を返す反復子と
を含むようにコンストラクトされることを特徴とする方法。 - 請求項19において、ロード・モジュールの反復子を前記ロード手段によりコールさせ、得られた参照のセットを用いて、ロードされなければならない他のロード・モジュールを判定するステップをさらに備えたことを特徴とする方法。
- 請求項13において、前記ロード・モジュールは、それぞれ、該ロード・モジュールが前記ロード手段によりロードされているとき、該ロード・モジュールにより必要とされるアドレス空間を指定するパラメータであって、該アドレス空間におけるアドレス空間要件と、前記ロード・モジュールにより占有されるアドレスとを指定するパラメータによりコンストラクトされることを特徴とする方法。
- 請求項21において、前記ロード・モジュールは、それぞれ、該ロード・モジュールに含まれているアドレス空間パラメータを、前記ロード手段に返して、該ロード手段が前記ロード・モジュールをロードできるようにするオブジェクト・メソッドによりコンストラクトされることを特徴とする方法。
- 請求項13において、ロード・モジュールをリンキングしている間にコンピュートされたデータを、同一ロード・モジュールを再リンキングするときに再使用するためにセーブするためのキュッシュ領域を前記ストレージに割り当てることを特徴とする方法。
- 請求項23において、前記ロード・モジュールは、それぞれ、セーブされたデータが有効であるかどうかを示す情報を含むようにコンストラクトされることを特徴する方法。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/037,054 US5369766A (en) | 1993-03-25 | 1993-03-25 | Object-oriented loader system with support for different load formats |
| US08/037,054 | 1993-03-25 | ||
| PCT/US1994/000017 WO1994023363A2 (en) | 1993-03-25 | 1994-01-03 | Loader system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08508593A JPH08508593A (ja) | 1996-09-10 |
| JP3550151B2 true JP3550151B2 (ja) | 2004-08-04 |
Family
ID=21892194
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP52202494A Expired - Lifetime JP3550151B2 (ja) | 1993-03-25 | 1994-01-03 | ロード・リンキング装置および方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US5369766A (ja) |
| EP (1) | EP0664903B1 (ja) |
| JP (1) | JP3550151B2 (ja) |
| AU (1) | AU6227594A (ja) |
| CA (1) | CA2145674A1 (ja) |
| DE (1) | DE69407560D1 (ja) |
| WO (1) | WO1994023363A2 (ja) |
Families Citing this family (137)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0578207B1 (en) * | 1992-07-06 | 1999-12-01 | Microsoft Corporation | Method for naming and binding objects |
| US5519862A (en) * | 1993-02-26 | 1996-05-21 | Taligent, Inc. | Concurrent processing apparatus with incremental command objects |
| US5459865A (en) * | 1993-04-05 | 1995-10-17 | Taligent Inc. | Runtime loader |
| US6684261B1 (en) * | 1993-07-19 | 2004-01-27 | Object Technology Licensing Corporation | Object-oriented operating system |
| US5379432A (en) * | 1993-07-19 | 1995-01-03 | Taligent, Inc. | Object-oriented interface for a procedural operating system |
| US5799181A (en) * | 1995-04-07 | 1998-08-25 | Sofmap Future Design, Inc. | Bossless architecture and digital cell technology for computer programs |
| CN1181141A (zh) | 1995-04-07 | 1998-05-06 | 软体未来设计股份有限公司 | 数据处理系统和方法,以及计算机程序体系结构 |
| US5790856A (en) * | 1995-05-08 | 1998-08-04 | Apple Computer, Inc. | Methods, apparatus, and data structures for data driven computer patches and static analysis of same |
| US6260075B1 (en) | 1995-06-19 | 2001-07-10 | International Business Machines Corporation | System and method for providing shared global offset table for common shared library in a computer system |
| US6449660B1 (en) | 1995-07-31 | 2002-09-10 | International Business Machines Corporation | Object-oriented I/O device interface framework mechanism |
| US5812848A (en) * | 1995-08-23 | 1998-09-22 | Symantec Corporation | Subclassing system for computer that operates with portable-executable (PE) modules |
| US5809302A (en) * | 1995-08-31 | 1998-09-15 | International Business Machines Corp. | System and method for enabling pointers to be passed from computer programs written using computer programming languages that do not support pointers |
| US6226691B1 (en) * | 1995-10-02 | 2001-05-01 | International Business Machines Corporation | System, method, and article of manufacture for adding object services to a binary class in an object oriented server |
| US6684259B1 (en) | 1995-10-11 | 2004-01-27 | Citrix Systems, Inc. | Method for providing user global object name space in a multi-user operating system |
| US5864862A (en) * | 1996-09-30 | 1999-01-26 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for creating reusable components in an object-oriented programming environment |
| US5872973A (en) * | 1995-10-26 | 1999-02-16 | Viewsoft, Inc. | Method for managing dynamic relations between objects in dynamic object-oriented languages |
| US6532487B1 (en) | 1995-12-04 | 2003-03-11 | International Business Machines Corporation | Method and system for managing semaphores in an object-oriented multi-tasking computer system |
| US6298476B1 (en) | 1995-12-04 | 2001-10-02 | International Business Machines Corporation | Object oriented software build framework mechanism |
| US5797014A (en) * | 1995-12-14 | 1998-08-18 | International Business Machines Corporation | Method for reducing processor cycles used for global offset table address computation in a position independent shared library |
| US5774722A (en) * | 1995-12-14 | 1998-06-30 | International Business Machines Corporation | Method for efficient external reference resolution in dynamically linked shared code libraries in single address space operating systems |
| US5768505A (en) * | 1995-12-19 | 1998-06-16 | International Business Machines Corporation | Object oriented mail server framework mechanism |
| US6526565B1 (en) * | 1995-12-21 | 2003-02-25 | International Business Machines Corporation | Packaging algorithm for providing object oriented applications having reduced footprints |
| US6144967A (en) * | 1996-01-25 | 2000-11-07 | International Business Machines Corporation | Object oriented processing log analysis tool framework mechanism |
| US5838972A (en) * | 1996-02-09 | 1998-11-17 | Sun Microsystems, Inc. | Method and apparatus for dynamically loading an input run-time module and an output run-time module |
| US6434739B1 (en) | 1996-04-22 | 2002-08-13 | International Business Machines Corporation | Object oriented framework mechanism for multi-target source code processing |
| US6081798A (en) * | 1996-04-24 | 2000-06-27 | International Business Machines Corp. | Object oriented case-based reasoning framework mechanism |
| US5778378A (en) | 1996-04-30 | 1998-07-07 | International Business Machines Corporation | Object oriented information retrieval framework mechanism |
| US5815718A (en) * | 1996-05-30 | 1998-09-29 | Sun Microsystems, Inc. | Method and system for loading classes in read-only memory |
| US6424991B1 (en) | 1996-07-01 | 2002-07-23 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server communication framework |
| US6304893B1 (en) | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US5848246A (en) * | 1996-07-01 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system |
| US5999972A (en) * | 1996-07-01 | 1999-12-07 | Sun Microsystems, Inc. | System, method and article of manufacture for a distributed computer system framework |
| US5987245A (en) * | 1996-07-01 | 1999-11-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework |
| US6434598B1 (en) | 1996-07-01 | 2002-08-13 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system |
| US6266709B1 (en) | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
| US6272555B1 (en) | 1996-07-01 | 2001-08-07 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system |
| US6038590A (en) * | 1996-07-01 | 2000-03-14 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system |
| US5915252A (en) * | 1996-09-30 | 1999-06-22 | International Business Machines Corporation | Object oriented framework mechanism for data transfer between a data source and a data target |
| US6104874A (en) * | 1996-10-15 | 2000-08-15 | International Business Machines Corporation | Object oriented framework mechanism for order processing including pre-defined extensible classes for defining an order processing environment |
| US6003095A (en) * | 1996-10-31 | 1999-12-14 | International Business Machines Corporation | Apparatus and method for demand loading a dynamic link library |
| US5937189A (en) * | 1996-11-12 | 1999-08-10 | International Business Machines Corporation | Object oriented framework mechanism for determining configuration relations |
| US6401109B1 (en) | 1996-11-18 | 2002-06-04 | International Business Machines Corp. | Virtual socket for JAVA interprocess communication |
| US6460058B2 (en) | 1996-12-06 | 2002-10-01 | Microsoft Corporation | Object-oriented framework for hyperlink navigation |
| US6401099B1 (en) | 1996-12-06 | 2002-06-04 | Microsoft Corporation | Asynchronous binding of named objects |
| US5970498A (en) * | 1996-12-06 | 1999-10-19 | International Business Machines Corporation | Object oriented framework mechanism for metering objects |
| US5946486A (en) * | 1996-12-10 | 1999-08-31 | International Business Machines Corporation | Apparatus and method for tracing entries to or exits from a dynamic link library |
| US6769126B1 (en) | 1996-12-10 | 2004-07-27 | International Business Machines Corporation | Apparatus and method for demand load analysis |
| US6052778A (en) * | 1997-01-13 | 2000-04-18 | International Business Machines Corporation | Embedded system having dynamically linked dynamic loader and method for linking dynamic loader shared libraries and application programs |
| US5961602A (en) * | 1997-02-10 | 1999-10-05 | International Business Machines Corporation | Method for optimizing off-peak caching of web data |
| US5878263A (en) * | 1997-03-05 | 1999-03-02 | International Business Machines Corporation | Internal chaining technique for fixup records |
| US5936860A (en) * | 1997-03-28 | 1999-08-10 | International Business Machines Corporation | Object oriented technology framework for warehouse control |
| US6041312A (en) * | 1997-03-28 | 2000-03-21 | International Business Machines Corporation | Object oriented technology framework for accounts receivable and accounts payable |
| US5987423A (en) * | 1997-03-28 | 1999-11-16 | International Business Machines Corporation | Object oriented technology framework for order processing |
| US6014637A (en) * | 1997-04-30 | 2000-01-11 | International Business Machines Corporation | Object oriented framework mechanism for fulfillment requirements management |
| CA2204971A1 (en) * | 1997-05-09 | 1998-11-09 | Michael Cheng | Uniform access to and interchange between objects employing a plurality of access methods |
| US6335972B1 (en) | 1997-05-23 | 2002-01-01 | International Business Machines Corporation | Framework-based cryptographic key recovery system |
| US6473893B1 (en) * | 1997-05-30 | 2002-10-29 | International Business Machines Corporation | Information objects system, method, and computer program organization |
| US5920725A (en) * | 1997-07-02 | 1999-07-06 | Adaptivity Inc. | Run-time object-synthesis and transparent client/server updating of distributed objects using a meta server of all object descriptors |
| US5893106A (en) * | 1997-07-11 | 1999-04-06 | International Business Machines Corporation | Object oriented server process framework with interdependent-object creation |
| US6513152B1 (en) | 1997-07-23 | 2003-01-28 | International Business Machines Corporation | Object oriented framework mechanism for customization of object oriented frameworks |
| US6378002B1 (en) | 1997-08-05 | 2002-04-23 | International Business Machines Corporation, | Object oriented server process framework with implicit data handling registry for remote method invocations |
| US6052670A (en) * | 1997-08-29 | 2000-04-18 | International Business Machines Corporation | Object oriented framework mechanism for an electronic catalog |
| US6016495A (en) * | 1997-09-19 | 2000-01-18 | International Business Machines Corporation | Object-oriented framework mechanism for providing persistent storage |
| US6421827B1 (en) | 1997-12-17 | 2002-07-16 | International Business Machines Corporation | System and method for detecting and reordering loading patterns |
| US5911073A (en) * | 1997-12-23 | 1999-06-08 | Hewlett-Packard Company | Method and apparatus for dynamic process monitoring through an ancillary control code system |
| US20010044901A1 (en) * | 1998-03-24 | 2001-11-22 | Symantec Corporation | Bubble-protected system for automatic decryption of file data on a per-use basis and automatic re-encryption |
| US6148437A (en) * | 1998-05-04 | 2000-11-14 | Hewlett-Packard Company | System and method for jump-evaluated trace designation |
| US6164841A (en) * | 1998-05-04 | 2000-12-26 | Hewlett-Packard Company | Method, apparatus, and product for dynamic software code translation system |
| US6189141B1 (en) | 1998-05-04 | 2001-02-13 | Hewlett-Packard Company | Control path evaluating trace designator with dynamically adjustable thresholds for activation of tracing for high (hot) activity and low (cold) activity of flow control |
| US6430569B1 (en) | 1998-08-14 | 2002-08-06 | Sun Microsystems, Inc. | Methods and apparatus for type safe, lazy, user-defined class loading |
| JP3837244B2 (ja) | 1998-10-23 | 2006-10-25 | 松下電器産業株式会社 | プログラムリンク装置及び方法 |
| US6628305B1 (en) | 1998-11-09 | 2003-09-30 | International Business Machines Corporation | Architecture and definition of an extensible, object-oriented graphical user interface framework for managing and administering heterogenous digital library datastores |
| CA2255042C (en) * | 1998-11-30 | 2004-04-13 | Leonard W. Theivendra | Class loader |
| US6618769B1 (en) * | 1999-05-27 | 2003-09-09 | Sun Microsystems, Inc. | Module-by-module verification |
| US6601114B1 (en) * | 1999-05-27 | 2003-07-29 | Sun Microsystems, Inc. | Fully lazy linking with module-by-module verification |
| US6356933B2 (en) | 1999-09-07 | 2002-03-12 | Citrix Systems, Inc. | Methods and apparatus for efficiently transmitting interactive application data between a client and a server using markup language |
| US6829761B1 (en) * | 1999-10-21 | 2004-12-07 | Oracle International Corporation | Method and apparatus for managing shared memory in a run-time environment |
| US6874143B1 (en) | 2000-06-21 | 2005-03-29 | Microsoft Corporation | Architectures for and methods of providing network-based software extensions |
| US7624356B1 (en) | 2000-06-21 | 2009-11-24 | Microsoft Corporation | Task-sensitive methods and systems for displaying command sets |
| US7346848B1 (en) | 2000-06-21 | 2008-03-18 | Microsoft Corporation | Single window navigation methods and systems |
| AU2001264895A1 (en) | 2000-06-21 | 2002-01-02 | Microsoft Corporation | System and method for integrating spreadsheets and word processing tables |
| US7117435B1 (en) | 2000-06-21 | 2006-10-03 | Microsoft Corporation | Spreadsheet fields in text |
| US7191394B1 (en) | 2000-06-21 | 2007-03-13 | Microsoft Corporation | Authoring arbitrary XML documents using DHTML and XSLT |
| US6883168B1 (en) | 2000-06-21 | 2005-04-19 | Microsoft Corporation | Methods, systems, architectures and data structures for delivering software via a network |
| US6948135B1 (en) | 2000-06-21 | 2005-09-20 | Microsoft Corporation | Method and systems of providing information to computer users |
| US7000230B1 (en) | 2000-06-21 | 2006-02-14 | Microsoft Corporation | Network-based software extensions |
| US7155667B1 (en) | 2000-06-21 | 2006-12-26 | Microsoft Corporation | User interface for integrated spreadsheets and word processing tables |
| US7346842B1 (en) | 2000-11-02 | 2008-03-18 | Citrix Systems, Inc. | Methods and apparatus for incorporating a partial page on a client |
| US20020105548A1 (en) | 2000-12-12 | 2002-08-08 | Richard Hayton | Methods and apparatus for creating a user interface using property paths |
| US7322040B1 (en) * | 2001-03-27 | 2008-01-22 | Microsoft Corporation | Authentication architecture |
| US7243346B1 (en) | 2001-05-21 | 2007-07-10 | Microsoft Corporation | Customized library management system |
| US7389515B1 (en) * | 2001-05-21 | 2008-06-17 | Microsoft Corporation | Application deflation system and method |
| US7246350B2 (en) * | 2002-01-07 | 2007-07-17 | Intel Corporation | Dynamic composition and maintenance of applications |
| US7421418B2 (en) * | 2003-02-19 | 2008-09-02 | Nahava Inc. | Method and apparatus for fundamental operations on token sequences: computing similarity, extracting term values, and searching efficiently |
| US7370066B1 (en) | 2003-03-24 | 2008-05-06 | Microsoft Corporation | System and method for offline editing of data files |
| US7415672B1 (en) | 2003-03-24 | 2008-08-19 | Microsoft Corporation | System and method for designing electronic forms |
| US7275216B2 (en) | 2003-03-24 | 2007-09-25 | Microsoft Corporation | System and method for designing electronic forms and hierarchical schemas |
| US7296017B2 (en) | 2003-03-28 | 2007-11-13 | Microsoft Corporation | Validation of XML data files |
| US7913159B2 (en) | 2003-03-28 | 2011-03-22 | Microsoft Corporation | System and method for real-time validation of structured data files |
| US7516145B2 (en) | 2003-03-31 | 2009-04-07 | Microsoft Corporation | System and method for incrementally transforming and rendering hierarchical data files |
| US7168035B1 (en) | 2003-06-11 | 2007-01-23 | Microsoft Corporation | Building a view on markup language data through a set of components |
| US7451392B1 (en) | 2003-06-30 | 2008-11-11 | Microsoft Corporation | Rendering an HTML electronic form by applying XSLT to XML using a solution |
| US7197515B2 (en) | 2003-06-30 | 2007-03-27 | Microsoft Corporation | Declarative solution definition |
| US7406660B1 (en) | 2003-08-01 | 2008-07-29 | Microsoft Corporation | Mapping between structured data and a visual surface |
| US7581177B1 (en) | 2003-08-01 | 2009-08-25 | Microsoft Corporation | Conversion of structured documents |
| US7334187B1 (en) | 2003-08-06 | 2008-02-19 | Microsoft Corporation | Electronic form aggregation |
| CN101119779A (zh) * | 2003-10-01 | 2008-02-06 | 现金系统公司 | 用于整合玩家跟踪和现金存取的系统和方法 |
| US7171649B1 (en) * | 2004-01-12 | 2007-01-30 | Sun Microsystems, Inc. | Optimizing safe downcasting in an object-oriented programming language |
| US8819072B1 (en) | 2004-02-02 | 2014-08-26 | Microsoft Corporation | Promoting data from structured data files |
| US7430711B2 (en) | 2004-02-17 | 2008-09-30 | Microsoft Corporation | Systems and methods for editing XML documents |
| US7318063B2 (en) | 2004-02-19 | 2008-01-08 | Microsoft Corporation | Managing XML documents containing hierarchical database information |
| US7437741B2 (en) | 2004-03-08 | 2008-10-14 | International Business Machines Corporation | Method, system, and program for invoking methods between computer languages |
| US7496837B1 (en) | 2004-04-29 | 2009-02-24 | Microsoft Corporation | Structural editing with schema awareness |
| US7568101B1 (en) | 2004-05-13 | 2009-07-28 | Microsoft Corporation | Digital signatures with an embedded view |
| US7281018B1 (en) | 2004-05-26 | 2007-10-09 | Microsoft Corporation | Form template data source change |
| US7774620B1 (en) | 2004-05-27 | 2010-08-10 | Microsoft Corporation | Executing applications at appropriate trust levels |
| US7493609B2 (en) * | 2004-08-30 | 2009-02-17 | International Business Machines Corporation | Method and apparatus for automatic second-order predictive commoning |
| US7692636B2 (en) | 2004-09-30 | 2010-04-06 | Microsoft Corporation | Systems and methods for handwriting to a screen |
| US7516399B2 (en) | 2004-09-30 | 2009-04-07 | Microsoft Corporation | Structured-document path-language expression methods and systems |
| US8487879B2 (en) | 2004-10-29 | 2013-07-16 | Microsoft Corporation | Systems and methods for interacting with a computer through handwriting to a screen |
| US7712022B2 (en) | 2004-11-15 | 2010-05-04 | Microsoft Corporation | Mutually exclusive options in electronic forms |
| US7584417B2 (en) | 2004-11-15 | 2009-09-01 | Microsoft Corporation | Role-dependent action for an electronic form |
| US7509353B2 (en) | 2004-11-16 | 2009-03-24 | Microsoft Corporation | Methods and systems for exchanging and rendering forms |
| US7721190B2 (en) | 2004-11-16 | 2010-05-18 | Microsoft Corporation | Methods and systems for server side form processing |
| US7904801B2 (en) | 2004-12-15 | 2011-03-08 | Microsoft Corporation | Recursive sections in electronic forms |
| US7437376B2 (en) | 2004-12-20 | 2008-10-14 | Microsoft Corporation | Scalable object model |
| US7937651B2 (en) | 2005-01-14 | 2011-05-03 | Microsoft Corporation | Structural editing operations for network forms |
| US7725834B2 (en) | 2005-03-04 | 2010-05-25 | Microsoft Corporation | Designer-created aspect for an electronic form template |
| US8010515B2 (en) | 2005-04-15 | 2011-08-30 | Microsoft Corporation | Query to an electronic form |
| US7543228B2 (en) | 2005-06-27 | 2009-06-02 | Microsoft Corporation | Template for rendering an electronic form |
| US8200975B2 (en) | 2005-06-29 | 2012-06-12 | Microsoft Corporation | Digital signatures for network forms |
| US7613996B2 (en) | 2005-08-15 | 2009-11-03 | Microsoft Corporation | Enabling selection of an inferred schema part |
| US8001459B2 (en) | 2005-12-05 | 2011-08-16 | Microsoft Corporation | Enabling electronic documents for limited-capability computing devices |
| US7779343B2 (en) | 2006-01-30 | 2010-08-17 | Microsoft Corporation | Opening network-enabled electronic documents |
| US10410117B2 (en) | 2008-09-21 | 2019-09-10 | Brainchip, Inc. | Method and a system for creating dynamic neural function libraries |
| US9747197B2 (en) * | 2014-05-20 | 2017-08-29 | Honeywell International Inc. | Methods and apparatus to use an access triggered computer architecture |
| US10353681B2 (en) | 2014-05-20 | 2019-07-16 | Honeywell International Inc. | Systems and methods for using error correction and pipelining techniques for an access triggered computer architecture |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63626A (ja) * | 1986-06-19 | 1988-01-05 | Casio Comput Co Ltd | プログラム管理装置 |
| US4821220A (en) * | 1986-07-25 | 1989-04-11 | Tektronix, Inc. | System for animating program operation and displaying time-based relationships |
| US4885717A (en) * | 1986-09-25 | 1989-12-05 | Tektronix, Inc. | System for graphically representing operation of object-oriented programs |
| US5261080A (en) * | 1987-08-21 | 1993-11-09 | Wang Laboratories, Inc. | Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formats |
| US4891630A (en) * | 1988-04-22 | 1990-01-02 | Friedman Mark B | Computer vision system with improved object orientation technique |
| US4953080A (en) * | 1988-04-25 | 1990-08-28 | Hewlett-Packard Company | Object management facility for maintaining data in a computer system |
| EP0347162A3 (en) * | 1988-06-14 | 1990-09-12 | Tektronix, Inc. | Apparatus and methods for controlling data flow processes by generated instruction sequences |
| US5041992A (en) * | 1988-10-24 | 1991-08-20 | University Of Pittsburgh | Interactive method of developing software interfaces |
| US5133075A (en) * | 1988-12-19 | 1992-07-21 | Hewlett-Packard Company | Method of monitoring changes in attribute values of object in an object-oriented database |
| US5050090A (en) * | 1989-03-30 | 1991-09-17 | R. J. Reynolds Tobacco Company | Object placement method and apparatus |
| US5060276A (en) * | 1989-05-31 | 1991-10-22 | At&T Bell Laboratories | Technique for object orientation detection using a feed-forward neural network |
| US5125091A (en) * | 1989-06-08 | 1992-06-23 | Hazox Corporation | Object oriented control of real-time processing |
| US5257369A (en) * | 1990-10-22 | 1993-10-26 | Skeen Marion D | Apparatus and method for providing decoupling of data exchange details for providing high performance communication between software processes |
| US5247678A (en) * | 1989-10-12 | 1993-09-21 | Texas Instruments Incorporated | Load time linker for software used with a multiprocessor system |
| US5181162A (en) * | 1989-12-06 | 1993-01-19 | Eastman Kodak Company | Document management and production system |
| US5093914A (en) * | 1989-12-15 | 1992-03-03 | At&T Bell Laboratories | Method of controlling the execution of object-oriented programs |
| US5075848A (en) * | 1989-12-22 | 1991-12-24 | Intel Corporation | Object lifetime control in an object-oriented memory protection mechanism |
| GB2242293A (en) * | 1990-01-05 | 1991-09-25 | Apple Computer | Apparatus and method for dynamic linking of computer software components |
| US5151987A (en) * | 1990-10-23 | 1992-09-29 | International Business Machines Corporation | Recovery objects in an object oriented computing environment |
| US5119475A (en) * | 1991-03-13 | 1992-06-02 | Schlumberger Technology Corporation | Object-oriented framework for menu definition |
| US5303375A (en) * | 1991-04-26 | 1994-04-12 | Hewlett-Packard Company | System and method for facilitating selection of running functional process in object-oriented environments |
-
1993
- 1993-03-25 US US08/037,054 patent/US5369766A/en not_active Expired - Lifetime
-
1994
- 1994-01-03 CA CA002145674A patent/CA2145674A1/en not_active Abandoned
- 1994-01-03 AU AU62275/94A patent/AU6227594A/en not_active Abandoned
- 1994-01-03 JP JP52202494A patent/JP3550151B2/ja not_active Expired - Lifetime
- 1994-01-03 WO PCT/US1994/000017 patent/WO1994023363A2/en active IP Right Grant
- 1994-01-03 EP EP94909429A patent/EP0664903B1/en not_active Expired - Lifetime
- 1994-01-03 DE DE69407560T patent/DE69407560D1/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| WO1994023363A3 (en) | 1995-01-12 |
| AU6227594A (en) | 1994-10-24 |
| EP0664903A1 (en) | 1995-08-02 |
| JPH08508593A (ja) | 1996-09-10 |
| US5369766A (en) | 1994-11-29 |
| WO1994023363A2 (en) | 1994-10-13 |
| EP0664903B1 (en) | 1997-12-29 |
| CA2145674A1 (en) | 1994-10-13 |
| DE69407560D1 (de) | 1998-02-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3550151B2 (ja) | ロード・リンキング装置および方法 | |
| US7225438B2 (en) | Lazy compilation of template-generated classes in dynamic compilation execution environments | |
| US5418964A (en) | System and method for parent class shadowing in a statically linked object hierarchy | |
| US6330709B1 (en) | Virtual machine implementation for shared persistent objects | |
| US5421016A (en) | System and method for dynamically invoking object methods from an application designed for static method invocation | |
| US5361350A (en) | Object oriented method management system and software for managing class method names in a computer system | |
| US5339438A (en) | Version independence for object oriented programs | |
| EP0546683B1 (en) | Language neutral objects | |
| US5493680A (en) | Method for creating an object subclass with selective inheritance | |
| US8434099B2 (en) | Efficient linking and loading for late binding and platform retargeting | |
| US7409694B2 (en) | Highly componentized system architecture with loadable virtual memory manager | |
| US7565665B2 (en) | Efficient linking and loading for late binding and platform retargeting | |
| US5692195A (en) | Parent class shadowing | |
| EP0706684B1 (en) | System for object oriented dynamic linking based upon a catalog of registered function set or class identifiers | |
| US7143421B2 (en) | Highly componentized system architecture with a demand-loading namespace and programming model | |
| US6728963B1 (en) | Highly componentized system architecture with a loadable interprocess communication manager | |
| US20070204259A1 (en) | Protection Domains for a Computer Operating System | |
| AU712005B2 (en) | System and method for runtime optimization of private variable function calls in a secure interpreter | |
| US20090133042A1 (en) | Efficient linking and loading for late binding and platform retargeting | |
| US6378003B1 (en) | Method and system for deriving metaclasses in an object oriented system | |
| US8464226B2 (en) | System and method for interoperating with foreign objects from a host computing environment | |
| US7703108B2 (en) | Native code isolation in a multi-tasking Java virtual machine | |
| Kempf et al. | Cross-address space dynamic linking | |
| Pizka et al. | Evolving Software Tools for New Distributed Computing Environments. | |
| McGachey et al. | Pervasive load-time transformation for transparently distributed Java |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040423 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090430 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090430 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100430 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110430 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110430 Year of fee payment: 7 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110430 Year of fee payment: 7 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120430 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120430 Year of fee payment: 8 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D04 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120430 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130430 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130430 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140430 Year of fee payment: 10 |
|
| EXPY | Cancellation because of completion of term |