JPH01263734A - マルチ・タスク環境における動的リンク識別子供給方法 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は総括的にいえば情報処理システムに関するもの
であり、さらに具体的にいえば、情報処理システム用の
オペレーティング・システム及びサブシステム、ならび
に多重ロード可能／実行可能プログラム単位として実現
されるアプリケ−シロンに関するものである。

Ｂ、従来技術 パーソナル−コンピューターシステムの発展の初期には
、そのためのオペレーティング・システムは、たとえば
、周知のスプレッドシート・プログラムの場合における
ように、通常、ただ１つの一般的な機能またはタスクを
実行することを目的とした単一アプリケーションのみを
、システムで実行可能であるといったものであった。し
かし、そのようなシステムに固有な限界から、複数のア
プリケーション・プログラムを同時に実行する機能を備
えることが非常に望ましいことがまもなく明らかになっ
た。この機能は当技術では、「マルチ・タスク」と呼ば
れるものであり、たとえば、ワード・プロセッシング・
プログラム、グラフィック・パッケージなどとともにス
プレッドシート・プログラムが実行される場合を指す。

したがって、所望されるこの機能をサポートする種々の
環境が考案されたが、これらの環境によってアプリケ−
シロンを、多重ロード可能プログラム単位として実行し
、共用ライブラリの出現をうながすことが可能となった
。これらの開発の中で注目スヘきものは、ＩＢＭ社（７
）ＩＢＭ　　Ｏ８／２（ＩＢＭ社の商標）及びＡＩＸ（
ＩＢＭ社の商標）オペレーティング・システム、及びＡ
Ｔ＆Ｔ社のＵＮＩＸＣＡＴ＆Ｔ社の商標）システムを含
む強力なオペレーティング・システム及びサブシステム
の考案であった。

上記マルチ・タスク動作環境のあるものの望ましい機能
の１つは、アプリケーション・プログラムがオペレーテ
ィング・システムを破壊するか、さもない場合はオペレ
ーティング・システムに損害を与えることを、オペレー
ティング・システムが防止することである。アプリケ−
シロンまたはサブシステムが、そのアプリケ−シロンに
割り振られていないメモリにアクセスしようとする場合
は、アプリケーションは終了され、その終了が報告され
るようになったシステムが考案された。

そのようなシステムは通常、保護動作モードを提供する
、新たに開発されたマイクロプロセッサ・ファミリを利
用し、この保護動作モードでは、物理的メモリ・アドレ
スはセレクタ及びオフセットから間接的に計算され、オ
フセットはそれにより上記のメモリ分離を行ない、オペ
レーティング・システムがオペレーティング・システム
に対するアプリケーションによる損傷を防ぐことを可能
にする。そのため、アプリケ−シロンの実行可能コード
に含まれていないセグメントに対する外部参照をアプリ
ケ−シロン・プログラムが「動的連係」を介して行なう
ことを可能にするオペレーティング・システムが考案さ
れた。それらのセグメントに対する参照は、ローダ、す
なわち、ディスクからメモリにプログラムをロードする
責任を負うオペレーティング・システムのカーネルの部
分により、以下で動的リンク・ライブラリ（ＤＬＬ）と
呼ぶ特別のプログラム・ライブラリで解決された。

しかし、これらの新しいシステム及びサブシステムは深
刻な問題を伴っていた。上記システムは、従来技術で経
験されたように、アプリケーションがシステムを損傷す
るのを回避することはできたが、それにもかかわらず、
終了を引き起こしたエラーの原因に関するさらに詳細な
指示（たとえば、特定のサブシステムにおける指定され
たロケーション）をプログラマ及びエンド・ユーザが受
は取ることが依然として望まれていた。このことは、デ
バッグのため（プログラマの場合）と、問題をさらに詳
細にそのようなプログラマに報告することが可能である
ようにするため（エンド・ユーザの場合）である。

マルチ・タスク・システムによりもたらされた決定的な
利点にもかかわらず、動的リンク・ライブラリを使って
実現されるプログラムに対するさらに詳細なエラー表示
を提供することに関して、少なくとも２つの別個の問題
が本明細書で考察するオペレーティング・システム環境
と関連づけられた。最初に、動的リンク・ライブラリ内
で実現された特定の機能が与えられたとすると、プログ
ラマは、アプリケーションが連係されたとき生成される
マツプを調べて、問題の機能の動的リンク・ライブラリ
内でのオフセットを決定することができた。しかし、プ
ログラマはまた、デバッグのため、ライブラリのコード
・セレクタを決定することができなければならない。し
かし、あいにく、セレクタの割当ては通常は機械に依存
し、アプリケーションの連続的実行に際して変わる。さ
らに、動的リンク・ライブラリ内での実行中にアプリケ
ーション・プログラムがシステムにより終了された場合
は、たとえ、障害状態のプログラムと関連した関連コー
ド・セレクタ及びオフセットがそのような終了時にオペ
レーティング・システムにより表示されたとしても、エ
ンド・ユーザが、問題を開発機構のプログラマに報告し
て、終了を引き起こしている特定の動的リンク・ライブ
ラリが正確に識別できるようにすることが必要であった
。

