JPH06222931A - パーソナルコンピュータのための制御プログラム及びプログラム間連絡提供方法 - Google Patents
パーソナルコンピュータのための制御プログラム及びプログラム間連絡提供方法Info
- Publication number
- JPH06222931A JPH06222931A JP5308158A JP30815893A JPH06222931A JP H06222931 A JPH06222931 A JP H06222931A JP 5308158 A JP5308158 A JP 5308158A JP 30815893 A JP30815893 A JP 30815893A JP H06222931 A JPH06222931 A JP H06222931A
- Authority
- JP
- Japan
- Prior art keywords
- program
- buffer
- control program
- data
- msdos
- 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.)
- Pending
Links
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/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- 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/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
(57)【要約】
【目的】 MSDOS(登録商標)と協同的に作動して
複雑なユーザの指令を多数の相互に作用する応用プログ
ラムにより効果的に達成させる保証された応答時間のプ
ログラム間連絡を提供する制御プログラムを提供する。 【構成】 MSDOSオペレーティングシステムを利用
するアイビーエムのコンパチブルマイクロプロセッサの
ための制御プログラムが、複数の応用プログラムが情報
をそれらの間及びカーネルプログラムに通すための能力
を提供し、それにより、カーネルプログラムがそのバッ
ファメッセージの内容に応じて応用を生み出す。これに
よって、プログラム間連絡計画と関連して通常出くわす
競合を伴うことなく、MSDOS環境を強化する。
複雑なユーザの指令を多数の相互に作用する応用プログ
ラムにより効果的に達成させる保証された応答時間のプ
ログラム間連絡を提供する制御プログラムを提供する。 【構成】 MSDOSオペレーティングシステムを利用
するアイビーエムのコンパチブルマイクロプロセッサの
ための制御プログラムが、複数の応用プログラムが情報
をそれらの間及びカーネルプログラムに通すための能力
を提供し、それにより、カーネルプログラムがそのバッ
ファメッセージの内容に応じて応用を生み出す。これに
よって、プログラム間連絡計画と関連して通常出くわす
競合を伴うことなく、MSDOS環境を強化する。
Description
【0001】発明の背景 1.発明の分野: 本発明は、一般的にはプログラム間
連絡に係り、そしてより詳しくは、相互連絡をし、相互
に制御しそしてユーザに対し一様なインターフェースを
提供している間共通ドライバを通して連絡ハードウェア
を共有するための能力を伴う応用プログラムを提供する
制御プログラム及びプログラム間連絡提供方法に関す
る。
連絡に係り、そしてより詳しくは、相互連絡をし、相互
に制御しそしてユーザに対し一様なインターフェースを
提供している間共通ドライバを通して連絡ハードウェア
を共有するための能力を伴う応用プログラムを提供する
制御プログラム及びプログラム間連絡提供方法に関す
る。
【0002】2.従来技術の記述: アイビーエム(I
BM)のパーソナルコンピュータ(PC)或いはアイビ
ーエムのコンパチブルパーソナルコンピュータとしても
知られているマイクロプロッセッサのインテル8x86
ファミリに基づくパーソナルコンピュータは個人的な計
算にとって有力な基準となる。この基準の継続的な人気
は、主として、マイクロソフトコーポレーション(Mi
crosoft Corporation)により販売
されているMSDOS(マイクロソフトディスクオペレ
ーティングシステム)として知られる特定のディスクオ
ペレーティングシステム(DOS)でもって演算処理す
るように書かれた応用ソフトウェアの大規模な本体の汎
用性に加え、相対的に低いハードウェアコストに起因す
る。MSDOSは、何らかのオペレーティングシステム
ソフトウェアを伴っているとき、応用プログラムのオペ
レーションのために規定された環境を提供する。術語
「MSDOS」は、字義通り、マイクロソフトコーポレ
ーションにより販売されているソフトウェアをいうが、
それは、何らかのアイビーエムのコンパチブルパーソナ
ルコンピュータにおいて含まれる読出専用メモリに含ま
れた基礎的な入力ー出力システム(BIOS)のプログ
ラムを含むようにしばしば解釈される。以下、術語「M
SDOS」は、BIOSを含み、MSDOS(バージョ
ン3.0或いはより後の)プロトコルに一般的に適合す
るアイビーエムのコンパチブルパーソナルコンピュータ
の標準オペレーティングシステムを意味するように使用
されるであろう。その技術に熟練した者達は、MSDO
Sのオペレーションの構成やモードの知識を備えている
であろうが、これらの望ましい更なる背景が、著作権1
988、マイクロソフトプレス(Microsoft
Press)、レイモンド・ダンカン(Raymond
Duncan)による「アドバンスドMSDOS」
(Advanced MSDOS)と称する出版物にて
見い出されるMSDOSの詳細な記述に言及される。
BM)のパーソナルコンピュータ(PC)或いはアイビ
ーエムのコンパチブルパーソナルコンピュータとしても
知られているマイクロプロッセッサのインテル8x86
ファミリに基づくパーソナルコンピュータは個人的な計
算にとって有力な基準となる。この基準の継続的な人気
は、主として、マイクロソフトコーポレーション(Mi
crosoft Corporation)により販売
されているMSDOS(マイクロソフトディスクオペレ
ーティングシステム)として知られる特定のディスクオ
ペレーティングシステム(DOS)でもって演算処理す
るように書かれた応用ソフトウェアの大規模な本体の汎
用性に加え、相対的に低いハードウェアコストに起因す
る。MSDOSは、何らかのオペレーティングシステム
ソフトウェアを伴っているとき、応用プログラムのオペ
レーションのために規定された環境を提供する。術語
「MSDOS」は、字義通り、マイクロソフトコーポレ
ーションにより販売されているソフトウェアをいうが、
それは、何らかのアイビーエムのコンパチブルパーソナ
ルコンピュータにおいて含まれる読出専用メモリに含ま
れた基礎的な入力ー出力システム(BIOS)のプログ
ラムを含むようにしばしば解釈される。以下、術語「M
SDOS」は、BIOSを含み、MSDOS(バージョ
ン3.0或いはより後の)プロトコルに一般的に適合す
るアイビーエムのコンパチブルパーソナルコンピュータ
の標準オペレーティングシステムを意味するように使用
されるであろう。その技術に熟練した者達は、MSDO
Sのオペレーションの構成やモードの知識を備えている
であろうが、これらの望ましい更なる背景が、著作権1
988、マイクロソフトプレス(Microsoft
Press)、レイモンド・ダンカン(Raymond
Duncan)による「アドバンスドMSDOS」
(Advanced MSDOS)と称する出版物にて
見い出されるMSDOSの詳細な記述に言及される。
【0003】簡単なMSDOSの個人指導 MSDOSは、プログラムの集合からなり、これらは、
共に、ユーザがパーソナルコンピュータのオペレーショ
ンを質問したり制御するオペレーティングインターフェ
ースを提供する。MSDOSが開始されるとき、それ
は、第1に、初期化の処理を完了させ、そしてそれから
コマンドインタープリター(COMMAND.COM)
を呼び出す。このプログラムは、キーボードを介しユー
ザにより入力されるコマンドを受けて作用する。このレ
ベルでは、コマンドは、現実には、対応する実行可能な
プログラムを含むファイルの名である。例えば、もしも
ユーザがコマンド「DIR」を入力すれば、そのコマン
ドのインタープリタープログラムは、ファイル「DI
R.COM」を見出し、もしも既に常駐していなけれ
ば、プログラムDIRをメモリにロードし、そして制御
をデイレクトリプログラムに転送するであろう。プログ
ラムDIRは実行されて現行のデイレクトリの内容をユ
ーザのディスプレイ上に書かせる。DIRプログラムは
制御をMSDOSコマンドインタープリターに戻すこと
により終了し、このインタープリターは従って次のユー
ザコマンドを待つ。ユーザは、従って、プログラム名を
入力することにより、何らかのMSDOSコマンド或い
は応用プログラムの実行を呼び出す。かくして呼び出さ
れたプログラムは、順に、低レベルのDOSのサービス
ルーチンを呼び出して色々な入力/出力資源と連絡す
る。
共に、ユーザがパーソナルコンピュータのオペレーショ
ンを質問したり制御するオペレーティングインターフェ
ースを提供する。MSDOSが開始されるとき、それ
は、第1に、初期化の処理を完了させ、そしてそれから
コマンドインタープリター(COMMAND.COM)
を呼び出す。このプログラムは、キーボードを介しユー
ザにより入力されるコマンドを受けて作用する。このレ
ベルでは、コマンドは、現実には、対応する実行可能な
プログラムを含むファイルの名である。例えば、もしも
ユーザがコマンド「DIR」を入力すれば、そのコマン
ドのインタープリタープログラムは、ファイル「DI
R.COM」を見出し、もしも既に常駐していなけれ
ば、プログラムDIRをメモリにロードし、そして制御
をデイレクトリプログラムに転送するであろう。プログ
ラムDIRは実行されて現行のデイレクトリの内容をユ
ーザのディスプレイ上に書かせる。DIRプログラムは
制御をMSDOSコマンドインタープリターに戻すこと
により終了し、このインタープリターは従って次のユー
ザコマンドを待つ。ユーザは、従って、プログラム名を
入力することにより、何らかのMSDOSコマンド或い
は応用プログラムの実行を呼び出す。かくして呼び出さ
れたプログラムは、順に、低レベルのDOSのサービス
ルーチンを呼び出して色々な入力/出力資源と連絡す
る。
【0004】上に述べた記述は、アイビーエムのパーソ
ナルコンピュータ、モデルXTと共に最初に導入された
ときのMSDOSの相対的に未発達な範囲を正しく取り
囲む。モデルXTの制限されたメモリ及び計算資源は、
既知の主なフレーム及びUNIXのようなミニコンピュ
ータオペレーティングシステムの能力の多くを妨害し
た。UNIXが非常に可能性のある多重ユーザ多重タス
ク環境を提供したのに反し、MSDOSはランダムアク
セスメモリのせいぜい640キロバイトでもって単一の
タスクを実行する単一のユーザに拘束された。より意味
ありげには、MSDOSは、応用プログラムを、非同期
の連絡ポートのような入力ー出力装置に非制限的にアク
セスさせる。上記制限は、MSDOSに固有であって、
妥協する互換性なしにはMSDOS内において直接的に
は打ち勝つことができない。効果的なプログラム間連絡
及び動的タスクスケジューリングの例は他のオペレーテ
ィングシステムにおいてよく知られているが、この望ま
しい能力は、これまでは、パーソナルコンピュータの実
行MSDOS上では有効ではなかった。
ナルコンピュータ、モデルXTと共に最初に導入された
ときのMSDOSの相対的に未発達な範囲を正しく取り
囲む。モデルXTの制限されたメモリ及び計算資源は、
既知の主なフレーム及びUNIXのようなミニコンピュ
ータオペレーティングシステムの能力の多くを妨害し
た。UNIXが非常に可能性のある多重ユーザ多重タス
ク環境を提供したのに反し、MSDOSはランダムアク
セスメモリのせいぜい640キロバイトでもって単一の
タスクを実行する単一のユーザに拘束された。より意味
ありげには、MSDOSは、応用プログラムを、非同期
の連絡ポートのような入力ー出力装置に非制限的にアク
セスさせる。上記制限は、MSDOSに固有であって、
妥協する互換性なしにはMSDOS内において直接的に
は打ち勝つことができない。効果的なプログラム間連絡
及び動的タスクスケジューリングの例は他のオペレーテ
ィングシステムにおいてよく知られているが、この望ま
しい能力は、これまでは、パーソナルコンピュータの実
行MSDOS上では有効ではなかった。
【0005】新しい制御プログラムが新しい或いは変更
された特徴をオペレーティングシステムに加えて併合さ
れ得るように、MSDOSは容易に拡張可能であるが、
既知の従来技術の機構はオペレーティング環境を生ぜ
ず、この環境においては、多数の別個の応用プログラム
が単一のユーザコマンドにより呼び出されて複雑なタス
クを効率よく協力して成就する。この能力の例はより可
能性のあるオペレーティングシステムにおいて豊富であ
るのに反し、MSDOSにおける典型的な実行は、タス
クの複雑さに対応する単一のモノリシックプログラムを
書くことである。これは、MSDOS下でのプログラム
間連絡及び動的スケジューリングに対する従来技術の解
決が不完全であるか或いは余りにも負担であるかのいず
れかであったと信じられている。根底となっている問題
は、連絡及びスケジューリングタスクを効率よく成就す
るためのプログラムに対して、それは、乏しいメモリ資
源のための応用プログラムでもって競うランダムアクセ
スメモリ内に常駐のままであるに違いないということで
ある。この競合が、パーソナルコンピュータの速度及び
ランダムアクセスメモリ容量が増大し続けるときでさえ
も継続する。
された特徴をオペレーティングシステムに加えて併合さ
れ得るように、MSDOSは容易に拡張可能であるが、
既知の従来技術の機構はオペレーティング環境を生ぜ
ず、この環境においては、多数の別個の応用プログラム
が単一のユーザコマンドにより呼び出されて複雑なタス
クを効率よく協力して成就する。この能力の例はより可
能性のあるオペレーティングシステムにおいて豊富であ
るのに反し、MSDOSにおける典型的な実行は、タス
クの複雑さに対応する単一のモノリシックプログラムを
書くことである。これは、MSDOS下でのプログラム
間連絡及び動的スケジューリングに対する従来技術の解
決が不完全であるか或いは余りにも負担であるかのいず
れかであったと信じられている。根底となっている問題
は、連絡及びスケジューリングタスクを効率よく成就す
るためのプログラムに対して、それは、乏しいメモリ資
源のための応用プログラムでもって競うランダムアクセ
スメモリ内に常駐のままであるに違いないということで
ある。この競合が、パーソナルコンピュータの速度及び
ランダムアクセスメモリ容量が増大し続けるときでさえ
も継続する。
【0006】DOS環境上への本発明の制御プログラム
の影響を理解するために、何らかのソフトウェア上のD
OSによりその制御下で課される制限の幾つかを議論す
ることは役に立つと思われる。この議論を通して、本発
明の制御プログラム環境の値がより明らかになるであろ
う。
の影響を理解するために、何らかのソフトウェア上のD
OSによりその制御下で課される制限の幾つかを議論す
ることは役に立つと思われる。この議論を通して、本発
明の制御プログラム環境の値がより明らかになるであろ
う。
【0007】DOSと呼ばれるオペレーティングシステ
ムは、本来的には、インテル8088マイクロプロセッ
サにより提供されるハードウェア環境にて作動するよう
に書かれていた。この環境において、最大1メガバイト
(MB)のアドレス可能なランダムアクセスメモリが入
手可能である。それはDOSにより二つの領域に分割さ
れる。より低いメモリスペースは640キロバイト(K
B)のプログラムメモリを含む。それは、プログラムが
ロードされそして実行されるこの領域内にある。ここに
ある制限は、もしもプログラムがメモリのこの量よりも
多く要求するならば、拡大すべき他のメモリはないとい
うことである。また、640キロバイトのスペースは、
応用、装置ドライバ及び他のシステムソフトウェアのた
めの残りのスペースをそのままにして、DOSプログラ
ムにより占められねばならないということが注目される
べきである。このことが、実行のための応用に対する十
分なメモリスペースをもたないことに帰結し得る。
ムは、本来的には、インテル8088マイクロプロセッ
サにより提供されるハードウェア環境にて作動するよう
に書かれていた。この環境において、最大1メガバイト
(MB)のアドレス可能なランダムアクセスメモリが入
手可能である。それはDOSにより二つの領域に分割さ
れる。より低いメモリスペースは640キロバイト(K
B)のプログラムメモリを含む。それは、プログラムが
ロードされそして実行されるこの領域内にある。ここに
ある制限は、もしもプログラムがメモリのこの量よりも
多く要求するならば、拡大すべき他のメモリはないとい
うことである。また、640キロバイトのスペースは、
応用、装置ドライバ及び他のシステムソフトウェアのた
めの残りのスペースをそのままにして、DOSプログラ
ムにより占められねばならないということが注目される
べきである。このことが、実行のための応用に対する十
分なメモリスペースをもたないことに帰結し得る。
【0008】より上位のメモリスペースは、残りの38
4キロバイトからなり、パーソナルコンピュータの拡張
スロットのいずれかに備えつけられたパーソナルコンピ
ュータボードのいずれか上に常駐するファームウェア
(firmware)のために使用される。ビデオラン
ダムアクセスメモリもまたここでアドレスされる。この
スペースは、応用プログラムのために使用されるように
は決して意図されていなかった。
4キロバイトからなり、パーソナルコンピュータの拡張
スロットのいずれかに備えつけられたパーソナルコンピ
ュータボードのいずれか上に常駐するファームウェア
(firmware)のために使用される。ビデオラン
ダムアクセスメモリもまたここでアドレスされる。この
スペースは、応用プログラムのために使用されるように
は決して意図されていなかった。
【0009】後の開発は、拡張メモリとして知られてい
ることの使用を通してより多くのメモリを備えていた。
この計画によれば、より上位の384キロバイトスペー
ス内に64キロバイトのバッファが置かれる。本来の1
メガバイトのスペースを超えるコンピュータ内のどのよ
うなメモリでも、ハードウェアレジスタの使用を通して
このバッファ内にスワップされる。そのメモリは、プロ
グラムデータに対しては有用であるが、応用の実行可能
なコードに対しては、やはり、メモリ制限を緩和しはし
ない。
ることの使用を通してより多くのメモリを備えていた。
この計画によれば、より上位の384キロバイトスペー
ス内に64キロバイトのバッファが置かれる。本来の1
メガバイトのスペースを超えるコンピュータ内のどのよ
うなメモリでも、ハードウェアレジスタの使用を通して
このバッファ内にスワップされる。そのメモリは、プロ
グラムデータに対しては有用であるが、応用の実行可能
なコードに対しては、やはり、メモリ制限を緩和しはし
ない。
【0010】80286及びより新しいプロセッサの導
入と共に、もう一つのメモリマッピング計画が展開され
た。それは、拡張メモリとして、これらのより新しいプ
ロセッサ(16メガバイトまで)の特別のアドレス可能
なメモリ能力を使用する。再び、このメモリはプログラ
ムデータを記憶するのに有効であるが、プログラム自体
には有効ではない。
入と共に、もう一つのメモリマッピング計画が展開され
た。それは、拡張メモリとして、これらのより新しいプ
ロセッサ(16メガバイトまで)の特別のアドレス可能
なメモリ能力を使用する。再び、このメモリはプログラ
ムデータを記憶するのに有効であるが、プログラム自体
には有効ではない。
【0011】これらのより新しいメモリマッピング計画
と共に、一つは、やはり、640キロバイトのプログラ
ムスペースにより制限される。従って、システムーレベ
ルのソフトウェアに対するどのような付加もできる限り
小さなメモリスペースを取らなければならない。そのよ
り新しい(80286及び前記の)プロセッサと共に、
ある装置ドライバ及び他のシステムプログラムを、より
上位の384キロバイト領域内に移動させることもまた
可能である。しかしながら、ある人は、そのようなソフ
トウェアが、メモリ内に配置される場所とは関係なく適
当に走るように再配置可能でなければならないことを評
価するに違いない。
と共に、一つは、やはり、640キロバイトのプログラ
ムスペースにより制限される。従って、システムーレベ
ルのソフトウェアに対するどのような付加もできる限り
小さなメモリスペースを取らなければならない。そのよ
り新しい(80286及び前記の)プロセッサと共に、
ある装置ドライバ及び他のシステムプログラムを、より
上位の384キロバイト領域内に移動させることもまた
可能である。しかしながら、ある人は、そのようなソフ
トウェアが、メモリ内に配置される場所とは関係なく適
当に走るように再配置可能でなければならないことを評
価するに違いない。
【0012】DOS環境の強力な特徴は、終了及び滞在
の常駐(TSR)のプログラムの概念である。それは、
走るとき、それ自身(通常は、割り込みに所属してい
る)を初期化しそして制御をDOSに戻すプログラムで
ある。そのような点から、その割り込みが発生されると
き、TSRプログラムは「ウェークアップ」(wake
up)しそして要求された機能を履行する。これの共通
の例は、ボーランドコーポレーション(Borland
Corporation)から入手可能な一般に普及
しているサイドキック(Sidekick)のソフトウ
ェアである。このソフトウェアは、それ自身、パーソナ
ルコンピュータのキーボード割り込みに所属している。
キーが押される度に、プログラムが「ウェークアップ」
しそしてカレンダー、メモ用紙とじ等の形態でユーザに
対し多数の機能を提供する。もしもキーストロークがサ
イドキックの「ホットキー」でなければ、サイドキック
は、単に、さらに処理をするためにキーストロークをD
OSに単に通過させる。
の常駐(TSR)のプログラムの概念である。それは、
走るとき、それ自身(通常は、割り込みに所属してい
る)を初期化しそして制御をDOSに戻すプログラムで
ある。そのような点から、その割り込みが発生されると
き、TSRプログラムは「ウェークアップ」(wake
up)しそして要求された機能を履行する。これの共通
の例は、ボーランドコーポレーション(Borland
Corporation)から入手可能な一般に普及
しているサイドキック(Sidekick)のソフトウ
ェアである。このソフトウェアは、それ自身、パーソナ
ルコンピュータのキーボード割り込みに所属している。
キーが押される度に、プログラムが「ウェークアップ」
しそしてカレンダー、メモ用紙とじ等の形態でユーザに
対し多数の機能を提供する。もしもキーストロークがサ
イドキックの「ホットキー」でなければ、サイドキック
は、単に、さらに処理をするためにキーストロークをD
OSに単に通過させる。
【0013】DOSはバッチファイル機構を備えてお
り、これにより、ユーザは、何らかのDOSのコマンド
ラインエントリーを含む情報交換用米国標準コードファ
イル(アスキーファイル)を創作し得る。応用プログラ
ム、DOSコマンド、及びDOSコマンドラインから開
始され得るどのような他の動作も、バッチファイルから
開始され得る。例えば、DOSから直接にファイルをク
リアするというタスクは、DOSコマンドラインでエン
ターされるように必要な一連のコマンドを含むバッチフ
ァイルを創作することにより自動化され得る。このバッ
チファイルが実行されるときはいつでも、それが含む一
連のコマンドが、あたかもDOSコマンドラインから手
動でエンターされたかのように実行されるであろう。実
際は、ソフトウェアを処理するDOSバッチファイルが
そのバッチファイルを解剖しそしてコマンド.コム(C
OMMAND.COM)を一時的に生み出してこれらの
コマンドを実行する。バッチファイル処理における固有
の一つの問題は、親のプログラム(この場合において
は、バッチファイルプロセッサ)の環境が子供の処理
(バッチファイルにおけるエントリにより発生される動
作)に沿っては通過されない。この理由により、バッチ
ファイルは、本発明の制御プログラム環境により許容さ
れると同様の統合された方法では十分には実行できな
い。なお、ラインがバッチファイル内にハードコード化
されるので、それらは外部の刺激における変化に応答し
て動的には変更され得ない。バッチファイルは出口上の
応用により作られる初歩的なエラーコードを利用できる
が、これを処理するためのラインが既にバッチファイル
内になければ、それは取り扱われ得ない。
り、これにより、ユーザは、何らかのDOSのコマンド
ラインエントリーを含む情報交換用米国標準コードファ
イル(アスキーファイル)を創作し得る。応用プログラ
ム、DOSコマンド、及びDOSコマンドラインから開
始され得るどのような他の動作も、バッチファイルから
開始され得る。例えば、DOSから直接にファイルをク
リアするというタスクは、DOSコマンドラインでエン
ターされるように必要な一連のコマンドを含むバッチフ
ァイルを創作することにより自動化され得る。このバッ
チファイルが実行されるときはいつでも、それが含む一
連のコマンドが、あたかもDOSコマンドラインから手
動でエンターされたかのように実行されるであろう。実
際は、ソフトウェアを処理するDOSバッチファイルが
そのバッチファイルを解剖しそしてコマンド.コム(C
OMMAND.COM)を一時的に生み出してこれらの
コマンドを実行する。バッチファイル処理における固有
の一つの問題は、親のプログラム(この場合において
は、バッチファイルプロセッサ)の環境が子供の処理
(バッチファイルにおけるエントリにより発生される動
作)に沿っては通過されない。この理由により、バッチ
ファイルは、本発明の制御プログラム環境により許容さ
れると同様の統合された方法では十分には実行できな
い。なお、ラインがバッチファイル内にハードコード化
されるので、それらは外部の刺激における変化に応答し
て動的には変更され得ない。バッチファイルは出口上の
応用により作られる初歩的なエラーコードを利用できる
が、これを処理するためのラインが既にバッチファイル
内になければ、それは取り扱われ得ない。
【0014】MSDOSのためのオペレーティングシス
テムのもう一つの部分は所謂「装置ドライバ」である。
それは応用ソフトウェアに装置の独立を提供する。ハー
ドウェアは、装置ドライバを通して、ファイルとして簡
単にアクセスされる。その装置は、読まれ書かれるため
に開かれ、そして応用がその装置と共に終了したときに
閉じられる。
テムのもう一つの部分は所謂「装置ドライバ」である。
それは応用ソフトウェアに装置の独立を提供する。ハー
ドウェアは、装置ドライバを通して、ファイルとして簡
単にアクセスされる。その装置は、読まれ書かれるため
に開かれ、そして応用がその装置と共に終了したときに
閉じられる。
【0015】発明の目的 本発明の目的は、MSDOSと共同的に作動して、複雑
なユーザの指令を多数の相互に作用する応用プログラム
により効果的に達成させる保証された応答時間のプログ
ラム間連絡を提供する制御プログラムを提供し、そし
て、さらに、この能力が、MSDOSを走らせるパーソ
ナルコンピュータがこれまで一般的に不適正であったよ
り時間臨界的(time−critical)な、結果
駆動される(event−driven)或いはリアル
タイムな処理に拡張できることにある。
なユーザの指令を多数の相互に作用する応用プログラム
により効果的に達成させる保証された応答時間のプログ
ラム間連絡を提供する制御プログラムを提供し、そし
て、さらに、この能力が、MSDOSを走らせるパーソ
ナルコンピュータがこれまで一般的に不適正であったよ
り時間臨界的(time−critical)な、結果
駆動される(event−driven)或いはリアル
タイムな処理に拡張できることにある。
【0016】本発明のさらなる目的は、それが制御する
応用プログラムが実行の流れを変更し得る動的なスケジ
ューリングを許容する制御プログラムを提供することに
ある。
応用プログラムが実行の流れを変更し得る動的なスケジ
ューリングを許容する制御プログラムを提供することに
ある。
【0017】本発明のもう一つの目的は、従属的な応用
プログラムが走らされる改善された程度の制御及び特性
のオペレーティング環境を提供することにある。
プログラムが走らされる改善された程度の制御及び特性
のオペレーティング環境を提供することにある。
【0018】本発明のもう一つの目的は、モジュールに
より調整した方法において容易に拡張可能な制御プログ
ラムを提供することにある。換言すれば、制御プログラ
ム環境は、他のソフトウェアプログラム(システム及び
(又は)応用レベル)が臨界的な素子或いは「フック」
(hooks)に十分なアクセスするような「開かれ
た」構成である。その結果は、ソフトウェアの強化が現
存するシステムに対する変更を殆ど伴うことなくその将
来に付加されるということである。
より調整した方法において容易に拡張可能な制御プログ
ラムを提供することにある。換言すれば、制御プログラ
ム環境は、他のソフトウェアプログラム(システム及び
(又は)応用レベル)が臨界的な素子或いは「フック」
(hooks)に十分なアクセスするような「開かれ
た」構成である。その結果は、ソフトウェアの強化が現
存するシステムに対する変更を殆ど伴うことなくその将
来に付加されるということである。
【0019】本発明のさらなる目的は、MSDOS或い
は何らかのMSDOSのコンパチブル応用プログラムと
競合することなくコンピュータを作動させることにあ
る。
は何らかのMSDOSのコンパチブル応用プログラムと
競合することなくコンピュータを作動させることにあ
る。
【0020】本発明のさらなる目的は、従属の応用プロ
グラムの効果的なオペレーションに対する新しい障害を
伴うことなく、非常にコンパクトなそして効果的な制御
プロトコルを使用することによりこれらのプログラムに
とって役に立つランダムアクセスメモリのスペースをさ
らに最小化しながら、上述の目的を達成することにあ
る。
グラムの効果的なオペレーションに対する新しい障害を
伴うことなく、非常にコンパクトなそして効果的な制御
プロトコルを使用することによりこれらのプログラムに
とって役に立つランダムアクセスメモリのスペースをさ
らに最小化しながら、上述の目的を達成することにあ
る。
【0021】本発明のさらにもう一つの目的は、全バッ
ファを含む常駐ソフトウェアが8086のアッセンブリ
語で全体的に書かれ、そして最小量のメモリスペース
(例えば、640キロバイトのスペースのうち約24キ
ロバイト)のみを要求する新しいソフトウェア環境を提
供することにある。さらに、本発明のソフトウェアは、
より上位の384キロバイトのメモリスペース内にロー
ドされ得る。これにより、さらに、640キロバイトの
スペースにおける全体的なメモリ要求を減少させる。
ファを含む常駐ソフトウェアが8086のアッセンブリ
語で全体的に書かれ、そして最小量のメモリスペース
(例えば、640キロバイトのスペースのうち約24キ
ロバイト)のみを要求する新しいソフトウェア環境を提
供することにある。さらに、本発明のソフトウェアは、
より上位の384キロバイトのメモリスペース内にロー
ドされ得る。これにより、さらに、640キロバイトの
スペースにおける全体的なメモリ要求を減少させる。
【0022】発明の要約 本発明は、新規な制御プログラムからなり、この制御プ
ログラムは、プログラム間連絡及び動的なスケジューリ
ングを含むように、MSDOSオペレーティングシステ
ムの能力を効果的に拡張する。それは、ホルダー及びカ
ーネルの二つのサブプログラムからなり、これらサブプ
ログラムは、システムの初期化中に常駐のプログラムと
して備えられ、そして従って、そのような拡張のための
MSDOS規則に適合するMSDOSオペレーティング
システムに対する拡張となる。図1は、MSDOSオペ
レーティングシステム及び拡張されたオペレーティング
システム下にて走る応用プログラムに対する制御プログ
ラムの関係を示す図式的な表示である。
ログラムは、プログラム間連絡及び動的なスケジューリ
ングを含むように、MSDOSオペレーティングシステ
ムの能力を効果的に拡張する。それは、ホルダー及びカ
ーネルの二つのサブプログラムからなり、これらサブプ
ログラムは、システムの初期化中に常駐のプログラムと
して備えられ、そして従って、そのような拡張のための
MSDOS規則に適合するMSDOSオペレーティング
システムに対する拡張となる。図1は、MSDOSオペ
レーティングシステム及び拡張されたオペレーティング
システム下にて走る応用プログラムに対する制御プログ
ラムの関係を示す図式的な表示である。
【0023】ホルダープログラムは、郵便局に類似す
る。それは、「郵便物」、即ちプログラム間連絡を受
け、記憶しそして配達するという手順を制御する。応用
プログラムは、郵便物を送り、それらにアドレス指定さ
れている何らかの郵便物があるかどうかを決定し、或い
は郵便物を受け取るために、ホルダープログラムを呼び
出す。ホルダープログラムは、同一の構成をもちそして
同様の制御プロトコルを使用する二つのバッファメモリ
(メイルルーム)を含む。しかしながら、それらは異な
る結果を実現する。パブリックバッファはプログラム間
連絡を支持するメイルルームである。応用プログラムA
は、ホルダープログラムを呼び出して、応用プログラム
Bに対しメッセージを送る。応用プログラムAが終わる
とき、そしてもしも応用プログラムBがある未来の時間
にて実行されるならば、応用プログラムBが、ホルダー
プログラムを呼び出して、応用プログラムAにより送ら
れるメッセージを受け取る。意図された名宛人は、デー
タの形の変数、即ちパブリックバッファ内に記憶される
各メッセージのヘッディングを形成する16ビットの非
符号の整数により表され、そしてかくして65,536
の異なるアドレスを提供する。ここまでは、応用プログ
ラムBがいままでにそのメッセージを受けるための機会
を得るということを応用プログラムAが保証する手段は
ない。これは、もしも両プログラムが連続的に呼び出さ
れるということを保証する予め規定された原本の一部で
あるならば、問題ではない。しかしながら、応用プログ
ラムAに応用プログラムBの実行をさせることは非常に
望ましく、これにより、原本の妨害なしに相互に作用し
合う一組の応用プログラムにより複雑なタスクを達成で
きる。動的なスケジューリングとして知られているこの
能力は、他のホルダーメイルルーム、即ち、特別な種類
の郵便物のために確保される専用バッファにより支持さ
れる。その専用バッファは、複雑なタスクを達成するた
めに要求される実行の流れを含む。応用プログラムは専
用バッファに対し一つ或いはそれ以上のメッセージを送
ることができ、各メッセージは、事実上、マスタープラ
ンを創作するために実行されるべきプログラムを確認す
る。応用プログラムが呼び出されてマスタープランにお
けるその役割を果たすとき、それは、一部であるマスタ
ープランを知るために連絡をとり、そしてまたそのプラ
ンを変更し得る。そのような変更は、そのプランに対す
る新しい応用プログラムを付加すること、そのプランか
ら応用プログラムを削除することそして実行の順序を変
えることを含む。それはまた、そのプランに対しそれ自
身のプログラム名を付加することによりそれ自身の将来
の再実行を引き起こす。
る。それは、「郵便物」、即ちプログラム間連絡を受
け、記憶しそして配達するという手順を制御する。応用
プログラムは、郵便物を送り、それらにアドレス指定さ
れている何らかの郵便物があるかどうかを決定し、或い
は郵便物を受け取るために、ホルダープログラムを呼び
出す。ホルダープログラムは、同一の構成をもちそして
同様の制御プロトコルを使用する二つのバッファメモリ
(メイルルーム)を含む。しかしながら、それらは異な
る結果を実現する。パブリックバッファはプログラム間
連絡を支持するメイルルームである。応用プログラムA
は、ホルダープログラムを呼び出して、応用プログラム
Bに対しメッセージを送る。応用プログラムAが終わる
とき、そしてもしも応用プログラムBがある未来の時間
にて実行されるならば、応用プログラムBが、ホルダー
プログラムを呼び出して、応用プログラムAにより送ら
れるメッセージを受け取る。意図された名宛人は、デー
タの形の変数、即ちパブリックバッファ内に記憶される
各メッセージのヘッディングを形成する16ビットの非
符号の整数により表され、そしてかくして65,536
の異なるアドレスを提供する。ここまでは、応用プログ
ラムBがいままでにそのメッセージを受けるための機会
を得るということを応用プログラムAが保証する手段は
ない。これは、もしも両プログラムが連続的に呼び出さ
れるということを保証する予め規定された原本の一部で
あるならば、問題ではない。しかしながら、応用プログ
ラムAに応用プログラムBの実行をさせることは非常に
望ましく、これにより、原本の妨害なしに相互に作用し
合う一組の応用プログラムにより複雑なタスクを達成で
きる。動的なスケジューリングとして知られているこの
能力は、他のホルダーメイルルーム、即ち、特別な種類
の郵便物のために確保される専用バッファにより支持さ
れる。その専用バッファは、複雑なタスクを達成するた
めに要求される実行の流れを含む。応用プログラムは専
用バッファに対し一つ或いはそれ以上のメッセージを送
ることができ、各メッセージは、事実上、マスタープラ
ンを創作するために実行されるべきプログラムを確認す
る。応用プログラムが呼び出されてマスタープランにお
けるその役割を果たすとき、それは、一部であるマスタ
ープランを知るために連絡をとり、そしてまたそのプラ
ンを変更し得る。そのような変更は、そのプランに対す
る新しい応用プログラムを付加すること、そのプランか
ら応用プログラムを削除することそして実行の順序を変
えることを含む。それはまた、そのプランに対しそれ自
身のプログラム名を付加することによりそれ自身の将来
の再実行を引き起こす。
【0024】上述した応用プログラムは、差し迫った発
明の部分ではないが、それらは、この能力を利用するた
めに差し迫った発明のプログラム間連絡プロトコルに適
合するように書かれねばならないということが理解され
る。しかしながら、上述のことは、例えそれがそう書か
れていなくても、マスタープランの実行の流れにおいて
何らかのMSDOSのコンパチブルプログラムを含むと
いう可能性を除外しない。
明の部分ではないが、それらは、この能力を利用するた
めに差し迫った発明のプログラム間連絡プロトコルに適
合するように書かれねばならないということが理解され
る。しかしながら、上述のことは、例えそれがそう書か
れていなくても、マスタープランの実行の流れにおいて
何らかのMSDOSのコンパチブルプログラムを含むと
いう可能性を除外しない。
【0025】差し迫った発明の制御プログラムを呼び出
し得る少なくとも一つの応用プログラムがなければなら
ない。パーソナルコンピュータの究極の制御が典型的に
は人間の操作者と共に常駐するから、典型的には、これ
は、ユーザ指令に応答するメニューイングプログラムで
ある。商業プログラム、即ちマイクロソフトコーポレー
ション(Microsoft Corporatio
n)により販売されるウインドーズ(Windows)
及びクオーターデックコーポレション(Quarter
deck Corporation)により販売される
デスクビュー(Deskview)は、ユーザが選択し
得るタスクのメニューを提供するメニューイングプログ
ラムの例である。ユーザ入力は、それぞれのプログラム
或いは各プログラムを実行させるメニューイングプログ
ラムにより解釈される。術語「メニュープログラム」
は、キーボード或いはマウスのような操作者入力装置を
これに限定されることなく含む何らかのコンピュータ入
力に応答して差し迫った発明の制御プログラムを呼び出
す何らかのプログラムを意味するように使用されるであ
ろう。メニュープログラムは、二つのステップにおいて
制御プログラムと連絡をとる。第1に、メニュープログ
ラムはホルダープログラムを呼び出して要求される実行
の流れを専用バッファ内に記憶する。最も簡単な場合に
は、これは、実行されるべき簡単な応用プログラムの名
であるが、専用バッファのスロット容量によってのみ制
限される一続きの32ほどのプログラムである。メニュ
ープログラムはまた、ホルダープログラムのパブリック
バッファを使用してメッセージをある応用プログラムに
送る。これらの応用プログラムは、それらが実行すると
きそれらの行動を修正するための実行の流れを含む。ま
た、各応用は、パブリック及び専用のホルダーバッファ
を修正して応用の制御に従う動作の進路を動的に変更す
る能力を有する。メニュープログラムは、カーネルによ
り生み出される子供の処理のような実際にまさにもう一
つの応用である。その環境を利用するどのような応用
も、同じような機能を履行し得る。
し得る少なくとも一つの応用プログラムがなければなら
ない。パーソナルコンピュータの究極の制御が典型的に
は人間の操作者と共に常駐するから、典型的には、これ
は、ユーザ指令に応答するメニューイングプログラムで
ある。商業プログラム、即ちマイクロソフトコーポレー
ション(Microsoft Corporatio
n)により販売されるウインドーズ(Windows)
及びクオーターデックコーポレション(Quarter
deck Corporation)により販売される
デスクビュー(Deskview)は、ユーザが選択し
得るタスクのメニューを提供するメニューイングプログ
ラムの例である。ユーザ入力は、それぞれのプログラム
或いは各プログラムを実行させるメニューイングプログ
ラムにより解釈される。術語「メニュープログラム」
は、キーボード或いはマウスのような操作者入力装置を
これに限定されることなく含む何らかのコンピュータ入
力に応答して差し迫った発明の制御プログラムを呼び出
す何らかのプログラムを意味するように使用されるであ
ろう。メニュープログラムは、二つのステップにおいて
制御プログラムと連絡をとる。第1に、メニュープログ
ラムはホルダープログラムを呼び出して要求される実行
の流れを専用バッファ内に記憶する。最も簡単な場合に
は、これは、実行されるべき簡単な応用プログラムの名
であるが、専用バッファのスロット容量によってのみ制
限される一続きの32ほどのプログラムである。メニュ
ープログラムはまた、ホルダープログラムのパブリック
バッファを使用してメッセージをある応用プログラムに
送る。これらの応用プログラムは、それらが実行すると
きそれらの行動を修正するための実行の流れを含む。ま
た、各応用は、パブリック及び専用のホルダーバッファ
を修正して応用の制御に従う動作の進路を動的に変更す
る能力を有する。メニュープログラムは、カーネルによ
り生み出される子供の処理のような実際にまさにもう一
つの応用である。その環境を利用するどのような応用
も、同じような機能を履行し得る。
【0026】ホルダープログラムとの相互作用は、単
に、実行のためのマスタープランを設立するだけである
ことを思い起こせ。現実の実行は、メニュープログラム
が制御をカーネルプログラムに通すときに開始される。
カーネルプログラムは、MSDOSに対するもう一つの
応用プログラムとして現れるが、それは、それが制御す
る応用プログラムに対する拡張されたオペレーティング
システムの一部として現れる。カーネルプログラムはデ
ィスパッチャーとして機能する。それが制御を得ると
き、それは、専用バッファを読んで呼び出すべき次のプ
ログラムを決定する。カーネルプログラムが専用バッフ
ァにおいて入力を見出すときはいつでも、それは、その
入力を動かしそしてそれぞれのプログラムを生み出す。
このように生み出されるプログラムはカーネルプログラ
ムに対し従属的であり、このカーネルプログラムにおい
て、生み出されるプログラムは、カーネルの環境を受け
継ぎ、そしてそれが終わるとき制御をカーネルプログラ
ムに戻す親のカーネルプログラムの子供である。制御を
回復する同時に、この動作が、実行の流れが完了されて
しまうまで、即ち、制御がメニュープログラムに逆に渡
される時間にて専用バッファが空になるまで、繰り返さ
れる。実行の流れの一部である応用プログラムは実行の
流れを修正し得るのに反して、カーネルプログラムは修
正を伴うことなく実行の流れに従うように強いられる。
に、実行のためのマスタープランを設立するだけである
ことを思い起こせ。現実の実行は、メニュープログラム
が制御をカーネルプログラムに通すときに開始される。
カーネルプログラムは、MSDOSに対するもう一つの
応用プログラムとして現れるが、それは、それが制御す
る応用プログラムに対する拡張されたオペレーティング
システムの一部として現れる。カーネルプログラムはデ
ィスパッチャーとして機能する。それが制御を得ると
き、それは、専用バッファを読んで呼び出すべき次のプ
ログラムを決定する。カーネルプログラムが専用バッフ
ァにおいて入力を見出すときはいつでも、それは、その
入力を動かしそしてそれぞれのプログラムを生み出す。
このように生み出されるプログラムはカーネルプログラ
ムに対し従属的であり、このカーネルプログラムにおい
て、生み出されるプログラムは、カーネルの環境を受け
継ぎ、そしてそれが終わるとき制御をカーネルプログラ
ムに戻す親のカーネルプログラムの子供である。制御を
回復する同時に、この動作が、実行の流れが完了されて
しまうまで、即ち、制御がメニュープログラムに逆に渡
される時間にて専用バッファが空になるまで、繰り返さ
れる。実行の流れの一部である応用プログラムは実行の
流れを修正し得るのに反して、カーネルプログラムは修
正を伴うことなく実行の流れに従うように強いられる。
【0027】好ましくは、全体の処理が、専用バッファ
の空を見出すとき、メニュープログラムを呼び出すカー
ネルプログラムを最初に呼び出すことにより開始される
べきである。カーネルプログラムは、今、メニュープロ
グラムの「親」であるから、制御は、メニュープログラ
ムが正常に終わるときはいつでもカーネルプログラムに
渡される。カーネルプログラムが、専用バッファ内に含
まれるそのメッセージの全てに応答することにより実行
の流れを完了したとき、デフォルトプログラム(典型的
にはメニュープログラム)が生み出されて再び制御プロ
グラムを含むであろう新しい事象を待つ。
の空を見出すとき、メニュープログラムを呼び出すカー
ネルプログラムを最初に呼び出すことにより開始される
べきである。カーネルプログラムは、今、メニュープロ
グラムの「親」であるから、制御は、メニュープログラ
ムが正常に終わるときはいつでもカーネルプログラムに
渡される。カーネルプログラムが、専用バッファ内に含
まれるそのメッセージの全てに応答することにより実行
の流れを完了したとき、デフォルトプログラム(典型的
にはメニュープログラム)が生み出されて再び制御プロ
グラムを含むであろう新しい事象を待つ。
【0028】要約すれば、メニュー応用プログラムは、
差し迫った発明の制御プログラムを使用して多数の他の
応用プログラムを、規定された未だ十分に書かれていな
い方法において動作させ得る。この能力はフットボール
チームの類推を考慮することによりよりよく理解され得
る。クォーターバックは、メニュー応用プログラムのよ
うに、与えられるプレイを成就するための詳細な指令を
彼のチーム(他の応用プログラム)の残りに連絡すると
いう役割をもつ。スクラムのラインにおける集合と呼び
出しが、各プレーヤが指定された役割をもつマスタープ
ランを、クォーターバックに連絡させる。あるプレーヤ
はプレイオプションとして知られている特別の指示を与
えられる。ボールがつかまれるとき、各プレーヤは、他
のプレーヤの動作に応答して、要求されるように、プラ
ン作成翻案(plan making adaptat
ions)の彼の一部を実行する(その類推は、プログ
ラムの行動を条件付きで修正する応用プログラムの動的
なオペレーティング環境に対向チームが類似であると考
えるようにさらに拡張される。)。フットボールチーム
は、各プレーヤが連絡をとりそして同時に影響し合う並
列モデルである。MSDOS環境においては、一つのプ
ログラムのみが、どのような瞬間にても能動的であるこ
とができ、そしてそのプログラムは、それに先行し或い
は従うプログラムを本来的に意識していない。動的なス
ケジューリング及び制御プログラムのプログラム間連絡
能力は、一組の応用プログラムに、この意識を得させそ
してそれらがあたかも多重タスクと関連する相対的に高
いオーバーヘッドを伴うことなく同時に作動するかのよ
うに行動させる。その結果は非常にコンパクトなプログ
ラムであり、このプログラムはランダムアクセスメモリ
内に全体的に常駐して速い応答を達成することができそ
して応用プログラムに対する十分なランダムアクセスメ
モリスペースをまだ残す。
差し迫った発明の制御プログラムを使用して多数の他の
応用プログラムを、規定された未だ十分に書かれていな
い方法において動作させ得る。この能力はフットボール
チームの類推を考慮することによりよりよく理解され得
る。クォーターバックは、メニュー応用プログラムのよ
うに、与えられるプレイを成就するための詳細な指令を
彼のチーム(他の応用プログラム)の残りに連絡すると
いう役割をもつ。スクラムのラインにおける集合と呼び
出しが、各プレーヤが指定された役割をもつマスタープ
ランを、クォーターバックに連絡させる。あるプレーヤ
はプレイオプションとして知られている特別の指示を与
えられる。ボールがつかまれるとき、各プレーヤは、他
のプレーヤの動作に応答して、要求されるように、プラ
ン作成翻案(plan making adaptat
ions)の彼の一部を実行する(その類推は、プログ
ラムの行動を条件付きで修正する応用プログラムの動的
なオペレーティング環境に対向チームが類似であると考
えるようにさらに拡張される。)。フットボールチーム
は、各プレーヤが連絡をとりそして同時に影響し合う並
列モデルである。MSDOS環境においては、一つのプ
ログラムのみが、どのような瞬間にても能動的であるこ
とができ、そしてそのプログラムは、それに先行し或い
は従うプログラムを本来的に意識していない。動的なス
ケジューリング及び制御プログラムのプログラム間連絡
能力は、一組の応用プログラムに、この意識を得させそ
してそれらがあたかも多重タスクと関連する相対的に高
いオーバーヘッドを伴うことなく同時に作動するかのよ
うに行動させる。その結果は非常にコンパクトなプログ
ラムであり、このプログラムはランダムアクセスメモリ
内に全体的に常駐して速い応答を達成することができそ
して応用プログラムに対する十分なランダムアクセスメ
モリスペースをまだ残す。
【0029】制御プログラム及び連絡ドライバの双方の
ために要求されるメモリは次のようである。 ホルダーコード − 4.6キロバイト 専用バッファ − 1 パブリックバッファ − 1 カーネルコード − 7.4 コム(COM)ドライバコード− 2 コム(COM)バッファ − 16 4キロバイト×4(4キロバイトのインバッファ(IN
buffer)及び4キロバイトのアウトバッファ
(OUT buffer)を各々伴う2ポート) 全体のメモリ − 32キロバイト
ために要求されるメモリは次のようである。 ホルダーコード − 4.6キロバイト 専用バッファ − 1 パブリックバッファ − 1 カーネルコード − 7.4 コム(COM)ドライバコード− 2 コム(COM)バッファ − 16 4キロバイト×4(4キロバイトのインバッファ(IN
buffer)及び4キロバイトのアウトバッファ
(OUT buffer)を各々伴う2ポート) 全体のメモリ − 32キロバイト
【0030】本発明の制御プログラム環境においては、
カーネルは、装置ドライバを介して、連絡ポートの双方
を開く。結果として生ずるファイルハンドルは従ってホ
ルダーTSRパブリックバッファ内に置かれる。それか
ら、どのような応用も、ホルダーTSRバッファ内のフ
ァイルハンドルを介してRS−232ポートをアクセス
する。その応用のみが読みそしてRS−232ポートに
書く。カーネルプログラムのみがそのポートを開き或い
は閉じるから、色々な応用がRS−232ハードウェア
を共有し得る。例えば、一つの応用がデータ転送を開始
させそして継続すべきもう一つの応用を生み出し得る。
装置ドライバ内のバッファは、19200のボーレート
にてデータの価値を典型的には2秒間保持するに十分な
程に大きいから、一つの応用がどのようなデータをも失
うことなくもう一つを生み出すのに十分な時間がある。
カーネルは、装置ドライバを介して、連絡ポートの双方
を開く。結果として生ずるファイルハンドルは従ってホ
ルダーTSRパブリックバッファ内に置かれる。それか
ら、どのような応用も、ホルダーTSRバッファ内のフ
ァイルハンドルを介してRS−232ポートをアクセス
する。その応用のみが読みそしてRS−232ポートに
書く。カーネルプログラムのみがそのポートを開き或い
は閉じるから、色々な応用がRS−232ハードウェア
を共有し得る。例えば、一つの応用がデータ転送を開始
させそして継続すべきもう一つの応用を生み出し得る。
装置ドライバ内のバッファは、19200のボーレート
にてデータの価値を典型的には2秒間保持するに十分な
程に大きいから、一つの応用がどのようなデータをも失
うことなくもう一つを生み出すのに十分な時間がある。
【0031】差し迫った発明のホルダープログラムはT
SRプログラムである。それは、応用或いは制御プログ
ラムカーネルにより明確に発生されるときにのみ、それ
が「ウェークアップ」するように、それ自身、非使用の
割り込みに所属する。この方法において、ホルダーのオ
ペレーションは、ユーザにとって完全に平明である。さ
らに、制御プログラムの技術的な詳細のすべてがユーザ
にとって完全に平明だる。ユーザに関する限りは、本発
明の制御プログラムは、実際にそれが多くの舞台裏型の
オペレーションであるとき、もう一つの簡単なメニュー
イングプログラム以上のなにものでもない。
SRプログラムである。それは、応用或いは制御プログ
ラムカーネルにより明確に発生されるときにのみ、それ
が「ウェークアップ」するように、それ自身、非使用の
割り込みに所属する。この方法において、ホルダーのオ
ペレーションは、ユーザにとって完全に平明である。さ
らに、制御プログラムの技術的な詳細のすべてがユーザ
にとって完全に平明だる。ユーザに関する限りは、本発
明の制御プログラムは、実際にそれが多くの舞台裏型の
オペレーションであるとき、もう一つの簡単なメニュー
イングプログラム以上のなにものでもない。
【0032】本発明の制御プログラムは、完全にMSD
OSとコンパチブルである。それは、MSDOSと共に
稼働し、取り扱うべきMSDOSに対するどのような認
識し得ないコマンドをも通し、そのTSRに対する非使
用の割り込みを取り、そしてマイクロソフトのガイドラ
インに厳格に従い書かれた装置ドライバを提供する。さ
らに、制御プログラム環境は、MSDOSの機能性を二
重にするように試みることはしない。その代わりに、そ
れは、MSDOSによっては既に提供されないこれらの
機能を提供することによりMSDOSを強化することを
試みる。さらに、有効なプログラムスペースからメモリ
の大きな量を取り上げることなくこれをすることは可能
である。
OSとコンパチブルである。それは、MSDOSと共に
稼働し、取り扱うべきMSDOSに対するどのような認
識し得ないコマンドをも通し、そのTSRに対する非使
用の割り込みを取り、そしてマイクロソフトのガイドラ
インに厳格に従い書かれた装置ドライバを提供する。さ
らに、制御プログラム環境は、MSDOSの機能性を二
重にするように試みることはしない。その代わりに、そ
れは、MSDOSによっては既に提供されないこれらの
機能を提供することによりMSDOSを強化することを
試みる。さらに、有効なプログラムスペースからメモリ
の大きな量を取り上げることなくこれをすることは可能
である。
【0033】ボーランドターボアッセンブラ(Borl
and Turbo Assembler)の言語にて
書かれているソースコードは、付録Aに含まれている。
and Turbo Assembler)の言語にて
書かれているソースコードは、付録Aに含まれている。
【0034】
本発明の詳細な記述 パーソナルコンピュータの初期化は、ランダムアクセス
メモリにおけるMSDOSの常駐部分の備えつけを含
む。これが完全であるとき、ホルダープログラム(HO
LDER PROGRAM)もまた、TSRプログラム
として備え付けされる。ホルダープログラムの開始アド
レスは割り込みべクトルテーブルにおけるアドレス63
hにて記憶される。これが、ホルダープログラムがプロ
グラム可能な割り込み63hを実行することにより呼び
出されることを許容する。最終的には、カーネルプログ
ラム(KERNER PROGRAM)が備えつけられ
る。それは、応用プログラムを呼び出すために使用され
る標準のMSDOSの手続を使用して呼び出されるの
で、それは割り込べクトルを要求しない。制御プログラ
ムは、今、応用プログラムに対する制御及び連絡サービ
スを提供するために常駐しそして準備される。
メモリにおけるMSDOSの常駐部分の備えつけを含
む。これが完全であるとき、ホルダープログラム(HO
LDER PROGRAM)もまた、TSRプログラム
として備え付けされる。ホルダープログラムの開始アド
レスは割り込みべクトルテーブルにおけるアドレス63
hにて記憶される。これが、ホルダープログラムがプロ
グラム可能な割り込み63hを実行することにより呼び
出されることを許容する。最終的には、カーネルプログ
ラム(KERNER PROGRAM)が備えつけられ
る。それは、応用プログラムを呼び出すために使用され
る標準のMSDOSの手続を使用して呼び出されるの
で、それは割り込べクトルを要求しない。制御プログラ
ムは、今、応用プログラムに対する制御及び連絡サービ
スを提供するために常駐しそして準備される。
【0035】カーネルは、管理プログラムであって、こ
れは、メニュー及びホルダーのプログラムと協力して作
動し、オペレーティング環境の継続的な制御の間、ユー
ザコマンドに応答して一プログラム或いは一連のプログ
ラムを初期化する。オペレーティング環境の制御を仮定
することは応用プログラムに対しては可能であるが、本
発明の意向とは反対に、カーネルは制御を放棄しない。
理解の助けとして、その応用プログラムは、パブリック
バッファ内に置かれるオペレーティング環境に対する何
らかの拡張に加え、親のMSDOSオペレーティング環
境を受け継ぐ「親」のカーネルプログラムの「子供」と
して考慮され得る。図2は、カーネルプログラムのオペ
レーションのブロック図を示す。そのカーネルは、MS
DOSコマンドラインからの唯一の応用実行である。制
御プログラム下で実行されるどのような応用も、子供の
処理としてカーネルにより開始される。これはメニュー
プログラムを含む。ホルダーは、DOSコマンドライン
から開始され得るが、TSRとして、通常、自動実行バ
ッチファイル(AUTO EXEC.BAT fil
e)からのシステム始動にて実行される。ホルダーは、
本発明の制御プログラムを実行する前に備えつけられな
ければならない。カーネルプログラムはエントリー点1
0にてエンターされ、メニュープログラムにより或いは
MSDOSコマンドレベルから直接に呼び出される。ス
テップ12にて、ステータスが、これがプログラムが呼
び出された最初であるかどうかを決定するために調べら
れる。もしもそうであるならば、ステップ14が実行さ
れる。連絡装置ドライバを開くために、私のプログラム
は、標準の「ファイルオープン」要求を簡単にDOSに
し、このDOSは、カーネルがパブリックホルダーバッ
ファ内に記憶するというファイル手段に戻る。これは各
振る舞いに対してなされる。このドライバは、MSDO
SドライバCOM1及びCOM2のように殆ど作動し、
本質的な連絡パラメータを確立する。MSDOSは、ホ
ストパーソナルコンピュータにおける存在であるように
見出される各ポートのためのファイルハンドルに復帰す
る。ファイルハンドル(file handle)は、
ファイル或いは連絡ポートと名付けられる16ビットの
整数である。それは、要求がされてファイル或いは連絡
ポートを開くときにMSDOSにより提供され、そして
ファイルサービスのためのMSDOSに対する後続要求
がファイルハンドルを含まなければならない。ブロック
14により示されているように、カーネルプログラム
は、ホルダープログラムと関連するパブリックバッファ
における独特の指定された識別子と共に各ファイルハン
ドルを記憶する。連絡ファイルハンドルが一定に留ま
り、そしてカーネルプログラムにより生み出されるすべ
ての応用プログラムに対しアクセス可能であるから、多
重応用は、今、共通のファイルハンドルを使用可能とな
り、かくして与えられた連絡ポートに対しアクセスを共
有する。これは、MSDOSが非常に多くの制御を引き
渡されてこれにより応用プログラムのためのより一層有
用な全体的なオペレーティング環境を提供するようなこ
れらの例において、オペレーティングシステムに、制御
を回復させ得る差し迫った発明の一般的な能力を例証す
る。
れは、メニュー及びホルダーのプログラムと協力して作
動し、オペレーティング環境の継続的な制御の間、ユー
ザコマンドに応答して一プログラム或いは一連のプログ
ラムを初期化する。オペレーティング環境の制御を仮定
することは応用プログラムに対しては可能であるが、本
発明の意向とは反対に、カーネルは制御を放棄しない。
理解の助けとして、その応用プログラムは、パブリック
バッファ内に置かれるオペレーティング環境に対する何
らかの拡張に加え、親のMSDOSオペレーティング環
境を受け継ぐ「親」のカーネルプログラムの「子供」と
して考慮され得る。図2は、カーネルプログラムのオペ
レーションのブロック図を示す。そのカーネルは、MS
DOSコマンドラインからの唯一の応用実行である。制
御プログラム下で実行されるどのような応用も、子供の
処理としてカーネルにより開始される。これはメニュー
プログラムを含む。ホルダーは、DOSコマンドライン
から開始され得るが、TSRとして、通常、自動実行バ
ッチファイル(AUTO EXEC.BAT fil
e)からのシステム始動にて実行される。ホルダーは、
本発明の制御プログラムを実行する前に備えつけられな
ければならない。カーネルプログラムはエントリー点1
0にてエンターされ、メニュープログラムにより或いは
MSDOSコマンドレベルから直接に呼び出される。ス
テップ12にて、ステータスが、これがプログラムが呼
び出された最初であるかどうかを決定するために調べら
れる。もしもそうであるならば、ステップ14が実行さ
れる。連絡装置ドライバを開くために、私のプログラム
は、標準の「ファイルオープン」要求を簡単にDOSに
し、このDOSは、カーネルがパブリックホルダーバッ
ファ内に記憶するというファイル手段に戻る。これは各
振る舞いに対してなされる。このドライバは、MSDO
SドライバCOM1及びCOM2のように殆ど作動し、
本質的な連絡パラメータを確立する。MSDOSは、ホ
ストパーソナルコンピュータにおける存在であるように
見出される各ポートのためのファイルハンドルに復帰す
る。ファイルハンドル(file handle)は、
ファイル或いは連絡ポートと名付けられる16ビットの
整数である。それは、要求がされてファイル或いは連絡
ポートを開くときにMSDOSにより提供され、そして
ファイルサービスのためのMSDOSに対する後続要求
がファイルハンドルを含まなければならない。ブロック
14により示されているように、カーネルプログラム
は、ホルダープログラムと関連するパブリックバッファ
における独特の指定された識別子と共に各ファイルハン
ドルを記憶する。連絡ファイルハンドルが一定に留ま
り、そしてカーネルプログラムにより生み出されるすべ
ての応用プログラムに対しアクセス可能であるから、多
重応用は、今、共通のファイルハンドルを使用可能とな
り、かくして与えられた連絡ポートに対しアクセスを共
有する。これは、MSDOSが非常に多くの制御を引き
渡されてこれにより応用プログラムのためのより一層有
用な全体的なオペレーティング環境を提供するようなこ
れらの例において、オペレーティングシステムに、制御
を回復させ得る差し迫った発明の一般的な能力を例証す
る。
【0036】もしもカーネルプログラムが予め呼び出さ
れたならば、ブランチ13が取られて、実行がブロック
20により表されるオペレーションに進む。もしもカー
ネルプログラムがMSDOSコマンドレベルから呼び出
されそして新しいデフォルト応用プログラムの名がコマ
ンドラインオプションとして入力されたならば、この状
態が決定ブロック16にて検出され、そしてブロック1
8のオペレーションが新しいプログラム名を獲得しそし
てメニューの固有のデフォルト応用プログラム名を上書
きする。もしも上記状態が起こらなかったならば、ブラ
ンチ13が取られそして実行がブロック20のオペレー
ションに直接進む。ここで、ホルダープログラムが、専
用バッファからデータを得るための要求コードと共に、
割り込み63hを介し呼び出される。ホルダープログラ
ムは、例えあるとしても、関連の識別子に沿って実行さ
れるべき次のプログラム或いはコマンドの本質(ide
ntify)に戻る。識別子は、それらが実行されるべ
き動作の型の分類を提供するように、予め定義されるこ
とが思い起こされるべきである。動作項目が復帰されな
いならば、制御が、デフォルト応用プログラムを生み出
させるブロック24への移行する。ブロック18のオペ
レーションの実行に起因してデフォルト名が変化されな
い限り、プログラムメニューが生み出される。
れたならば、ブランチ13が取られて、実行がブロック
20により表されるオペレーションに進む。もしもカー
ネルプログラムがMSDOSコマンドレベルから呼び出
されそして新しいデフォルト応用プログラムの名がコマ
ンドラインオプションとして入力されたならば、この状
態が決定ブロック16にて検出され、そしてブロック1
8のオペレーションが新しいプログラム名を獲得しそし
てメニューの固有のデフォルト応用プログラム名を上書
きする。もしも上記状態が起こらなかったならば、ブラ
ンチ13が取られそして実行がブロック20のオペレー
ションに直接進む。ここで、ホルダープログラムが、専
用バッファからデータを得るための要求コードと共に、
割り込み63hを介し呼び出される。ホルダープログラ
ムは、例えあるとしても、関連の識別子に沿って実行さ
れるべき次のプログラム或いはコマンドの本質(ide
ntify)に戻る。識別子は、それらが実行されるべ
き動作の型の分類を提供するように、予め定義されるこ
とが思い起こされるべきである。動作項目が復帰されな
いならば、制御が、デフォルト応用プログラムを生み出
させるブロック24への移行する。ブロック18のオペ
レーションの実行に起因してデフォルト名が変化されな
い限り、プログラムメニューが生み出される。
【0037】もしも動作項目が復帰されるならば、ブロ
ック26において、動作項目と関連する識別子の値がブ
ロック20のオペレーションにて回復したかどうかの試
験がなされる。もしもそれが、動作項目が応用プログラ
ムの名であることを表すならば、そのときには、ブロッ
ク28のオペレーションがその応用プログラムを「子
供」の処理としてMSDOSの呼び出しを介し生み出
す。もしも識別子が2という値をもちそして動作項目が
テーブル1の内部カーネルコマンドの一つとして認識さ
れるならば、そのときには、ステップ34が内部コマン
ド及びブランチをブロック20のオペレーションに戻
す。さもなければ、そのコマンドはMSDOSであると
仮定され、そしてそのコマンドが実行のためのMSDO
Sに渡される。
ック26において、動作項目と関連する識別子の値がブ
ロック20のオペレーションにて回復したかどうかの試
験がなされる。もしもそれが、動作項目が応用プログラ
ムの名であることを表すならば、そのときには、ブロッ
ク28のオペレーションがその応用プログラムを「子
供」の処理としてMSDOSの呼び出しを介し生み出
す。もしも識別子が2という値をもちそして動作項目が
テーブル1の内部カーネルコマンドの一つとして認識さ
れるならば、そのときには、ステップ34が内部コマン
ド及びブランチをブロック20のオペレーションに戻
す。さもなければ、そのコマンドはMSDOSであると
仮定され、そしてそのコマンドが実行のためのMSDO
Sに渡される。
【0038】 テーブル 1 カーネルプログラム内部コマンド コマンド 意味 ホーム(home) 制御プログラムのホームディレクトリに戻る リセット(reset) すべてのホルダーTSRバッファをクリアする ヘルプ(help) すべてのコマンドリストを書く(print) シェル(shell) 制御プログラムコマンドモードを入力する dos 制御プログラムコマンドモードからMSDOS へのシェル エグジット(exit) 制御コマンドモードを出て子供の応用に戻る( 或いはもしもその子供の応用がコマンドを出す ならば、カーネルはMSDOSに出る)。
【0039】図5のソフトウェアフローチャートは、差
し迫った発明により与えられるプログラム間連絡及び相
互作用能力を使用するように設計された何らかの応用プ
ログラム内にてプログラムの流れを例証する。エントリ
点50は、図2におけるブロック24或いは28のいず
れかのオペレーションから生み出される何らかのプログ
ラムの開始である。ステップ52及び54は、もう一つ
の応用プログラムによりそこに置かれるパブリックバッ
ファからデータを得るための要求コードと共に、割り込
み63hを介して、ホルダープログラムを呼び出す。ブ
ロック58により示されるように、その応用は、その意
図された機能を実行し、そしてブロック60において試
験が実行されて差し迫った応用プログラムがもう一つの
関連応用プログラムの実行を要求すべきかどうかを決定
する。もしもそうならば、オペレーションブロックステ
ップ64は、実行されるべき応用プログラムの名が、そ
の識別子と共に、「プットデータ(put dat
a)」要求コードを使用して、割り込み63hを介し、
専用バッファ内に置かれる。同様の方法において、図5
においてブロック66、68及び72により表されるオ
ペレーション及び試験の実行が、パブリックバッファ内
にデータを置くためにオプションを提供し、かくして、
他の応用プログラムにとって有用となる。ブロック74
は、通常のプログラムの終了が、カーネルプログラムを
点A(ブロック10、図2)にて再入力させる動作のた
めに確保されたいずれかのMSDOS機能を呼び出すこ
とにより実行されるということを示している。要約すれ
ば、オペレーション60及び64が動的スケジューリン
グを提供しそして各ステップ66、68及び72が出力
データを他の応用プログラムに提供する一方、オペレー
ション52及び54により表される各オペレーションの
実行は他の応用プログラムからの入力データを提供す
る。代わりとして、カーネルプログラムが、カーネル或
いはホルダーのプログラムを意識していない応用を生み
出し得る。この場合、各ブロック58及び74のオペレ
ーションのみが実行される。
し迫った発明により与えられるプログラム間連絡及び相
互作用能力を使用するように設計された何らかの応用プ
ログラム内にてプログラムの流れを例証する。エントリ
点50は、図2におけるブロック24或いは28のいず
れかのオペレーションから生み出される何らかのプログ
ラムの開始である。ステップ52及び54は、もう一つ
の応用プログラムによりそこに置かれるパブリックバッ
ファからデータを得るための要求コードと共に、割り込
み63hを介して、ホルダープログラムを呼び出す。ブ
ロック58により示されるように、その応用は、その意
図された機能を実行し、そしてブロック60において試
験が実行されて差し迫った応用プログラムがもう一つの
関連応用プログラムの実行を要求すべきかどうかを決定
する。もしもそうならば、オペレーションブロックステ
ップ64は、実行されるべき応用プログラムの名が、そ
の識別子と共に、「プットデータ(put dat
a)」要求コードを使用して、割り込み63hを介し、
専用バッファ内に置かれる。同様の方法において、図5
においてブロック66、68及び72により表されるオ
ペレーション及び試験の実行が、パブリックバッファ内
にデータを置くためにオプションを提供し、かくして、
他の応用プログラムにとって有用となる。ブロック74
は、通常のプログラムの終了が、カーネルプログラムを
点A(ブロック10、図2)にて再入力させる動作のた
めに確保されたいずれかのMSDOS機能を呼び出すこ
とにより実行されるということを示している。要約すれ
ば、オペレーション60及び64が動的スケジューリン
グを提供しそして各ステップ66、68及び72が出力
データを他の応用プログラムに提供する一方、オペレー
ション52及び54により表される各オペレーションの
実行は他の応用プログラムからの入力データを提供す
る。代わりとして、カーネルプログラムが、カーネル或
いはホルダーのプログラムを意識していない応用を生み
出し得る。この場合、各ブロック58及び74のオペレ
ーションのみが実行される。
【0040】図8にて示される次の例は、これらのプロ
グラムにより与えられる変現自在の例証である。細い実
線は各バッファへ及び同各バッファからの連絡を表して
いるが、太い破線はプログラムの実行の流れを表してい
る。カーネルプログラムは初期的にはMSDOSのコマ
ンドレベルから呼び出される。すべてのホルダーバッフ
ァは初期的には空であるから、デフォルト応用プログラ
ムメニューが生み出される。ユーザは実行されるべきメ
ニューオプションを選択し、このメニューオプション
は、プログラムAがユーザの指定位置、プログラムB、
C或いはDからデータを集めることを要求してそのデー
タを条件付きで処理し、そしてプログラムEを要求し
て、介在プログラムが走ったとき、そのデータをまき散
らす。メニュープログラムはプログラムAの識別子を使
用してメッセージをパブリックバッファを介してプログ
ラムAに急送し、ソースデータを見い出す場所をプログ
ラムAに告げる。そのメニュープログラムはまた、専用
バッファ内に動作項目を置き、プログラムAを生み出す
ように向ける。そのメニュープログラムは終了し、カー
ネルプログラムに制御を戻し、メニュープログラムから
動作項目を見い出すと、応用プログラムAを生み出す。
プログラムAはメニュープログラムからメッセージを得
て、データを集め、そして受け取られたデータが各プロ
グラムB及びDによる処理を要求するがプログラムCに
よるのではないことを決定し、カーネルに向く専用バッ
ファ内に動作項目を置かさせて、各プログラムB、D及
びEをその順序にて生み出す。次のプログラムAはメッ
セージを各プログラムB及びDに急送して、それらに各
データを見出す場所を告げそして終了し、制御をカーネ
ルプログラムに戻す。同じような方法において、各プロ
グラムB、D及びEは、要求されるように、メッセージ
を進める各プログラムと共に、パブリックバッファを介
して、生み出される。付加的な応用プログラムは、示さ
れてはいないが、スケジュールに動的に付加されて、エ
ラー報告或いはエラー復活のような例外処理に便宜を図
る。プログラムEが終了すると、カーネルプログラム
が、専用バッファにおける動作項目を見出さないとき、
メニュープログラムを再び生み出して、制御をユーザに
戻し、もう一つのメニュー選択を実行する。
グラムにより与えられる変現自在の例証である。細い実
線は各バッファへ及び同各バッファからの連絡を表して
いるが、太い破線はプログラムの実行の流れを表してい
る。カーネルプログラムは初期的にはMSDOSのコマ
ンドレベルから呼び出される。すべてのホルダーバッフ
ァは初期的には空であるから、デフォルト応用プログラ
ムメニューが生み出される。ユーザは実行されるべきメ
ニューオプションを選択し、このメニューオプション
は、プログラムAがユーザの指定位置、プログラムB、
C或いはDからデータを集めることを要求してそのデー
タを条件付きで処理し、そしてプログラムEを要求し
て、介在プログラムが走ったとき、そのデータをまき散
らす。メニュープログラムはプログラムAの識別子を使
用してメッセージをパブリックバッファを介してプログ
ラムAに急送し、ソースデータを見い出す場所をプログ
ラムAに告げる。そのメニュープログラムはまた、専用
バッファ内に動作項目を置き、プログラムAを生み出す
ように向ける。そのメニュープログラムは終了し、カー
ネルプログラムに制御を戻し、メニュープログラムから
動作項目を見い出すと、応用プログラムAを生み出す。
プログラムAはメニュープログラムからメッセージを得
て、データを集め、そして受け取られたデータが各プロ
グラムB及びDによる処理を要求するがプログラムCに
よるのではないことを決定し、カーネルに向く専用バッ
ファ内に動作項目を置かさせて、各プログラムB、D及
びEをその順序にて生み出す。次のプログラムAはメッ
セージを各プログラムB及びDに急送して、それらに各
データを見出す場所を告げそして終了し、制御をカーネ
ルプログラムに戻す。同じような方法において、各プロ
グラムB、D及びEは、要求されるように、メッセージ
を進める各プログラムと共に、パブリックバッファを介
して、生み出される。付加的な応用プログラムは、示さ
れてはいないが、スケジュールに動的に付加されて、エ
ラー報告或いはエラー復活のような例外処理に便宜を図
る。プログラムEが終了すると、カーネルプログラム
が、専用バッファにおける動作項目を見出さないとき、
メニュープログラムを再び生み出して、制御をユーザに
戻し、もう一つのメニュー選択を実行する。
【0041】図5の各ブロック54及び72により示さ
れる応用プログラムとホルダープログラムとの間の連絡
は、標準的なMSDOS機能の呼び出し手続を使用す
る。色々な中央処理演算装置のレジスタは、実行される
べき機能に応じたその応用によりデータと共にロードさ
れる。そのとき、その応用はプログラムされた割り込み
63hを実行してホルダープログラムを呼び出す。ホル
ダープログラムは、その要求された機能を実行し、色々
な中央演算処理装置のレジスタを、要求された情報と共
にロードしそしてそれから制御を応用プログラムに戻
す。要求コードの指定された値にてのみ異なる共通のセ
ットの機能は、パブリック及び専用の両バッファのため
のサービスを提供する。これらは、 − ゲットブロック(getblock):指定された
識別子に応じて、一区画のデータを得る。 − ゲットネクスト(getnext):最新の指定さ
れた識別子に応じて、次の一区画のデータを得る。 − プットブロック(putblock):一区画のデ
ータをその識別子と共にホルダースロット内に置く。 − クリアブロック(clearblock):最新の
回復されたブロックのデータをクリアする。一区画のデ
ータを得るための要求は非破壊的であり、従って、どの
ような多数の処理も、必要に応じ、それにアクセスでき
る。 − ステータス(status):最新のオペレーショ
ンのステータスを得る。 − 署名(signature):(開始ルーチンに備
えられているならば)HODER.EXEプログラムの
署名を得る。この呼び出しは、HODER.EXE T
SR及びその改定レベルの両存在を設立するために使用
される。この呼び出しは、開始上の中央プログラムのカ
ーネルによりなされる。
れる応用プログラムとホルダープログラムとの間の連絡
は、標準的なMSDOS機能の呼び出し手続を使用す
る。色々な中央処理演算装置のレジスタは、実行される
べき機能に応じたその応用によりデータと共にロードさ
れる。そのとき、その応用はプログラムされた割り込み
63hを実行してホルダープログラムを呼び出す。ホル
ダープログラムは、その要求された機能を実行し、色々
な中央演算処理装置のレジスタを、要求された情報と共
にロードしそしてそれから制御を応用プログラムに戻
す。要求コードの指定された値にてのみ異なる共通のセ
ットの機能は、パブリック及び専用の両バッファのため
のサービスを提供する。これらは、 − ゲットブロック(getblock):指定された
識別子に応じて、一区画のデータを得る。 − ゲットネクスト(getnext):最新の指定さ
れた識別子に応じて、次の一区画のデータを得る。 − プットブロック(putblock):一区画のデ
ータをその識別子と共にホルダースロット内に置く。 − クリアブロック(clearblock):最新の
回復されたブロックのデータをクリアする。一区画のデ
ータを得るための要求は非破壊的であり、従って、どの
ような多数の処理も、必要に応じ、それにアクセスでき
る。 − ステータス(status):最新のオペレーショ
ンのステータスを得る。 − 署名(signature):(開始ルーチンに備
えられているならば)HODER.EXEプログラムの
署名を得る。この呼び出しは、HODER.EXE T
SR及びその改定レベルの両存在を設立するために使用
される。この呼び出しは、開始上の中央プログラムのカ
ーネルによりなされる。
【0042】これらの機能の詳細な説明は次の通りであ
る。パブリックバッファ機能 :機能 1:ホルダーのバッファから記憶データを得る。 呼び出しに対してセットするためのレジスタ: AH=1 CX=回復されるべきバイトの数 DL=識別子コード(0=アンタイプド(untype
d)) ES:DI=行き先アドレス その行き先はすべての要求されたデータを保持するに十
分に広範でなければならないということに注目すべきで
ある。 セットオンリターン(set on return)と
してのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しければ、バッファは空であってデ
ータは転送されなかったことに注意せよ。この機能を呼
び出す前に、記憶されたデータが現行のプログラムに対
してであることを確かめるためにホルダーの現行のステ
ータスを得ることは賢明である。
る。パブリックバッファ機能 :機能 1:ホルダーのバッファから記憶データを得る。 呼び出しに対してセットするためのレジスタ: AH=1 CX=回復されるべきバイトの数 DL=識別子コード(0=アンタイプド(untype
d)) ES:DI=行き先アドレス その行き先はすべての要求されたデータを保持するに十
分に広範でなければならないということに注目すべきで
ある。 セットオンリターン(set on return)と
してのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しければ、バッファは空であってデ
ータは転送されなかったことに注意せよ。この機能を呼
び出す前に、記憶されたデータが現行のプログラムに対
してであることを確かめるためにホルダーの現行のステ
ータスを得ることは賢明である。
【0043】機能2:ホルダーのバッファ内にデータを
置く 呼び出しのためにセットすべきレジスタ: AH=2 CX=記憶されるべきバイトの数 DL=識別子コード(0=アンタイプド) ES:SI=ソースアドレス CXにおける値はバッファの大きさ以下でなければなら
ないことに注目せよ。もしもCXが零に等しければ、バ
ッファは削除される。 セットオンリターンとしてのレジスタ: CX=実際に記憶されるバイトの数 非常にしばしば、そのバッファ内にデータを記憶するた
めの最上の方法は正式のC構成と共にあるであろう。ホ
ルダーの見地からは、送られるどのようなデータも一つ
の流れのバイトにすぎず、ホルダーは理解することを試
みない。識別子コードは、もう一つのプログラムのため
に、記憶されたデータが利益があるかどうかを確認する
のに使用されるべきである。
置く 呼び出しのためにセットすべきレジスタ: AH=2 CX=記憶されるべきバイトの数 DL=識別子コード(0=アンタイプド) ES:SI=ソースアドレス CXにおける値はバッファの大きさ以下でなければなら
ないことに注目せよ。もしもCXが零に等しければ、バ
ッファは削除される。 セットオンリターンとしてのレジスタ: CX=実際に記憶されるバイトの数 非常にしばしば、そのバッファ内にデータを記憶するた
めの最上の方法は正式のC構成と共にあるであろう。ホ
ルダーの見地からは、送られるどのようなデータも一つ
の流れのバイトにすぎず、ホルダーは理解することを試
みない。識別子コードは、もう一つのプログラムのため
に、記憶されたデータが利益があるかどうかを確認する
のに使用されるべきである。
【0044】機能3:ホルダーの内部バッファをクリア
する 呼び出しのためにセットすべきレジスタ: AH=3 セットオンリターンとしてのレジスタ: セットオンリターンなし 呼び出し人が、新しいデータを記憶しようとするか或い
はもう一つのプログラムが記憶されたデータにアクセス
することを欲しないときに、この呼び出しがなされるべ
きである。
する 呼び出しのためにセットすべきレジスタ: AH=3 セットオンリターンとしてのレジスタ: セットオンリターンなし 呼び出し人が、新しいデータを記憶しようとするか或い
はもう一つのプログラムが記憶されたデータにアクセス
することを欲しないときに、この呼び出しがなされるべ
きである。
【0045】機能4:ホルダーの現行ステータスを得る 呼び出しのためにセットすべきレジスタ: AH=4 このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ: BX=(バイトにおける)内部バッファの大きさ CX=内部バッファ内に記憶される現行のバイトの数 DH=先のオペレーションからのエラーコード DL=バッファ内に記憶されるデータの識別子コード これは、要求されるオペレーションが首尾よく履行され
たことを保証するために、各オペレーションの後になさ
れるべきである。
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ: BX=(バイトにおける)内部バッファの大きさ CX=内部バッファ内に記憶される現行のバイトの数 DH=先のオペレーションからのエラーコード DL=バッファ内に記憶されるデータの識別子コード これは、要求されるオペレーションが首尾よく履行され
たことを保証するために、各オペレーションの後になさ
れるべきである。
【0046】機能5:同じ識別子を伴うデータの次のブ
ロックを得る 呼び出しのためにセットすべきレジスタ: AH=5 CX=回復されるべきバイトの数 ES:DI=行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 セットオンリターンとしてのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。
ロックを得る 呼び出しのためにセットすべきレジスタ: AH=5 CX=回復されるべきバイトの数 ES:DI=行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 セットオンリターンとしてのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。
【0047】機能100:ホルダーのバージョン及び署
名を得る 呼び出しのためにセットすべきレジスタ: AH=5 このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ: CX=TSR署名(6996) DH=TSRの主要なバージョン数 DL=TSRの主要でないバージョン数 例:バージョン1.2−−DH=1及びDL=2 このオペレーションは、ホルダーのベクトルにおけるコ
ードが現実にホルダであることを保証するために呼び出
されるべきである。
名を得る 呼び出しのためにセットすべきレジスタ: AH=5 このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ: CX=TSR署名(6996) DH=TSRの主要なバージョン数 DL=TSRの主要でないバージョン数 例:バージョン1.2−−DH=1及びDL=2 このオペレーションは、ホルダーのベクトルにおけるコ
ードが現実にホルダであることを保証するために呼び出
されるべきである。
【0048】専用バッファ機能: 機能101:ホルダーのバッファから記憶されたデータ
を得る 呼び出しのためにセットすべきレジスタ: AH=101 CX=回復されるべきバイトの数 ES:DI=行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 復セットオンリターンとしてのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。
この機能を呼び出す前に、記憶されたデータが現行のプ
ログラムに対してであることを確かめるためにホルダー
の現行のステータスを得ることは賢明である。
を得る 呼び出しのためにセットすべきレジスタ: AH=101 CX=回復されるべきバイトの数 ES:DI=行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 復セットオンリターンとしてのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。
この機能を呼び出す前に、記憶されたデータが現行のプ
ログラムに対してであることを確かめるためにホルダー
の現行のステータスを得ることは賢明である。
【0049】機能102:ホルダーのバッファ内にデー
タを置く 呼び出しのためにセットすべきレジスタ: AH=102 CX=記憶されるべきバイトの数 DL=識別子コード(0=アンタイプド) ES:DI=ソースアドレス CXにおける値はバッファの大きさ以下でなければなら
ないことに注目せよ。もしもCXが零に等しければ、バ
ッファは削除される。 セットオンリターンとしてのレジスタ: CX=実際に記憶されるバイトの数 非常にしばしば、そのバッファ内にデータを記憶するた
めの最上の方法は正式のC構成と共にあるであろう。ホ
ルダーの見地からは、送られるどのようなデータも一つ
の流れのバイトにすぎず、ホルダーは理解することを試
みない。識別子コードは、もう一つのプログラムのため
に、記憶されたデータが利益があるかどうかを確認する
のに使用されるべきである。
タを置く 呼び出しのためにセットすべきレジスタ: AH=102 CX=記憶されるべきバイトの数 DL=識別子コード(0=アンタイプド) ES:DI=ソースアドレス CXにおける値はバッファの大きさ以下でなければなら
ないことに注目せよ。もしもCXが零に等しければ、バ
ッファは削除される。 セットオンリターンとしてのレジスタ: CX=実際に記憶されるバイトの数 非常にしばしば、そのバッファ内にデータを記憶するた
めの最上の方法は正式のC構成と共にあるであろう。ホ
ルダーの見地からは、送られるどのようなデータも一つ
の流れのバイトにすぎず、ホルダーは理解することを試
みない。識別子コードは、もう一つのプログラムのため
に、記憶されたデータが利益があるかどうかを確認する
のに使用されるべきである。
【0050】機能103:ホルダーの内部バッファをク
リアする 呼び出しのためにセットすべきレジスタ: AH=103 セットオンリターンとしてのレジスタ: セットオンリターンなし 呼び出し人が、新しいデータを記憶しようとするか或い
はもう一つのプログラムが記憶されたデータにアクセス
することを欲しないときに、この呼び出しがなされるべ
きである。
リアする 呼び出しのためにセットすべきレジスタ: AH=103 セットオンリターンとしてのレジスタ: セットオンリターンなし 呼び出し人が、新しいデータを記憶しようとするか或い
はもう一つのプログラムが記憶されたデータにアクセス
することを欲しないときに、この呼び出しがなされるべ
きである。
【0051】機能104:ホルダーの現行ステータスを
得る 呼び出しのためにセットすべきレジスタ: AH=104 このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ: BX=(バイトにおける)内部バッファの大きさ CX=内部バッファ内に記憶される現行のバイトの数 DH=先のオペレーションからのエラーコード DL=バッファ内に記憶されるデータの識別子コード これは、要求されるオペレーションが首尾よく履行され
たことを保証するために、各オペレーションの後になさ
れるべきである。
得る 呼び出しのためにセットすべきレジスタ: AH=104 このルーチンは再入可能でありそして再帰的に呼び出さ
れ得ることに注目せよ。 セットオンリターンとしてのレジスタ: BX=(バイトにおける)内部バッファの大きさ CX=内部バッファ内に記憶される現行のバイトの数 DH=先のオペレーションからのエラーコード DL=バッファ内に記憶されるデータの識別子コード これは、要求されるオペレーションが首尾よく履行され
たことを保証するために、各オペレーションの後になさ
れるべきである。
【0052】機能105:同じ識別子を伴うデータの次
のブロックを得る 呼び出しのためにセットすべきレジスタ: AH=105 CX=回復されるべきバイトの数 ES:DI=行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 セットオンリターンとしてのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。 次のエラーはステータス復帰として報告され得る: 1 価値のないホルダー機能呼び出し 2 より多くのデータに対するバッファ内の空き
がない 3 ホルダーはビジー 201 システム割り込みエラー 202 要求される識別子は見出されなかった
のブロックを得る 呼び出しのためにセットすべきレジスタ: AH=105 CX=回復されるべきバイトの数 ES:DI=行き先のアドレス その行き先は、すべての要求されるデータを保持するに
十分な程広くなければならないことに注目せよ。 セットオンリターンとしてのレジスタ: CX=実際に転送されるバイトの数 もしもCXが零に等しいならば、そのバッファは空であ
りそして転送されるデータはなかったことに注目せよ。 次のエラーはステータス復帰として報告され得る: 1 価値のないホルダー機能呼び出し 2 より多くのデータに対するバッファ内の空き
がない 3 ホルダーはビジー 201 システム割り込みエラー 202 要求される識別子は見出されなかった
【0053】図9は、ホルダープログラムのプログラム
図を示す。カーネルプログラム或いは応用プログラムの
いずれかが、プログラムされた割り込み63hを実行す
ることにより、ホルダープログラムを呼び出し得る。ブ
ロック102にて、試験が、どんな動作が呼び出しプロ
グラムにより要求されつつあるかを決定するために、レ
ジスタAHからなされる。もしも要求コードが、決定ブ
ロック104により決定されるパブリック機能の一つに
対してならば、そのときには、ブロック106及び10
8により表されるオペレーションが実行される。もしも
要求コードが決定ブロック110により決定される専用
機能の一つに対してならば、そのときには、ブロック1
12及び114により呼び出されるオペレーションが実
行される。専用機能は動的スケジューリングを維持する
が、パブリック機能、即ち、パブリックバッファ上で実
行されるオペレーションはプログラム間連絡を維持する
ということを思い起こせ。もしもブロック116の試験
が、要求コードが100に等しいと決定するならば、ブ
ロック118のオペレーションはホルダープログラムの
署名及びバージョンを回復するために実行される。もし
も要求コードが無効であるならば、ブロック120のオ
ペレーションは無効な要求ステータスを記憶するために
実行される。そのプログラムを通る各パスが、呼び出し
プログラムにより要求される情報を、ホルダーコマンド
機能により指定される中央演算処理装置のレジスタ内に
ロードする。ホルダープログラムは、プログラム122
にて割り込み指令からの復帰を実行することにより終了
し、これによって、制御を呼び出しプログラムに戻す。
図を示す。カーネルプログラム或いは応用プログラムの
いずれかが、プログラムされた割り込み63hを実行す
ることにより、ホルダープログラムを呼び出し得る。ブ
ロック102にて、試験が、どんな動作が呼び出しプロ
グラムにより要求されつつあるかを決定するために、レ
ジスタAHからなされる。もしも要求コードが、決定ブ
ロック104により決定されるパブリック機能の一つに
対してならば、そのときには、ブロック106及び10
8により表されるオペレーションが実行される。もしも
要求コードが決定ブロック110により決定される専用
機能の一つに対してならば、そのときには、ブロック1
12及び114により呼び出されるオペレーションが実
行される。専用機能は動的スケジューリングを維持する
が、パブリック機能、即ち、パブリックバッファ上で実
行されるオペレーションはプログラム間連絡を維持する
ということを思い起こせ。もしもブロック116の試験
が、要求コードが100に等しいと決定するならば、ブ
ロック118のオペレーションはホルダープログラムの
署名及びバージョンを回復するために実行される。もし
も要求コードが無効であるならば、ブロック120のオ
ペレーションは無効な要求ステータスを記憶するために
実行される。そのプログラムを通る各パスが、呼び出し
プログラムにより要求される情報を、ホルダーコマンド
機能により指定される中央演算処理装置のレジスタ内に
ロードする。ホルダープログラムは、プログラム122
にて割り込み指令からの復帰を実行することにより終了
し、これによって、制御を呼び出しプログラムに戻す。
【0054】いくつかの特徴がホルダープログラムに合
併されてそれをコンパクトに、能率よくそして万能にす
る。各バッファ、即ち、一キロバイト専用バッファ及び
一キロバイトパブリックバッファに対しては、識別子及
び各スロットのためのブロックサイズを含むスロットテ
ーブルが維持される。そのスロットテーブルは、与えら
れたスロットに対する一つに加え、データの終わりに対
応するバッファアドレスを含む。各スロットテーブルに
対しては、そのホルダープログラムが、現行のスロット
インデックス及び次のスロットインデックスの二つのイ
ンデックスを維持する。スロットテーブル及びそのイン
デックスが次のように初期化される。 スロット 0 1 2 3 ・・・ 31 0 1024 1024 1024 1024 現行スロット=0 次のスロット=0
併されてそれをコンパクトに、能率よくそして万能にす
る。各バッファ、即ち、一キロバイト専用バッファ及び
一キロバイトパブリックバッファに対しては、識別子及
び各スロットのためのブロックサイズを含むスロットテ
ーブルが維持される。そのスロットテーブルは、与えら
れたスロットに対する一つに加え、データの終わりに対
応するバッファアドレスを含む。各スロットテーブルに
対しては、そのホルダープログラムが、現行のスロット
インデックス及び次のスロットインデックスの二つのイ
ンデックスを維持する。スロットテーブル及びそのイン
デックスが次のように初期化される。 スロット 0 1 2 3 ・・・ 31 0 1024 1024 1024 1024 現行スロット=0 次のスロット=0
【0055】もしも、例えば、ホルダープログラムがコ
マンドを受けて次のスロットにて20バイトのデータを
記憶するならば、そのデータはアドレス0乃至19にて
バッファ内に入力され、次のスロットインデックスがイ
ンレクメントされ、そしてそのスロットテーブルが次の
ように更新される。 スロット 0 1 2 3 ・・・ 31 0 20 1024 1024 1024 現行スロット=0 次のスロット=1 もしも、例えば、ホルダープログラムが次にコマンドを
受けて次のスロットにて30バイトのデータを記憶する
ならば、このデータは、次のスロットインデックスの値
により指定されるように、スロットテーブルのスロット
1の内容でアドレス20にて開始するバッファ内に記憶
される。現行のスロットインデックス及び次のスロット
インデックスの双方がインクレメントされそしてそのス
ロットが次のように更新される。 スロット 0 1 2 3 ・・・ 31 0 20 50 1024 1024 現行スロット=1 次のスロット=2
マンドを受けて次のスロットにて20バイトのデータを
記憶するならば、そのデータはアドレス0乃至19にて
バッファ内に入力され、次のスロットインデックスがイ
ンレクメントされ、そしてそのスロットテーブルが次の
ように更新される。 スロット 0 1 2 3 ・・・ 31 0 20 1024 1024 1024 現行スロット=0 次のスロット=1 もしも、例えば、ホルダープログラムが次にコマンドを
受けて次のスロットにて30バイトのデータを記憶する
ならば、このデータは、次のスロットインデックスの値
により指定されるように、スロットテーブルのスロット
1の内容でアドレス20にて開始するバッファ内に記憶
される。現行のスロットインデックス及び次のスロット
インデックスの双方がインクレメントされそしてそのス
ロットが次のように更新される。 スロット 0 1 2 3 ・・・ 31 0 20 50 1024 1024 現行スロット=1 次のスロット=2
【0056】もしもホルダープログラムがコマンドを受
けて現行のスロットにおけるデータを削除するならば、
次のスロットから現行のスロットを引いた内容が現行ス
ロット内に置かれ、そしてバッファ内のデータがこの変
化を反映するように移される。この処理過程は、最初の
非使用スロットが出くわされるまで、即ち、スロットテ
ーブル入力の内容が1024に等しくなるまで、各連続
のスロットに対して繰り返される。「ガーベージコレク
ション」としての技術にて知られているこのバッファ管
理の方法は、さもなけらば、スロットインデックス及び
スロットテーブル入力を使用して、メッセージの始め及
び終わりをホルダープログラムに容易に確認させる一
方、メッセージデータの大きさに適合するようにスロッ
トの境界を連続的に調整することを許容する。
けて現行のスロットにおけるデータを削除するならば、
次のスロットから現行のスロットを引いた内容が現行ス
ロット内に置かれ、そしてバッファ内のデータがこの変
化を反映するように移される。この処理過程は、最初の
非使用スロットが出くわされるまで、即ち、スロットテ
ーブル入力の内容が1024に等しくなるまで、各連続
のスロットに対して繰り返される。「ガーベージコレク
ション」としての技術にて知られているこのバッファ管
理の方法は、さもなけらば、スロットインデックス及び
スロットテーブル入力を使用して、メッセージの始め及
び終わりをホルダープログラムに容易に確認させる一
方、メッセージデータの大きさに適合するようにスロッ
トの境界を連続的に調整することを許容する。
【0057】これは、大きな仮想メールボックス容量を
提供するように使用される相対的に小さなバッファを許
容する。どのようなスロットも、全体の一キロバイトバ
ッファスペースのどのような部分を使用してもよく、そ
してどのようなスロットの内容も、現実のデータ、ラン
ダムアクセスメモリにおけるどこか他の所でデータの位
置を確認するべクトル、或いはディスクメモリ内のデー
タの位置を確認するファイルハンドルのいずれかであっ
てもよい。好ましくは、これらの約束が、与えられたス
ロットの内容に適用されるような識別子が解釈するため
に使用される。ディスク上にデータを記憶することは、
より一層価値あるランダムアクセスメモリスペースを維
持する一方、スロット内に、直接、データを記憶するこ
とは、最も速い応答を提供する。かくして、公共のメイ
ルボックス設備、即ち応用プログラムの各ユーザが、共
同のパブリックバッファスペース上に置かれた要求を伴
う実行に対する必要性を賢明に釣り合わせ得るので、全
体のバッファスペースは相対的に小さくし得る。識別子
は、ホルダープログラムを、それを速くコンパクトに使
用して、簡単化するメールボックスアドレスの形を提供
する。ホルダープログラムのオペレーションは、非常に
制限されそして簡単なセットの規則を使用して情報を記
憶しそして回復させ得るファイル係に類似している。ホ
ルダープログラムはまた、パブリック及び専用の各バッ
ファの双方に対する同じようなバッファ構成及び制御戦
略を使用して、コンパクトに作られ、これにより、共有
されるべきプログラムコードの部分を許容する。
提供するように使用される相対的に小さなバッファを許
容する。どのようなスロットも、全体の一キロバイトバ
ッファスペースのどのような部分を使用してもよく、そ
してどのようなスロットの内容も、現実のデータ、ラン
ダムアクセスメモリにおけるどこか他の所でデータの位
置を確認するべクトル、或いはディスクメモリ内のデー
タの位置を確認するファイルハンドルのいずれかであっ
てもよい。好ましくは、これらの約束が、与えられたス
ロットの内容に適用されるような識別子が解釈するため
に使用される。ディスク上にデータを記憶することは、
より一層価値あるランダムアクセスメモリスペースを維
持する一方、スロット内に、直接、データを記憶するこ
とは、最も速い応答を提供する。かくして、公共のメイ
ルボックス設備、即ち応用プログラムの各ユーザが、共
同のパブリックバッファスペース上に置かれた要求を伴
う実行に対する必要性を賢明に釣り合わせ得るので、全
体のバッファスペースは相対的に小さくし得る。識別子
は、ホルダープログラムを、それを速くコンパクトに使
用して、簡単化するメールボックスアドレスの形を提供
する。ホルダープログラムのオペレーションは、非常に
制限されそして簡単なセットの規則を使用して情報を記
憶しそして回復させ得るファイル係に類似している。ホ
ルダープログラムはまた、パブリック及び専用の各バッ
ファの双方に対する同じようなバッファ構成及び制御戦
略を使用して、コンパクトに作られ、これにより、共有
されるべきプログラムコードの部分を許容する。
【0058】図10及び図11〜図15は、図9におけ
るブロック104及び106により表されるオペレーシ
ョンのより詳細なブロック図を示す。図10のフローチ
ャートにより表されるソフトウェアは、レジスタDLに
渡される識別子の値を試験することにより要求される指
定された機能を解釈し、そしてそれから、パブ(Pu
b)A〜パブEとして明示されているように、ブロック
142−150により表されるそれぞれの入力点に分岐
していく。図11〜図15の各々はこれらの入力点の一
つに対応する。パブリックバッファAからのデータを得
る要求が受け取られたならば、ブロック160(図1
1)により表されるオペレーションが実行され、パブリ
ックスロットテーブルを連続的に探索し、例えあるとし
ても、マッチング識別子の最初の発生を見出すにすぎな
い。もしもなにも見出されなければ、制御がブロック1
64に進められてエラーステータスを記憶する。もしも
識別子が見出されれば、ブロック166のオペレーショ
ンが実行され、スロットテーブルをアクセスしてパブリ
ックバッファ内のスロットデータの位置を見出す。それ
から、スロットデータが、パブリックバッファ内のその
スロットの位置から、レジスタES及びDIを介して呼
び出しプログラムにより指定された行き先の位置に移さ
れる。ブロック168のオペレーションが実行されると
き、それはデータの首尾よき転送のステータスを記憶す
る。パブリックバッファ内にデータを記憶する要求が受
け取られたならば、オペレーション180が実行され、
パブリックバッファ内の自由なスペースを、記憶される
ように要求されるバイトの数を含むレジスタCXの内容
と比較する(図12)。もしも満足すべき十分な自由ス
ペースがあるならば、要求ステップ182が実行され、
新しい入力を、識別子及びスロットの大きさ、即ち記憶
されるべきバイトの数からなるスロットテーブルにアペ
ンドする。ブロック184及び186により呼び出され
るオペレーションはDS及びSIレジスタの内容を使用
して、記憶されるべきデータのソースを突き止め、そし
てスロットテーブルの内容を使用してパブリックバッフ
ァ内のデータの行き先を突き止めて、その転送を実行す
る。スロットテーブル及びパブリックバッファは、今、
必要な情報を含み、もう一つの応用プログラムに、先に
述べた獲得データ機能を使用して、記憶されたデータを
回復させる。ブロック188により示されるオペレーシ
ョンの実行はデータの首尾よき転送のステータスを記憶
する。
るブロック104及び106により表されるオペレーシ
ョンのより詳細なブロック図を示す。図10のフローチ
ャートにより表されるソフトウェアは、レジスタDLに
渡される識別子の値を試験することにより要求される指
定された機能を解釈し、そしてそれから、パブ(Pu
b)A〜パブEとして明示されているように、ブロック
142−150により表されるそれぞれの入力点に分岐
していく。図11〜図15の各々はこれらの入力点の一
つに対応する。パブリックバッファAからのデータを得
る要求が受け取られたならば、ブロック160(図1
1)により表されるオペレーションが実行され、パブリ
ックスロットテーブルを連続的に探索し、例えあるとし
ても、マッチング識別子の最初の発生を見出すにすぎな
い。もしもなにも見出されなければ、制御がブロック1
64に進められてエラーステータスを記憶する。もしも
識別子が見出されれば、ブロック166のオペレーショ
ンが実行され、スロットテーブルをアクセスしてパブリ
ックバッファ内のスロットデータの位置を見出す。それ
から、スロットデータが、パブリックバッファ内のその
スロットの位置から、レジスタES及びDIを介して呼
び出しプログラムにより指定された行き先の位置に移さ
れる。ブロック168のオペレーションが実行されると
き、それはデータの首尾よき転送のステータスを記憶す
る。パブリックバッファ内にデータを記憶する要求が受
け取られたならば、オペレーション180が実行され、
パブリックバッファ内の自由なスペースを、記憶される
ように要求されるバイトの数を含むレジスタCXの内容
と比較する(図12)。もしも満足すべき十分な自由ス
ペースがあるならば、要求ステップ182が実行され、
新しい入力を、識別子及びスロットの大きさ、即ち記憶
されるべきバイトの数からなるスロットテーブルにアペ
ンドする。ブロック184及び186により呼び出され
るオペレーションはDS及びSIレジスタの内容を使用
して、記憶されるべきデータのソースを突き止め、そし
てスロットテーブルの内容を使用してパブリックバッフ
ァ内のデータの行き先を突き止めて、その転送を実行す
る。スロットテーブル及びパブリックバッファは、今、
必要な情報を含み、もう一つの応用プログラムに、先に
述べた獲得データ機能を使用して、記憶されたデータを
回復させる。ブロック188により示されるオペレーシ
ョンの実行はデータの首尾よき転送のステータスを記憶
する。
【0059】図13はホルダーの「ガーベージコレクシ
ョン」の機能を示す。これは、小さなバッファにより非
常に有効な使用を提供する。ガーベージコレクション
は、必要に応じて、外部の仲介なしに起こり、バッファ
スペースの増大を阻止する。パブリックバッファから現
行のスロットをクリアするための要求が受け取られたな
らば、オペレーション200(図13)が実行され、現
行のスロットを越えて次のスロットの内容を複写する。
オペレーション202は、スロットテーブルを更新し、
次のスロットデータのパブリックバッファ内の新しい位
置に反映させる。次に、ブロック200及び202によ
り呼び出されるオペレーションは、決定ブロック204
にてなされる試験が次のスロットが空であると決定する
まで、繰り返される。もし決定されれば、オペレーショ
ン208がスロットテーブル内に入力されるパブリック
バッファの新しい状態に終わる一方、オペレーション2
06が使用されていないバッファスペースをクリアす
る。この点において、パブリックバッファが、データが
現行のスロットに最後に記憶される直前に実行した状態
に復帰されている。ブロック210にて示されるオペレ
ーションの実行は首尾のよいクリアオペレーションのス
テータスを記憶する。
ョン」の機能を示す。これは、小さなバッファにより非
常に有効な使用を提供する。ガーベージコレクション
は、必要に応じて、外部の仲介なしに起こり、バッファ
スペースの増大を阻止する。パブリックバッファから現
行のスロットをクリアするための要求が受け取られたな
らば、オペレーション200(図13)が実行され、現
行のスロットを越えて次のスロットの内容を複写する。
オペレーション202は、スロットテーブルを更新し、
次のスロットデータのパブリックバッファ内の新しい位
置に反映させる。次に、ブロック200及び202によ
り呼び出されるオペレーションは、決定ブロック204
にてなされる試験が次のスロットが空であると決定する
まで、繰り返される。もし決定されれば、オペレーショ
ン208がスロットテーブル内に入力されるパブリック
バッファの新しい状態に終わる一方、オペレーション2
06が使用されていないバッファスペースをクリアす
る。この点において、パブリックバッファが、データが
現行のスロットに最後に記憶される直前に実行した状態
に復帰されている。ブロック210にて示されるオペレ
ーションの実行は首尾のよいクリアオペレーションのス
テータスを記憶する。
【0060】もしも「獲得に対する要求」のステータス
が受け取られたならば、ブロック220(図14)のオ
ペレーションが実行され、オペレーション168、18
8、210或いは236の実行中に記憶されたステータ
スを回復させ、そしてそれを応用プログラムに戻す。ま
た、パブリックバッファの大きさ、パブリックバッファ
に実際に記憶されているバイトの数及び現行のスロット
に記憶されているデータの識別子が復帰される。パブリ
ックバッファの次のスロットからの同じような形、即ち
同じような識別子をもつ「獲得データに対する要求」が
受け取られたならば、プログラム230のオペレーショ
ンが実行され、バッファスロットテーブルを連続的に探
索せしめて、もしあれば、マッチング識別子の次の発生
を見出す。もしもブロック232にて確認される試験に
より決定されるとき、なにも見出されなければ、ブロッ
ク233のオペレーションが実行されてエラーステータ
スを記憶する。さもなければ、スロットテーブルがアク
セスされてパブリックバッファ内のスロットデータの位
置を見出す(ブロック234)。それから、スロットデ
ータが、パブリックバッファ内のそのスロット位置か
ら、呼び出しプログラムにより指定される行き先位置
に、レジスタES及びDIを介して移される。ブロック
236のオペレーションはデータの首尾のよい転送を記
憶する。
が受け取られたならば、ブロック220(図14)のオ
ペレーションが実行され、オペレーション168、18
8、210或いは236の実行中に記憶されたステータ
スを回復させ、そしてそれを応用プログラムに戻す。ま
た、パブリックバッファの大きさ、パブリックバッファ
に実際に記憶されているバイトの数及び現行のスロット
に記憶されているデータの識別子が復帰される。パブリ
ックバッファの次のスロットからの同じような形、即ち
同じような識別子をもつ「獲得データに対する要求」が
受け取られたならば、プログラム230のオペレーショ
ンが実行され、バッファスロットテーブルを連続的に探
索せしめて、もしあれば、マッチング識別子の次の発生
を見出す。もしもブロック232にて確認される試験に
より決定されるとき、なにも見出されなければ、ブロッ
ク233のオペレーションが実行されてエラーステータ
スを記憶する。さもなければ、スロットテーブルがアク
セスされてパブリックバッファ内のスロットデータの位
置を見出す(ブロック234)。それから、スロットデ
ータが、パブリックバッファ内のそのスロット位置か
ら、呼び出しプログラムにより指定される行き先位置
に、レジスタES及びDIを介して移される。ブロック
236のオペレーションはデータの首尾のよい転送を記
憶する。
【0061】専用バッファ機能はパブリックバッファ機
能に十分に対応し、オペレーションが専用バッファ上で
実行されるということのみにおいて異なる。より好まし
いカーネルプログラムの要求を最小限に満足させるより
少ない可能性の専用バッファ構成を使用することは可能
であるが、そうすることは好ましくない。それが如何に
簡単であるかにかかわらず、異なる専用バッファ構成が
ホルダープログラムコードの共有を減少させそして、か
くして、その大きさを増加させる。さらに、専用バッフ
ァに対するパブリックバッファ構成の融通性を維持する
ことは有益である。それは、未だ予期されてない新しい
機能を仮定する一方、本発明のソフトウェアに後ろ向き
の互換性を維持させるより先の開いた構成を提供するか
らである。
能に十分に対応し、オペレーションが専用バッファ上で
実行されるということのみにおいて異なる。より好まし
いカーネルプログラムの要求を最小限に満足させるより
少ない可能性の専用バッファ構成を使用することは可能
であるが、そうすることは好ましくない。それが如何に
簡単であるかにかかわらず、異なる専用バッファ構成が
ホルダープログラムコードの共有を減少させそして、か
くして、その大きさを増加させる。さらに、専用バッフ
ァに対するパブリックバッファ構成の融通性を維持する
ことは有益である。それは、未だ予期されてない新しい
機能を仮定する一方、本発明のソフトウェアに後ろ向き
の互換性を維持させるより先の開いた構成を提供するか
らである。
【0062】次の議論は、基本的な制御プログラムの変
形無しに付加的な機能性を組み入れるための本発明の代
わりの実施例及び本発明の融通性の例示の双方である。
TSRプログラム クロン(CHRON)はコンピュー
タのリアルタイムクロックの値に関連付けられる動的な
スケジューリングの能力を付加する。クロンプログラム
上の機能は、時間刻印をしたメッセージに対しパブリッ
クバッファを周期的に走査し、指示された時間にて、こ
れらのメッセージを解釈して、専用バッファ内に含まれ
る実行の流れに付加されるべき実行可能なメッセージを
構成する。メニュープログラムを含むどのような応用プ
ログラムも、時間を刻印したメッセージをパブリックバ
ッファ内に置き得る。そのようなメッセージは、指定さ
れた将来の時間にて一度応用プログラムを実行するため
の指令であり得る。代わりとして、メッセージは、指定
された未来時間にて開始する指定された間隔にて、応用
プログラムの実行をN回或いは不定回数指示し得る。時
間を刻印したメッセージは、それらの識別子の値により
区別される。図16はクロンプログラムのフローチャー
トを示す。入力点250は、割り込みベクトルテーブル
が、クロンプログラムが正常なタイマー割り込みのため
に意図される割り込みベクトルを遮断するように変更さ
れていることを示している。これは、クロンプログラム
に、呼び出させる、即ち、それが1秒につき18.2回
毎に、即ち、さもなければ正常なタイマー割り込みが呼
び出されるときに、「ウェークアップ」の呼び出しを得
る。各0.05秒の間隔にてクロンルーチンを実行する
ことが可能であるが、このことが、利益のないオーバー
ヘッドを処理することを付加する。むしろ、ブロック2
54により表されるオペレーションは各ウェークアップ
呼び出しを計数し、そして第n番目のウェークアップ呼
び出しに対してのみ制御をブロック256に進める。例
えば、もしもnが1000に等しければ、制御は50秒
毎にブロック256のオペレーションに進む。すべての
介在ウェークアップ呼び出しに対して、制御は、次の時
間割り込みの取扱者に直接進められる。ブロック256
にて、ホルダープログラムが呼び出されて、次のスロッ
トが時間を刻印したメッセージを含むかどうかを決定す
る。もしもそうでなければ、そのときには、ブロック2
60のオペレーションが、CXレジスタの値を試験する
ことによりパブリックバッファ内により多くのメッセー
ジがあるかどうかを決定する。このレジスタは、もしも
走査されるべきより多くのデータがなければ、零の値で
もって復帰されたであろうことを思い起こせ。この結果
において、制御は次のタイマー割り込みの取扱者に進
む。さもなければ、プログラムはブロック256に戻
る。もしクロンメッセージが見出されれば、時間の刻印
が試験されて、今、それがメッセージを実行する時刻が
どうかを決定する。もしもそうでなければ、プログラム
は、オペレーションブロック260に対して述べた方法
にて、ブロック264を介して、オペレーション256
に条件付きで戻る。今、メッセージを実行する時刻であ
ることを決定するとき、制御は、カーネルプログラムの
ための実行可能なメッセージを創作するブロック266
に進む。明確には、クロンプログラムにおいて見出され
る応用プログラムの名が専用バッファに付加されて実行
の流れの一部になる。
形無しに付加的な機能性を組み入れるための本発明の代
わりの実施例及び本発明の融通性の例示の双方である。
TSRプログラム クロン(CHRON)はコンピュー
タのリアルタイムクロックの値に関連付けられる動的な
スケジューリングの能力を付加する。クロンプログラム
上の機能は、時間刻印をしたメッセージに対しパブリッ
クバッファを周期的に走査し、指示された時間にて、こ
れらのメッセージを解釈して、専用バッファ内に含まれ
る実行の流れに付加されるべき実行可能なメッセージを
構成する。メニュープログラムを含むどのような応用プ
ログラムも、時間を刻印したメッセージをパブリックバ
ッファ内に置き得る。そのようなメッセージは、指定さ
れた将来の時間にて一度応用プログラムを実行するため
の指令であり得る。代わりとして、メッセージは、指定
された未来時間にて開始する指定された間隔にて、応用
プログラムの実行をN回或いは不定回数指示し得る。時
間を刻印したメッセージは、それらの識別子の値により
区別される。図16はクロンプログラムのフローチャー
トを示す。入力点250は、割り込みベクトルテーブル
が、クロンプログラムが正常なタイマー割り込みのため
に意図される割り込みベクトルを遮断するように変更さ
れていることを示している。これは、クロンプログラム
に、呼び出させる、即ち、それが1秒につき18.2回
毎に、即ち、さもなければ正常なタイマー割り込みが呼
び出されるときに、「ウェークアップ」の呼び出しを得
る。各0.05秒の間隔にてクロンルーチンを実行する
ことが可能であるが、このことが、利益のないオーバー
ヘッドを処理することを付加する。むしろ、ブロック2
54により表されるオペレーションは各ウェークアップ
呼び出しを計数し、そして第n番目のウェークアップ呼
び出しに対してのみ制御をブロック256に進める。例
えば、もしもnが1000に等しければ、制御は50秒
毎にブロック256のオペレーションに進む。すべての
介在ウェークアップ呼び出しに対して、制御は、次の時
間割り込みの取扱者に直接進められる。ブロック256
にて、ホルダープログラムが呼び出されて、次のスロッ
トが時間を刻印したメッセージを含むかどうかを決定す
る。もしもそうでなければ、そのときには、ブロック2
60のオペレーションが、CXレジスタの値を試験する
ことによりパブリックバッファ内により多くのメッセー
ジがあるかどうかを決定する。このレジスタは、もしも
走査されるべきより多くのデータがなければ、零の値で
もって復帰されたであろうことを思い起こせ。この結果
において、制御は次のタイマー割り込みの取扱者に進
む。さもなければ、プログラムはブロック256に戻
る。もしクロンメッセージが見出されれば、時間の刻印
が試験されて、今、それがメッセージを実行する時刻が
どうかを決定する。もしもそうでなければ、プログラム
は、オペレーションブロック260に対して述べた方法
にて、ブロック264を介して、オペレーション256
に条件付きで戻る。今、メッセージを実行する時刻であ
ることを決定するとき、制御は、カーネルプログラムの
ための実行可能なメッセージを創作するブロック266
に進む。明確には、クロンプログラムにおいて見出され
る応用プログラムの名が専用バッファに付加されて実行
の流れの一部になる。
【0063】実行メッセージは、クロンメッセージから
抽出される先行データの色々な形を任意に含み得る。も
しも先行データが専用バッファ内で有効に作られるなら
ば、そのときには、どのような応用プログラムも、実行
されている限り、専用バッファを周期的に調べて、クロ
ンプログラムが実行の流れにより高い先行プログラムを
いつ付加したかを検出する。これは、より低い先行プロ
グラムに対しその機会を提供して実行されるべきより高
い先行プログラムを許容することに終わる。
抽出される先行データの色々な形を任意に含み得る。も
しも先行データが専用バッファ内で有効に作られるなら
ば、そのときには、どのような応用プログラムも、実行
されている限り、専用バッファを周期的に調べて、クロ
ンプログラムが実行の流れにより高い先行プログラムを
いつ付加したかを検出する。これは、より低い先行プロ
グラムに対しその機会を提供して実行されるべきより高
い先行プログラムを許容することに終わる。
【0064】専用バッファ機能は、パブリックバッファ
機能に十分に対応し、オペレーションが専用バッファ上
で実行されるということにおいてのみ異なる。より好ま
しいカーネルプログラムの要求を最小限に満たすより少
ない可能性の専用バッファ構成を使用することは可能で
あるが、そうすることは好ましくない。それが如何に簡
単であるかにかかわらず、異なる専用バッファ構成がホ
ルダープログラムコードの共有を減少させそして、かく
して、その大きさを増加させる。さらに、専用バッファ
に対するパブリックバッファ構成の融通性を維持すこと
は有益である。それは、未だ予期されていない新しい機
能を仮定する一方、後ろ向きの互換性を本発明のソフト
ウェアに維持させるより先の開かれた構成を提供するか
らである。
機能に十分に対応し、オペレーションが専用バッファ上
で実行されるということにおいてのみ異なる。より好ま
しいカーネルプログラムの要求を最小限に満たすより少
ない可能性の専用バッファ構成を使用することは可能で
あるが、そうすることは好ましくない。それが如何に簡
単であるかにかかわらず、異なる専用バッファ構成がホ
ルダープログラムコードの共有を減少させそして、かく
して、その大きさを増加させる。さらに、専用バッファ
に対するパブリックバッファ構成の融通性を維持すこと
は有益である。それは、未だ予期されていない新しい機
能を仮定する一方、後ろ向きの互換性を本発明のソフト
ウェアに維持させるより先の開かれた構成を提供するか
らである。
【0065】この発明は、ここでは、特許法に従い、新
規な原理を適用するために必要とされる情報をその技術
にて熟練した者達に提供し、そして要求されるような特
殊化された構成要素を構成及び使用するためにかなり詳
細に述べられてきた。しかしながら、本発明は明らかに
異なる設備及び装置により成し遂げられること、そして
色々な変形が、設備の詳細及びオペレーション手続の双
方に関して、本発明自体の範囲から逸脱することなく達
成され得る。
規な原理を適用するために必要とされる情報をその技術
にて熟練した者達に提供し、そして要求されるような特
殊化された構成要素を構成及び使用するためにかなり詳
細に述べられてきた。しかしながら、本発明は明らかに
異なる設備及び装置により成し遂げられること、そして
色々な変形が、設備の詳細及びオペレーション手続の双
方に関して、本発明自体の範囲から逸脱することなく達
成され得る。
【図1】本発明の制御プログラム及びそのMSDOS及
び非常駐応用プログラムに対する関連を合併するオペレ
ーションシステムの構成を示すブロック図である。
び非常駐応用プログラムに対する関連を合併するオペレ
ーションシステムの構成を示すブロック図である。
【図2】本図として図3及び図4が配列されるとき、本
発明に応じてカーネルプログラムを示すソフトウェアフ
ローチャートである。
発明に応じてカーネルプログラムを示すソフトウェアフ
ローチャートである。
【図3】同ソフトウェアフローチャートの前段部であ
る。
る。
【図4】同ソフトウェアフローチャートの後段部であ
る。
る。
【図5】本図して図6及び図7が配列されるとき、本発
明の制御プログラムにより与えられるプログラム間連絡
を利用するために設計された何らかの応用プログラム内
でのプログラムの流れを示すソフトウェアフローチャー
トである。
明の制御プログラムにより与えられるプログラム間連絡
を利用するために設計された何らかの応用プログラム内
でのプログラムの流れを示すソフトウェアフローチャー
トである。
【図6】同ソフトウェアフローチャートの前段部であ
る。
る。
【図7】同ソフトウェアフローチャートの後段部であ
る。
る。
【図8】本発明の制御プログラムを利用する応用プログ
ラムに与えられる実行順序制御及びプログラム間連絡を
示すフローチャートである。
ラムに与えられる実行順序制御及びプログラム間連絡を
示すフローチャートである。
【図9】本発明の全体の制御プログラムの一部を形成す
るホルダープログラムのソフトウェアフローチャートで
ある。
るホルダープログラムのソフトウェアフローチャートで
ある。
【図10】パブリックバッファ内に含まれそして記憶さ
れた識別子を使用して要求される機能の解釈を示す一般
的なソフトウェアフローチャートである。
れた識別子を使用して要求される機能の解釈を示す一般
的なソフトウェアフローチャートである。
【図11】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
【図12】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
【図13】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
【図14】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
【図15】パブリックバッファを介しホルダープログラ
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
ムにより意図される機能解釈の結果に依存して利用でき
る色々なオプションを表すより詳細なソフトウェアフロ
ーチャートである。
【図16】クロンプログラムを示すソフトウェアフロー
チャートである。
チャートである。
Claims (7)
- 【請求項1】 MSDOS型ディスクオペレーティング
システムを記憶するためのランダムアクセスメモリ及び
リアルタイムの割り込みを発生するためのリアルタイム
クロックを合併するアイビーエム(IBM)コンパチブ
ル型マイクロコンピュータにおいて、従属の応用プログ
ラムのオペレティング環境を拡張しそして強化するため
の制御プログラムであって、 (a)プログラム間メッセージを記憶するための前記ラ
ンダムアクセスメモリ内に常駐の固定された容量の第1
のバッファと、 (b)条件付きで指定される実行順序を表すデータを記
憶するための前記ランダムアクセスメモリ内に常駐の固
定された容量の第2のバッファと、 (c)第1の予め定めたコマンドプロトコルに応じて前
記第1のバッファへ及び同バッファからのデータの転送
を制御するための第1のサブプログラムであって、第2
の予め定めたコマンドプロトコルに応じて前記第2のバ
ッファへ及び同バッファからのデータの転送をさらに制
御する第1のサブプログラムと、そして (d)前記第2のバッファの内容に応じて複数の別個の
そして従属(子供)の応用プログラムの実行の順序を制
御する第2のサブプログラムとからなり、 これにより、前記従属の応用プログラムが前記第1のバ
ッファを介し連絡することを許容される制御プログラ
ム。 - 【請求項2】 前記第1のサブプログラムを規定するコ
ードが最小化される程に、前記第1の予め定めたコマン
ドプロトコルが、前記第2の予め定めたコマンドプロト
コルと実質的に同様である請求項1に記載の制御プログ
ラム。 - 【請求項3】 前記第1及び第2のバッファの各々が、
複数のスロットを含み、各スロットが、前記第1のバッ
ファの全容量のどのような部分でも占め得るメッセージ
及び前記第2のバッファの全容量のどのような部分でも
占め得る実行順序データを収容するために大きさにおい
て可変である請求項2に記載の制御プログラム。 - 【請求項4】 前記プログラム間メッセージが、与えら
れるメッセージの名宛人を確認するのに役立つ予め定め
た識別子を含む請求項3に記載の制御プログラム。 - 【請求項5】 前記第2のサブプログラムが、さらに、
連続的な連絡ポートのオペレーションを制御し、そして
前記第1のバッファ内の前記連絡ポートと関連するファ
イルハンドルを記憶し、これにより、多重の従属(子
供)の応用プログラムが単一の連続的な連絡ポートを共
有する請求項1に記載の制御プログラム。 - 【請求項6】 前記ランダムアクセスメモリ内に記憶さ
れ、そして前記リアルタイム割り込み及び前記マイクロ
コンピュータの前記リアルタイムクロックの状態に応答
して、前記従属の応用プログラムの一つにより前記第2
のバッファ内に置かれる時間を刻印したメッセージによ
り指定されるように、前記第1のバッファ内に実行可能
なメッセージを記憶するための第3のサブプログラムを
さらに含む請求項1に記載の制御プログラム。 - 【請求項7】 MSDOS型ディスクオペレーティング
システムを記憶するためのランダムアクセスメモリを合
併するアイビーエムのコンパチブル型マイクロコンピュ
ータのためのプログラム間連絡を提供する方法であっ
て、 (a)プログラム間連絡メッセージ及び条件付きで指定
される実行順序を表すデータを記憶するために、それぞ
れ固定された容量を有しそして前記ランダムアクセスメ
モリ内に常駐の第1及び第2のバッファを規定する制御
プログラムを提供し、 (b)第1の予め定めたプロトコルに応じて前記第1の
バッファへ及び同バッファからの転送を制御するための
第1のサブプログラムを前記制御プログラム内に含み、
前記第1のサブプログラムが、さらに、第2の予め定め
たコマンドプロトコルに応じて前記第2のバッファへ及
び同バッファからの転送を制御し、そして (c)前記第2のバッファの内容に応じて、複数の別個
のそして従属の応用プログラムの実行の順序を、前記従
属の応用プログラムが前記第1のバッファを介し連絡で
きるように、制御するための第2のサブプログラムを前
記制御プログラム内に含む各ステップからなるプログラ
ム間連絡を提供する方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US99540992A | 1992-12-18 | 1992-12-18 | |
US995409 | 1992-12-18 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH06222931A true JPH06222931A (ja) | 1994-08-12 |
Family
ID=25541752
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP5308158A Pending JPH06222931A (ja) | 1992-12-18 | 1993-12-08 | パーソナルコンピュータのための制御プログラム及びプログラム間連絡提供方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US5630074A (ja) |
JP (1) | JPH06222931A (ja) |
FR (1) | FR2699702A1 (ja) |
GB (1) | GB2273591A (ja) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2293470A (en) * | 1994-09-22 | 1996-03-27 | Ibm | Message encapsulation in Object Oriented Programming. |
WO1999026377A2 (en) * | 1997-11-17 | 1999-05-27 | Mcmz Technology Innovations Llc | A high performance interoperable network communications architecture (inca) |
US6292842B1 (en) * | 1998-08-28 | 2001-09-18 | Hewlett-Packard Company | Method for transferring data to an application |
US6983350B1 (en) | 1999-08-31 | 2006-01-03 | Intel Corporation | SDRAM controller for parallel processor architecture |
US6532509B1 (en) | 1999-12-22 | 2003-03-11 | Intel Corporation | Arbitrating command requests in a parallel multi-threaded processing system |
US6694380B1 (en) | 1999-12-27 | 2004-02-17 | Intel Corporation | Mapping requests from a processing unit that uses memory-mapped input-output space |
US7620702B1 (en) | 1999-12-28 | 2009-11-17 | Intel Corporation | Providing real-time control data for a network processor |
US6661794B1 (en) | 1999-12-29 | 2003-12-09 | Intel Corporation | Method and apparatus for gigabit packet assignment for multithreaded packet processing |
US6584522B1 (en) | 1999-12-30 | 2003-06-24 | Intel Corporation | Communication between processors |
US7480706B1 (en) | 1999-12-30 | 2009-01-20 | Intel Corporation | Multi-threaded round-robin receive for fast network port |
US6952824B1 (en) * | 1999-12-30 | 2005-10-04 | Intel Corporation | Multi-threaded sequenced receive for fast network port stream of packets |
US6904597B2 (en) * | 2001-03-30 | 2005-06-07 | Intel Corporation | Inter-thread communications between different components using double buffer |
US20060218556A1 (en) * | 2001-09-28 | 2006-09-28 | Nemirovsky Mario D | Mechanism for managing resource locking in a multi-threaded environment |
US7471688B2 (en) | 2002-06-18 | 2008-12-30 | Intel Corporation | Scheduling system for transmission of cells to ATM virtual circuits and DSL ports |
US7352769B2 (en) | 2002-09-12 | 2008-04-01 | Intel Corporation | Multiple calendar schedule reservation structure and method |
US7433307B2 (en) | 2002-11-05 | 2008-10-07 | Intel Corporation | Flow control in a network environment |
TW588284B (en) * | 2002-11-12 | 2004-05-21 | Mitac Technology Corp | Computer real-time power-on system and method |
US7443836B2 (en) | 2003-06-16 | 2008-10-28 | Intel Corporation | Processing a data packet |
CN1310146C (zh) * | 2004-02-09 | 2007-04-11 | 中兴通讯股份有限公司 | 单片机操作系统的模块化实现方法 |
US9465670B2 (en) | 2011-12-16 | 2016-10-11 | Intel Corporation | Generational thread scheduler using reservations for fair scheduling |
US10235220B2 (en) * | 2012-01-23 | 2019-03-19 | Advanced Micro Devices, Inc. | Multithreaded computing |
US10459911B2 (en) | 2016-09-27 | 2019-10-29 | Bank Of America Corporation | System and method for inter-program file control communication |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4177513A (en) * | 1977-07-08 | 1979-12-04 | International Business Machines Corporation | Task handling apparatus for a computer system |
US4724517A (en) * | 1982-11-26 | 1988-02-09 | Inmos Limited | Microcomputer with prefixing functions |
GB8309770D0 (en) * | 1983-04-11 | 1983-05-18 | Inmos Ltd | Microcomputer |
JPH02310664A (ja) * | 1989-05-26 | 1990-12-26 | Hitachi Ltd | 共有メモリを用いた通信方式 |
US5212792A (en) * | 1989-06-01 | 1993-05-18 | Hewlett-Packard Company | Method and apparatus for controlling execution of tools in a computer-aided software engineering system |
US5274821A (en) * | 1989-08-14 | 1993-12-28 | International Business Machines Corporation | Communication between prolog and an external process |
US5237691A (en) * | 1990-08-01 | 1993-08-17 | At&T Bell Laboratories | Method and apparatus for automatically generating parallel programs from user-specified block diagrams |
US5265239A (en) * | 1991-04-08 | 1993-11-23 | Ardolino Anthony A | Method for remotely accessing service programs of a local processing system supporting multiple protocol stacks and multiple device drivers |
-
1993
- 1993-11-03 GB GB9322682A patent/GB2273591A/en not_active Withdrawn
- 1993-12-08 JP JP5308158A patent/JPH06222931A/ja active Pending
- 1993-12-17 FR FR9315242A patent/FR2699702A1/fr active Pending
-
1995
- 1995-05-15 US US08/441,120 patent/US5630074A/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
FR2699702A1 (fr) | 1994-06-24 |
GB9322682D0 (en) | 1993-12-22 |
US5630074A (en) | 1997-05-13 |
GB2273591A (en) | 1994-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JPH06222931A (ja) | パーソナルコンピュータのための制御プログラム及びプログラム間連絡提供方法 | |
US6848046B2 (en) | SMM loader and execution mechanism for component software for multiple architectures | |
US5305455A (en) | Per thread exception management for multitasking multithreaded operating system | |
US5210873A (en) | Real-time computer system with multitasking supervisor for building access control or the like | |
US7810096B2 (en) | Computer executing multiple operating systems | |
EP1449077B1 (en) | Method and system for concurrent handler execution in an smi and pmi-based dispatch-execution framework | |
US5799188A (en) | System and method for managing variable weight thread contexts in a multithreaded computer system | |
US4859995A (en) | Mouse pointer with switchable emulation mode | |
JPH03501784A (ja) | コンピュータのインタフェース・アーキテクチャ | |
US4660144A (en) | Adjunct machine | |
JPS58195966A (ja) | 多重タスク処理ワ−ド・プロセツサにおける使用者制御によるリソ−ス切換え方法 | |
JPS61206043A (ja) | 仮想計算機システムにおける割込制御方法 | |
CA1304513C (en) | Multiple i/o bus virtual broadcast of programmed i/o instructions | |
JPH05216689A (ja) | コンピュータ装置およびコンピュータ装置を動作させる方法 | |
US5355488A (en) | Method for adaptively building a library of program threads | |
JPH0756753A (ja) | オペレーティング・システム間のユーティリティ・ファンクションの共有方法およびシステム | |
US7415547B1 (en) | Tracking states of communication between PS/2 hardware and hardware drivers within an extensible firmware interface environment | |
KR102567773B1 (ko) | 전투체계 시스템에서의 로그 정보 추출장치 및 그 방법 | |
JP3861304B2 (ja) | エミュレーション装置およびその方法 | |
Papadimitriou et al. | Mac OS versus FreeBSD: A comparative evaluation | |
JPS6097440A (ja) | 仮想多重プロセツサ装置 | |
JP2003005987A (ja) | エミュレーション装置 | |
JP3022398B2 (ja) | 仮想計算機方式 | |
JPH09179728A (ja) | 異パーソナリティ・アプリケーションの起動方法およびコンピュータ・システム | |
CN117908988A (zh) | 从服务器内存按需加载运行程序内容的方法及系统 |