JPH06222931A - パーソナルコンピュータのための制御プログラム及びプログラム間連絡提供方法 - Google Patents

Abstract

(57)【要約】 【目的】 ＭＳＤＯＳ（登録商標）と協同的に作動して
複雑なユーザの指令を多数の相互に作用する応用プログ
ラムにより効果的に達成させる保証された応答時間のプ
ログラム間連絡を提供する制御プログラムを提供する。 【構成】 ＭＳＤＯＳオペレーティングシステムを利用
するアイビーエムのコンパチブルマイクロプロセッサの
ための制御プログラムが、複数の応用プログラムが情報
をそれらの間及びカーネルプログラムに通すための能力
を提供し、それにより、カーネルプログラムがそのバッ
ファメッセージの内容に応じて応用を生み出す。これに
よって、プログラム間連絡計画と関連して通常出くわす
競合を伴うことなく、ＭＳＤＯＳ環境を強化する。

Description

【発明の詳細な説明】

【０００１】発明の背景 １．発明の分野： 本発明は、一般的にはプログラム間
連絡に係り、そしてより詳しくは、相互連絡をし、相互
に制御しそしてユーザに対し一様なインターフェースを
提供している間共通ドライバを通して連絡ハードウェア
を共有するための能力を伴う応用プログラムを提供する
制御プログラム及びプログラム間連絡提供方法に関す
る。

【０００２】２．従来技術の記述： アイビーエム（Ｉ
ＢＭ）のパーソナルコンピュータ（ＰＣ）或いはアイビ
ーエムのコンパチブルパーソナルコンピュータとしても
知られているマイクロプロッセッサのインテル８ｘ８６
ファミリに基づくパーソナルコンピュータは個人的な計
算にとって有力な基準となる。この基準の継続的な人気
は、主として、マイクロソフトコーポレーション（Ｍｉ
ｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ）により販売
されているＭＳＤＯＳ（マイクロソフトディスクオペレ
ーティングシステム）として知られる特定のディスクオ
ペレーティングシステム（ＤＯＳ）でもって演算処理す
るように書かれた応用ソフトウェアの大規模な本体の汎
用性に加え、相対的に低いハードウェアコストに起因す
る。ＭＳＤＯＳは、何らかのオペレーティングシステム
ソフトウェアを伴っているとき、応用プログラムのオペ
レーションのために規定された環境を提供する。術語
「ＭＳＤＯＳ」は、字義通り、マイクロソフトコーポレ
ーションにより販売されているソフトウェアをいうが、
それは、何らかのアイビーエムのコンパチブルパーソナ
ルコンピュータにおいて含まれる読出専用メモリに含ま
れた基礎的な入力ー出力システム（ＢＩＯＳ）のプログ
ラムを含むようにしばしば解釈される。以下、術語「Ｍ
ＳＤＯＳ」は、ＢＩＯＳを含み、ＭＳＤＯＳ（バージョ
ン３．０或いはより後の）プロトコルに一般的に適合す
るアイビーエムのコンパチブルパーソナルコンピュータ
の標準オペレーティングシステムを意味するように使用
されるであろう。その技術に熟練した者達は、ＭＳＤＯ
Ｓのオペレーションの構成やモードの知識を備えている
であろうが、これらの望ましい更なる背景が、著作権１
９８８、マイクロソフトプレス（Ｍｉｃｒｏｓｏｆｔ
Ｐｒｅｓｓ）、レイモンド・ダンカン（Ｒａｙｍｏｎｄ
Ｄｕｎｃａｎ）による「アドバンスドＭＳＤＯＳ」
（Ａｄｖａｎｃｅｄ ＭＳＤＯＳ）と称する出版物にて
見い出されるＭＳＤＯＳの詳細な記述に言及される。

【０００３】簡単なＭＳＤＯＳの個人指導 ＭＳＤＯＳは、プログラムの集合からなり、これらは、
共に、ユーザがパーソナルコンピュータのオペレーショ
ンを質問したり制御するオペレーティングインターフェ
ースを提供する。ＭＳＤＯＳが開始されるとき、それ
は、第１に、初期化の処理を完了させ、そしてそれから
コマンドインタープリター（ＣＯＭＭＡＮＤ．ＣＯＭ）
を呼び出す。このプログラムは、キーボードを介しユー
ザにより入力されるコマンドを受けて作用する。このレ
ベルでは、コマンドは、現実には、対応する実行可能な
プログラムを含むファイルの名である。例えば、もしも
ユーザがコマンド「ＤＩＲ」を入力すれば、そのコマン
ドのインタープリタープログラムは、ファイル「ＤＩ
Ｒ．ＣＯＭ」を見出し、もしも既に常駐していなけれ
ば、プログラムＤＩＲをメモリにロードし、そして制御
をデイレクトリプログラムに転送するであろう。プログ
ラムＤＩＲは実行されて現行のデイレクトリの内容をユ
ーザのディスプレイ上に書かせる。ＤＩＲプログラムは
制御をＭＳＤＯＳコマンドインタープリターに戻すこと
により終了し、このインタープリターは従って次のユー
ザコマンドを待つ。ユーザは、従って、プログラム名を
入力することにより、何らかのＭＳＤＯＳコマンド或い
は応用プログラムの実行を呼び出す。かくして呼び出さ
れたプログラムは、順に、低レベルのＤＯＳのサービス
ルーチンを呼び出して色々な入力／出力資源と連絡す
る。

【０００４】上に述べた記述は、アイビーエムのパーソ
ナルコンピュータ、モデルＸＴと共に最初に導入された
ときのＭＳＤＯＳの相対的に未発達な範囲を正しく取り
囲む。モデルＸＴの制限されたメモリ及び計算資源は、
既知の主なフレーム及びＵＮＩＸのようなミニコンピュ
ータオペレーティングシステムの能力の多くを妨害し
た。ＵＮＩＸが非常に可能性のある多重ユーザ多重タス
ク環境を提供したのに反し、ＭＳＤＯＳはランダムアク
セスメモリのせいぜい６４０キロバイトでもって単一の
タスクを実行する単一のユーザに拘束された。より意味
ありげには、ＭＳＤＯＳは、応用プログラムを、非同期
の連絡ポートのような入力ー出力装置に非制限的にアク
セスさせる。上記制限は、ＭＳＤＯＳに固有であって、
妥協する互換性なしにはＭＳＤＯＳ内において直接的に
は打ち勝つことができない。効果的なプログラム間連絡
及び動的タスクスケジューリングの例は他のオペレーテ
ィングシステムにおいてよく知られているが、この望ま
しい能力は、これまでは、パーソナルコンピュータの実
行ＭＳＤＯＳ上では有効ではなかった。

【０００５】新しい制御プログラムが新しい或いは変更
された特徴をオペレーティングシステムに加えて併合さ
れ得るように、ＭＳＤＯＳは容易に拡張可能であるが、
既知の従来技術の機構はオペレーティング環境を生ぜ
ず、この環境においては、多数の別個の応用プログラム
が単一のユーザコマンドにより呼び出されて複雑なタス
クを効率よく協力して成就する。この能力の例はより可
能性のあるオペレーティングシステムにおいて豊富であ
るのに反し、ＭＳＤＯＳにおける典型的な実行は、タス
クの複雑さに対応する単一のモノリシックプログラムを
書くことである。これは、ＭＳＤＯＳ下でのプログラム
間連絡及び動的スケジューリングに対する従来技術の解
決が不完全であるか或いは余りにも負担であるかのいず
れかであったと信じられている。根底となっている問題
は、連絡及びスケジューリングタスクを効率よく成就す
るためのプログラムに対して、それは、乏しいメモリ資
源のための応用プログラムでもって競うランダムアクセ
スメモリ内に常駐のままであるに違いないということで
ある。この競合が、パーソナルコンピュータの速度及び
ランダムアクセスメモリ容量が増大し続けるときでさえ
も継続する。

【０００６】ＤＯＳ環境上への本発明の制御プログラム
の影響を理解するために、何らかのソフトウェア上のＤ
ＯＳによりその制御下で課される制限の幾つかを議論す
ることは役に立つと思われる。この議論を通して、本発
明の制御プログラム環境の値がより明らかになるであろ
う。

【０００７】ＤＯＳと呼ばれるオペレーティングシステ
ムは、本来的には、インテル８０８８マイクロプロセッ
サにより提供されるハードウェア環境にて作動するよう
に書かれていた。この環境において、最大１メガバイト
（ＭＢ）のアドレス可能なランダムアクセスメモリが入
手可能である。それはＤＯＳにより二つの領域に分割さ
れる。より低いメモリスペースは６４０キロバイト（Ｋ
Ｂ）のプログラムメモリを含む。それは、プログラムが
ロードされそして実行されるこの領域内にある。ここに
ある制限は、もしもプログラムがメモリのこの量よりも
多く要求するならば、拡大すべき他のメモリはないとい
うことである。また、６４０キロバイトのスペースは、
応用、装置ドライバ及び他のシステムソフトウェアのた
めの残りのスペースをそのままにして、ＤＯＳプログラ
ムにより占められねばならないということが注目される
べきである。このことが、実行のための応用に対する十
分なメモリスペースをもたないことに帰結し得る。