デバッグの問題に対する１つの解決策はソース・レベル
・デバッガである。この−例は、ＩＢＭ／マイクロソフ
トＣ用にｒｃｏｄｅｖｉｅｖＪという商品名でマイクロ
ソフト（Ｍｉｃｒｏｓｏｆｔ　）社により販売されてい
る製品である。そのようなツールは一般には、プログラ
マが簡略記憶法でコード及びデータを参照するのを可能
にするので、セレクタの値を知ることを不必要にする。

しかし、エンド・ユーザは一般にはソース・コードまた
はデバッガにアクセスしないので、これらのツールは、
問題を報告するエンド・ユーザにとっての問題を解決し
ない。さらに、そのようなソース・レベルのデバッグ・
ツールは版売者の言語に依存しており、使用されている
多数のソース言語のすべてにただちに使用可能なわけで
はない。また、ある特定の問題にとっては、アセンブラ
・レベルのデバッガ（セレクタ値に関する知識を必要と
する）の方が望ましいこともある（必要プログラム資源
がソース・レベルのデバッガの容量を超えるとき、また
はタイミングに依存する問題の場合等）。

さらに詳細なエラー表示を提供するさらにもう１つの方
法は（特定の動的リンク・ライブラリ・ファイルのため
の特定のセレクタを識別することにより、または、その
代りに、指定されたセレクタからファイルを識別するこ
とにより）、オペレーティング・システムの内部データ
域にアクセスする装置ドライバを書き、次に、ドライバ
から情報を得るためのプログラムを書くことにより実行
することができる。当技術では周知のそのような方法の
１つの問題点は、ドライバを組み立てることは比較的困
難かつ高価であり、退屈な設計、コーディング、及び特
に困難なものとなる可能性があるデバッグを必要とする
。しかし、その上、−層深刻なことには、そのようなド
ライバは、たとえ効果的に設計されたとしても、同じ保
護レベルでオペレーティング・システムと共に動作する
であろう。したがって、ドライバはすべてのシステム・
データ・セグメントにアクセスし、その結果、考察中の
オペレーティング・システム環境の上記利点、すなわち
、メモリ分離はそれによって無効にされる。

Ｃ０発明が解決しようとする問題点 したがって、アプリケーションが多重ロード可能プログ
ラム単位として実行されることを可能にする環境で特定
のプログラム単位の識別を可能にし、アプリケーション
・プログラマにより容易かつ簡単に実現されることが可
能な解決策が求められ、強く望まれていた。

Ｄ０問題点を解決するための手段 本発明は、プログラマが所定のコード・セレクタを、オ
ペレーティング・システム・アプリケーションまたはサ
ブシステム内の特定の動的リンク・ライブラリのための
セレクタとして識別し、さらに、特定の動的リンク・ラ
イブラリが与えられれば、その動的リンク・ライブラリ
のためのコード・セレクタを識別することを可能にする
手法を提供する。

アプリケ−シリンが多重ロード可能プログラム単位を実
行することを可能にするオペレーティング・システム環
境が提供される。システムは保護メモリ・モードで稼働
し、アプリケーション・プログラムが動的リンクを介し
て、アプリケージぼンの実行可能コードに含まれていな
いセグメントを外部的に参照することを可能にする。ア
プリケージ鮪ン・プログラムは、実行時アプリケーシロ
ン・プログラム・インターフェース機能コードを含む特
別なプログラム動的リンク・ライブラリＤＬＬに対する
アプリケーション・プログラム・インターフェース呼出
しにより、これらの外部参照を含む。

システム・カーネルのローダ部分はロード中にＤＬＬ内
のセグメントに対するセグメント間参照を解決する。各
アプリケーションは、アプリケ−シロン専用のセグメン
トを含む相関的な局所記述子テーブルＬＤＴを有する。

ＬＤＴはまた、使用可能な全セグメントをシステム内の
すべてのタスクにもたらすシステム大域記述子テーブル
ＧＤＴの複写を含む。これにより、すべてのシステム・
セグメントに対するアクセスがアプリケ−シロンに提供
される。

ローダがアプリケ−シロンをロードするとき、対応する
ＤＬＬがロードされ、セレクタを割り当てられる。相関
セグメントは、そのセレクタ及びオフセットに対する機
能のアドレスを決定するローダによりＧＤＴ及びＬＤＴ
に記憶される。同じ機能を参照する後続アプリケ−シロ
ンの外部参照は同じセレクタ及びオフセットに帰着され
る。それによって、マルチ・タスク環境における複数の
アプリケーションは、アプリケージ１ン・プログラム・
インターフェース・コードのコピー１部のみが必要とな
る。

