JP2001507835A - 過去に互換性のあるオペレーティングシステムのリアルタイムサービス - Google Patents

Abstract

(57)【要約】 Ｗｉｎｄｏｗｓ ９５等のモダンオペレーティングシステム上でＤＯＳアプリケーション等の以前のアプリケーションを実行する際のＣＰＵホッギングに関連する問題が、様々なプロセスおよびデバイスによる保証されたＣＰＵアクセスに対する要求を管理するための仮想デバイスドライバＶｘＤを作ることによって克服される。仮想デバイスドライバは、仮想マシンマネージャのサービスを利用し、それによって、プロセスおよびデバイスを要求することによりＣＰＵアクセスが保証される。

Description

【発明の詳細な説明】 過去に互換性のあるオペレーティングシステムのリアルタイムサービス 発明の分野 本発明は、マルチタスキングコンピュータシステムおよび方法に関し、特に、 ＤＯＳアプリケーションの実行を可能とする過去（backwardly）に互換性のある オペレーティングシステムによってサービスされるリアルタイムアプリケーショ ンに対する十分なＣＰＵリソースを確保するための技術に関する。 発明の背景 新しく設計されたマイクロプロセッサは、拡大したメモリアドレッシング機構 と、向上した能力を生みだす改訂されたアーキテクチャとを備え得る。このよう なマイクロプロセッサが新しいコンピュータシステムで使用される場合には、そ れらのマイクロプロセッサにより、その向上した能力のために、前にあったもの より機能的に優れたコンピュータがしばしば生み出される。新しいコンピュータ が、その前にあったものに対して持ち得る任意の機能的な利点にもかかわらず、 改良されたマイクロプロセッサを用いたコンピュータは、商業的に成功しないか もしれない。「ソフトウェア」と時に呼ばれるコンピュータプログラムは、マイ クロプロセッサに対して特定的である。従って、新しいマイクロプロセッサを用 いたコンピュータが市場に紹介されると、通常、その上で実行できるソフトウェ アはほとんど、または全く存在しない。以前のマイクロプロセッサ用に書かれた 現存のソフトウェアは、新しいコンピュータに対して互換性がない可能性が高い 。その結果、このような新しいコンピュータの売上げは、そのコンピュータに対 して十分なソフトウェアが利用可能であることを消費者がわかるまでは不振であ ることが多い。さらに、現存のコンピュータ用のソフトウェアライブラリを持つ 消費者は、全て新しいソフトウェアに投資することを必要とする新しいコンピュ ータを購入することを嫌がるかもしれない。この問題は、ソフトウェアのライタ および販売者が、マイクロプロセッサを組み込んだコンピュータの売上げが、ソ フ トウェアの比較的大きな潜在的購入者のグループを生じさせるのに十分となるま で、その新しいマイクロプロセッサ用のソフトウェアを作成することを嫌がると いう事実としばしば組み合わせられる。消費者およびソフトウェアライタの両方 の側の「成り行きを見守る」姿勢により、新しいマイクロプロセッサおよびその マイクロプロセッサを使用したコンピュータの成功が危うくなり得る。 新しいマイクロプロセッサの設計者は、時に、複数のモードで動作するように 新しいマイクロプロセッサを設計することによってこの問題を解決しようとする 。例えば、第１のモードでは、マイクロプロセッサは先行のマイクロプロセッサ をエミュレートし、先行のマイクロプロセッサ用に書かれた現存のプログラムを 実行する。第２のモードでは、マイクロプロセッサは、その向上した能力をフル に活用する。このような設計により、そのマイクロプロセッサを用いたコンピュ ータシステムのメーカーが、そのコンピュータ上で先行のマイクロプロセッサ用 に書かれた現存のプログラムの全てが実行されることを宣伝でき、その結果（理 論上は）、ソフトウェアライタが、その新しい向上したモードで実行されるよう に設計されたプログラムを書き始める時点にまでコンピュータの売上げを刺激す ることができる。 そのようなマイクロプロセッサの１つに、カリフォルニアのサンタクララにあ るIntel Corporationが製造したインテル８０２８６がある。インテル８０２８ ６の設計および動作は、Intel Corporationから入手可能で、本明細書中に参考 として援用される、「iAPX286 Programmer's Reference Manual Including the iAPX286 Numeric Supplement」というタイトルの刊行物に詳細に記載されている 。 インテル８０２８６（以下「８０２８６」）は、２つのモードで動作する。「 リアルモード」と呼ばれる第１のモードでは、８０２８６が、例えばＩＢＭのＰ Ｃおよび互換性コンピュータに使用される、８０８８マイクロプロセッサ系のイ ンテルの以前の８０８６のアーキテクチャをエミュレートする。従って、８０２ ８６マイクロプロセッサを組み込んだコンピュータ（ＩＢＭのＰＣ／ＡＴ等）が 、ＩＢＭのＰＣおよび互換性コンピュータ用に書かれた現存の８０８６プログラ ムを実行できる。 「保護モード」と呼ばれる第２のモードでは、８０２８６アーキテクチャは、 拡大したメモリアドレッシング能力、向上したマルチタスキング支援機能、およ び精巧な保護機構を提供する。 このようなマイクロプロセッサの別のものには、インテル８０３８６がある。 インテル８０３８６の設計および動作は、Intel Corporationから入手可能で、 本明細書中に参考として援用される、「iAPX386 Programmer's Reference Manua l Including the iAPX386 Numeric Supplement」というタイトルの刊行物に詳細 に記載されている。 ８０２８６に関して上に記載したようなリアルモードおよび保護モードに加え て、８０３８６は、仮想−８０８６モードと呼ばれる第３のモードを有する。仮 想８０８６においては、８０３８６は、リアルモードに類似の様式で８０８６プ ロセッサをエミュレートする。リアルモードと仮想−８０８６モードとの違いは 、仮想−８０８６モードでは、８０３８６が、メモリ管理、保護およびマルチタ スキング支援を提供することである。仮想−８０８６モードにより、８０８６プ ログラムを８０３８６上のタスクの１つとして実行することが可能となる。仮想 −８０８６モードの各タスクは、８０８６上で実行しているという錯覚を持つ。 特別なオペレーティングシステムソフトウェアである、仮想マシンモニタ（Ｖ ＭＭ）は、幾つかの８０８６プログラムのマルチタスキングを調整する。ＶＭＭ は、保護モードで実行する。別のタスクが開始され得るように１つのタスクから ＶＭＭに制御を移すための２つの標準的技術が存在する。第１に、８０８６プロ グラムによって実行される全ての割込み、ソフトウェアおよびハードウェアによ って制御がＶＭＭに移されるように、ＶＭＭが８０３８６に対してコンフィギュ レーションする。第２に、ＶＭＭがタイマ割込みを設定する。指定の間隔後に割 込まれた際に、ＶＭＭが制御を受け取る。 これらの技術は、ディスクオペレーティングシステム（ＤＯＳ）の下で実行さ れるように設計された８０８６プログラムからの移行を支援するために用いられ 得る。ワシントン州のレドモンドにあるMicrosoft Corporationが提供するＭＳ −ＤＯＳバージョン３．Ｘ等の典型的なパーソナルコンピュータＤＯＳは、シン グルスレッドオペレーティングシステムである。すなわち、ＤＯＳがマルチタス キング環境を支援するように設計されていない。ＤＯＳがマルチタスキング環境 で実行されると、ＤＯＳが割込まれる際に問題が生じ得る。ＤＯＳがインターバ ルタイマの実行の間などの、機能を実行する間に無作為に割込まれると、別のタ スクへの移行により、ＤＯＳデータ構造の崩壊が生じ得る。従って、ＶＭＭによ り、別のタスクが開始される前にＤＯＳが機能を完了することが可能になる。Ｄ ＯＳシステム呼出しから出る際に、ＤＯＳデータ構造は適切な状態にある。 残念なことに、タスクを移す前に全ての機能呼出しが完了することを可能とす るＶＭＭにより、システム性能は不十分なものとなる。ＤＯＳの幾つかのシステ ム呼出しは、完了するのに不定量の時間がかかり得る。例えば、キーボートから １つの文字を取り出すための呼出しは、キーが実際に入力されるまでは完了しな い。同様に、プログラムが通信ポートから読み出すためのシステム呼出しを発す る場合、ある文字が実際に受け取られるまでは、そのシステム呼出しが完了しな い。ＤＯＳはコードの一部をループスルーし（loop through）、その文字が受け 取られたかどうかを見るためにポートをチェックする。従って、この不定の期間 は他のタスクをスケジュールすることができない。 データ構造が崩壊不可能である状態にＤＯＳがあったかどうかがＶＭＭにはわ からないので、不定期間のシステム呼出しのタイマ割込みは不十分である。 米国特許第4,974,159号（Hargroveら、１９９０年１１月２７日に発行）は、 制御を仮想マシンマネージャ（ＶＭＭ）へ移すことに失敗するＤＯＳルーチンの 問題に対して、制御が仮想マシンマネージャに定期的に移され、それによってシ ステムがＤＯＳアプリケーションによってロックアップしないことを確実にする ために、仮想マシンブレークポイント命令を実行可能コードに書くことによって 取り組んでいる。Hargroveのアプローチでは、ＤＯＳデータ構造を崩壊させるこ となくタスク切換えが生じ得るプログラム実行の特定の点が検出される。これら の点の幾つかが、仮想マシンブレークポイントの挿入のために選択される。実行 の際にブレークポイントに到達すると、仮想マシンマネージャが、ＤＯＳデータ 構造を崩壊させることなく自由に別のタスクを開始する、または他の機能を行う 。Hargroveによる、仮想マシンブレークポイントの挿入に使用されたブレークポ イントの位置は、キーボード呼出しを読み出すための呼出し等の、不定期間のＤ ＯＳシステム呼出し中に位置する。キーが押されなければ、キーが押されるまで ア プリケーションは一時停止する。Hargroveは、仮想マシンブレークポイントを任 意の他の種の位置に配置する例を提供していない。 Hargroveの技術の実現は、選択されたルーチンのコピーが別に保存され、それ によって実行可能コードにおいて１バイトの仮想マシンブレークポイント命令に よって上書きされるコードの部分が修復されることを必要とする。これは複雑で 、不必要なプロセスステップおよびストレージを必要とする。 Ｗｉｎｄｏｗｓ９５オペレーティングシステムは、仮想マシン環境で実行され るＤＯＳアプリケーションによってＣＰＵホッギングを受ける上記のタイプのオ ペレーティングシステムである。 インテルアーキテクチャ信号処理オペレーティングシステム(Intel Architect ure Signal Processing Operating System）（ＩＡＳＰＯＸ）により、ネイティ ブ信号処理（ＮＳＰ）の概念が紹介され、このシステムは、ＩｎｔｅｌおよびＳ ｐｅｃｔｒｏｎ Ｍｉｃｒｏｓｙｓｔｅｍｓにより開発された。 ＩＡＳＰＯＸオペレーティングシステムは、それと共に、システムメモリとＣ ＰＵの使用法および利用とに関して著しいオーバーヘッドをもたらす。ＩＡＳＰ ＯＸを購入し、それをホストコンピュータに別個にインストールしなければなら ない。ＩＡＳＰＯＸは、ＰＣのタスクのスケジューリングを引き受け、ＩＡＳＰ ＯＸアプリケーションがアイドル状態にある場合にのみウィンドウズアプリケー ション／ドライバを実行する。ＩＡＳＰＯＸは、リアルタイムクロックを、約９ ００マイクロ秒の細分に再プログラムし、それによって、ＩＡＳＰＯＸタスクが 全く実行されていない場合でも著しい割込み（保護モードにおいて４８６／６６ Ｍｈｚで１つの割込みにつき１５マイクロ秒の）オーバーヘッドが引き起こされ る。１秒につき１，０００の割込みまたは１ミリ秒毎に１回に端数を切り捨てる と、割込み待ち時間のみで、いかなるコードも実行することなくＣＰＵの１．５ ％を消費する。 現在ＩＡＳＰＯＸは、ＶｘＤのプログラミングモデルに従わず、Ｗｉｎｄｏｗ ｓ９５のカーネルを徐々に害するので、Ｍｉｃｒｏｓｏｆｔによって支持されて いない。現在のＩＡＳＰＯＸコードの約８０％がすでにＷｉｎｄｏｗｓ９５内に あり、冗長インタフェースおよび不必要なメモリ消費につながっている。また、 新しいカーネルおよび関連するプリミティブと、ツールと、開発環境（１５ＭＢ のディスクスペース）とにプログラマが頼ることを必要とする。 さらに、ＩＡＳＰＯＸは、その下でのタスクとして動作しているＷｉｎｄｏｗ ｓ９５と共にスーパーオペレーティングシステムとして明らかに実行している。 このように、ＩＡＳＰＯＸは、Ｗｉｎｄｏｗｓ９５の状態に関係なくプロセッサ へのアクセスに対する制御を維持する。 発明の要旨 本発明によれば、リアルタイムアプリケーションが、同時に実行中のＤＯＳア プリケーションを含むあらゆるアプリケーションの状態とは無関係にＣＰＵアク セスを保証し得る。本発明によれば、仮想マシンマネージャによって提供される ネスト（nest）された実行／優先イベント機構が、そのアクセスを提供するため に利用される。本発明は、リアルタイムサービスまたはＲＴＳと呼ばれるプロセ スとして実現される。ＲＴＳは、どのアプリケーションまたは仮想マシンが実行 されているかとは無関係に、実行される優先コールバック機能をスケジュールす る仮想デバイスドライバ（ＶｘＤ）として実現される。 本発明は、オペレーティングシステムおよび少なくとも１つのプロセスまたは デバイスと相互作用し、それによってコンピュータ上で実行されているどのよう なアプリケーションの状態とも無関係にＣＰＶアクセスが確保されるスケジュー リングプロセスを実行することによって、コンピュータにおける反復プロセスを スケジュールするための方法および装置に関する。 本発明のさらに他の目的および利点は、本発明の実施を意図する最良の形態の 例示を単に目的として、本発明の好適な実施形態のみが示され、説明される以下 の詳細な説明から当業者には容易に明らかとなるであろう。理解されるように、 本発明は、他の異なる実施形態も可能であり、その幾つかの細部を、全て本発明 から逸脱することなく種々の明白な点で改変することが可能である。従って、図 面および説明は、限定的なものではなく、事実上例示的なものとして考えられる ものである。図面の簡単な説明 図１は、本発明を行うのに有用な従来技術のオペレーティングシステム例を表 す。 図２は、図１に示されるオペレーティングシステムのためのデバイスドライバ 例の構成要素のブロック図である。 図３は、リアルタイムサービス（ＲＴＳ）が、本発明の仮想デバイスドライバ としてどのように実現されるかを示すブロック図である。 図４は、モデム機能からの十分なＣＰＵアクセスを確保するための本発明のリ アルタイムサービスを使用したホストベースのモデムのブロック図である。 図５は、ＲＴＳと、仮想マシンマネージャおよびタイミングデバイスのための 仮想デバイスドライバ（ＶＴＤ）に支援されるモデムＶｘＤおよびオペレーティ ングシステムサービスとの間のプロセス間通信を示すタイミング図である。 図６は、モデムのバックグラウンド機能を作動させるために定期的に使用され るプロセス間通信のタイミング図である。 図７は、モデムのハートビート（heartbeat）として機能するように用いられ るプロセス間通信のタイミング図である。 図８は、他のプロセスを妨害しない時にアプリケーションが移行を開始するこ とを許可するために使用されるプロセス間通信のタイミング図である。 好適な実施形態の詳細な説明 図１は、本発明を実施するために有用な従来技術のオペレーティングシステム 例の図示である。 アプリケーションレイヤー１００は、３２ビットアプリケーションと同様に、 １６ビットアプリケーション、およびＤＯＳアプリケーションを含む様々なアプ リケーションを含む。シェル１１０は、オペレーティングシステムコア機能に対 するインタフェースとして働く。シェルは、複数のユーザインタフェースツール も含む。コアは、３つのコメントである、ユーザ領域、カーネル領域、およびグ ラフィカルデバイスインタフェースから構成される。 ユーザ構成要素は、キーボード、マウス、および他の入力デバイスからの入力 と、ユーザインタフェース（ウィンドウ、アイコン、メニュー等）に対する出力 を管理する。ユーザ構成要素はまた、音声ドライバ、タイマ、および通信ポート とのインタラクションを管理する。 図１に示されるオペレーティングシステム（好ましくは、Ｗｉｎｄｏｗｓ９５ ）は、システムおよびアプリケーションに対する全ての入力に関して非同期入力 モデルを使用する。様々な入力デバイスが割込みを生成するので、割込みハンド ラが、これらの割込みをメッセージに変換し、メッセージを未処理の入力スレッ ド領域に送信し、未処理の入力スレッド領域は、次に、各メッセージを適切なメ ッセージキューに渡す。３２ビットベースのスレッドの各々は、それ自体のメッ セージキューを有し得、全ての１６ビットベースのアプリケーションは、共通の １つのメッセージキューを共有する。 グラフィカルデバイスインタフェース（ＧＤＩ）は、画面に現れるものを管理 するグラフィックシステムである。ＧＤＩはまた、プリンタおよび他の出力デバ イスに対してグラフィックス支援を提供する。ＧＤＩは、グラフィックプリミテ ィブを描画し、ビットマップを操作し、ディスプレイデバイスのためのドライバ およびプリンタ出力デバイスドライバを含むデバイス独立グラフィックドライバ と相互作用する。 カーネルは、Ｉ／Ｏサービス、仮想メモリ管理、およびタスクスケジューリン グを含む基礎的なオペレーティングシステム機能性を提供する。 例外取扱いは、カーネルの別のサービスである。カーネルはまた、仮想メモリ を割当て、インポート参照を解決し、アプリケーションに対する要求時ページン グを支援する。カーネルにより、１６ビットおよび３２ビットのアプリケーショ ンの両方に対するサービスが提供される。 オペレーティングシステムにおける中央情報データベースは、レジストリと呼 ばれる。この階層型データベースは、オペレーティングシステムを単純化し、且 つオペレーティングシステムを、より適応可能にする。 オペレーティングシステムにおけるレジストリの主な役割は、ハードウェア検 出およびプラグアンドプレイシステム構成要素による使用のためにハードウェア 特定的情報に関する中央保管所として機能することである。オペレーティングシ ステムは、レジストリの階層構造における列挙プロセスによって識別されたハー ドウェア構成要素およびデバイスに関する情報を維持する。新しいデバイスがイ ンストールされると、システムは、レジストリにおける現存のコンフィギュレー ションをチェックし、それによって使用されていないハードウェアリソース（例 えば、ＩＲＱ、Ｉ／Ｏアドレス、ＤＭＡチャネル等）が決定され、その結果、そ の新しいデバイスが、そのシステムにすでにインストールされているデバイスと コンフリクトすることなく適切にコンフィギュレーションされ得る。 ちょうどコンフィギュレーションマネージャがコンピュータ上の各デバイスが 必要とする全てのリソースを提供するように、別の構成要素である仮想マシンマ ネージャは、コンピュータ上で実行中のアプリケーションおよびシステムプロセ スの各々が必要とするリソースを提供する。仮想マシンマネージャは、アプリケ ーションおよびシステムプロセスが実行される仮想マシン環境を生成および維持 する。 仮想マシン（ＶＭ）は、アプリケーションの観点からは別個のコンピュータ（ コンピュータは、リソースの全てを備えて完全なものとなる）であるかのように 見えるメモリ中の環境である。マシンマネージャは各アプリケーションに対して 、それが必要とするシステムリソースを提供する。 オペレーティングシステムは、システムＶＭと呼ばれる単一のＶＭを備え、そ こでは、全てのシステムプロセスが実行される。さらに、３２ビットベースおよ び１６ビットベースのアプリケーションの全てがこのＶＭで実行される。ＭＳ− ＤＯＳベースのアプリケーションの各々は、それ自体のＶＭ内で実行される。 プロセススケジューラは、実行するアプリケーションおよび他のプロセスにシ ステムリソースを提供する、および複数のアプリケーションが同時に実行される ことが可能となるようにプロセスをスケジューリングする責任がある構成要素で ある。 プロセススケジューラはまた、複数のアプリケーションおよび他のプロセスが 同時に実行されることが可能となるようにプロセスのスケジューリングを行う。 オペレーティングシステムは、同時プロセススケジューリングのための２つの方 法、すなわちコーオペレイティブマルチタスキングおよびプリエンプティブマル チタスキングを使用する。 Ｗｉｎｄｏｗｓ３．１等の以前のオペレーティングシステムにおいては、アプ リケーションが、コーオペレイティブマルチタスキングとして公知の方法によっ て同時に実行される。この方法を用いた場合、オペレーティングシステムは、ア プリケーションがメッセージキューを定期的にチェックし、他の実行中のアプリ ケーションに対してシステムの制御を放棄することを必要とした。メッセージキ ューを頻繁にチェックしなかったアプリケーションは、効果的にＣＰＵ時間を「 ホッグ（hog）」し、ユーザが別のアプリケーションに切換えることを防止する 。互換性の理由から、オペレーティングシステムは、１６ビットベースのアプリ ケーションをコーオペレイティブにマルチタスキングする。 オペレーティングシステムは、３２ビットベースのアプリケーションに対して プリエンプティブマルチタスキングを用いる。これは、オペレーティングシステ ムが、システムの要求に応じて、別の実行中であるタスクから制御を取り上げる 、または別の実行中のタスクに制御を与えることを意味する。 １６ビットベースのアプリケーションとは異なり、３２ビットベースのアプリ ケーションは、適切にマルチタスキングを行うために、他の実行中のタスクに譲 る必要がない。３２ビットベースのアプリケーションは、アプリケーションを同 時に実行する能力を促進するためにオペレーティングシステムが提供する機構で あるマルチスレッディングを利用することができる。システムで実行中の３２ビ ットベースのアプリケーションは、オペレーティングシステムの観点からプロセ スと呼ばれる。各プロセスは、オペレーティングシステムによって実行される際 にコードパスフローを識別する実行の少なくとも１つのスレッドからなる。１つ のスレッドは、コードの１つのユニットであり、これは、コードの他のユニット と同時に実行するためにオペレーティングシステムからタイムスライスを得るこ とができ、１つのプロセスに関連していなければならない。しかし、３２ビット ベースのアプリケーションは、スループットを向上させる、応答性を高める、お よびバックグラウンド処理を助けることによって、ユーザに対してアプリケーシ ョンを向上させるために、所与のプロセスに対して複数のスレッドを起動するこ とができる。オペレーティングシステムのプリエンプティブマルチタスキングの 性質のため、実行のスレッドにより、コードがバックグラウンドでスムーズに処 理されることが可能となる。 ＩＦＳマネージャは、ファイルシステムデバイスおよび他のファイルシステム デバイス構成要素に対するアクセスを調停する。 プラグアンドプレイの機能性を支援するために、オペレーティングシステムア ーキテクチャは、コンフィギュレーションプロセスを調整するコンフイギュレー ションマネージャを含む。このプロセスは、単一のシステムに共存する多くのバ スおよびデバイスアーキテクチャに関与し得、同じバスアーキテクチャを用いた ２つ以上のデバイスタイプを有するが、各デバイスが別のコンフィギュレーショ ン要件セットを有する。（バスは、情報がコンピュータとデバイスとの間で転送 されることを可能とする機構である。）例えば、マウスおよびキーボードは共に 、同じキーボードコントローラバスを使用し得る；ＣＤ−ＲＯＭドライブおよび ハードディスクドライブは共に、同じＳＣＳＩバスを使用し得る。 コンフィギュレーションマネージャは、多数のサブコンポーネントと連動し、 それによって、システムの各バスおよび各デバイスが識別され、各デバイスに対 するコンフィギュレーション設定が識別される。コンフィギュレーションマネー ジャにより、コンピュータ上の各デバイスが、他のデバイスとコンフリクトする ことなく、ＩＲＱ，Ｉ／Ｏポートアドレス、および他のリソースを使用し得るこ とが確実となる。 コンフィギュレーションマネージャはまた、存在するデバイスの数およびタイ プの変化についてコンピュータを監視する援助をし、変化が生じた場合に必要に 応じてデバイスの再コンフィギュレーションを管理する。これらのイベントが起 こると、コンフィギュレーションマネージャは、アプリケーションに情報を伝え る。 その役割を果たすために、コンフィギュレーションマネージャは、バス調査器 （bus enumerator）に、それらの特定のバスにある全てのデバイスおよびそれぞ れのリソース要件を識別するように依頼する。 オペレーティングシステムは、ディスクデバイス、ディスプレイアダプタ、マ ウスおよび他のポインティングデバイス、モデム、ファクシミリマシン、および プリンタを含むハードウェアデバイスおよび周辺デバイスに対して向上した支援 を提供する。 Ｗｉｎｄｏｗｓ３．１等の以前のオペレーティングシステムにおいては、デバ イスドライバは、大半はモノリシックであり、開発が複雑であった。記載されて いるオペレーティングシステムは、ハードウェアベンダが自分達のハードウェア に対してデバイス特定的コードを提供することを容易にするユニバーサルドライ バ／ミニドライバアーキテクチャを使用する。 図２に示されるように、ユニバーサルドライバ（２１０）は、ある特定のデバ イスクラスのデバイス（プリンタまたはモデム等）にとって、適切なオペレーテ ィングシステム構成要素（印刷または通信サブシステム等）と通信するために必 要なコードの大部分を含む。ミニドライバ（２２０）は、比較的小型で、ある特 定のデバイスが必要とする任意の追加の命令を含む単純なドライバである。しか し、多くの場合には、ある特定のカテゴリのデバイスに対するユニバーサルドラ イバはまた、そのカテゴリにとって最も一般的な標準型に設計されたデバイスを 動作させるのに必要なコードを含む。（例えば、ユニモデムドライバは、ＡＴコ マンドを支援する全てのモデムで機能する。） 仮想デバイスドライバ（ＶｘＤ ）は、ハードウェアデバイスまたはインストールされたソフトウェア等のシステ ムリソースを管理し、それによって２つ以上のアプリケーションがリソースを同 時に使用可能となる、３２ビットの保護モードドライバである。「ＶｘＤ」は、 一般的な仮想デバイスドライバを意味し、「ｘ」はデバイスドライバのタイプを 表す。例えば、ディスプレイデバイス用の仮想デバイスドライバは、ＶＤＤとし て知られ、タイマデバイス用の仮想デバイスドライバはＶＴＤであり、プリンタ デバイス用の仮想デバイスドライバはＶＰＤである、等である。 Ｗｉｎｄｏｗｓ３．ｌ等の以前のオペレーティングシステムにおいては、Ｖｘ Ｄは、静的にロードされ、多くのメモリ空間をとった。しかし、説明されている オペレーティングシステムは、ＶｘＤを動的にロードする。すなわち、任意の所 与の時間に必要とされるもののみがメモリにロードされる。さらに、新しいＶｘ Ｄは、メモリの全てがページロックされる必要はなく、その結果、システム中の 利用可能なメモリがさらに増加する。 ＶｘＤは、ディスクコントローラ、シリアルおよびパラレルポート、キーボー ド、およびディスプレイデバイス等を含む、典型的なコンピュータ用の全てのハ ードウェアデバイスを支援する。ハードウェアデバイスの状態が、複数のアプリ ケーション間で切換えを行うことによって中断させられ得る場合には、デバイス は、各アプリケーションに対して対応する仮想デバイスを持たなければならない 。この仮想デバイスは、アプリケーションが継続する時はいつでもデバイスが正 しい状態にあることを確実にする。 ほとんどの仮想デバイスはハードウェアを管理するが、インストールされたソ フトウェアのみを管理するものもある（ＭＳ−ＤＯＳデバイスドライバまたはＴ ＳＲプログラム等）。このような仮想デバイスは、ソフトウェアをエミュレート する、またはソフトウェアが現在実行中のアプリケーションのみに適用されるデ ータを使用することを確実にするためのコードを含む。また、ＶｘＤはソフトウ ェアの性能を向上させるためにしばしば使用される。 図３は、リアルタイムサービス（ＲＴＳ）が、本発明による仮想デバイスドラ イバとしてどのように実現されるかを示すブロック図である。図３に示されるよ うに、リング３レベルでは、システム仮想マシンは、複数の３２ビットアプリケ ーションを別個のアドレス空間で実行する。しかし、１６ビットのアプリケーシ ョンは、単一のアドレス空間で実行される。さらに、ＤＯＳアプリケーションは 、示されるように、別個の仮想マシンとして実行される。仮想マシンマネージャ サブシステムは、リング０で示される。仮想マシンマネージャサブシステムは、 他の機能に加えて、本発明のリアルタイムサービスを含む仮想デバイスドライバ を管理する。仮想デバイスドライバとして実現されているリアルタイムサービス は、必要な時にリアルタイムサービスへのＣＰＵアクセスを確保するために必要 な特定の仮想メモリマネージャサブシステム能力に対するアクセスを持つ。この ことは、以下により詳しく説明される。 図４は、モデム機能に対する十分なＣＰＵアクセスを確保するために本発明の リアルタイムサービスを用いたホストベースのモデムのブロック図である。説明 されているアプリケーションのソフトウェアアーキテクチャは、説明の便宜上、 複数のレイヤーに分割されている。アプリケーションレイヤー４００では、３２ ビットアプリケーション（ウィンドウズアプリケーション４０１等）およびＤＯ Ｓアプリケーション（アプリケーション４０２等）が、同時に実行中であり得る 。レイヤー４１０では、仮想マシンマネージャ４１３がコンフィギュレーション マネージャ４１２と共に示されている。これらは説明済みである。ＶＣＯＭＭブ ロック４１１は、ウィンドウズベースのアプリケーションおよびドライバがポー トおよびモデムを使用することを可能とする保護モードサービスを提供する通信 デバイスドライバである。システムリソースを大切にするために、通信ドライバ は、アプリケーションによって使用されている場合のみにメモリにロードされる 。また、ＶＣＯＭＭは、通信デバイスのコンフィギュレーションおよびインスト ールを補助するためにオペレーティングシステムにおいてプラグアンドプレイサ ービスを使用する。リアルタイムサービスブロック４１４が、レイヤー４１０お よびレイヤー４２０内に部分的に示されている。太線４８０は、オペレーティン グシステムと、この具体的な実施例のホストベースのモデムのためのソフトウェ アとの間の境界を象徴するように設計されている。この境界線は、固定境界を表 すことを意図したものではなく、むしろ、アプリケーションからアプリケーショ ンへ、だいたいのコードがソフトウェアスタックのオペレーティングシステム側 またはモデム側のどちらかで実現され得ることを示すものである。ＲＴＳが境界 ４８０を越えるという事実は、ＲＴＳがモデムサービスのために仮想マシンマネ ージャ４１３に対するインタフェースとして機能するという事実を示しているに 過ぎない。 図３に示されるように、１６ビットアプリケーションは、単一のアドレス空間 で実行される。それらは、先制的にスケジュールされるのではなく、協調的にス ケジュールされる。単一の別個のアドレス空間で動作しているように示される３ ２ビットアプリケーションは、先制的にスケジュールされ、その結果、必要な時 にＣＰＵのアテンションを得る。しかし、１６ビットアプリケーションは、メッ セージボートを使ってスケジューリングを行う。従って、１６ビットアプリケー ションが、プロセッサを制御している場合には、制御を放棄するためのメッセー ジを通知するまでは、１６ビットアプリケーションが制御を維持する。このよう なアプリケーションが非協調的である場合には、アテンションが必要な他のプロ セスの排除に対してＣＰＵをホッグできる。 従来、モデムはマイクロコントローラおよびデータポンプを利用してきた。マ イクロコントローラを排除し、さもなければマイクロコントローラが行うであろ う処理をホストに行わせることが望ましい。しかし、このようなホストベースの モデムは、イベントおよび応答に関する、時には厳格な要件を満たすために、Ｃ ＰＵへの保証されたアクセスを必要とする。１６ビットアプリケーションが非協 調的となる能力、または他のアプリケーションが他の要求を落としめてＣＰＵへ の専用アクセスを要求する能力により、必要とされる指定の間隔内でのＣＰＵへ のアクセスを保証できなければ、ホストベースのモデムを作製することが不可能 となる可能性が生じる。本発明によれば、ＶｘＤアーキテクチャのサービスが利 用され、それによって、他のアプリケーションまたはドライバが実行中であるか もしれないこととは無関係に、モデムがＣＰＵ時間のスライスを得ることが可能 となる。 ＡＣＵバックグラウンドプロセスまたは機能は、主ルーチンにほぼ類似してお り、複数の従属ルーチンを逐次的に呼出す。マイクロコントローラ環境において は、ＡＣＵバックグラウンドループは、継続的に実行され、マイクロコントロー ラによって扱われる。マイクロコントローラの機能性がホストによって扱われて いる場合には、ホストベースのモデム環境において、モデム機能が、例えばどの ようなコネクションまたは文字も落とすことなく確実に起きることを可能とする ために十分なＣＰＵアクセスおよび時間が存在することを確実にする必要がある 。 ウィンドウズインタフェースレイヤー４２０は、ポートドライバインタフェー ス４２１、ＤＯＳのＣＯＭＭポート仮想化（Virtual ization）４２２、および プラグアンドプレイインタフェース４２３を含む。これらのモジュールにより、 レイヤー４００のアプリケーションが、オペレーティングシステムを介してモデ ムの主コードにアクセスすることが可能となる。ウィンドウズインタフェースレ イヤーの各インタフェースは、ユニバーサル同期受信機送信機（ＵＡＲＴ）エミ ュレーションモジュール４３１と通信する。これによっても、インタフェースレ イヤーの各インタフェースモジュールが、以下のコードに対する標準インタフェ ー スを持つことが可能となる。 モジュールレイヤー４４０は、ファクシミリモジュール４４１、データモジュ ール４４２（Ｖ．４２）、音声モジュール（ＶＣＥ）（４４３）、およびＤＴＥ モジュール４４５を含む。モジュール４４１〜４４３は、それぞれのタイプのサ ービスに関するデータを扱う。上に言及されたＡＣＵは、自動制御ユニットを表 し、モデムをコンフィギュレーションするために機能する。ＡＣＵは全ての従属 ルーチンを逐次的に繰り返し呼び出すバックグラウンドプロセスとして動作する 。ある特定のモジュール４４２が行うべき作業を持つ場合には、ループ中にリス トされた次のモジュールに制御を渡す前にその作業を完了する期間は、バックグ ラウンドプロセスを一時停止する。上記のように、ＡＣＵモジュールが十分頻繁 に起動させられない場合には、様々なサービスに関する文字またはコネクション が失われ得る。レイヤー４４０のＤＴＥモジュール４４５は、Ｉ／Ｏバッファ情 報の対応するモジュールへの移動を管理する。モジュールＩ／Ｏレイヤー４５０ は、様々なタイプのサービスモジュール４４１〜４４３に対してそれぞれのイン タフェースとモデムタスク４５４とを含む。モデムタスク４５４は、標準化イン タフェースを、モデムタスク自体のレイヤーおよびそれ以上のレイヤーにあるモ ジュールに提供し、データポンプ４７２の特質からそれらを隔離している。割込 みレイヤーは、データ送信／受信モジュール４６１を含み、これは、文字をデー タポンプからＰＣＩ／Ｏインタフェース４７１を通してサービスＩ／Ｏモジュー ル４５１〜４５３と、次に対応するモジュール４４１および４４３とに移動させ る。割込みレイヤーがデータポンプを適時にサービスし、それによってバッファ のオーバーフロー等により失われる文字がないことが確実にされることが特に重 要である。タイマ４６２は、それを行うことを助ける。タイマは、ＲＴＳ４１４ によって定期的に起動され、それによってモデムに対する十分に頻繁なハートビ ートが確保される。 図５は、ＲＴＳと、モデムＶｘＤと、仮想マシンマネージャに支援されるオペ レーティングシステムサービスと、タイミングデバイスのための仮想デバイスド ライバ（ＶＴＤ）との間のプロセス間通信を表すタイミング図である。この具体 的な図は、同時に実行される複数のサービスを含む。実行中のサービスの各タイ プの説明を容易にするために、この図面の部分が抽出され、後続の図に表示され る。 ３つの主要なサービスが図５に同時に示されている。１番目は、モデム機能の 妥当性を確保するために適時にモデムにおいてＡＣＵを起動させるバックグラウ ンドコールバックである。第２のサービスは、モデムの頻繁なハートビートを確 保するように設計されたものである。第３のサービスは、アプリケーションプロ セスが、他のプロセスを妨害しない時に移行を開始することを可能にする。これ らは、図６〜図８にそれぞれ示される。 図６では、プロセスが、モデムデバイスドライバからＲＴＳに対する、バック グラウンドコールバックを登録するための要求で開始する。それに応答して、Ｒ ＴＳが、仮想マシンマネージャに対してｓｅｔ＿ｇｌｏｂａｌ＿ｔｉｍｅｏｕｔ 命令を呼び出す。ＲＴＳはまた、タイマの細分性を設定するために、ＶＴＤ＿ｂ ｅｇｉｎ＿ｍｉｎ＿ｉｎｔ＿Ｐｅｒｉｏｄを送信する。典型的には、タイマは、 ５４ミリ秒のデフォルトに設定される。しかし、このデフォルトは、このコマン ドを用いて、インテル８２５３タイマ等のプログラム可能割込みタイマ（ＰＩＴ ）が許容する細分性にまで減少させられ得る。次に、モデムＶｘＤは、バックグ ラウンドタイムアウト間隔を設定する。典型的には、これは１００ミリ秒以下で ある。以前に設定されたグローバルタイムアウトに応じて、グローバルタイムア ウトが生じ、ＶＭＭモジュールがＲＴＳに知らせる。ＲＴＳは次に、ｓｃｈｅｄ ｕｌｅ＿ｇｌｏｂａｌ＿ｅｖｅｎｔコマンドをＶＭＭに送り、グローバルイベン トスケジュール完了応答（global event scheduled response）を受け取る。そ の応答が入ると、ＡＣＵに対するバックグラウンドコールが実行され、別のｓｅ ｔ＿ｇｌｏｂａｌ＿ｔｉｍｅｏｕｔコマンドがＶＭＭに送られる。ＲＴＳとＶＭ Ｍとの間の最後の４つの相互交換は、定期的に生じ、その結果、定期的なＡＣＵ バックグラウンドプロセスの実行が生じる反復セットを構成する。 図７は、モデムのハートビートとして機能するように用いられるプロセス間通 信のタイミング図である。モデムＶｘＤは、タイマコールバックをＲＴＳに登録 し、タイマタイムアウト間隔を設定する。それに応答して、ＲＴＳは、ｓｅｔ＿ ａｓｙｎｃ＿ｔｉｍｅｒをＶＭＭに送り、そのタイマがタイムアウトすると、Ｒ ＴＳが、ＶＭＭによって知らされ、モデムコードにおいてモデムクロックのハー トビートまたは減分をトリガするタイマコールバックを実行する。タイマコール バックが実行された後、ＲＴＳは再び、ｓｅｔ＿ａｓｙｎｃ＿ｔｉｍｅｒコマン ドをＶＭＭに送る。タイマタイムアウトがあり、ハートビートとしてタイマコー ルバックを実行する非同期タイマの設定プロセスは、定期的に繰り返され、それ によって、モデムの十分なハートビートが確保される。 図８は、レイヤー４００のアプリケーションが他のプロセスを妨害しない時に 移行を開始することを可能とするために使用されるプロセス間通信のタイミング 図である。特定の初期化シーケンスにおいては，ウィンドウズアプリケーション が、モデムの「性格」に関する情報を要求し得る。このような呼出しは、ＲＴＳ へ経路づけられ、次に、ＳＨＥＬＬ＿ＣａｌｌＡｔＡｐｐｙＴｉｍｅを呼出す。 ＶＭＭが、モデムとアプリケーションとの間の性格交換が、継続中のＩ／Ｏまた は他のプロセスを破損することなく生じ得ることを検出すると、アプリケーショ ンコールバックが実行され、それによって、アプリケーションおよび交換が生じ る。 従って、リアルタイムサービスおよび仮想マシンマネージャのサービスを使用 することによって、同時に実行中の他のアプリケーションまたはドライバとは無 関係に、ＣＰＵアテンションの十分な割当てを受けることが保証されるホストベ ースのモデム、他のプロセス、またはデバイスが実現され得る。このリアルタイ ムサービスを仮想デバイスドライバとして実現することによって、従来技術では 生じたであろう問題とは無関係に、ＣＰＵ時間に対する公平および平等な競争を 許可するように、仮想マシンマネージャのサービスに対するアクセスが持てる。 この開示では、本発明の好適な実施形態のみが示され、説明されたが、上記の ように、本発明は、様々な他の組み合わせおよび環境で使用することが可能であ り、本明細書に述べられたような発明概念の範囲内で変更または改変することが 可能であることが理解されるものとする。

Claims (1)

1. 【特許請求の範囲】 １．プロセスまたはデバイスに対する十分なコンピュータリソースを確保するた めの装置であって、 ａ．コンピュータと、 ｂ．ＤＯＳアプリケーションを実行するために過去に互換性のある、該コンピ ュータ上のオペレーティングシステム動作と、 ｃ．ＤＯＳアプリケーションのいかなる状態とも無関係にＣＰＵアクセスを確 保するために、該オペレーティングシステムおよび少なくとも１つのプロセスま たはデバイスと相互作用する仮想デバイスドライバと、 を備えた装置。 ２．前記オペレーティングシステムがＷｉｎｄｏｗｓ９５である、請求項１に記 載の装置。 ３．前記仮想デバイスドライバが仮想マシンマネージャと相互作用する、請求項 １に記載の装置。 ４．前記少なくとも１つのプロセスまたはデバイスがホストベースのモデムであ る、請求項１に記載の装置。 ５．前記仮想デバイスドライバが、繰り返されるバックグラウンドプロセスをス ケジュールするために使用される、請求項４に記載の装置。 ６．前記仮想デバイスドライバが、繰り返されるハートビートプロセスをスケジ ュールするために使用される、請求項４に記載の装置。 ７．前記仮想デバイスドライバが、アプリケーションとモデムとの間のモデム情 報の交換をスケジュールするために使用される、請求項４に記載の装置。 ８．前記少なくとも１つのプロセスまたはデバイスが、前記コンピュータの外部 のデバイスである、請求項１に記載の装置。 ９．前記少なくとも１つのプロセスまたはデバイスが、リアルタイムデータを収 集するためのデバイスである、請求項１に記載の装置。 １０．ＤＯＳアプリケーションを実行するために過去に互換性のあるオペレーテ ィングシステムを備えたコンピュータにおいて、反復プロセスをスケジュールす るための方法であって、 ａ．ＤＯＳアプリケーションのいかなる状態とも無関係にＣＰＵアクセスを確 保するための、該オペレーティングシステムおよび少なくとも１つのプロセスま たはデバイスと相互作用するスケジューリングプロセスを実行するステップ、 を包含する方法。 １１．仮想マシンマネージャおよびタイミングプロセスを持つオペレーティング システムを備えたコンピュータにおいて反復プロセスをスケジュールするための 方法であって、 ａ．該仮想マシンマネージャのサービスを使用して反復プロセスのためのスケ ジューリング機構として機能するための仮想デバイスドライバを実行するステッ プ、 を包含する方法。 １２．前記仮想マシンマネージャの前記サービスが、ｓｅｔ ｇｌｏｂａｌ ｔ ｉｍｅｏｕｔを含む、請求項１１に記載の方法。 １３．前記仮想マシンマネージャの前記サービスが、ｓｃｈｅｄｕｌｅ ｇｌｏ ｂａｌ ｅｖｅｎｔを含む、請求項１２に記載の方法。 １４．前記仮想マシンマネージャの前記サービスが、ｓｅｔ ａｓｙｎｃ ｔｉ ｍｅｒを含む、請求項１２に記載の方法。 １５．前記仮想マシンマネージャの前記サービスが、ｓｈｅｌｌ ｃａｌｌ ａ ｔ Ａｐｐｙ ｔｉｍｅを含む、請求項１２に記載の方法。 １６．リアルタイム要件をサービスするためのシステムであって、 ａ．オペレーティングシステムを備えたコンピュータと、 ｂ．少なくとも１つの周辺デバイスドライバによって管理される１つ以上の周 辺デバイスと、 ｃ．該周辺デバイスの少なくとも１つによるコンピュータリソースへのアクセ スを確保するための、仮想デバイスドライバとして実現されるプロセススケジュ ーラと、 を備えたシステム。 １７．前記１つ以上の周辺デバイスの１つがネットワーク制御盤である、請求項 １６に記載のシステム。 １８．前記ネットワーク制御盤が、１つ以上のユーザデバイスが接続されたネッ トワークに接続される、請求項１７に記載のシステム。 １９．周辺デバイスのリアルタイム要件をサービスするための方法であって、 ａ．コンピュータリソースに対して定期的および保証されたアクセスを必要と する該周辺デバイスに関連するプロセスに対して共通のスケジューリング機構と して機能するために仮想デバイスドライバを使用するステップ、 を包含する方法。 ２０．コンピュータプログラムプロダクトであって ａ．メモリ媒体と、 ｂ．該メモリ媒体に格納されたコンピュータプログラムであって、オペレーテ ィングシステムおよび少なくとも１つのプロセスまたはデバイスと相互作用し、 それによってＤＯＳアプリケーションのいかなる状態とも無関係に該プロセスま たはデバイスによるＣＰＵアクセスを確保するスケジューリングプロセスを実行 するための命令を含むコンピュータプログラムと、 を備えた、コンピュータプログラムプロダクト。 ２１．仮想マシンマネージャおよびタイミングプロセスを持つオペレーティング システムを備えたコンピュータにおいて反復プロセスをスケジュールするための コンピュータプログラムプロダクトであって、 ａ．メモリ媒体と、 ｂ．該メモリ媒体に格納されるコンピュータプログラムであって、該仮想マシ ンマネージャのサービスを用いて、反復プロセスのためのスケジューリング機構 として機能するように仮想デバイスドライバを実行するための命令を備えたコン ピュータプログラムと、 を備えた、コンピュータプログラムプロダクト。