【０００８】より上位のメモリスペースは、残りの３８
４キロバイトからなり、パーソナルコンピュータの拡張
スロットのいずれかに備えつけられたパーソナルコンピ
ュータボードのいずれか上に常駐するファームウェア
（ｆｉｒｍｗａｒｅ）のために使用される。ビデオラン
ダムアクセスメモリもまたここでアドレスされる。この
スペースは、応用プログラムのために使用されるように
は決して意図されていなかった。

【０００９】後の開発は、拡張メモリとして知られてい
ることの使用を通してより多くのメモリを備えていた。
この計画によれば、より上位の３８４キロバイトスペー
ス内に６４キロバイトのバッファが置かれる。本来の１
メガバイトのスペースを超えるコンピュータ内のどのよ
うなメモリでも、ハードウェアレジスタの使用を通して
このバッファ内にスワップされる。そのメモリは、プロ
グラムデータに対しては有用であるが、応用の実行可能
なコードに対しては、やはり、メモリ制限を緩和しはし
ない。

【００１０】８０２８６及びより新しいプロセッサの導
入と共に、もう一つのメモリマッピング計画が展開され
た。それは、拡張メモリとして、これらのより新しいプ
ロセッサ（１６メガバイトまで）の特別のアドレス可能
なメモリ能力を使用する。再び、このメモリはプログラ
ムデータを記憶するのに有効であるが、プログラム自体
には有効ではない。

【００１１】これらのより新しいメモリマッピング計画
と共に、一つは、やはり、６４０キロバイトのプログラ
ムスペースにより制限される。従って、システムーレベ
ルのソフトウェアに対するどのような付加もできる限り
小さなメモリスペースを取らなければならない。そのよ
り新しい（８０２８６及び前記の）プロセッサと共に、
ある装置ドライバ及び他のシステムプログラムを、より
上位の３８４キロバイト領域内に移動させることもまた
可能である。しかしながら、ある人は、そのようなソフ
トウェアが、メモリ内に配置される場所とは関係なく適
当に走るように再配置可能でなければならないことを評
価するに違いない。

【００１２】ＤＯＳ環境の強力な特徴は、終了及び滞在
の常駐（ＴＳＲ）のプログラムの概念である。それは、
走るとき、それ自身（通常は、割り込みに所属してい
る）を初期化しそして制御をＤＯＳに戻すプログラムで
ある。そのような点から、その割り込みが発生されると
き、ＴＳＲプログラムは「ウェークアップ」（ｗａｋｅ
ｕｐ）しそして要求された機能を履行する。これの共通
の例は、ボーランドコーポレーション（Ｂｏｒｌａｎｄ
Ｃｏｒｐｏｒａｔｉｏｎ）から入手可能な一般に普及
しているサイドキック（Ｓｉｄｅｋｉｃｋ）のソフトウ
ェアである。このソフトウェアは、それ自身、パーソナ
ルコンピュータのキーボード割り込みに所属している。
キーが押される度に、プログラムが「ウェークアップ」
しそしてカレンダー、メモ用紙とじ等の形態でユーザに
対し多数の機能を提供する。もしもキーストロークがサ
イドキックの「ホットキー」でなければ、サイドキック
は、単に、さらに処理をするためにキーストロークをＤ
ＯＳに単に通過させる。

【００１３】ＤＯＳはバッチファイル機構を備えてお
り、これにより、ユーザは、何らかのＤＯＳのコマンド
ラインエントリーを含む情報交換用米国標準コードファ
イル（アスキーファイル）を創作し得る。応用プログラ
ム、ＤＯＳコマンド、及びＤＯＳコマンドラインから開
始され得るどのような他の動作も、バッチファイルから
開始され得る。例えば、ＤＯＳから直接にファイルをク
リアするというタスクは、ＤＯＳコマンドラインでエン
ターされるように必要な一連のコマンドを含むバッチフ
ァイルを創作することにより自動化され得る。このバッ
チファイルが実行されるときはいつでも、それが含む一
連のコマンドが、あたかもＤＯＳコマンドラインから手
動でエンターされたかのように実行されるであろう。実
際は、ソフトウェアを処理するＤＯＳバッチファイルが
そのバッチファイルを解剖しそしてコマンド．コム（Ｃ
ＯＭＭＡＮＤ．ＣＯＭ）を一時的に生み出してこれらの
コマンドを実行する。バッチファイル処理における固有
の一つの問題は、親のプログラム（この場合において
は、バッチファイルプロセッサ）の環境が子供の処理
（バッチファイルにおけるエントリにより発生される動
作）に沿っては通過されない。この理由により、バッチ
ファイルは、本発明の制御プログラム環境により許容さ
れると同様の統合された方法では十分には実行できな
い。なお、ラインがバッチファイル内にハードコード化
されるので、それらは外部の刺激における変化に応答し
て動的には変更され得ない。バッチファイルは出口上の
応用により作られる初歩的なエラーコードを利用できる
が、これを処理するためのラインが既にバッチファイル
内になければ、それは取り扱われ得ない。

【００１４】ＭＳＤＯＳのためのオペレーティングシス
テムのもう一つの部分は所謂「装置ドライバ」である。
それは応用ソフトウェアに装置の独立を提供する。ハー
ドウェアは、装置ドライバを通して、ファイルとして簡
単にアクセスされる。その装置は、読まれ書かれるため
に開かれ、そして応用がその装置と共に終了したときに
閉じられる。

【００１５】発明の目的 本発明の目的は、ＭＳＤＯＳと共同的に作動して、複雑
なユーザの指令を多数の相互に作用する応用プログラム
により効果的に達成させる保証された応答時間のプログ
ラム間連絡を提供する制御プログラムを提供し、そし
て、さらに、この能力が、ＭＳＤＯＳを走らせるパーソ
ナルコンピュータがこれまで一般的に不適正であったよ
り時間臨界的（ｔｉｍｅ−ｃｒｉｔｉｃａｌ）な、結果
駆動される（ｅｖｅｎｔ−ｄｒｉｖｅｎ）或いはリアル
タイムな処理に拡張できることにある。

【００１６】本発明のさらなる目的は、それが制御する
応用プログラムが実行の流れを変更し得る動的なスケジ
ューリングを許容する制御プログラムを提供することに
ある。

【００１７】本発明のもう一つの目的は、従属的な応用
プログラムが走らされる改善された程度の制御及び特性
のオペレーティング環境を提供することにある。

【００１８】本発明のもう一つの目的は、モジュールに
より調整した方法において容易に拡張可能な制御プログ
ラムを提供することにある。換言すれば、制御プログラ
ム環境は、他のソフトウェアプログラム（システム及び
（又は）応用レベル）が臨界的な素子或いは「フック」
（ｈｏｏｋｓ）に十分なアクセスするような「開かれ
た」構成である。その結果は、ソフトウェアの強化が現
存するシステムに対する変更を殆ど伴うことなくその将
来に付加されるということである。

【００１９】本発明のさらなる目的は、ＭＳＤＯＳ或い
は何らかのＭＳＤＯＳのコンパチブル応用プログラムと
競合することなくコンピュータを作動させることにあ
る。

【００２０】本発明のさらなる目的は、従属の応用プロ
グラムの効果的なオペレーションに対する新しい障害を
伴うことなく、非常にコンパクトなそして効果的な制御
プロトコルを使用することによりこれらのプログラムに
とって役に立つランダムアクセスメモリのスペースをさ
らに最小化しながら、上述の目的を達成することにあ
る。

【００２１】本発明のさらにもう一つの目的は、全バッ
ファを含む常駐ソフトウェアが８０８６のアッセンブリ
語で全体的に書かれ、そして最小量のメモリスペース
（例えば、６４０キロバイトのスペースのうち約２４キ
ロバイト）のみを要求する新しいソフトウェア環境を提
供することにある。さらに、本発明のソフトウェアは、
より上位の３８４キロバイトのメモリスペース内にロー
ドされ得る。これにより、さらに、６４０キロバイトの
スペースにおける全体的なメモリ要求を減少させる。

【００２２】発明の要約 本発明は、新規な制御プログラムからなり、この制御プ
ログラムは、プログラム間連絡及び動的なスケジューリ
ングを含むように、ＭＳＤＯＳオペレーティングシステ
ムの能力を効果的に拡張する。それは、ホルダー及びカ
ーネルの二つのサブプログラムからなり、これらサブプ
ログラムは、システムの初期化中に常駐のプログラムと
して備えられ、そして従って、そのような拡張のための
ＭＳＤＯＳ規則に適合するＭＳＤＯＳオペレーティング
システムに対する拡張となる。図１は、ＭＳＤＯＳオペ
レーティングシステム及び拡張されたオペレーティング
システム下にて走る応用プログラムに対する制御プログ
ラムの関係を示す図式的な表示である。