各ＤＬＬについて、動的リンク識別機能ＤＬＩＦがＤＬ
Ｌ内の入口点として含まれる。ＤＬＩＦによって、それ
ぞれのプログラムにおける各ＤＬＬごとにセレクタをも
たらすルーチンを呼び出すプログラムを作成することが
可能となる。あるプログラムはそれぞれのセレクタによ
る名前ごとにすべてのＤＬＬを表示する。別のプログラ
ムはアプリケージ冒ンの異常終了時にシステム・カーネ
ルに報告されたセレクタを受は取り、ＤＬＬ内のセレク
タの番号を含むＤＬＬｍ別を返す。

このようにして、システム・カーネルに対するアプリケ
−シロン・プログラム・インターフェースは所定のＤＬ
Ｌファイルに対するコード・セレクタを識別するか、ま
たはその代りとして、コード・セレクタを与えられたＤ
ＬＬファイルを識別する。

Ｅ、実施例 そのメモリ・モデルが当技術で周知のメモリ間接手段を
提供するマイクロプロセッサがある。−例ではあるが、
「保護モード」で動作するインテル社製のよく知られた
２　８８／３８６プロセツサ・ファミリのメモリ・モデ
ルはそのようなメモリ間接手段を提供する。第１図を参
照すると、保護モードは、以下のように、この点で「実
モード」から区別されている。

ａ、実モードでは、物理アドレス１は「セグメント」２
（メモリの開始ロケーションを識別する）及び「オフセ
ット」３（開始ロケーションからのバイト数を識別する
）から直接計算される。

ｂ、保護モードでは、物理アドレス４は、実質的にテー
ブル６へのインデックスであるセレクタ５とオフセット
７から間接的に計算される。

セレクタに対するテーブル項目はアドレス計算のための
メモリの開始ロケーションを識別する。

保護モードは、以下でさらに詳細に説明する本発明に関
連した幾つかの利点をもたらすが、これらの利点の中に
は、アプリケーションがシステムに損害を与えるのを防
止するメモリ分離がある。

システム内のすべてのタスクにとって使用可能なすべて
のセグメントに対して使用されるテーブル６を、大域記
述テーブル（ＧＤＴ）と呼ぶ。ＩＢＭ社のＯ８／２オペ
レーテイング・システムのシステム・アーキテクチャ構
造を示す第２図を参照すると、アプリケーションはアプ
リケ−シロン・プログラム・インターフェース（ＡＰＩ
）１１を使って、オペレーティング・システムにアクセ
スする。このシステムは、マルチ・タスク及び動的リン
ク機能を特徴とするオペレーティング・システムを示す
ものであり、その他の例には、ＡＩＸ及び幾つかのバー
ジロンのＵＮＩＸがある。以下で使用されるオペレーテ
ィング・システムという用語はこのようなシステムを指
すものである。したがって、本発明の１実施例を説明す
るためＯ８／２オペレーテイング・システムの詳細を本
明細書で用いるかもしれないが、本発明はこれに限定さ
れるものではなく、その他のオペレーティング・システ
ムに対する広範な適用を意図するものであることを理解
すべきである。Ｏ８／２オペレーテイング・システムに
ついてのこれ以上の詳細は、引用により本明細書に組み
込まれたＥｄ　ＩａｃｏｂｕｃｃｉのＯＳ／２　Ｐｒｏ
ｇｒａｍｍｅｒ’ｓ　Ｇｕｉｄｅ１マグロ−ヒル、１９
８８年から得ることができる。

オペレーティング・システム拳カーネル・コード１５及
び共通サブシステム・サービス１３に対するＡＰＩのた
め必要とされるセグメントが、ＧＤＴに含まれている。

オペレーティング・システムを拡張可能に設計する１つ
の方法は、アプリケーシロン１０がそれら自体のサブシ
ステム１４を書いて、それらのＡＰ１１２をオペレーテ
ィング・システムの論理的拡張部分にすることができる
ようにすることである。これらのサブシステムにとって
必要なセグメントもＧＤＴに含まれる。

オペレーティング・システムでは、ハード−ファイル等
の他の媒体からメモリにプログラムをロードする責任を
負うシステム・カーネルの部分を、ローダと呼ぶ。オペ
レーティング・システムは、アプリケ−シロン・プログ
ラムが、アプリケ−シロンの実行可能コード（ＥＸＥフ
ァイル）に含まれていないセグメントに対して「動的リ
ンク」を介して外部参照を行なうことを可能にする。ロ
ーダは、動的リンク・ライブラリ（ＤＬＬ）と呼ばれる
特別なプログラム・ライブラリに含まれたセグメントに
対する参照を解決することができる。ＡＰＩ（及びその
拡張部分）全体は動的リンクに基づく。実行時ＡＰＩコ
ード全体はＤＬＬに含まれる。ＤＬＬに対する外部参照
（たとえば、ＡＰＩ呼出し）を含むプログラムをロード
する場合、ローダはセグメント間の参照を解決する。好
ましい実施例における各アプリケ−シロンは、そのアプ
リケーション専用のセグメントを含む、局所記述子テー
ブル（ＬＤＴ）と呼ばれるそれ自体の記述子テーブル、
ならびにシステム・セグメントに対するアプリケ−シロ
ン・アクセスをもたらすＧＤＴの複写ををする。