【００２３】ホルダープログラムは、郵便局に類似す
る。それは、「郵便物」、即ちプログラム間連絡を受
け、記憶しそして配達するという手順を制御する。応用
プログラムは、郵便物を送り、それらにアドレス指定さ
れている何らかの郵便物があるかどうかを決定し、或い
は郵便物を受け取るために、ホルダープログラムを呼び
出す。ホルダープログラムは、同一の構成をもちそして
同様の制御プロトコルを使用する二つのバッファメモリ
（メイルルーム）を含む。しかしながら、それらは異な
る結果を実現する。パブリックバッファはプログラム間
連絡を支持するメイルルームである。応用プログラムＡ
は、ホルダープログラムを呼び出して、応用プログラム
Ｂに対しメッセージを送る。応用プログラムＡが終わる
とき、そしてもしも応用プログラムＢがある未来の時間
にて実行されるならば、応用プログラムＢが、ホルダー
プログラムを呼び出して、応用プログラムＡにより送ら
れるメッセージを受け取る。意図された名宛人は、デー
タの形の変数、即ちパブリックバッファ内に記憶される
各メッセージのヘッディングを形成する１６ビットの非
符号の整数により表され、そしてかくして６５，５３６
の異なるアドレスを提供する。ここまでは、応用プログ
ラムＢがいままでにそのメッセージを受けるための機会
を得るということを応用プログラムＡが保証する手段は
ない。これは、もしも両プログラムが連続的に呼び出さ
れるということを保証する予め規定された原本の一部で
あるならば、問題ではない。しかしながら、応用プログ
ラムＡに応用プログラムＢの実行をさせることは非常に
望ましく、これにより、原本の妨害なしに相互に作用し
合う一組の応用プログラムにより複雑なタスクを達成で
きる。動的なスケジューリングとして知られているこの
能力は、他のホルダーメイルルーム、即ち、特別な種類
の郵便物のために確保される専用バッファにより支持さ
れる。その専用バッファは、複雑なタスクを達成するた
めに要求される実行の流れを含む。応用プログラムは専
用バッファに対し一つ或いはそれ以上のメッセージを送
ることができ、各メッセージは、事実上、マスタープラ
ンを創作するために実行されるべきプログラムを確認す
る。応用プログラムが呼び出されてマスタープランにお
けるその役割を果たすとき、それは、一部であるマスタ
ープランを知るために連絡をとり、そしてまたそのプラ
ンを変更し得る。そのような変更は、そのプランに対す
る新しい応用プログラムを付加すること、そのプランか
ら応用プログラムを削除することそして実行の順序を変
えることを含む。それはまた、そのプランに対しそれ自
身のプログラム名を付加することによりそれ自身の将来
の再実行を引き起こす。

【００２４】上述した応用プログラムは、差し迫った発
明の部分ではないが、それらは、この能力を利用するた
めに差し迫った発明のプログラム間連絡プロトコルに適
合するように書かれねばならないということが理解され
る。しかしながら、上述のことは、例えそれがそう書か
れていなくても、マスタープランの実行の流れにおいて
何らかのＭＳＤＯＳのコンパチブルプログラムを含むと
いう可能性を除外しない。

【００２５】差し迫った発明の制御プログラムを呼び出
し得る少なくとも一つの応用プログラムがなければなら
ない。パーソナルコンピュータの究極の制御が典型的に
は人間の操作者と共に常駐するから、典型的には、これ
は、ユーザ指令に応答するメニューイングプログラムで
ある。商業プログラム、即ちマイクロソフトコーポレー
ション（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏ
ｎ）により販売されるウインドーズ（Ｗｉｎｄｏｗｓ）
及びクオーターデックコーポレション（Ｑｕａｒｔｅｒ
ｄｅｃｋ Ｃｏｒｐｏｒａｔｉｏｎ）により販売される
デスクビュー（Ｄｅｓｋｖｉｅｗ）は、ユーザが選択し
得るタスクのメニューを提供するメニューイングプログ
ラムの例である。ユーザ入力は、それぞれのプログラム
或いは各プログラムを実行させるメニューイングプログ
ラムにより解釈される。術語「メニュープログラム」
は、キーボード或いはマウスのような操作者入力装置を
これに限定されることなく含む何らかのコンピュータ入
力に応答して差し迫った発明の制御プログラムを呼び出
す何らかのプログラムを意味するように使用されるであ
ろう。メニュープログラムは、二つのステップにおいて
制御プログラムと連絡をとる。第１に、メニュープログ
ラムはホルダープログラムを呼び出して要求される実行
の流れを専用バッファ内に記憶する。最も簡単な場合に
は、これは、実行されるべき簡単な応用プログラムの名
であるが、専用バッファのスロット容量によってのみ制
限される一続きの３２ほどのプログラムである。メニュ
ープログラムはまた、ホルダープログラムのパブリック
バッファを使用してメッセージをある応用プログラムに
送る。これらの応用プログラムは、それらが実行すると
きそれらの行動を修正するための実行の流れを含む。ま
た、各応用は、パブリック及び専用のホルダーバッファ
を修正して応用の制御に従う動作の進路を動的に変更す
る能力を有する。メニュープログラムは、カーネルによ
り生み出される子供の処理のような実際にまさにもう一
つの応用である。その環境を利用するどのような応用
も、同じような機能を履行し得る。

【００２６】ホルダープログラムとの相互作用は、単
に、実行のためのマスタープランを設立するだけである
ことを思い起こせ。現実の実行は、メニュープログラム
が制御をカーネルプログラムに通すときに開始される。
カーネルプログラムは、ＭＳＤＯＳに対するもう一つの
応用プログラムとして現れるが、それは、それが制御す
る応用プログラムに対する拡張されたオペレーティング
システムの一部として現れる。カーネルプログラムはデ
ィスパッチャーとして機能する。それが制御を得ると
き、それは、専用バッファを読んで呼び出すべき次のプ
ログラムを決定する。カーネルプログラムが専用バッフ
ァにおいて入力を見出すときはいつでも、それは、その
入力を動かしそしてそれぞれのプログラムを生み出す。
このように生み出されるプログラムはカーネルプログラ
ムに対し従属的であり、このカーネルプログラムにおい
て、生み出されるプログラムは、カーネルの環境を受け
継ぎ、そしてそれが終わるとき制御をカーネルプログラ
ムに戻す親のカーネルプログラムの子供である。制御を
回復する同時に、この動作が、実行の流れが完了されて
しまうまで、即ち、制御がメニュープログラムに逆に渡
される時間にて専用バッファが空になるまで、繰り返さ
れる。実行の流れの一部である応用プログラムは実行の
流れを修正し得るのに反して、カーネルプログラムは修
正を伴うことなく実行の流れに従うように強いられる。

【００２７】好ましくは、全体の処理が、専用バッファ
の空を見出すとき、メニュープログラムを呼び出すカー
ネルプログラムを最初に呼び出すことにより開始される
べきである。カーネルプログラムは、今、メニュープロ
グラムの「親」であるから、制御は、メニュープログラ
ムが正常に終わるときはいつでもカーネルプログラムに
渡される。カーネルプログラムが、専用バッファ内に含
まれるそのメッセージの全てに応答することにより実行
の流れを完了したとき、デフォルトプログラム（典型的
にはメニュープログラム）が生み出されて再び制御プロ
グラムを含むであろう新しい事象を待つ。

【００２８】要約すれば、メニュー応用プログラムは、
差し迫った発明の制御プログラムを使用して多数の他の
応用プログラムを、規定された未だ十分に書かれていな
い方法において動作させ得る。この能力はフットボール
チームの類推を考慮することによりよりよく理解され得
る。クォーターバックは、メニュー応用プログラムのよ
うに、与えられるプレイを成就するための詳細な指令を
彼のチーム（他の応用プログラム）の残りに連絡すると
いう役割をもつ。スクラムのラインにおける集合と呼び
出しが、各プレーヤが指定された役割をもつマスタープ
ランを、クォーターバックに連絡させる。あるプレーヤ
はプレイオプションとして知られている特別の指示を与
えられる。ボールがつかまれるとき、各プレーヤは、他
のプレーヤの動作に応答して、要求されるように、プラ
ン作成翻案（ｐｌａｎ ｍａｋｉｎｇ ａｄａｐｔａｔ
ｉｏｎｓ）の彼の一部を実行する（その類推は、プログ
ラムの行動を条件付きで修正する応用プログラムの動的
なオペレーティング環境に対向チームが類似であると考
えるようにさらに拡張される。）。フットボールチーム
は、各プレーヤが連絡をとりそして同時に影響し合う並
列モデルである。ＭＳＤＯＳ環境においては、一つのプ
ログラムのみが、どのような瞬間にても能動的であるこ
とができ、そしてそのプログラムは、それに先行し或い
は従うプログラムを本来的に意識していない。動的なス
ケジューリング及び制御プログラムのプログラム間連絡
能力は、一組の応用プログラムに、この意識を得させそ
してそれらがあたかも多重タスクと関連する相対的に高
いオーバーヘッドを伴うことなく同時に作動するかのよ
うに行動させる。その結果は非常にコンパクトなプログ
ラムであり、このプログラムはランダムアクセスメモリ
内に全体的に常駐して速い応答を達成することができそ
して応用プログラムに対する十分なランダムアクセスメ
モリスペースをまだ残す。

【００２９】制御プログラム及び連絡ドライバの双方の
ために要求されるメモリは次のようである。 ホルダーコード − ４．６キロバイト 専用バッファ − １ パブリックバッファ − １ カーネルコード − ７．４ コム（ＣＯＭ）ドライバコード− ２ コム（ＣＯＭ）バッファ − １６ ４キロバイト×４（４キロバイトのインバッファ（ＩＮ
ｂｕｆｆｅｒ）及び４キロバイトのアウトバッファ
（ＯＵＴ ｂｕｆｆｅｒ）を各々伴う２ポート） 全体のメモリ − ３２キロバイト

【００３０】本発明の制御プログラム環境においては、
カーネルは、装置ドライバを介して、連絡ポートの双方
を開く。結果として生ずるファイルハンドルは従ってホ
ルダーＴＳＲパブリックバッファ内に置かれる。それか
ら、どのような応用も、ホルダーＴＳＲバッファ内のフ
ァイルハンドルを介してＲＳ−２３２ポートをアクセス
する。その応用のみが読みそしてＲＳ−２３２ポートに
書く。カーネルプログラムのみがそのポートを開き或い
は閉じるから、色々な応用がＲＳ−２３２ハードウェア
を共有し得る。例えば、一つの応用がデータ転送を開始
させそして継続すべきもう一つの応用を生み出し得る。
装置ドライバ内のバッファは、１９２００のボーレート
にてデータの価値を典型的には２秒間保持するに十分な
程に大きいから、一つの応用がどのようなデータをも失
うことなくもう一つを生み出すのに十分な時間がある。

【００３１】差し迫った発明のホルダープログラムはＴ
ＳＲプログラムである。それは、応用或いは制御プログ
ラムカーネルにより明確に発生されるときにのみ、それ
が「ウェークアップ」するように、それ自身、非使用の
割り込みに所属する。この方法において、ホルダーのオ
ペレーションは、ユーザにとって完全に平明である。さ
らに、制御プログラムの技術的な詳細のすべてがユーザ
にとって完全に平明だる。ユーザに関する限りは、本発
明の制御プログラムは、実際にそれが多くの舞台裏型の
オペレーションであるとき、もう一つの簡単なメニュー
イングプログラム以上のなにものでもない。

【００３２】本発明の制御プログラムは、完全にＭＳＤ
ＯＳとコンパチブルである。それは、ＭＳＤＯＳと共に
稼働し、取り扱うべきＭＳＤＯＳに対するどのような認
識し得ないコマンドをも通し、そのＴＳＲに対する非使
用の割り込みを取り、そしてマイクロソフトのガイドラ
インに厳格に従い書かれた装置ドライバを提供する。さ
らに、制御プログラム環境は、ＭＳＤＯＳの機能性を二
重にするように試みることはしない。その代わりに、そ
れは、ＭＳＤＯＳによっては既に提供されないこれらの
機能を提供することによりＭＳＤＯＳを強化することを
試みる。さらに、有効なプログラムスペースからメモリ
の大きな量を取り上げることなくこれをすることは可能
である。

【００３３】ボーランドターボアッセンブラ（Ｂｏｒｌ
ａｎｄ Ｔｕｒｂｏ Ａｓｓｅｍｂｌｅｒ）の言語にて
書かれているソースコードは、付録Ａに含まれている。

【００３４】

【実施例】

本発明の詳細な記述 パーソナルコンピュータの初期化は、ランダムアクセス
メモリにおけるＭＳＤＯＳの常駐部分の備えつけを含
む。これが完全であるとき、ホルダープログラム（ＨＯ
ＬＤＥＲ ＰＲＯＧＲＡＭ）もまた、ＴＳＲプログラム
として備え付けされる。ホルダープログラムの開始アド
レスは割り込みべクトルテーブルにおけるアドレス６３
ｈにて記憶される。これが、ホルダープログラムがプロ
グラム可能な割り込み６３ｈを実行することにより呼び
出されることを許容する。最終的には、カーネルプログ
ラム（ＫＥＲＮＥＲ ＰＲＯＧＲＡＭ）が備えつけられ
る。それは、応用プログラムを呼び出すために使用され
る標準のＭＳＤＯＳの手続を使用して呼び出されるの
で、それは割り込べクトルを要求しない。制御プログラ
ムは、今、応用プログラムに対する制御及び連絡サービ
スを提供するために常駐しそして準備される。

【００３５】カーネルは、管理プログラムであって、こ
れは、メニュー及びホルダーのプログラムと協力して作
動し、オペレーティング環境の継続的な制御の間、ユー
ザコマンドに応答して一プログラム或いは一連のプログ
ラムを初期化する。オペレーティング環境の制御を仮定
することは応用プログラムに対しては可能であるが、本
発明の意向とは反対に、カーネルは制御を放棄しない。
理解の助けとして、その応用プログラムは、パブリック
バッファ内に置かれるオペレーティング環境に対する何
らかの拡張に加え、親のＭＳＤＯＳオペレーティング環
境を受け継ぐ「親」のカーネルプログラムの「子供」と
して考慮され得る。図２は、カーネルプログラムのオペ
レーションのブロック図を示す。そのカーネルは、ＭＳ
ＤＯＳコマンドラインからの唯一の応用実行である。制
御プログラム下で実行されるどのような応用も、子供の
処理としてカーネルにより開始される。これはメニュー
プログラムを含む。ホルダーは、ＤＯＳコマンドライン
から開始され得るが、ＴＳＲとして、通常、自動実行バ
ッチファイル（ＡＵＴＯ ＥＸＥＣ．ＢＡＴ ｆｉｌ
ｅ）からのシステム始動にて実行される。ホルダーは、
本発明の制御プログラムを実行する前に備えつけられな
ければならない。カーネルプログラムはエントリー点１
０にてエンターされ、メニュープログラムにより或いは
ＭＳＤＯＳコマンドレベルから直接に呼び出される。ス
テップ１２にて、ステータスが、これがプログラムが呼
び出された最初であるかどうかを決定するために調べら
れる。もしもそうであるならば、ステップ１４が実行さ
れる。連絡装置ドライバを開くために、私のプログラム
は、標準の「ファイルオープン」要求を簡単にＤＯＳに
し、このＤＯＳは、カーネルがパブリックホルダーバッ
ファ内に記憶するというファイル手段に戻る。これは各
振る舞いに対してなされる。このドライバは、ＭＳＤＯ
ＳドライバＣＯＭ１及びＣＯＭ２のように殆ど作動し、
本質的な連絡パラメータを確立する。ＭＳＤＯＳは、ホ
ストパーソナルコンピュータにおける存在であるように
見出される各ポートのためのファイルハンドルに復帰す
る。ファイルハンドル（ｆｉｌｅ ｈａｎｄｌｅ）は、
ファイル或いは連絡ポートと名付けられる１６ビットの
整数である。それは、要求がされてファイル或いは連絡
ポートを開くときにＭＳＤＯＳにより提供され、そして
ファイルサービスのためのＭＳＤＯＳに対する後続要求
がファイルハンドルを含まなければならない。ブロック
１４により示されているように、カーネルプログラム
は、ホルダープログラムと関連するパブリックバッファ
における独特の指定された識別子と共に各ファイルハン
ドルを記憶する。連絡ファイルハンドルが一定に留ま
り、そしてカーネルプログラムにより生み出されるすべ
ての応用プログラムに対しアクセス可能であるから、多
重応用は、今、共通のファイルハンドルを使用可能とな
り、かくして与えられた連絡ポートに対しアクセスを共
有する。これは、ＭＳＤＯＳが非常に多くの制御を引き
渡されてこれにより応用プログラムのためのより一層有
用な全体的なオペレーティング環境を提供するようなこ
れらの例において、オペレーティングシステムに、制御
を回復させ得る差し迫った発明の一般的な能力を例証す
る。

【００３６】もしもカーネルプログラムが予め呼び出さ
れたならば、ブランチ１３が取られて、実行がブロック
２０により表されるオペレーションに進む。もしもカー
ネルプログラムがＭＳＤＯＳコマンドレベルから呼び出
されそして新しいデフォルト応用プログラムの名がコマ
ンドラインオプションとして入力されたならば、この状
態が決定ブロック１６にて検出され、そしてブロック１
８のオペレーションが新しいプログラム名を獲得しそし
てメニューの固有のデフォルト応用プログラム名を上書
きする。もしも上記状態が起こらなかったならば、ブラ
ンチ１３が取られそして実行がブロック２０のオペレー
ションに直接進む。ここで、ホルダープログラムが、専
用バッファからデータを得るための要求コードと共に、
割り込み６３ｈを介し呼び出される。ホルダープログラ
ムは、例えあるとしても、関連の識別子に沿って実行さ
れるべき次のプログラム或いはコマンドの本質（ｉｄｅ
ｎｔｉｆｙ）に戻る。識別子は、それらが実行されるべ
き動作の型の分類を提供するように、予め定義されるこ
とが思い起こされるべきである。動作項目が復帰されな
いならば、制御が、デフォルト応用プログラムを生み出
させるブロック２４への移行する。ブロック１８のオペ
レーションの実行に起因してデフォルト名が変化されな
い限り、プログラムメニューが生み出される。

【００３７】もしも動作項目が復帰されるならば、ブロ
ック２６において、動作項目と関連する識別子の値がブ
ロック２０のオペレーションにて回復したかどうかの試
験がなされる。もしもそれが、動作項目が応用プログラ
ムの名であることを表すならば、そのときには、ブロッ
ク２８のオペレーションがその応用プログラムを「子
供」の処理としてＭＳＤＯＳの呼び出しを介し生み出
す。もしも識別子が２という値をもちそして動作項目が
テーブル１の内部カーネルコマンドの一つとして認識さ
れるならば、そのときには、ステップ３４が内部コマン
ド及びブランチをブロック２０のオペレーションに戻
す。さもなければ、そのコマンドはＭＳＤＯＳであると
仮定され、そしてそのコマンドが実行のためのＭＳＤＯ
Ｓに渡される。