上記より、要するに、ＡＰＩ機能のための実行時コード
がＤＬＬに含まれていることに、留意されたい。このよ
うなＡＰＩ機能の例には、ファイルの読取り及び書込み
がある。アプリケ−シロンがこの機能に対する呼出しを
含んでいる場合、アプリケーションのＥＸＥファイルは
この機能に対する外部参照のみを含む。ローダがこのア
プリケージ１ンをロードするときは、必要に応じ、ＤＬ
Ｌをもロードしくそれにセレクタを割り当て、実際のセ
グメントをＧＤＴ及びＬＤＴに記憶する）、機能のアド
レスをそのセレクタ及びオフセットに分解する。同じ機
能を参照する後続のアプリケーションは、それらの外部
参照を同じセレクタ及びオフセットに分解させる。した
がって、マルチ・タスク環境におけるすべてのアプリケ
ーションに必要なのは、ＡＰＩコードのコピー１つのみ
となる。

マルチ・タスク・オペレーティング環境の望ましい機能
の１つは、アプリケ−シロン・プログラムがシステムを
破壊できないことである。保護モードはメモリ分離をも
たらすので、オペレーティング・システムは、アプリケ
ーションがシステムに損害を与えるのを防ぐことができ
る。アプリケーション（またはサブシステム）が、その
アプリケーションに割り振られていないメモリにアクセ
スしようとすると、システムはそのアプリケーションを
終了し、問題を訂正するため使用することができる情報
と共に保護違反を報告する。この情報は、他の項目と共
に、プログラムが違法動作を試みたコード・セレクタ及
びオフセットを含んでいる。

アプリケ−シロンをオペレーティング・システムに対す
る拡張として実現する能力は、そのような問題をコード
で訂正しなければならないプログラマに対してジレンマ
を生じる。アプリケーション・−プログラムが終了され
た場合、アプリケ−シロンが連係されたとき生成される
マツプを使って、アプリケ−シリンの該当するコード・
セグメントに、コード・セレクタを容易にマツプするこ
とができる。これは、アプリケ−シロンが実行されるた
びに、アプリケージぼンにとって局所的なセグメントに
同じセレクタが割り当てられるからである。しかし、Ｄ
ＬＬに対するセレクタは容易に特定のプログラムと関連
づけられず、実際には、アプリケーションが実行される
たびに異なる可能性がある。

本明細書で考察しているオペレーティング・システム環
境では、ＤＬＬを使用して実現されたプログラムに対し
て、開発機構に現われる２つの異なる問題がある。

１、ＤＬＬ内に特定の機能が与えられた場合、プログラ
マはマツプを調べ、その機能のＤＬＬ内のオフセットを
見つけることができる。しかし、プログラマはまた、デ
バッグのためＤＬＬのコード・セレクタを判別しなけれ
ばならない。セレクタの割当ては機械により、さらには
、アプリケージ目ンの連続的実行で変わることに留意さ
れたい。

２、ＤＬＬ内での実行中に、プログラムがシステムによ
り終了された場合、終了が行なわれたときにコード・セ
レクタ及びオフセットがオペレーティング・システムに
より表示されるか、または他の方法で示されるとすると
、顧客は、どのＤＬＬから終了が生じたかを正確に識別
するような方法で、問題をプログラマに報告することが
できなければならない。

これらの問題を解決するための１つの方法は、特定のＤ
ＬＬファイルに対するセレクタを識別するため、または
セレクタを与えられたＤＬＬファイルを識別するため、
システム・カーネルがＡＰＩを提供することである。オ
ペレーティング・システムに本来備わったそのような機
能がなくても、情報を判別するためオペレーティング・
システムの内部領域にアクセスする装置ドライバを作成
し、次に装置ドライバから情報を得るためのプログラム
を作成することにより、プログラマはその機能を提供す
ることができる。しかし、装置ドライバを作成すること
は非常に単調な作業であり、コードは特にデバッグが困
難である。さらに、そのような装置ドライバはオペレー
ティング・システム自体と同じ保護レベルで働き、した
がって、すべてのシステム・データ・セグメントにアク
セスし、システムのメモリ分離を弱体化の危険にさらす
ことになる。どのようなプログラマでもアプリケ−シロ
ンについて実現することができる簡単な解決策が一層望
ましい。

この実施例では、プログラムの各ＤＬＬについて、動的
リンク識別機能（ＤＬ　Ｉ　Ｆ）と呼ばれるＤＬＬ内の
入口点である機能が含まれる（この機能はＤＬＬにより
伝えられる）。これらの機能の各々は次のように定義さ
れる。

ｃｈａｒ　ｆａｒ　零ｆａｒ　ｐａｓｃａｌ　ｆｎ　（
ｖｏｉｄ）；次の表１は本発明の動的リンク識別機能の
Ｃプログラミング言語のソース・コードである。