【００３８】 テーブル １ カーネルプログラム内部コマンド コマンド 意味 ホーム（ｈｏｍｅ） 制御プログラムのホームディレクトリに戻る リセット（ｒｅｓｅｔ） すべてのホルダーＴＳＲバッファをクリアする ヘルプ（ｈｅｌｐ） すべてのコマンドリストを書く（ｐｒｉｎｔ） シェル（ｓｈｅｌｌ） 制御プログラムコマンドモードを入力する ｄｏｓ 制御プログラムコマンドモードからＭＳＤＯＳ へのシェル エグジット（ｅｘｉｔ） 制御コマンドモードを出て子供の応用に戻る（ 或いはもしもその子供の応用がコマンドを出す ならば、カーネルはＭＳＤＯＳに出る）。

【００３９】図５のソフトウェアフローチャートは、差
し迫った発明により与えられるプログラム間連絡及び相
互作用能力を使用するように設計された何らかの応用プ
ログラム内にてプログラムの流れを例証する。エントリ
点５０は、図２におけるブロック２４或いは２８のいず
れかのオペレーションから生み出される何らかのプログ
ラムの開始である。ステップ５２及び５４は、もう一つ
の応用プログラムによりそこに置かれるパブリックバッ
ファからデータを得るための要求コードと共に、割り込
み６３ｈを介して、ホルダープログラムを呼び出す。ブ
ロック５８により示されるように、その応用は、その意
図された機能を実行し、そしてブロック６０において試
験が実行されて差し迫った応用プログラムがもう一つの
関連応用プログラムの実行を要求すべきかどうかを決定
する。もしもそうならば、オペレーションブロックステ
ップ６４は、実行されるべき応用プログラムの名が、そ
の識別子と共に、「プットデータ（ｐｕｔ ｄａｔ
ａ）」要求コードを使用して、割り込み６３ｈを介し、
専用バッファ内に置かれる。同様の方法において、図５
においてブロック６６、６８及び７２により表されるオ
ペレーション及び試験の実行が、パブリックバッファ内
にデータを置くためにオプションを提供し、かくして、
他の応用プログラムにとって有用となる。ブロック７４
は、通常のプログラムの終了が、カーネルプログラムを
点Ａ（ブロック１０、図２）にて再入力させる動作のた
めに確保されたいずれかのＭＳＤＯＳ機能を呼び出すこ
とにより実行されるということを示している。要約すれ
ば、オペレーション６０及び６４が動的スケジューリン
グを提供しそして各ステップ６６、６８及び７２が出力
データを他の応用プログラムに提供する一方、オペレー
ション５２及び５４により表される各オペレーションの
実行は他の応用プログラムからの入力データを提供す
る。代わりとして、カーネルプログラムが、カーネル或
いはホルダーのプログラムを意識していない応用を生み
出し得る。この場合、各ブロック５８及び７４のオペレ
ーションのみが実行される。

【００４０】図８にて示される次の例は、これらのプロ
グラムにより与えられる変現自在の例証である。細い実
線は各バッファへ及び同各バッファからの連絡を表して
いるが、太い破線はプログラムの実行の流れを表してい
る。カーネルプログラムは初期的にはＭＳＤＯＳのコマ
ンドレベルから呼び出される。すべてのホルダーバッフ
ァは初期的には空であるから、デフォルト応用プログラ
ムメニューが生み出される。ユーザは実行されるべきメ
ニューオプションを選択し、このメニューオプション
は、プログラムＡがユーザの指定位置、プログラムＢ、
Ｃ或いはＤからデータを集めることを要求してそのデー
タを条件付きで処理し、そしてプログラムＥを要求し
て、介在プログラムが走ったとき、そのデータをまき散
らす。メニュープログラムはプログラムＡの識別子を使
用してメッセージをパブリックバッファを介してプログ
ラムＡに急送し、ソースデータを見い出す場所をプログ
ラムＡに告げる。そのメニュープログラムはまた、専用
バッファ内に動作項目を置き、プログラムＡを生み出す
ように向ける。そのメニュープログラムは終了し、カー
ネルプログラムに制御を戻し、メニュープログラムから
動作項目を見い出すと、応用プログラムＡを生み出す。
プログラムＡはメニュープログラムからメッセージを得
て、データを集め、そして受け取られたデータが各プロ
グラムＢ及びＤによる処理を要求するがプログラムＣに
よるのではないことを決定し、カーネルに向く専用バッ
ファ内に動作項目を置かさせて、各プログラムＢ、Ｄ及
びＥをその順序にて生み出す。次のプログラムＡはメッ
セージを各プログラムＢ及びＤに急送して、それらに各
データを見出す場所を告げそして終了し、制御をカーネ
ルプログラムに戻す。同じような方法において、各プロ
グラムＢ、Ｄ及びＥは、要求されるように、メッセージ
を進める各プログラムと共に、パブリックバッファを介
して、生み出される。付加的な応用プログラムは、示さ
れてはいないが、スケジュールに動的に付加されて、エ
ラー報告或いはエラー復活のような例外処理に便宜を図
る。プログラムＥが終了すると、カーネルプログラム
が、専用バッファにおける動作項目を見出さないとき、
メニュープログラムを再び生み出して、制御をユーザに
戻し、もう一つのメニュー選択を実行する。

【００４１】図５の各ブロック５４及び７２により示さ
れる応用プログラムとホルダープログラムとの間の連絡
は、標準的なＭＳＤＯＳ機能の呼び出し手続を使用す
る。色々な中央処理演算装置のレジスタは、実行される
べき機能に応じたその応用によりデータと共にロードさ
れる。そのとき、その応用はプログラムされた割り込み
６３ｈを実行してホルダープログラムを呼び出す。ホル
ダープログラムは、その要求された機能を実行し、色々
な中央演算処理装置のレジスタを、要求された情報と共
にロードしそしてそれから制御を応用プログラムに戻
す。要求コードの指定された値にてのみ異なる共通のセ
ットの機能は、パブリック及び専用の両バッファのため
のサービスを提供する。これらは、 − ゲットブロック（ｇｅｔｂｌｏｃｋ）：指定された
識別子に応じて、一区画のデータを得る。 − ゲットネクスト（ｇｅｔｎｅｘｔ）：最新の指定さ
れた識別子に応じて、次の一区画のデータを得る。 − プットブロック（ｐｕｔｂｌｏｃｋ）：一区画のデ
ータをその識別子と共にホルダースロット内に置く。 − クリアブロック（ｃｌｅａｒｂｌｏｃｋ）：最新の
回復されたブロックのデータをクリアする。一区画のデ
ータを得るための要求は非破壊的であり、従って、どの
ような多数の処理も、必要に応じ、それにアクセスでき
る。 − ステータス（ｓｔａｔｕｓ）：最新のオペレーショ
ンのステータスを得る。 − 署名（ｓｉｇｎａｔｕｒｅ）：（開始ルーチンに備
えられているならば）ＨＯＤＥＲ．ＥＸＥプログラムの
署名を得る。この呼び出しは、ＨＯＤＥＲ．ＥＸＥ Ｔ
ＳＲ及びその改定レベルの両存在を設立するために使用
される。この呼び出しは、開始上の中央プログラムのカ
ーネルによりなされる。

【００４２】これらの機能の詳細な説明は次の通りであ
る。パブリックバッファ機能 ：機能 １：ホルダーのバッファから記憶データを得る。 呼び出しに対してセットするためのレジスタ： ＡＨ＝１ ＣＸ＝回復されるべきバイトの数 ＤＬ＝識別子コード（０＝アンタイプド（ｕｎｔｙｐｅ
ｄ）） ＥＳ：ＤＩ＝行き先アドレス その行き先はすべての要求されたデータを保持するに十
分に広範でなければならないということに注目すべきで
ある。 セットオンリターン（ｓｅｔ ｏｎ ｒｅｔｕｒｎ）と
してのレジスタ： ＣＸ＝実際に転送されるバイトの数 もしもＣＸが零に等しければ、バッファは空であってデ
ータは転送されなかったことに注意せよ。この機能を呼
び出す前に、記憶されたデータが現行のプログラムに対
してであることを確かめるためにホルダーの現行のステ
ータスを得ることは賢明である。

【００４３】機能２：ホルダーのバッファ内にデータを
置く 呼び出しのためにセットすべきレジスタ： ＡＨ＝２ ＣＸ＝記憶されるべきバイトの数 ＤＬ＝識別子コード（０＝アンタイプド） ＥＳ：ＳＩ＝ソースアドレス ＣＸにおける値はバッファの大きさ以下でなければなら
ないことに注目せよ。もしもＣＸが零に等しければ、バ
ッファは削除される。 セットオンリターンとしてのレジスタ： ＣＸ＝実際に記憶されるバイトの数 非常にしばしば、そのバッファ内にデータを記憶するた
めの最上の方法は正式のＣ構成と共にあるであろう。ホ
ルダーの見地からは、送られるどのようなデータも一つ
の流れのバイトにすぎず、ホルダーは理解することを試
みない。識別子コードは、もう一つのプログラムのため
に、記憶されたデータが利益があるかどうかを確認する
のに使用されるべきである。