表　　１ １　　　　ｆｆ１ｎｃｌｕｄｅ　　＜ｄｏｓ、ｈ＞２　
ｉｎｔ　ｇｅｔｓｅｌ　（ｖｏｉｄ）；３５ｔａｔｉｃ
　ｖｏｉｄ　ｄｕ＋ｕ＋ｙ　（ｖｏｉｄ）；４　ｃｈａ
ｒ　ｆａｒ　＊　ｆａｒ　ｐａｓｃａｌ　ｆｎ　０６ｉ
ｎｔ　ｒｃニ ア　　ｖｏｉｄ　（：ｆｐ）０　＝ｄｕｍｍｙ；８　　
ｒｃ　＝　ｇｅｔｓｅｌ　０ ９　　ＦＰ　０ＦＦ（ｆｐ）　＝（（ｒｅ　−ＦＰ　５
ＥＧ（ｆｐ））　）＞　４）　÷１；１０　　ｒｅｔｕ
ｒｎ　（（ｃｈａｒ　ｆａｒ　：）　ｆｐ）；１２５ｔ
ａｔｉｃ　ｖｏｉｄ　ｄｕ＋ａｍｙ　０１３〔 表１において、行１は、以下に示すように、Ｃポインタ
のオフセット及びセレクタ部分を判別するためのマクロ
を定義するオペレーティング・システム・ヘッダ・ファ
イルを示す。

＃ｄｅｆｉｎｅ　ＦＰ　５ＥＧ（ｆｐ）　（零（（ｕｎ
ｓｉｇｎｅｄ零）＆（ｆｐ）　＋１））ｕｄｅｆｉｎｅ
　ＦＰ　０ＦＦ（ｆｐ）　（＊（（ｕｎｓｉｇｎｅｄ　
：）＆（ｆｐ）））次の表２は、そのコード・セレクタ
を返す機能の、アセンブラ・コードによるソース・コー
ドである。

表　　２ ｔｅｘｔ　　ｓｅｇｍｅｎｔ　ｂｙｔｅ　ｐｕｂｌｉｃ
　’Ｃ０ＤＥ’ｔｅｘｔ　　ｅｎｄｓ ａｓｓｕｍｅ　　ｃｓ：　ｔｅｘｔ ｔｅｘｔ　　ｓｅｇｍｅｎｔ ｐｕｂｌｉｃ　　ｇｅｔｓｅｌ ｇｅｔｓｅｌ　ｐｒｏｃ　ｆａｒ ｐｕｓｈ　ａｓ ｐｏｐ　　　ａｘ ｅｔ ｇｅｔｓｅｌ　ｅｎｄｐ ｔｅｘｔ　　ｅｎｄｓ ｎｄ 機能の実現態様を示す表１をさらに参照すると、行２は
機能ｇｅｔｓｅ　ｌを宣言し、この機能は表２で、その
コード・セレクタ（ＣＳレジスタ）を返すアセンブラ言
語ルーチンとして定義され、実現されている。行３は、
行１２−１４で定義されるダミー機能を宣言する。行４
はＤＬＩＦ機能自体を、ＤＬＬ内への入口点として必要
とされるものとして、かつ４バイトのｆａｒポインタ　
（ｆｐ）を返すものとして定義する。行７はｆｐを、機
能を指すポインタとして宣言し、ｆ’ｌ）はＤＬＩＦの
直後のダミー機能のアドレスにセットされる。このこと
によって、ポインタｆＰのセレクタ部分はＤＬＩＦのセ
レクタを含むようになるが、このセレクタはＤＬＬの最
初のセレクタと等しいものでなければならない。行８で
、ｒｃにはｇｅｔｓｅ　１機能のセレクタが割り当てら
れるが、このセレクタはＤＬＬの最後のセレクタでなけ
ればならない。行９で、ｇｅｔｓｅ１機能に対するセレ
クタとＤＬＩＦ機能に労するセレクタの間の差を１６で
除算し、１を加算することにより、ＤＬＬに対するコー
ド・セレクタの数が計算される。この数は、ＤＬＩＦを
指すポインタ内のオフセットの代りに記憶される。

行１０で、ＤＬＩＦのセレクタを依然として含み、ＤＬ
Ｌに対するコード・セレクタの数を含むために変更され
た変数ｆｐが、呼出しプログラムに返される。

アプリケージ騨ン（すなわち、ＥＸＥファイル）または
動的リンク・ライブラリ（すなわち、ＤＬＬファイル）
をリンクした場合、リンク処理が中力内のモジュールの
配列の指定を可能にすることを、想起されたい。

ＤＬＩＦを含むモジュールがＤＬＬに対するリンク・リ
ストの最初のモジュールであれば、ＤＬＬに対するコー
ド・セレクタの数が正確に返され、ｇｅｔｓｅｌ　ルー
チンがライブラリから静的に連係され、以下によりコー
ド化される。

ｔｅｘｔ　ｓｅｇｍｅｎｔ　ｔ＋ｙｔｅ　ｐｕｂｌｉｃ
　’Ｃ０ＤＥ’第３図を参照すると、これはＤＬＩＦ機
能２７を強制的にＤＬＬ２Ｂに対する最初のコード・セ
グメントにする。ＤＬＬがローダによりロードされると
きは、ＤＬＬ２１に対する最初のセレクタが割り当てら
れる。リンク処理はまた、ｇｅｔｓｅ１機能２９をＤＬ
Ｌ２８に対する最後のコード・セグメントにおける他の
Ｃライブラリ機能とともに存在させる。ＤＬＬがローダ
によりロードされるときは、ＤＬＬ２３に対する最後の
セレクタが割り当てられる。他のセレクタは増分量１６
で、中間でローダにより順次割り当てられる（この例で
はコード・セグメント２２５として）。第３図に示すよ
うに、実メモリ２４におけるＤＬＬのコードの物理的ロ
ケーションにかかわらず、入城記述子テーブル２０にお
けるコード・セレクタの割当てはこのとき、ＤＬＬのす
べてのコード・セグメントを識別するため使用すること
ができる。本発明は、コード・セレクタを割り当てる方
法に限定されることを意図するものではなく、連続した
コード・セレクタを増分量８で割り当てる方法等の他の
方法が使用されるようになったローダを目的とするもの
であることを理解すべきである。さらに、本発明は、説
明したリンク処理に限定されることを意図するものでは
なく、他のある処理（セグメント名によりセグメントの
順序を明示的に指定するといった）が必要とされるリン
カを目的とするものである。

ＤＬＩＦは、これらのルーチンを呼び出し、プログラム
内のＤＬＬの各々に対するセレクタを得るアプリケーシ
ョン・プログラムを作成することを可能にする。

次の表３は、−組の動的リンク・ライブラリのコード・
セレクタを識別するための本発明の動作の流れ図である
。

表　　３ Ｄｉｓｐｌａｙ　ｃｏｄｅ　５ｅｌｅｃｔｏｒｓ　ｏｆ
　ＤＬＬｓＦｏｒ　ｅａｃｈ　ＤＬＬ　ｉｎ　ｔｈｅ　
ｐｒｏｇｒａｍＣａｌｌ　ｔｈｅ　ＤＬＩＦ　ｏｆ　ｔ
ｈｅ　ＤＬＬ　ｔｏ　ｏｂｔａｉｎ　ｔｈｅｆｉｒｓｔ
　ｃｏｄｅ ｓｅｌｅｃｔｏｒ　ａｄｄ　ｔｈｅ　ｎｕｍｂｅｒ　ｏ
ｆｃｏｄｅ　５ｅＢｅｎｔｓ Ｆｏｒ　ｅａｃｈ　ｃｏｄｅ　ｓｅｇｍｅｎｔ　ｏｆ　
ｔｈｅ　ＤＬＬＤｉｓｐｌａｙ　ｔｈｅ　ｃｏｄｅ　５
ｅｌｅｃｔｏｒＩｎｃｒｅ＋＊ｅｎｔ　ｔｈｅ　ｃｏｄ
ｅ　５ｅｌｅｃｔｏｒ　ｂｙ　１６Ｄｅｃｒｅｍｅｎｔ
　　ｔｈｅ　　ｎｕ＋ａｂｅｒ　　ｏｆ　　５ｅｌｅｃ
ｔｏｒｓ　　ｔ。

ｄｉｓｐｌａｙ ｎｄｆｏｒ ｎｄｆｏｒ 表３を参照すると、ここに示したようなプログラムを作
成し、すべてのＤＬＬをそれらのそれぞれのセレクタに
より名前ごとに表示することができる。

次の表４は、表３に記載した機能の実施例の出力の画面
表示である。プログラムの画面出力を表４に示す。

表　　４ Ｓｅｌｅｃｔｏｒｓ　ｆｏｒ　ＤＬＬＩ　ａｒｅ　５Ｃ
７５Ｄ７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ２　ｉｓ　
７７７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ３　ｉｓ　Ｂ
１７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ４　ｉｓ　Ｂ１
７Ｓｅｌｅｃｔｏｒｓ　ｆｏｒ　ＤＬＬ５　ａｒｅ　Ｂ
８７　Ｂ９７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ６　ｉ
ｓ　Ｂ１７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ７　ｉｓ
　Ｂ１７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ８　ｉｓ　
Ｃ０７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ９　ｉｓ　Ｃ
６７Ｓｅｌｅｃｔｏｒｓ　ｆｏｒ　ＤＬＬＩＯａｒｅ　
Ｃ８７Ｃ９７Ｃ０７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ
ＩＩ　ｉｓ　ＣＣ７５ｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ
Ｉ２　ｉｓ　Ｃ０７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ
Ｉ３　ｉｓ　Ｄ８７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ
Ｉ４　ｉｓ　Ｄ４７Ｓｅｌｅｃｔｏｒ　ｆｏｒ　ＤＬＬ
Ｉ５　ｉｓ　Ｄ１７次の表５は、コード・セレクタを与
えられた動的リンク・ライブラリを識別するための本発
明の動作の流れ図である。