【００４４】機能３：ホルダーの内部バッファをクリア
する 呼び出しのためにセットすべきレジスタ： ＡＨ＝３ セットオンリターンとしてのレジスタ： セットオンリターンなし 呼び出し人が、新しいデータを記憶しようとするか或い
はもう一つのプログラムが記憶されたデータにアクセス
することを欲しないときに、この呼び出しがなされるべ
きである。

【００４５】機能４：ホルダーの現行ステータスを得る 呼び出しのためにセットすべきレジスタ： ＡＨ＝４ このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ： ＢＸ＝（バイトにおける）内部バッファの大きさ ＣＸ＝内部バッファ内に記憶される現行のバイトの数 ＤＨ＝先のオペレーションからのエラーコード ＤＬ＝バッファ内に記憶されるデータの識別子コード これは、要求されるオペレーションが首尾よく履行され
たことを保証するために、各オペレーションの後になさ
れるべきである。

【００４６】機能５：同じ識別子を伴うデータの次のブ
ロックを得る 呼び出しのためにセットすべきレジスタ： ＡＨ＝５ ＣＸ＝回復されるべきバイトの数 ＥＳ：ＤＩ＝行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 セットオンリターンとしてのレジスタ： ＣＸ＝実際に転送されるバイトの数 もしもＣＸが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。

【００４７】機能１００：ホルダーのバージョン及び署
名を得る 呼び出しのためにセットすべきレジスタ： ＡＨ＝５ このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ： ＣＸ＝ＴＳＲ署名（６９９６） ＤＨ＝ＴＳＲの主要なバージョン数 ＤＬ＝ＴＳＲの主要でないバージョン数 例：バージョン１．２−−ＤＨ＝１及びＤＬ＝２ このオペレーションは、ホルダーのベクトルにおけるコ
ードが現実にホルダであることを保証するために呼び出
されるべきである。

【００４８】専用バッファ機能： 機能１０１：ホルダーのバッファから記憶されたデータ
を得る 呼び出しのためにセットすべきレジスタ： ＡＨ＝１０１ ＣＸ＝回復されるべきバイトの数 ＥＳ：ＤＩ＝行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 復セットオンリターンとしてのレジスタ： ＣＸ＝実際に転送されるバイトの数 もしもＣＸが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。
この機能を呼び出す前に、記憶されたデータが現行のプ
ログラムに対してであることを確かめるためにホルダー
の現行のステータスを得ることは賢明である。

【００４９】機能１０２：ホルダーのバッファ内にデー
タを置く 呼び出しのためにセットすべきレジスタ： ＡＨ＝１０２ ＣＸ＝記憶されるべきバイトの数 ＤＬ＝識別子コード（０＝アンタイプド） ＥＳ：ＤＩ＝ソースアドレス ＣＸにおける値はバッファの大きさ以下でなければなら
ないことに注目せよ。もしもＣＸが零に等しければ、バ
ッファは削除される。 セットオンリターンとしてのレジスタ： ＣＸ＝実際に記憶されるバイトの数 非常にしばしば、そのバッファ内にデータを記憶するた
めの最上の方法は正式のＣ構成と共にあるであろう。ホ
ルダーの見地からは、送られるどのようなデータも一つ
の流れのバイトにすぎず、ホルダーは理解することを試
みない。識別子コードは、もう一つのプログラムのため
に、記憶されたデータが利益があるかどうかを確認する
のに使用されるべきである。

【００５０】機能１０３：ホルダーの内部バッファをク
リアする 呼び出しのためにセットすべきレジスタ： ＡＨ＝１０３ セットオンリターンとしてのレジスタ： セットオンリターンなし 呼び出し人が、新しいデータを記憶しようとするか或い
はもう一つのプログラムが記憶されたデータにアクセス
することを欲しないときに、この呼び出しがなされるべ
きである。

【００５１】機能１０４：ホルダーの現行ステータスを
得る 呼び出しのためにセットすべきレジスタ： ＡＨ＝１０４ このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ： ＢＸ＝（バイトにおける）内部バッファの大きさ ＣＸ＝内部バッファ内に記憶される現行のバイトの数 ＤＨ＝先のオペレーションからのエラーコード ＤＬ＝バッファ内に記憶されるデータの識別子コード これは、要求されるオペレーションが首尾よく履行され
たことを保証するために、各オペレーションの後になさ
れるべきである。

【００５２】機能１０５：同じ識別子を伴うデータの次
のブロックを得る 呼び出しのためにセットすべきレジスタ： ＡＨ＝１０５ ＣＸ＝回復されるべきバイトの数 ＥＳ：ＤＩ＝行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 セットオンリターンとしてのレジスタ： ＣＸ＝実際に転送されるバイトの数 もしもＣＸが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。 次のエラーはステータス復帰として報告され得る： １ 価値のないホルダー機能呼び出し ２ より多くのデータに対するバッファ内の空き
がない ３ ホルダーはビジー ２０１ システム割り込みエラー ２０２ 要求される識別子は見出されなかった

【００５３】図９は、ホルダープログラムのプログラム
図を示す。カーネルプログラム或いは応用プログラムの
いずれかが、プログラムされた割り込み６３ｈを実行す
ることにより、ホルダープログラムを呼び出し得る。ブ
ロック１０２にて、試験が、どんな動作が呼び出しプロ
グラムにより要求されつつあるかを決定するために、レ
ジスタＡＨからなされる。もしも要求コードが、決定ブ
ロック１０４により決定されるパブリック機能の一つに
対してならば、そのときには、ブロック１０６及び１０
８により表されるオペレーションが実行される。もしも
要求コードが決定ブロック１１０により決定される専用
機能の一つに対してならば、そのときには、ブロック１
１２及び１１４により呼び出されるオペレーションが実
行される。専用機能は動的スケジューリングを維持する
が、パブリック機能、即ち、パブリックバッファ上で実
行されるオペレーションはプログラム間連絡を維持する
ということを思い起こせ。もしもブロック１１６の試験
が、要求コードが１００に等しいと決定するならば、ブ
ロック１１８のオペレーションはホルダープログラムの
署名及びバージョンを回復するために実行される。もし
も要求コードが無効であるならば、ブロック１２０のオ
ペレーションは無効な要求ステータスを記憶するために
実行される。そのプログラムを通る各パスが、呼び出し
プログラムにより要求される情報を、ホルダーコマンド
機能により指定される中央演算処理装置のレジスタ内に
ロードする。ホルダープログラムは、プログラム１２２
にて割り込み指令からの復帰を実行することにより終了
し、これによって、制御を呼び出しプログラムに戻す。

【００５４】いくつかの特徴がホルダープログラムに合
併されてそれをコンパクトに、能率よくそして万能にす
る。各バッファ、即ち、一キロバイト専用バッファ及び
一キロバイトパブリックバッファに対しては、識別子及
び各スロットのためのブロックサイズを含むスロットテ
ーブルが維持される。そのスロットテーブルは、与えら
れたスロットに対する一つに加え、データの終わりに対
応するバッファアドレスを含む。各スロットテーブルに
対しては、そのホルダープログラムが、現行のスロット
インデックス及び次のスロットインデックスの二つのイ
ンデックスを維持する。スロットテーブル及びそのイン
デックスが次のように初期化される。 スロット ０ １ ２ ３ ・・・ ３１ ０ １０２４ １０２４ １０２４ １０２４ 現行スロット＝０ 次のスロット＝０

【００５５】もしも、例えば、ホルダープログラムがコ
マンドを受けて次のスロットにて２０バイトのデータを
記憶するならば、そのデータはアドレス０乃至１９にて
バッファ内に入力され、次のスロットインデックスがイ
ンレクメントされ、そしてそのスロットテーブルが次の
ように更新される。 スロット ０ １ ２ ３ ・・・ ３１ ０ ２０ １０２４ １０２４ １０２４ 現行スロット＝０ 次のスロット＝１ もしも、例えば、ホルダープログラムが次にコマンドを
受けて次のスロットにて３０バイトのデータを記憶する
ならば、このデータは、次のスロットインデックスの値
により指定されるように、スロットテーブルのスロット
１の内容でアドレス２０にて開始するバッファ内に記憶
される。現行のスロットインデックス及び次のスロット
インデックスの双方がインクレメントされそしてそのス
ロットが次のように更新される。 スロット ０ １ ２ ３ ・・・ ３１ ０ ２０ ５０ １０２４ １０２４ 現行スロット＝１ 次のスロット＝２

【００５６】もしもホルダープログラムがコマンドを受
けて現行のスロットにおけるデータを削除するならば、
次のスロットから現行のスロットを引いた内容が現行ス
ロット内に置かれ、そしてバッファ内のデータがこの変
化を反映するように移される。この処理過程は、最初の
非使用スロットが出くわされるまで、即ち、スロットテ
ーブル入力の内容が１０２４に等しくなるまで、各連続
のスロットに対して繰り返される。「ガーベージコレク
ション」としての技術にて知られているこのバッファ管
理の方法は、さもなけらば、スロットインデックス及び
スロットテーブル入力を使用して、メッセージの始め及
び終わりをホルダープログラムに容易に確認させる一
方、メッセージデータの大きさに適合するようにスロッ
トの境界を連続的に調整することを許容する。