表　　５ Ｉｄｅｎｔｉｆｙ　ＤＬＬ　ｆｏｒ　ａ　ｇｉｖｅｎ　
ｃｏｄｅ　５ｅｌｅｃｔｏｒＦｏｒ　　ｅａｃｈ　　Ｄ
ＬＬ　　ｉｎ　　ｔｈｅ　　ｐｒｏｇｒａｍＣａｌｌ　
ｔｈｅ　ＤＬＩＦ　ｏｆ　ｔｈｅ　ＤＬＬ　ｔｏ　ｏｂ
ｔａｉｎ　ｔｈｅｆｉｒｓｔ　ｃｏｄｅ　５ｅｌｅｃｔ
ｏｒ　ａｎｄ　ｔｈｅ　ｎｕｍｂｅｒｏｆ　ｃｏｄｅ　
ｓｅｇｍｅｎｔｓ Ｉｎｉｔｉａｌｉｚｅ　ｔｈｅ　ｎｕｍｂｅｒ　ｏｆ　
ｔｈｅ　ｃｏｄｅ　ｓｅｇｍｅｎｔｗｉｔｈｉｎ　ｔｈ
ｅ　ＤＬＬ　ｔｏ　ＩＦｏｒ　ｅａｃｈ　ｃｏｄｅ　ｓ
ｅｇｍｅｎｔ　ｏｆ　ｔｈｅ　ＤＬＬＩｆ　ｔｈｅ　ｇ
ｉｖｅｎ　ｃｏｄｅ　５ｅｌｅｃｔｏｒ　ｉｓ　ｅｑｕ
ａｌ　ｔ。

ｔｈｅ　ＤＬＬ　ｃｏｄｅ　５ｅｌｅｃｔｏｒＤｉｓｐ
ｌａｙ　ｔｈｅ　ＤＬＬ　ｎａｍｅＤｉｓｐｌａｙ　ｔ
ｈｅ　ｎｕｍｂｅｒ　ｏｆ　ｔｈｅ　ｃｏｄｅ　ｓｅｇ
ｍｅｎｔｗｉｔｈｉｎ　ｔｈｅ　ＤＬＬ Ｅｘｉｔ　ｔｈｅ　１ｏｏｐ ｌｓｅ Ｉｎｃｒｅｍｅｎｔ　　ｔｈｅ　　ＤＬＬ　　ｃｏｄｅ
　　５ｅｌｅｃｔｏｒ　　ｂｙ　　１６Ｉｎｃｒｅｍｅ
ｎｔ　　ｔｈｅ　　ｎｕｍｂｅｒ　　ｏｆ　　ｔｈｅ　
　ｃｏｄｅ　　ｓｅｇｍｅｎｔｗｉｔｈｉｎ　　ｔｈｅ
　　ＤＬＬ Ｄｅｃｒｅｍｅｎｔ　　ｔｈｅ　　ｎｕｍｂｅｒ　　ｏ
ｆ　　５ｅｌｅｃｔｏｒｓ　　ｔｏ　　ｔｅｓｔｎｄｉ
ｆ ｎｄｆｏｒ 上記の表５に示すようなもう１つのプログラムを作成す
ることができるが、このプログラムは、アプリケ−シロ
ンが異常終了されたとき、システム・カーネルにより報
告されたセレクタを受は取り、ＤＬＬ内のセレクタの数
を含むＤＬＬｍ別を返すものである。このプログラムを
使用するときは、終了されたアプリケージ１ンと同じＤ
ＬＬセットを参照する別のアプリケーションを同時に（
異常終了が発生したとき）実行することが必要である。

表３に記載したプログラムをこのために使用することが
できる。このことは、表５に記載したプログラムが実行
されているときは、ＤＬＬに割り当てられたセレクタは
解放及び再割当てされないことを保証する。上述した本
発明の機能は問題解決及びデバッグの際にプログラム開
発者によっておおいに有益であることは明らかであろう
。

第４図には、前述のアルゴリズムの機能を提供するコン
ピュータ・プログラムを実行するため使用されて、本発
明のシステムを実現することが可能な処理装置のブロッ
ク・ダイヤグラムが示されている。システムは、ＩＢＭ
パーソナル・システム／２で具現化されているような典
型的なパーソナル・コンピュータ・アーキテクチャの形
を取ることが好ましい。このシステム３０に関連して、
インテル８０２８６または８０３８６デバイス等のマイ
クロプロセッサ３２が設けられ、マイクロプロセッサ３
２はバス４２により入出力装置３４、ＲＯＭ３８、メモ
リ３８及び媒体４０の内の所望のものに結合される。バ
ス４２は通常の態様で、当技術で周知の目的のためアド
レス、コマンド及びデータ線からなることが理解される
であろう。

本発明のシステム３０に備えることができる入出力Ｂ置
３４はＩＢＭパーソナル・システム・カラー表示装置８
５１０等の表示装置、キーボード、ユーザ入力用のマウ
ス等、及び必要に応じ、印刷装置を含むことができる。

簡単のため第４図からアダプタが省略されているが、そ
れぞれの装置３４−４０のためのそのようなアダプタは
ＩＢＭパーソナル・システム／２の一部として含めるこ
とも、または、ＩＢＭ社からのプラグ・イン・オプショ
ンとして入手することができることも理解されるであろ
う。