【００５７】これは、大きな仮想メールボックス容量を
提供するように使用される相対的に小さなバッファを許
容する。どのようなスロットも、全体の一キロバイトバ
ッファスペースのどのような部分を使用してもよく、そ
してどのようなスロットの内容も、現実のデータ、ラン
ダムアクセスメモリにおけるどこか他の所でデータの位
置を確認するべクトル、或いはディスクメモリ内のデー
タの位置を確認するファイルハンドルのいずれかであっ
てもよい。好ましくは、これらの約束が、与えられたス
ロットの内容に適用されるような識別子が解釈するため
に使用される。ディスク上にデータを記憶することは、
より一層価値あるランダムアクセスメモリスペースを維
持する一方、スロット内に、直接、データを記憶するこ
とは、最も速い応答を提供する。かくして、公共のメイ
ルボックス設備、即ち応用プログラムの各ユーザが、共
同のパブリックバッファスペース上に置かれた要求を伴
う実行に対する必要性を賢明に釣り合わせ得るので、全
体のバッファスペースは相対的に小さくし得る。識別子
は、ホルダープログラムを、それを速くコンパクトに使
用して、簡単化するメールボックスアドレスの形を提供
する。ホルダープログラムのオペレーションは、非常に
制限されそして簡単なセットの規則を使用して情報を記
憶しそして回復させ得るファイル係に類似している。ホ
ルダープログラムはまた、パブリック及び専用の各バッ
ファの双方に対する同じようなバッファ構成及び制御戦
略を使用して、コンパクトに作られ、これにより、共有
されるべきプログラムコードの部分を許容する。

【００５８】図１０及び図１１〜図１５は、図９におけ
るブロック１０４及び１０６により表されるオペレーシ
ョンのより詳細なブロック図を示す。図１０のフローチ
ャートにより表されるソフトウェアは、レジスタＤＬに
渡される識別子の値を試験することにより要求される指
定された機能を解釈し、そしてそれから、パブ（Ｐｕ
ｂ）Ａ〜パブＥとして明示されているように、ブロック
１４２−１５０により表されるそれぞれの入力点に分岐
していく。図１１〜図１５の各々はこれらの入力点の一
つに対応する。パブリックバッファＡからのデータを得
る要求が受け取られたならば、ブロック１６０（図１
１）により表されるオペレーションが実行され、パブリ
ックスロットテーブルを連続的に探索し、例えあるとし
ても、マッチング識別子の最初の発生を見出すにすぎな
い。もしもなにも見出されなければ、制御がブロック１
６４に進められてエラーステータスを記憶する。もしも
識別子が見出されれば、ブロック１６６のオペレーショ
ンが実行され、スロットテーブルをアクセスしてパブリ
ックバッファ内のスロットデータの位置を見出す。それ
から、スロットデータが、パブリックバッファ内のその
スロットの位置から、レジスタＥＳ及びＤＩを介して呼
び出しプログラムにより指定された行き先の位置に移さ
れる。ブロック１６８のオペレーションが実行されると
き、それはデータの首尾よき転送のステータスを記憶す
る。パブリックバッファ内にデータを記憶する要求が受
け取られたならば、オペレーション１８０が実行され、
パブリックバッファ内の自由なスペースを、記憶される
ように要求されるバイトの数を含むレジスタＣＸの内容
と比較する（図１２）。もしも満足すべき十分な自由ス
ペースがあるならば、要求ステップ１８２が実行され、
新しい入力を、識別子及びスロットの大きさ、即ち記憶
されるべきバイトの数からなるスロットテーブルにアペ
ンドする。ブロック１８４及び１８６により呼び出され
るオペレーションはＤＳ及びＳＩレジスタの内容を使用
して、記憶されるべきデータのソースを突き止め、そし
てスロットテーブルの内容を使用してパブリックバッフ
ァ内のデータの行き先を突き止めて、その転送を実行す
る。スロットテーブル及びパブリックバッファは、今、
必要な情報を含み、もう一つの応用プログラムに、先に
述べた獲得データ機能を使用して、記憶されたデータを
回復させる。ブロック１８８により示されるオペレーシ
ョンの実行はデータの首尾よき転送のステータスを記憶
する。

【００５９】図１３はホルダーの「ガーベージコレクシ
ョン」の機能を示す。これは、小さなバッファにより非
常に有効な使用を提供する。ガーベージコレクション
は、必要に応じて、外部の仲介なしに起こり、バッファ
スペースの増大を阻止する。パブリックバッファから現
行のスロットをクリアするための要求が受け取られたな
らば、オペレーション２００（図１３）が実行され、現
行のスロットを越えて次のスロットの内容を複写する。
オペレーション２０２は、スロットテーブルを更新し、
次のスロットデータのパブリックバッファ内の新しい位
置に反映させる。次に、ブロック２００及び２０２によ
り呼び出されるオペレーションは、決定ブロック２０４
にてなされる試験が次のスロットが空であると決定する
まで、繰り返される。もし決定されれば、オペレーショ
ン２０８がスロットテーブル内に入力されるパブリック
バッファの新しい状態に終わる一方、オペレーション２
０６が使用されていないバッファスペースをクリアす
る。この点において、パブリックバッファが、データが
現行のスロットに最後に記憶される直前に実行した状態
に復帰されている。ブロック２１０にて示されるオペレ
ーションの実行は首尾のよいクリアオペレーションのス
テータスを記憶する。

【００６０】もしも「獲得に対する要求」のステータス
が受け取られたならば、ブロック２２０（図１４）のオ
ペレーションが実行され、オペレーション１６８、１８
８、２１０或いは２３６の実行中に記憶されたステータ
スを回復させ、そしてそれを応用プログラムに戻す。ま
た、パブリックバッファの大きさ、パブリックバッファ
に実際に記憶されているバイトの数及び現行のスロット
に記憶されているデータの識別子が復帰される。パブリ
ックバッファの次のスロットからの同じような形、即ち
同じような識別子をもつ「獲得データに対する要求」が
受け取られたならば、プログラム２３０のオペレーショ
ンが実行され、バッファスロットテーブルを連続的に探
索せしめて、もしあれば、マッチング識別子の次の発生
を見出す。もしもブロック２３２にて確認される試験に
より決定されるとき、なにも見出されなければ、ブロッ
ク２３３のオペレーションが実行されてエラーステータ
スを記憶する。さもなければ、スロットテーブルがアク
セスされてパブリックバッファ内のスロットデータの位
置を見出す（ブロック２３４）。それから、スロットデ
ータが、パブリックバッファ内のそのスロット位置か
ら、呼び出しプログラムにより指定される行き先位置
に、レジスタＥＳ及びＤＩを介して移される。ブロック
２３６のオペレーションはデータの首尾のよい転送を記
憶する。

【００６１】専用バッファ機能はパブリックバッファ機
能に十分に対応し、オペレーションが専用バッファ上で
実行されるということのみにおいて異なる。より好まし
いカーネルプログラムの要求を最小限に満足させるより
少ない可能性の専用バッファ構成を使用することは可能
であるが、そうすることは好ましくない。それが如何に
簡単であるかにかかわらず、異なる専用バッファ構成が
ホルダープログラムコードの共有を減少させそして、か
くして、その大きさを増加させる。さらに、専用バッフ
ァに対するパブリックバッファ構成の融通性を維持する
ことは有益である。それは、未だ予期されてない新しい
機能を仮定する一方、本発明のソフトウェアに後ろ向き
の互換性を維持させるより先の開いた構成を提供するか
らである。

【００６２】次の議論は、基本的な制御プログラムの変
形無しに付加的な機能性を組み入れるための本発明の代
わりの実施例及び本発明の融通性の例示の双方である。
ＴＳＲプログラム クロン（ＣＨＲＯＮ）はコンピュー
タのリアルタイムクロックの値に関連付けられる動的な
スケジューリングの能力を付加する。クロンプログラム
上の機能は、時間刻印をしたメッセージに対しパブリッ
クバッファを周期的に走査し、指示された時間にて、こ
れらのメッセージを解釈して、専用バッファ内に含まれ
る実行の流れに付加されるべき実行可能なメッセージを
構成する。メニュープログラムを含むどのような応用プ
ログラムも、時間を刻印したメッセージをパブリックバ
ッファ内に置き得る。そのようなメッセージは、指定さ
れた将来の時間にて一度応用プログラムを実行するため
の指令であり得る。代わりとして、メッセージは、指定
された未来時間にて開始する指定された間隔にて、応用
プログラムの実行をＮ回或いは不定回数指示し得る。時
間を刻印したメッセージは、それらの識別子の値により
区別される。図１６はクロンプログラムのフローチャー
トを示す。入力点２５０は、割り込みベクトルテーブル
が、クロンプログラムが正常なタイマー割り込みのため
に意図される割り込みベクトルを遮断するように変更さ
れていることを示している。これは、クロンプログラム
に、呼び出させる、即ち、それが１秒につき１８．２回
毎に、即ち、さもなければ正常なタイマー割り込みが呼
び出されるときに、「ウェークアップ」の呼び出しを得
る。各０．０５秒の間隔にてクロンルーチンを実行する
ことが可能であるが、このことが、利益のないオーバー
ヘッドを処理することを付加する。むしろ、ブロック２
５４により表されるオペレーションは各ウェークアップ
呼び出しを計数し、そして第ｎ番目のウェークアップ呼
び出しに対してのみ制御をブロック２５６に進める。例
えば、もしもｎが１０００に等しければ、制御は５０秒
毎にブロック２５６のオペレーションに進む。すべての
介在ウェークアップ呼び出しに対して、制御は、次の時
間割り込みの取扱者に直接進められる。ブロック２５６
にて、ホルダープログラムが呼び出されて、次のスロッ
トが時間を刻印したメッセージを含むかどうかを決定す
る。もしもそうでなければ、そのときには、ブロック２
６０のオペレーションが、ＣＸレジスタの値を試験する
ことによりパブリックバッファ内により多くのメッセー
ジがあるかどうかを決定する。このレジスタは、もしも
走査されるべきより多くのデータがなければ、零の値で
もって復帰されたであろうことを思い起こせ。この結果
において、制御は次のタイマー割り込みの取扱者に進
む。さもなければ、プログラムはブロック２５６に戻
る。もしクロンメッセージが見出されれば、時間の刻印
が試験されて、今、それがメッセージを実行する時刻が
どうかを決定する。もしもそうでなければ、プログラム
は、オペレーションブロック２６０に対して述べた方法
にて、ブロック２６４を介して、オペレーション２５６
に条件付きで戻る。今、メッセージを実行する時刻であ
ることを決定するとき、制御は、カーネルプログラムの
ための実行可能なメッセージを創作するブロック２６６
に進む。明確には、クロンプログラムにおいて見出され
る応用プログラムの名が専用バッファに付加されて実行
の流れの一部になる。