読取り専用メモリすなわちＲＯＭ３８内には、基本人出
力オペレーティング・システムすなわちＢＩＯ８が記憶
されており、プロセッサ３２によって実行される。ＢＩ
Ｏ８は周知のようにコンピュータ・システム３０の基本
動作を制御する。さらに、Ｏ８／２等のオペレーティン
グ・システム４４が設けられており、オペレーティング
・システム４４はメモリ３８にロードされ、ＲＯＭ３Ｂ
のＢＩＯ８と関連して実行される。

本発明のシステム及び方法を実現するため好ましい実施
例で使用することができるパーソナル・システム／２及
びオペレーティング・システムＯ８／２に関するその他
の情報は、引用により本書に組み込まれた以下の参考文
献に記載されている。

ｒＩＢＭオペレーティング・システム／２バージロン１
．０基本版、技術解説書（ＩＢＭ　Ｏｐｅｒａｔｉｎｇ
Ｓｙｓｔｅｍ／２　Ｖｅｒｓｉｏｎ　１．０５ｔａｎｄ
ａｒｄ　ＥｄｉｔｉｏｎＴｅｃｈｎｉｃａｌ　Ｒｅｆｅ
ｒｅｎｃｅ）　Ｊ、ＩＢＭパーツ番号６２８０２０１、
注文番号５８７１−ＡＡｌ　ｒ技術解説書、パーソナル
・システム／２（８０型）（Ｐｅｒｓｏｎａｌ　Ｓｙｓ
ｔｅｍ／２　（Ｍｏｄｅｌ　８０））　Ｊ、ＩＢＭパー
ツ番号６８Ｘ−２２５６、注文番号５６８Ｘ−２２５６
、及びｒＯ８／２プログラマの手引（ＯＳ／２Ｐｒｏｇ
ｒａｍｍｅｒ’ｓ　Ｇｕｉｄｅ）　Ｊ　、Ｉａｃｏｂｕ
ｃｃｉ１Ｅｄ１マグロ−ヒル、１９８８年。

本発明によれば、メモリ３８にロードするか、または媒
体４０に記憶することができるアプリケーション・プロ
グラム１０がさらに設けられている。

この媒体４０はハード・ファイル、ディスク駆動機構に
挿入されたディスケット等のどのような通常形態でもよ
い。Ｏ８／２によれば、データベース・アプリケーショ
ン・プログラム１０はオペレーティング・システム４４
の拡張と見なすことができ、システム３０が上記の関係
データベース機能を実行できるようにプロセッサ３２に
命令を与えるデータベース・プログラムと通常の方法で
関連づけられた多数の機能を含んでいる。オペレータは
種々の入出力装置３４を介してデータベース・プログラ
ムとインターフェースすることができ、そのようなイン
ターフェース処理はデータの入力、アクセス、変更また
はデータベースからのデータの削除、及びその他の同様
なタスクを含むものである。たとえば、ユーザは当技術
で周知のＳＱＬ言語等の何らかの形式のコマンドをキー
ボードを介して入力することにより、データベース・プ
ログラム４６とインターフェースすることができ、その
結果、システム３０は、データベースにあるデータを照
会し、検査のためユーザにより設定された所望の応答を
ビデオ端末、印刷装置等に出力する。

オペレーティング・システム４４は、本発明の第２図の
構成要素ｔ　ｔ−ｔｅと関連して考察した機能を実現す
るためのソフトウェア手段の一般化された説明図として
第４図上で認識される。

【図面の簡単な説明】

第１図は、本発明の装置におけるメモリ・アドレス計算
を示すブロック・ダイヤグラムである。 第２図は、本発明の装置におけるシステム・アーキテク
チャ構造のブロック・ダイヤグラムである。 第３図は、本発明の大域記述テーブルと動的リンク・ラ
イブラリの間の関係の説明図である。 第４図は、第１図ないし第３図に関連して説明する本発
明のソフトウェア機能を実現するシステムの機能ブロッ
ク・ダイヤグラムである。 １０・・・・アプリケ−シロン・プログラム、３２・・
・・プロセッサ、３４・・・・入出力装置、３６・・・
・読取り専用メモリ、３８・・・・メモリ、４０・・・
・媒体、４４・・・・オペレーティング・システム。 物可メモリ　２４

Claims (1)

1. 【特許請求の範囲】 アプリケーションが多重ロード可能プログラム単位とし
   て実行される動作環境において、少なくとも１つの動的
   リンク・ライブラリを生成するステップと、 複数のコード・セレクタを生成するステップと、上記複
   数のコード・セレクタに関連した上記動的リンク・ライ
   ブラリの内の上記少なくとも１つにおいて第１のコード
   ・モジュールを生成するステップと、 上記動的リンク・ライブラリ及び上記複数のコード・セ
   レクタに対応する機能を引き出すステップと、 上記機能に対応する表示を生成するステップとからなる
   マルチ・タスク環境における動的リンク識別子供給方法
   。