【００６３】実行メッセージは、クロンメッセージから
抽出される先行データの色々な形を任意に含み得る。も
しも先行データが専用バッファ内で有効に作られるなら
ば、そのときには、どのような応用プログラムも、実行
されている限り、専用バッファを周期的に調べて、クロ
ンプログラムが実行の流れにより高い先行プログラムを
いつ付加したかを検出する。これは、より低い先行プロ
グラムに対しその機会を提供して実行されるべきより高
い先行プログラムを許容することに終わる。

【００６４】専用バッファ機能は、パブリックバッファ
機能に十分に対応し、オペレーションが専用バッファ上
で実行されるということにおいてのみ異なる。より好ま
しいカーネルプログラムの要求を最小限に満たすより少
ない可能性の専用バッファ構成を使用することは可能で
あるが、そうすることは好ましくない。それが如何に簡
単であるかにかかわらず、異なる専用バッファ構成がホ
ルダープログラムコードの共有を減少させそして、かく
して、その大きさを増加させる。さらに、専用バッファ
に対するパブリックバッファ構成の融通性を維持すこと
は有益である。それは、未だ予期されていない新しい機
能を仮定する一方、後ろ向きの互換性を本発明のソフト
ウェアに維持させるより先の開かれた構成を提供するか
らである。

【００６５】この発明は、ここでは、特許法に従い、新
規な原理を適用するために必要とされる情報をその技術
にて熟練した者達に提供し、そして要求されるような特
殊化された構成要素を構成及び使用するためにかなり詳
細に述べられてきた。しかしながら、本発明は明らかに
異なる設備及び装置により成し遂げられること、そして
色々な変形が、設備の詳細及びオペレーション手続の双
方に関して、本発明自体の範囲から逸脱することなく達
成され得る。

【図面の簡単な説明】

【図１】本発明の制御プログラム及びそのＭＳＤＯＳ及
び非常駐応用プログラムに対する関連を合併するオペレ
ーションシステムの構成を示すブロック図である。

【図２】本図として図３及び図４が配列されるとき、本
発明に応じてカーネルプログラムを示すソフトウェアフ
ローチャートである。

【図３】同ソフトウェアフローチャートの前段部であ
る。

【図４】同ソフトウェアフローチャートの後段部であ
る。

【図５】本図して図６及び図７が配列されるとき、本発
明の制御プログラムにより与えられるプログラム間連絡
を利用するために設計された何らかの応用プログラム内
でのプログラムの流れを示すソフトウェアフローチャー
トである。

【図６】同ソフトウェアフローチャートの前段部であ
る。

【図７】同ソフトウェアフローチャートの後段部であ
る。

【図８】本発明の制御プログラムを利用する応用プログ
ラムに与えられる実行順序制御及びプログラム間連絡を
示すフローチャートである。

【図９】本発明の全体の制御プログラムの一部を形成す
るホルダープログラムのソフトウェアフローチャートで
ある。

【図１０】パブリックバッファ内に含まれそして記憶さ
れた識別子を使用して要求される機能の解釈を示す一般
的なソフトウェアフローチャートである。

【図１１】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。

【図１２】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。

【図１３】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。

【図１４】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。

【図１５】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。

【図１６】クロンプログラムを示すソフトウェアフロー
チャートである。

Claims (7)

【特許請求の範囲】
1. 【請求項１】 ＭＳＤＯＳ型ディスクオペレーティング
   システムを記憶するためのランダムアクセスメモリ及び
   リアルタイムの割り込みを発生するためのリアルタイム
   クロックを合併するアイビーエム（ＩＢＭ）コンパチブ
   ル型マイクロコンピュータにおいて、従属の応用プログ
   ラムのオペレティング環境を拡張しそして強化するため
   の制御プログラムであって、 （ａ）プログラム間メッセージを記憶するための前記ラ
   ンダムアクセスメモリ内に常駐の固定された容量の第１
   のバッファと、 （ｂ）条件付きで指定される実行順序を表すデータを記
   憶するための前記ランダムアクセスメモリ内に常駐の固
   定された容量の第２のバッファと、 （ｃ）第１の予め定めたコマンドプロトコルに応じて前
   記第１のバッファへ及び同バッファからのデータの転送
   を制御するための第１のサブプログラムであって、第２
   の予め定めたコマンドプロトコルに応じて前記第２のバ
   ッファへ及び同バッファからのデータの転送をさらに制
   御する第１のサブプログラムと、そして （ｄ）前記第２のバッファの内容に応じて複数の別個の
   そして従属（子供）の応用プログラムの実行の順序を制
   御する第２のサブプログラムとからなり、 これにより、前記従属の応用プログラムが前記第１のバ
   ッファを介し連絡することを許容される制御プログラ
   ム。
2. 【請求項２】 前記第１のサブプログラムを規定するコ
   ードが最小化される程に、前記第１の予め定めたコマン
   ドプロトコルが、前記第２の予め定めたコマンドプロト
   コルと実質的に同様である請求項１に記載の制御プログ
   ラム。
3. 【請求項３】 前記第１及び第２のバッファの各々が、
   複数のスロットを含み、各スロットが、前記第１のバッ
   ファの全容量のどのような部分でも占め得るメッセージ
   及び前記第２のバッファの全容量のどのような部分でも
   占め得る実行順序データを収容するために大きさにおい
   て可変である請求項２に記載の制御プログラム。
4. 【請求項４】 前記プログラム間メッセージが、与えら
   れるメッセージの名宛人を確認するのに役立つ予め定め
   た識別子を含む請求項３に記載の制御プログラム。
5. 【請求項５】 前記第２のサブプログラムが、さらに、
   連続的な連絡ポートのオペレーションを制御し、そして
   前記第１のバッファ内の前記連絡ポートと関連するファ
   イルハンドルを記憶し、これにより、多重の従属（子
   供）の応用プログラムが単一の連続的な連絡ポートを共
   有する請求項１に記載の制御プログラム。
6. 【請求項６】 前記ランダムアクセスメモリ内に記憶さ
   れ、そして前記リアルタイム割り込み及び前記マイクロ
   コンピュータの前記リアルタイムクロックの状態に応答
   して、前記従属の応用プログラムの一つにより前記第２
   のバッファ内に置かれる時間を刻印したメッセージによ
   り指定されるように、前記第１のバッファ内に実行可能
   なメッセージを記憶するための第３のサブプログラムを
   さらに含む請求項１に記載の制御プログラム。
7. 【請求項７】 ＭＳＤＯＳ型ディスクオペレーティング
   システムを記憶するためのランダムアクセスメモリを合
   併するアイビーエムのコンパチブル型マイクロコンピュ
   ータのためのプログラム間連絡を提供する方法であっ
   て、 （ａ）プログラム間連絡メッセージ及び条件付きで指定
   される実行順序を表すデータを記憶するために、それぞ
   れ固定された容量を有しそして前記ランダムアクセスメ
   モリ内に常駐の第１及び第２のバッファを規定する制御
   プログラムを提供し、 （ｂ）第１の予め定めたプロトコルに応じて前記第１の
   バッファへ及び同バッファからの転送を制御するための
   第１のサブプログラムを前記制御プログラム内に含み、
   前記第１のサブプログラムが、さらに、第２の予め定め
   たコマンドプロトコルに応じて前記第２のバッファへ及
   び同バッファからの転送を制御し、そして （ｃ）前記第２のバッファの内容に応じて、複数の別個
   のそして従属の応用プログラムの実行の順序を、前記従
   属の応用プログラムが前記第１のバッファを介し連絡で
   きるように、制御するための第２のサブプログラムを前
   記制御プログラム内に含む各ステップからなるプログラ
   ム間連絡を提供する方法。