JP2000500601A - 動的プログラム可能なモード切換えディバイスドライバアーキテクチャ - Google Patents

Abstract

(57)【要約】 オペレーティングシステム（５４）を機能サブエレメントを含むコントローラディバイスのコンピュータインタフェースへ結合するディバイスドライバアーキテクチャ。ディバイスドライバ（５０）は各々がオペレーティングシステムインタフェース（ＯＳＩ）をオペレーティングシステム（５４）へ提供するオペレーティングシステムインタフェースオブジェクトと、コントローラディバイスの前以て決定されたそれぞれのサブエレメントのオペレーティングモード確立するために各々がコンピュータインタフェースへ適用されるべきプログラミング値の生成を提供するコンピュータインタフェースオブジェクトと、データを処理し、そして、前以て決定済みの組合わせにおける複数のコンピュータインタフェースオブジェクトへのコールを生成するためにオペレーティングシステムインタフェースオブジェクトの各々によってコール可能な処理ルーチンのディバイスドライバライブラリとを有する。ディバイスドライバライブラリはその中においてプログラミング値の生成とコンピュータインタフェースへの適用を定義する実行コンテキストの選択を作動可能化する。ハードウェアインタフェースの状態は、個別のコンテキストにおいて仮想化および維持され、実質的にディバイスドライバ（５０）専用のコンテキスト切換えを介して、選択されたオペレーティングシステム事象に応答してハードウェアインタフェースの状態のアプリケーション特有の動的変更を可能にする。

Description

【発明の詳細な説明】 動的プログラム可能なモード切換えディバイスドライバアーキテクチャ 発明の背景 発明の分野 本発明は、全体的に、コアオペレーティングシステムと、通常、ハードウェア ディバイスとの間のインタフェースを定義および確立するためにコンピュータオ ペレーティングシステムにおいて用いられるディバイスドライバの設計に関し、 詳細には、その中で特に情報ディスプレイ機能を含むオペレーティングシステム 機能を一般的にサポートするハードウェアディバイスが作動する、仮想化され、 かつ、コンテキスト切り替え可能なインタフェース環境を提供するモジュール式 ディバイスドライバアーキテクチャに関する。 関連技術の説明 通常のコンピュータシステムにおいて、ソフトウェアオペレーティングシステ ムは、ユーティリティ及びデーモンプログラムを含むアプリケーションプログラ ムに一般化されたシステムサービスを提供する。これらのシステムサービスには 、通常、個々のハードウェア周辺ディバイスへのアクセスが含まれ、この場合、 各ディバイスが、通常、コンピュータシステムに、明確に定義されたハードウェ アインタフェースを提供するこれらのハードウェア周辺ディバイスは、コンピュ ータシステムに直接的或いは間接的に付加されていても差し支えない。ディバイ スドライバは、オペレーティングシステムに一体構造として統合可能なソフトウ ェアモジュール又は構成要素として実現され、通常、明確に定義されたソフトウ ェアアプリケーションプログラムインタフェース（ＡＰＩ）を、オペレーティン グシステム及び各ハードウェアインタフェース用のアプリケーションプログラム に提供するために用いられる。ディバイスドライバは、しばしば、例えばビデオ コントローラのような特定クラスのハードウェアインタフェースに関する細目仕 様を備えたアプリケーションプログラム又はオペレーティングシステムの対話（ イ ンタラクション）を単純化することの出来る程度のディバイス独立性または仮想 化を提供する。通常、特定のハードウェアインタフェースの基礎となる各具体化 に関しては、アプリケーションプログラム及びオペレーティングシステムに提供 される他の点では共通なＡＰＩを実現するために特有のディバイスドライバが用 いられる。 従来のディバイスドライバ設計に固有な多くに問題が有る。第１に、従来のデ ィバイスドライバは、特定のハードウェアインタフェース、及び、基礎ディバイ ス、又は、コントローラシステムの機能にとって特有である。従って、ハードウ ェアコントローラの新規または異なるバージョンが作成されると、必ず、新規ま たは異なるハードウェアにとって同等に特有な新規ディバイスドライバも開発さ れなければならない。多数の異なるバージョンのあるハードウェアディバイスの 場合には、概して同数のディバイスドライバが開発されなければならない。その 代わりに、複数のバージョン又はタイプのディバイスをサポートするように、単 一組合わせディバイスドライバを作成することが可能である。この種のディバイ スドライバは、通常、他の点では実質的に相互に独立している複数のディバイス 特有ドライバを、単一２進ファイルに組み込む。 特定のハードウェア１個をサポートするために必要なディバイスドライバの有 効個数も、その中で当該ハードウェアが使用されるオペレーティングシステム環 境の個数および差に依存する。極めて密接に関係したオペレーティングシステム において、当該ディバイスドライバの実質的な再開発には、特定のオペレーティ ングシステムに当該ディバイスドライバを組み込む適切な能力を提供すること、 及び、おそらく更に重要なはずであるが、論理的には類似するが、しばしば、全 く異なるＡＰＩを当該オペレーティングシステム及びアプリケーションに提供す ることの両方が必要とされる。通常、当該ディバイスドライバのＡＰＩの詳細な 定義は、当該ディバイスドライバ自体の詳細な設計を規制する。従って、ハード ウェアは同じであるがオペレーティングシステムの異なる場合のディバイスドラ イバは、しばしば、殆ど完全に独立して開発される。 特定のハードウェアコントローラをサポートするために必要なディバイスドラ イバの個数に影響する別の問題は特定のコントローラへ接続される他のハードウ ェア及びシステムの性質に起因する。再び、コンピュータシステムの詳細な構成 に融通性を持たせるために、ハードウェアコントローラは、多数の明確に異なる オペレーションモードをサポート可能であり得る。例えば、ビデオコントローラ は、かなりの範囲に亙って、ビデオディスプレイ解像度及び色深度をサポート可 能であり得る。ただし、この場合の範囲は、例えば、特定のビデオコントローラ に実際に実現されたビデオＲＡＭの量のような、直接的制限条件により、そして 、添付ビデオディスプレイの垂直および水平最大周波数によって間接的に拘束さ れることがある。特定のアプリケーションの必要条件が、ディバイスドライバに よってサポートされなければならない特定のオペレーションモードの選択を要求 することもあり得る。一般的に、多くのディバイスドライバは、それぞれ、１つ 又は複数のオペレーションモード異なる集合をサポートするようなハードウェア コントローラを備える。従って、特定のコンピュータシステムのコンフィギュレ ーションに直接基づくオペレーティングシステムの組込みに関して、装備されて いるディバイスドライバのなかの１つが選定されなければならない。所要のオペ レーティングモードの集合をサポートするディバイスドライバを選出することが 困難であることは別として、異なる個々のディバイスドライバをサポートする多 くの種類のモードをプリエンプティブ（割り込み優先的）に決定するには本質的 な困難が存在する。個々のドライバは僅かな量だけ異なるとしても、開発対象と なるドライバが、かなりの個数に達することはあり得るはずである。 第２の問題は、部分的には第１の問題の結果に関係するが、各ディバイスドラ イバは、商的に受け入れ可能なオペレーションであることを保証するために、当 該ディバイスドライバがその中で使用される可能性のある全ての種類の環境にお いて徹底的にテストされなければならないということである。一般に、ディバイ スドライバは、実質的には、オペレーティングシステムに全体として組込まれた モノリシックソフトウェアモジュールである。従って、特定のオペレーティング システム用の或る１個のディバイスドライバの極く些細な異形部をテストを行う 場合であっても、当該ディバイスドライバの正しい動作を立証するために、操作 機能及びアプリケーション互換性の全テストを行うことが必要である。選択的機 能テストは、モノリシックにコード化されたディバイスドライバのあらゆる修正 に起因する付帯的な操作上のエラーの真の可能性により、一般に、不適当である 。実際に異なるディバイスドライバの実質的な個数が、適度に複雑なハードウェ アコントローラ及び対応するテストの組のサイズ及び範囲に関して、テストの実 施を支持したとしても、ディバイスドライバのテストを実施することは、かなり の出費と新規製品または改良バージョンの市販開始の大幅な遅延とを意味する。 従来のディバイスドライバ設計に関する第３の問題は、この種の設計が実質的 に静的なタイプのハードウェアコントローラ管理を提供することである。一般に 、ディバイスドライバは、当該ディバイスドライバによって管理されるハードウ ェアコントローラに関して、ただ１組のオペレーティングパラメータを設定する 。コンピュータシステムにおいて実行するオペレーティングシステム及びアプリ ケーションプログラムは、全て、この静的モードのパラメータを許容しなければ ならず、そうでなければ、正しく作動することに実質的に失敗するはずである。 限られた場合において、従来のディバイスドライバは、ある種のモードを利用可 能にするか、或いは、アプリケーションプログラムにとって見える状態にするこ とが可能である。従って、これらのモードを利用するために、ディバイスドライ バは、アプリケーションプログラムを信頼して、実質的にコンパイルされたハー ドウェア依存性を持つ。このような場合、モードスイッチ（態様切換え）を引き 起こすことができるとしても、この種のあらゆるスイッチ（切換え）に実際的に 気付かない他の実行プログラムに潜在的な悪影響を及ぼすけれども、アプリケー ションプログラムはモード変更を引き起こす。 一般に、或る種の多重タスクオペレーティングシステムは、オペレーティング システムにサポートされた状態変更に限られるけれども、制限された動的ハード ウェアコントローラモード切換えを実施することが出来る。これらの場合、オペ レーティングシステムは、新規な作動モードの状態に関して一貫性をもつディバ イスドライバ及びハードウェアコントローラの状態を実質的に再ロードする。た だし、実行中のアプリケーションとディバイスドライバ及びハードウェアコント ローラの状態との間には直接的関係はない。再び、あらゆる実行中のアプリケー ションは、あらゆるモードスイッチに、完全にではないとしても殆ど気付かない 。従って、選定されたモードは、いくらかの実行中アプリケーションに関しては 最 適であっても、現行の実行焦点調節を伴ったアプリケーションに関しては、必ず しも最適であるとは限らないはすである。 発明の要約 従って、本発明の一般的な目的は、動的再構成に基づき独立したハードウェア コンフィギュレーションオプションを提供することのできる融通性に富むモジュ ール式ディバイスドライバアーキテクチャを提供することにある。 これは、本発明において、プロセッサを有するコンピュータシステムの記憶装 置に装備され、複数の機能サブエレメントを含むコントローラディバイスのコン ピュータインタフェースにオペレーティングシステムを結合するために作動する ディバイスドライバアーキテクチャを提供することによって達成される。ディバ イスドライバは、それぞれがオペレーティングシステムへのオペレーティングシ ステムインタフェース（ＯＳＩ）を提供する複数のオペレーティングシステムイ ンタフェースオブジェクトと、コントローラディバイスのそれぞれ所定のサブエ レメントのオペレーティングモードを確立するためにそれぞれがコンピュータイ ンタフェースへ適用されるべきプログラミング値の生成を提供する複数のコンピ ュータインタフェースオブジェクトと、データを処理し、そして、所定の組合わ せにおける複数のコンピュータインタフェースオブジェクトへのコールを生成す るために、複数のオペレーティングシステムインタフェースオブジェクトの各々 によってコール可能な処理ルーチンのディバイスドライバライブラリとを有する 。 ディバイスドライバライブラリは、その中において、プログラミング値の生成 及びコンピュータインタフェースへのプログラミング値の適用を定義するための 実行コンテキストの選択を作動可能化する。 本発明の利点は、ハードウェアインタフェースの状態、及び、これに対応して 、ハードウェアインタフェースを提供するコントローラの状態が個別コンテキス ト内において仮想化および維持されることである。ほかの点においては個々のア プリケーションプログラムによって取り扱い或いは管理されなければならないコ ントローラの操作上の機能またはモードは、本発明のオペレーションによって仮 想化可能である。本発明は、ディバイスドライバのオペレーションによって実行 さ れる実質的な専用コンテキスト切換えを介してハードウェアインタフェースの状 態のアプリケーション特有の動的変更を提供する。選定されたオペレーティング システム事象は、新規コンテキストの作成、及び、当該ディバイスドライバによ るコンテキスト間の動的切換えを開始するために、修正或いはトラップされる。 本発明の他の利点は、ディバイスドライバが、当該ディバイスドライバを介し てコントローラによりサポートされる機能の包括的な最適化を提供することであ る。ディバイスドライバは、当該ディバイスドライバによってサポートされるＡ ＰＩコールインタフェースの仮想化を提供する。オペレーティングシステムイン タフェースオブジェクトの使用を介したコールインタフェースの仮想化は、独立 して定義されたＡＰＩ、及び、共通実行ストリームによって実質的にサポートさ れるべき機能的に等価なコールの変換に関して、特有のサポートを提供する。 本発明の更なる利点は、ディバイスドライバのコールインタフェースの仮想化 が、ＡＰＩコール及びそれらのパラメータの共同評価を構造的に確立し、共同実 行ストリーム内における後続するパラメータチェックに関する必要条件を実質的 に除去することである。コンテキストデータ構造を参照するポインタと結合した 結果としての実質的に線形の実行ストリームは、効率的な実行動作を保証し、同 時に、従来のモノリシックディバイスドライバにおいて達成可能であるよりも実 質的に更に大きい機能性を作動可能化する。 本発明の更に他の利点は、ディバイスドライバが、実質的に線形の実行ストリ ームのコンテキスト依存変更を提供することである。コンテキスト間の切換えを 作動化またはサポートするために必要な変換機能は、変換機能の実施が必要かど うかを判定するための反復テストを最小限にするように実行ストリームに機能を 直接リンクすることによってサポートされる。 本発明の更なる別の利点は、ディバイスドライバが、ハードウェアインタフェ ースを介してアクセス可能な特定のコントローラコンフィギュレーションをサポ ートするために必要または最適である実質的な機能オブジェクトの動的ローディ ング及びコンフィギュレーションを組み込むことである。ディバイスドライバは 、当該コントローラを構成する独立した機能的なサブエレメントを識別するため にハードウェアインタフェースを介して、或いは、そうでなければ、コントロー ラ から獲得された符号化済みコンフィギュレーションデータに応答し、サブエレメ ントをサポートするために適したハードウェアインタフェースオブジェクトの対 応する集合を決定し、当該ディバイスドライバの初期化の一部として、オブジェ クト集合において動的にロード及びリンクする。 本発明の更に別の利点は、ディバイスドライバが、機能的または操作上の或る アスペクトに関してプログラム可能であるような様々のハードウェアインタフェ ースオブジェクトをサポートすることである。ハードウェアインタフェースを介 して、或いは、そうでなければ、コントローラから獲得された符号化済みのコン フィギュレーションデータに基づき、当該ディバイスドライバは、ハードウェア インタフェースオブジクトがそれらの対応するサブエレメントをどのようにして サポートするかということの詳細について定義する操作上のコンフィギュレーシ ョンデータを用いてハードウェアインタフェースオブジェクトをプログラムする ために、システムメモリからのコンフィギュレーションデータを識別し、そして 、ロードする。 更に本発明の他の利点は、当該ディバイスドライバが、その中において、他の ハードウェアインタフェースオブジェクト、及び、ディバイスドライバの他の構 造的構成要素との実質的分離における新規ハードウェアインタフェースオブジェ クトが開発可能であるような、確立したアーキテクチャを提供することである。 ハードウェアインタフェースオブジェクトの構造的設計は、対応するハードウェ アインタフェースオブジェクトをプログラムするために使用される操作上のコン フィギュレーションデータを再定義することによって実施されるべきコンフィギ ュレーションの実質的な改訂及び改良を前記オブジェクト自体が同様に可能にす る。改訂されるか、或いは、新規なコントローラサブエレメントをサポートする ディバイスドライバの修正は、サブエレメントに対応するハードウェアインタフ ェースオブジェクトに対してソースコード修正の準備をすることと対照的に、コ ンフィギュレーションデータファイルの単なる編集に限られることがある。いず れにせよ、互換性テストは、コントローラの改訂されるか、或いは、新規なサブ エレメントをサポートする特定のハードウェアインタフェースオブジェクトのテ ストに適当に限定することが出来る。 本発明の更に別の利点は、ディバイスドライバが、ビデオディスプレイコント ローラによって現在サポートされている色深度について一貫性のある報告を実施 するために、オペレーティングシステムの修正を提供することである。異なる色 深度コンテキストは、１つ又は複数の実行中アプリケーションの最大許容色深度 に対応する各コンテキストを用いて、実行中のアプリケーションの集合に関して 確立される。コンテキストが変更されるにつれて、或るアプリケーションの最大 色深度が、ビデオディスプレイコントローラの色深度能力を越えた場合、該当す る線形実行ストリームにリンクされた色深度変換機能が、ディスプレイデータ色 深度変換を提供する。 図面の簡単な説明 本発明のこれら及び他の利点及び特徴は、本発明について以下に示す詳細な説 明を添付図面と関連して考察することにより一層良く理解されるはずである。こ の場合、次に示す添付図面全体を通して、同じ参照番号は同じ部分を示すものと する。 図１は本発明に従って作成されたコンピュータシステムの概略構成図である。 図２は本発明のディバイスドライバの初期化期間中における、本発明のアーキ テクチャ的コンフィギュレーションの概略構成図を提供する。 図３は本発明の初期化を詳述するフローチャートを提供する。 図４は本発明のディバイスドライバのランタイム実行期間中における、本発明 のアーキテクチャ的コンフィギュレーションの概略構成図を提供する。 図５ａはディバイスドライバコンテキストを定義する複数のシェルオブジェクト とシェルライブラリと、本発明の好ましい実施例と一貫性をもつオペレーティン グシステムの物理的ディバイス構造との間の関係を示す一般的な説明図を提供す る。 図５ｂは本発明の好ましい実施例と一貫性をもつハードウェアインタフェース オブジェクトの複数の例示の間の関係を示す一般化された説明図を提供する。 図６ａは、本発明の好ましい実施例に従ったコンテキストスイッチに関して準 備する過程の動作を示すフローチャートを提供する。 図６ｂは、本発明の好ましい実施例に従った新規コンテキストの実現化に用い られる過程を示すフローチャートを提供する。 図７は本発明の好ましい実施例に従って構成されたディバイスドライバの動作 を終結させるために用いられる過程のソフトウェアフロー図を提供する。 図８は本発明と一貫性をもつオペレーティングシステム内において実行する多 重仮想マシンをサポートする本発明の真、及び、仮想の両アーキテクチュア的コ ンフィギュレーションの使用を説明する構成図を提供する。 図９は本発明に従って作成された仮想ディバイスドライバのアーキテクチュア 的コンフィギュレーションの概略構成図を提供する。発明の詳細な説明 Ｉ．ハードウェアシステムの概観 本発明の利用に適したコンピュータシステム１０を図１に示す。コンピュータ システム１０は、システムデータバス１４を介して主記憶装置１６および大容量 記憶周辺装置１８に結合される中央処理装置（ＣＰＵ）１２を含むことが好まし く、前記の大容量記憶周辺装置はディスクドライブコントローラ及びハードディ スクドライブユニットを含むことが好ましい。サポートされている機能が非揮発 性資源からの或る実行可能なデータ及び構成ファイルの読取りを可能にする場合 には、本発明のためには、大容量記憶周辺装置１８の動作だけで十分である。従 って、大容量記憶周辺装置１８は、一般にファイル指向編成されているコンピュ ータシステム１０によって読取り可能なデータの記憶装置を提供する外部又は遠 隔装置、或いは、システムへのアクセスを提供する通信コントローラであっても 差し支えない。 ビデオディスプレイコントローラ１９も、同様に、システムバス１４に結合さ れた周辺ディバイスとして提供される。本発明に用いられるビデオディスプレイ コントローラ１９のハードウェア具体化例の性質は全体的に従来通りである。た だし、本発明に関係する状況について説明する場合における当該ビデオコントロ ーラ１９は、統合的に当該コントローラ１９を構成する論理的に独立したサブエ レメントの収集体として一意的に記述される。これらのサブエレメントは、全体 的に独立した操作プログラミング可能性に関して、これらが特に機能的な独自性 （アイデンティティ）を持つことによって論理的に区別される。すなわち、コン トローラ１９のハードウェア具体化例の機能に関する区分が、本発明のためのコ ントローラ１９を構成する個別サブエレメントを大筋において規制する。 サブエレメントを区別するための別の基準は、プログラムによるＣＰＵ１２の 実行の最終的な結果として、対応するサブエレメントをプログラミングする方法 における一般性（コモナリティ）に基づいて機能をグループ化することである。 従って、図１に概要的に示すように、ビデオコントローラ１９のサブエレメント には、これらに限定されることなく、ビデオディスプレイバッファ２０、Ｄ−Ａ 変換器（ＤＡＣ）２２、ビデオグラフィックスアクセラレータ２４、ビデオコン トローラ２６、プログラム可能なクロックゼネレータ２８、ハードウェアカーソ ルコントローラ、及び、コーダ‐デコーダユニット（ＣＯＤＥＣ）が含まれるこ とが好ましい。コントローラ１９を構成するこれらサブエレメントの各々は、シ ステムバス１４に適切に結合されるハードウェアレジスタインタフェース３０を 介して比較的独立的にプログラム可能である。従って、ＣＰＵ１２は、サブエレ メント２０、２２、２４、２６、２８からの情報をプログラム化および獲得可能 である。レジスタインタフェース３０及び１つ又は複数のサブエレメントは、実 際問題として、１つの単一集積回路上に物理的に常駐可能である。１つの単一集 積回路上にサブエレメントが共同所在すること、又は、サブエレメントが他のサ ブエレメントを介してアクセス可能である可能性は、サブエレメントを相互に機 能的に区別することには影響を及ぼさない。 サブエレメント２０〜２８のプログラミングによって、ビデオディスプレイ３ ２は、テキスト及び図式情報の提示（プレゼンテーション）用としてサポートさ れる。本発明の好ましい実施例において、多重ディスプレイウィンドウ３４、３ ６は、ディスプレイ３２上に見える現在作動中または「焦点（フォーカス）」デ ィスプレイウィンドウを選択するために使用できるポインタ３８と組合わせてサ ポートされる。ディスプレイウィンドウ３４、３６は、多数の個別事象を介して 現行焦点を獲得することが出来る。これらの事象には、コンピュータシステム１ ０によって実行するための新規アプリケーションプログラムの開始が含まれる。 新規に開始されるアプリケーションのメインウィンドウは、デフォルトにより、 ディスプレイ３２の現行焦点を獲得する。ポインタ３８は、例えば、マウスクリ ックの発生に際して焦点調節を受けるウィンドウ３４、３６を選択するためにも 利用することができる。最後に、ディスプレイウィンドウ３４、３６は、別のア プリケーションの終了に際して焦点調節を受けることが可能である。これらの情 況の各々において、焦点調節事象が生成され、この生成に際して、オペレーティ ングシステムの実行を介してＣＰＵ１２が作動可能である。 他の周辺装置４０も、同様に、コンピュータシステム１０の構成要素として存 在しても差し支えない。これら他の周辺装置４０には、オーディオ、リアルタイ ムビデオ、及び、単独または相互組合わせされた他の複雑な多重機能作動（オペ レーション）をサポートする複雑なコントローラが含まれても差し支えない。当 該コントローラの機能的動作及び編成が、ＣＰＵ１２によって直接或いは間接的 にプログラム可能な非常に多数の機能エレメントとして合理的に細分化されるこ とを条件として、この種の複雑なコントローラは本発明によって効果的にサポー ト可能である。例えば、システムバス１４に呈示されるレジスタインタフェース を介して全て直接或いは間接的に表されるウェーブテーブル合成、ＦＭ合成、等 化コントローラ、残響コントローラ、及び、多重チャネル増幅器サブエレメント を呈示する高性能オーディオサブシステムは、本発明によって最も適切にサポー ト可能である。 ＩＩ．ソフトウェアシステムの概観 本発明は、任意の個数のサブエレメントを備えたあらゆる周辺コントローラを 容易にサポート可能であるが、好ましい実施例に示すように、ビデオディスプレ イコントローラ１９のサポート及び制御用として適用される場合に、最もよく理 解されるはずである。図２において、本発明の好ましいディバイスドライバ実施 例５０は、ビデオディスプレイコントローラ１９のレジスタインタフェース３０ へのディバイスドライバの論理的結合を表すハードウェアインタフェースとオペ レーティングシステム層５４との間に配置されている。オペレーティングシステ ム層５４には、一般に、オペレーティングシステム核５６と、いくらかの基礎的 なオペレーティングシステムレベルの機能性を追加する潜在的に１つ又は複数の オペレーティングシステムエキステンション５８とが含まれる。最後に、オペレ ーティングシステム層５４は、結果的に、１つ又は複数のアプリケーションプロ グラム６０をサポート可能である。 動作に際して、アプリケーションプログラム６０は、アプリケーション６０に よってコール出来る実行エントリポイントの１つの集合として効果的に提供され るアプリケーションプログラムインタフェース（ＡＰＩ）を介してオペレーティ ングシステム層５４サポートサービスを獲得する。本発明の実施例に従い、オペ レーティングシステム核ＡＰＩコールポイントの小さい部分集合６２は、ディバ イスドライバ５０の初期化に際して修正される。これらの修正されたコールポイ ントには、ウィンドウ焦点調節変化事象をアプリケーション６０に報告するエン トリポイントルーチン、及び、当該ディスプレイ３２の現行カラー深度をアプリ ケーション６０に報告し返すエントリポイントルーチンが含まれる。焦点調節変 化事象（イベント）は、当該事象に応答して追加事象処理を提供するオペレーテ ィングシステムエキステンション５８へのＡＰＩコールを含むように修正される ことが好ましい。この追加事象処理には、焦点調節事象の結果として一般的に開 始されるべきアプリケーションの実行環境を定量化するデータを獲得するための 構成（コンフィギュレーション）検索の実施が含まれる。検索されたデータには 、開始されようとしているアプリケーションのために必要とされるスクリーン解 像度およびカラー深度構成（コンフィギュレーション）が含まれることが好まし い。 カラー深度報告ルーチンの修正は、任意のアプリケーション６０によって要求 された最大カラー深度が当該ディスプレイ３２の現行カラー深度としてアプリケ ーション６０に報告されることを保証するために明確に実施される。従って、本 発明の好ましい実施例によれば、全てのアプリケーション６０は、特にカラー深 度に関して、当該ディスプレイ３２の完全に仮想化された表現を基準として実行 する。即ち、ディバイスドライバ５０は、どのようなカラー深度がアプリケーシ ョン６０によって要求されようとも、要求されたカラー深度が他のアプリケーシ ョン６０によって扱うことの出来る最大カラー深度、或いは、実際に、当該ディ スプレイ３２自体の最大カラー深度を超過すると否とに拘わらず、完全なサポー トを提供する。 Ａ．ディバイスドライバのソフトウェアアーキテクチャ 上位レベル： 核層５４は、オペレーティングシステム核５６及びあらゆるエキステンション ５８に、ディバイスドライバ５０へのエントリポイントを提供するオペレーティ ングシステムＡＰＩ（Ｏ／Ｓ ＡＰＩ）を介してディバイスドライバ５０に接続 する。ディバイスドライバ５０内において、Ｏ／Ｓ ＡＰＩは、主として、グラ フィックスディスプレイインタフェース（ＧＤＩ）モジュール６４、直接ドロー （ＤＤ）モジュール６６、各々が、例えば、直接３Ｄ（Ｄ３Ｄ）のような現在ま たは将来の定義済みＡＰＩを表す任意の個数の他のモジュール６８を含む多数の オペレーティングシステムインタフェースモジュールによってサポートされてい る。追加ＡＰＩエントリポイントは、オペレーティングシステム（Ｏ／Ｓ）モジ ュール７０、グラフィックスインタフェース（ＧＲＸ）モジュール７１、及び、 シェルモジュール７２によって提供される。これらのモジュールは、当該ディバ イスドライバ５０のＯ／Ｓ ＡＰＩを構成するコール可能な実質的にすべてのエ ントリポイントを集団的に表す。 シェルモジュール７２は、システム始動に際してオペレーティングシステム核 ５６の初期化の一部として記憶装置１６にロードされるディバイスドライバ５０ の初期構成要素である。例えば、Ｍｉｃｒｏｓｏｆｔ ＭＳ−Ｗｉｎｄｏｗｓ’ ９５TMのような通常のオペレーティングシステムにおいては、例えば、ＭＳ−Ｗ ｉｎｄｏｗｓ’９５のレジストリサービスのような標準初期化構成（コンフィギ ュレーション）ファイル又はデータベースにおける参照の結果として、オペレー ティングシステム核５６は、シェルモジュール７２を記憶装置１６にロードする はずである。 シェルモジュール７２によって提供される初期化エントリポイントは、オペレ ーティングシステム核５６がディバイスドライバ５０の当該ディバイスドライバ 特有の初期化を開始することを可能にする。この初期化の一部分として、シェル モジュールは、ボードドライバ、ハードウェアインタフェースモジュールの集合 、及び、オペレーティングシステム層５４に呈示されるはずのＯ／Ｓ ＡＰＩを サポートするようにディバイスドライバ５０の具体化を完成するために必要なオ ペレーティングシステムインタフェースモジュールの補集合を決定する。好まし い実施例において、シェルモジュール７２に静的にリンクされなかった場合には 、決定されたこれらの追加モジュールが動的にロードされ、その次に、ディバイ スドライバ５０に論理的にリンクされる。 ディバイスドライバ５０の初期化のためのサポートサービスを獲得するために 必要なＯ／Ｓ ＡＰＩへのコールインタフェースを確立するためには、少なくと もオペレーティングシステムモジュール７０は、シェルモジュール７２の必須部 分または構成要素としてロードする。ＧＲＸモジュール７１も同様にシェルモジ ュール７２によってロードされることが好ましい。実用的利便さの問題として、 一般的に使用される他のデフォルトオペレーティングシステムインタフェースモ ジュールも、同様に、オペレーティングシステムモジュール７０に静的にリンク 可能である。 ＧＤＩ６４，ＤＤ６６、及び、Ｄ３Ｄ６８モジュールによって特に実演される ように、本発明のディバイスドライバ５０は、当該ディバイスドライバ５０のＯ ／Ｓ ＡＰＩを、オペレーティングシステム核５６、及び／又は、オペレーティ ングシステムエキステンション５８の特定の部分に特有な分離されたユニットと して具体化することが好ましい。従って、好ましい実施例において、ＧＤＩモジ ュール６４は、ＭＳ−Ｗｉｎｄｏｗｓ’９５TM製品用としてＭｉｃｒｏｓｏｆｔ によって事前に定義されたフラットモデルＤＩＢエンジンドライバインタフェー スをサポートすることが好ましい。同様に、直接ドローモジュール６６は、標準 直接ドローＡＰＩ用ハードウェア独立インタフェースをサポートする。Ｄ３Ｄモ ジュール６８は、Ｗｉｎｄｏｗｓ’９５TM用として発表済みのＭｉｃｒｏｓｏｆ ｔ直接３Ｄ ＡＰＩをサポートするはずである。これらの各ＡＰＩに関する文書 は、Ｍｉｃｒｏｓｏｆｔ，Ｉｎｃ．（Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎ） の市販製品として入手可能なＭｉｃｒｏｓｏｆｔソフトウェア開発キット（ＳＤ Ｋ）及びＭｉｃｒｏｓｏｆｔディバイスドライバキット（ＳＤＫ）の一部として 入手可能である。従って、本発明にかかる動的ローディング能力は、ディバイス ドライバ５０によって提供される包括的ＡＰＩサポートが、容易に注文作成され ることを可能にし、そして、追加オペレーティングシステムインタフェースモジ ュールの動的ローディングを介して、拡張されることを可能にする。 Ｏ／Ｓ及びＧＲＸモジュール７０、７１を含むシェルモジュール７２は、ディ バイスドライバ５０の動作（オペレーション）を介して、通常および所有権を主 張できる（プロプラェタリ）両サポート機能をサポートするための必要性に応じ て、オペレーティングシステム層５４に対し、通常および所有権を主張できる（ プロプラェタリ）両ＡＰＩインタフェース部分を提供する。通常のＡＰＩ部分に は、記憶装置１６へのローディングに際して、オペレーティングシステム層５４ により、シェルモジュール７２の初期化を開始することを可能にする初期化エン トリポイントが含まれる。一般的標準終了（ターミネーション）コールエントリ ポイントも同様に提供される。このエントリポイントは、オペレーティングシス テム層５４が、オペレーティングシステム層５４のシャットダウンが切迫してい ること、及び、ディバイスドライバの順序立った終了が要求されることをディバ イスドライブ５０に合図することを可能にする。 シェルモジュール７２によって提供される所有権を主張できる（プロプラエタ リ）ＡＰＩエントリポイントには、当該ディスプレイ３２上に呈示されるデスク トップを定義するデータの読取り及び書き込み、現行ビューポート、及び、ディ バイスドライバ５０のオペレーションを定義する或るデータを提供するエントリ ポイントが含まれる。この後の方の情報には、ディスプレイ３２の現在の物理的 カラー深度、ディスプレイポインタ３８の現行カラー及びパターン、及び、例え ば、ディバイスドライバ５０のインタレース、ビデオ同期化タイプ、ビデオ高速 スクロール、及び、カラーイネイブルオプションのような、大幅にビデオハード ウェア特有化された多数の態様の設定が含まれても差し支えない。 最後に、オペレーティングシステムモジュール７２は、基礎的なオペレーティ ングシステムサービスを獲得するためにオペレーティングシステム層５４をコー ルするディバイスドライバサポートルーチンを提供する。本発明の好ましい実施 例において、これらのシステムサービスには、記憶装置の割当、既に割当て済み である記憶装置の解放、メモリオブジェクトの実行可能またはロック状態を不能 にし、データを読み取り、そして、定義済みＩ／Ｏアドレスにデータを書き込み 、そして、一般に大容量記憶周辺装置１８によって記憶された状態にある名前付 きデータファイルを開き、読み取り、そして、閉じるために動的リンクライブラ リ、例えばメモリオブジェクトを実行可能にするかく又は、実メモリ内のメモリ オブジェクトをロックすることを可能にするような記憶管理機能のローディング 及びアンローディングが含まれる。 Ｂ．ディバイスドライバソフトウェアのアーキテクチャ 下位レベル： シェルモジュール７２は、ビデオディスプレイコントローラ１９の特定の場合 に関して、同様に、ディバイスドライバ５０の動的構成（コンフィギュレーショ ン）を提供する。コンピュータシステム１０においては、機能的に類似する多数 のビデオディスプレイコントローラ１９のうちの任意の個数を利用可能であるが 、本発明のディバイスドライバ５０は、特定のビデオディスプレイコントローラ １９のハードウェア仕様細目を最適サポートするようにボードドライバ７４の動 的選択およびディバイスドライバ５０への包含（インクリュージョン）を提供す る。シェルモジュール７２は、任意個数の異形体（バリアント）の中から、特定 のビデオディスプレイコントローラ１９の主要態様に対応する特定のボードドラ イバ７４を選定する。実際には、特定のビデオディスプレイコントローラ１９の 主要態様は、コントローラ１９の具体化に用いられる集積回路グラフィックスア クセラレータチップ又はチップ集合の特定の構造（アーキテクチャ）である。従 って、１つの単一ボードドライバ７４は、ディスプレイコントローラ１９の特定 変形体の適切に定義されたファミリに対応しても差し支えない。他のボードドラ イバは、定義の異なるコントローラの別のファミリに対応するように構成可能で ある。 ボードドライバ７４は、１組のハードウェアインターフェイスモジュールを選 択的にサポートすることにより、ディバイスドライバ５０の動的構成（コンフィ ギュレーション）の追加層を提供する。これらのハードウェアインタフェースモ ジュールは、ディバイスドライバ５０の構成要素として動的にロードすることが 可能であり、そして、ビデオディスプレイコントローラ１９の特定具体化の個別 サブエレメントに実質的に対応する。本発明の好ましい実施例において、ハード ウェアインタフェースモジュールの集合には、クロックモジュール７６、ＤＡＣ モジュール７８、ＣＯＤＢＣモジュール８０、ハードウェアカーソルサポートモ ジュール８２、ビデオモジュール８４、二次元グラフィックス制御モジュール８ ６、及び、三次元グラフィックス制御（３Ｄ）モジュール８８が含まれる。ディ バイスドライバ５０に動的にロードされたハードウェアインタフェースモジュー ルの特定の集合は、ビデオディスプレイコントローラ１９の具体化例に存在する 特定のサブエレメントに対応するボードドライバ７４によって決定される。即ち 、クロックサブエレメント２８の特定の具体化例に従属する特定の対応するクロ ックモジュール７６は、ボードドライバ７４によって識別され、そして、ディバ イスドライバ５０に動的にロードされる。従って、例えば、ＤＡＣサブエレメン ト２２の新規バージョンを、ほかの点では一般的に既に存在するビデオディスプ レイコントローラ１９の設計に包含させることは、ディバイスドライバ５０の実 質的にはＤＡＣモジュール７８のみの機能性に関して対応する改訂を実施するこ とにより、即座に収容可能である。従って、ディバイスドライバ５０のサブエレ メント特有の態様を、動的にロード可能なモジュール内に配分することにより、 ディバイスドライバ５０の最終的構成性能および動作の有意な改訂が、ディバイ スドライバ５０を残りの部分から分離することによって実施されることを可能に する。この種のハードウェア特有の変更も、同様に、他のハードウェアインタフ ェースモジュール及びディバイスドライバ５０の更に高位の層から効果的に分離 される。従って、ディスプレイコントローラ１９の新規バージョンに関するディ バイスドライバ５０構成（コンフィギュレーション）は、１個または複数の特定 の新規または改訂済みハードウェアインターフェイスモジュールのみを基準とし てテストすることが可能である。 実際問題として、或る種のハードウェアインタフェースモジュールは、ボード ドライバ７４と静的にリンクしても差し支えない。モジュールの基礎的な補集合 は、必ず、或いは、ほぼ必ず特定のボードドライバ７４と共に使用されるが、こ の場合には、ボードドライバ７４と一緒にモジュールをロードすることによって 最適化が達成される。静的にリンクされたモジュールを後続使用することは、対 応するサブエレメントをサポートするために動的にリンク可能なモジュールを準 備することにより、同じく効果的にオーバライド可能である。動的にロードされ たモジュールは、静的にリンクされた対応するモジュールに優先して使用するこ とが好ましい。 ＩＩＩ．ディバイスドライバの初期化 本発明のディバイスドライバ５０を初期化する過程の概要を図３に示す。ＭＳ −Ｗｉｎｄｏｗｓ’９５ＴＭオペレーティングシステムによって作動する好まし い実施例に関して、この初期化過程を説明することとする。 Ａ．初期上位レベル初期化 オペレーティングシステム初期化の通常の実行に関連して、シェルモジュール ７２は、レジストリサービスデータベースファイルにおける通常のシステムドラ イバ参照（リファレンス）の結果として、記憶装置１６にロードされる９０。一 旦、記憶装置内に常駐した場合には、ディバイスドライバ従属初期化を開始する ために、コールが、シェルモジュール７２の初期化エントリポイントに対して行 われる。シェルモジュール７２の初期化ルーチンは、シェルオブジェクト１２６ （ＳＨＥＬＬＯＢＪ）の作成９２、その次に、９３においてオペレーティングシ ステムオブジェクト１２８（ＯＳＯＢＪ）の作成を提供する。 シェルオブジェクトは、ディバイスドライバ５０の構造と論理的にリンクする 最上レベルデータ構造として用いられる。シェルオブジェクトの有意要素を表Ｉ に識別する。 表に示すように、シェルオブジェクトには、いくらかの大域フラグデータ、Ａ ＰＴコールエントリポイント、ディバイスドライバ５０の構成要素を表す高レベ ルソフトウェアオブジェクトへのポインタ、及び、多数のシェルライブラリルー チン又はディバイスドライバ５０の内部オペレーションをサポートするために用 いられる機能が含まれる。 オペレーティングシステムオブジェクトは、オペレーティングシステム層５４ サポート機能へのＡＰＩコールアクセスを提供する。オペレーティングシステム オブジェクトのエレメントを表ＩＩに識別する。 サポートされるエントリポイント別に示すように、Ｏ／Ｓオブジェクトは、オ ペレーティングシステム層５４へのコールインタフェースを供給する。下位レベ ル及びＢＩＯＳ機能へのコールインタフェース、及び、プラットホーム特有機能 へのコールインタフェースを提供する。このプラットホーム特有コールインタフ ェースは、プラットホーム可搬性の細部を隠すために役立つ多数のユーティリテ ィ又はライブラリルーチンを意味する。Ｏ／Ｓオブジェクトの他の機能と必ずし も関連しているとは限らないが、１つのモジュールに全てのプラットホーム特有 コール及び機能を収集するために、これらのルーチンはこのモジュールに集中さ れ、それによって、プラットホーム可搬性の変化を実質的にこの１つのモジュー ルに制限する。更に、これらのルーチンは、当該モジュールの残りの部分と同様 に、アセンブラコーディングを用いて、全体的に最も良好に具体化される。 Ｂ．下位レベル初期化 シェルモジュール７２は、次に、ディバイスドライバ５０の残りの部分の動的 ローディングを開始する。正しいボードドライバ７４を識別するために、シェル モジュール７２は、特定のボードタイプを識別するためのビデオディスプレイコ ントローラ１９の初期評価９４を実施する。ボード識別子は、コントローラ１９ に物理的に常駐し、そして、シェルオブジェクトの「ＢｏａｒｄＤａｔａ」フィ ールドに記憶されているデータ構造から、コントローラ１９を介して読み取られ ることが好ましい。好ましい実施例において、ボード識別子は、最初、レジスタ インタフェース３０を介してアクセス可能なビデオディスプレイコントローラ１ ９に設置されている通常のオンボードＲＯＭ２９に記憶される。表ＩＩＩは、ボ ード識別子データ構造の好ましい構造を提供する。 「ＩＤ」フィールドは、ボード識別子構造がディバイスドライバ５０に適合す ることを確認する静的データ値を提供する。「Ｒｅｖｉｓｉｏｎ」フィールドは 、将来、代替構造が具体化された場合に、ボード識別子構造の特定構造を定義す るために用いられる。「ＳｔｒｕｃｔｕｒｅＳｉｚｅ」フィールドは、構造のサ イズを定義する。「ＢｏａｒｄＦａｍｉｌｙ」フィールドは、この特定な場合に おけるビデオディスプレイコントローラ１９をサポートするために必要なディバ イスドライバ５０の一部分としてロードされることが必要なボードドライバ７４ を主として識別するために用いることのできる値を記憶する。少なくとも「Ｂｏ ａｒｄＦａｍｉｌｙ」値を含むボード識別子構造の値は、ｂｏａｒｄ．ｄａｔフ ァイルにおいてキー名探索（ルックアップ）を実施するためのキーとして用いら れる。キーは、有意ボード識別子フィールド値の単純連結として形成されること が好ましい。ｂｏａｒｄ．ｄａｔファイルは、特定の場合におけるボードドライ バ７４の対応ファイル名にキーを相関関係付けるフラットファイルであることが 好ましい。 特定のボードドライバ７４が９４において一旦識別されると、当該キー値に対 応するボードドライバ７４をロードするために、シェルモジュール７２は、オペ レーティングシステムモジュール７０を介してコールを発行する。これに応答し て、オペレーティングシステム層５４は、９６において、リクエストされたボー ドドライバ７４を記憶装置１６にロードし、そして、メモリポインタをシェルモ ジュール７２に戻す。次に、ボードドライバ７４の初期化エントリポイントがコ ールされる。 ボードドライバ７４の初期化の一部分として、ボードオブジェクト９８が作成 される。ボードオブジェクトは、厳密には、オペレーティングシステムもハード ウェアインタフェースモジュールも表さないが、オペレーティングシステム又は ハードウェアインタフェースモジュールを表すオブジェクトによって便宜上用い られる基礎データ構造形を確立する。ボードオブジェクトの構造を表ＩＶに示す 。 ボードオブジェクト初期化の一部分として、ボード識別子構造へのポインタ「 ＢｏａｒｄＤａｔａ」は、シェル７２から獲得される１００。ビデオディスプレ イコントローラ１９に所在する各サブエレメントの特定のタイプを識別するため に、ボード識別子構造における更なるフィールドが調査される。プリセットされ たコード化済みの値は、特定の場合におけるサブエレメントを識別するために用 いられる。ボード識別子のフィールドは、一般に、コントローラ１９のサブエレ メントの固定された態様に対応することが好ましい。例えば、ＤＡＣのタイプ又 はビデオメモリ、ＶＲＡＭ又はＤＲＡＭのタイプは、ボード識別子構造を介して 提供されても差し支えない。 おそらくフィールドがアップグレード可能であるために、サブエレメントの態 様が固定されていない場合には、特定の態様は、従来の方法によって決定される ことが必要である。例えば、コントローラが一度使用されさえすれば、ビデオデ ィスプレイコントローラ１９において利用可能なディスプレイＲＡＭの量（ビデ オメモリサイズ）は変更可能である。ただし、ボード識別子は、静的であり、そ して、コントローラ１９の製造に際して確立される。従って、従来のメモリ走査 ルーチンは、そのような場合においてビデオディスプレイコントローラ１９に所 在するビデオメモリの全体量を正確に決定するために利用することが出来る。デ ィスプレイコントローラ１９は、おそらく、当該コントローラ１９が遺産的に具 体化されたことにより、同様に、ボード識別子２９を持っていないこともあり得 る。従って、この場合、当該コントローラ１９に所在するサブエレメントの妥当 な識別は、通常のＩｎｔ１０ Ｂｉｏｓコールを介して獲得された情報から推論 可能である。 ボード識別子構造における最後のフィールドは「ＢｏａｒｄＤｅｐｅｎｄｅｎ ｔＩｎｆｏ」フィールドである。このフィールドは、特定のボードタイプ及びモ デルの追加操作特性にフラグを立てるために使用されることが好ましいワード‐ ワイドビットマップデータエリアを提供する。これらのフラグは、従属的かつボ ードドライバ７４によって一意的に復号された具体化である。特に、これらのフ ラグビットは、識別されなければボード識別子の他のフィールドによってカバー されることのない詳細な構成（コンフィギュレーション）オプションを識別する ために使用可能である。例えば、１つのフラグビットは、ディバイスドライバ５ ０のより後の方のバージョンと共に使用可能な些細なサブエレメントオプション の存在を識別するために使用可能である。 従って、ボードドライバ７４は、ボード識別子構造から、ビデオディスプレイ コントローラ１９を最適サポートするために必要なハードウェアインタフェース モジュールの特定の集合を決定する１０２。次に、ボードドライバ７４は、オペ レーティングシステムモジュール７０を介してボードモジュールと静的にリンク していないハードウェアインタフェースモジュールの識別済み集合を順次にロー ディングすること１０４をリクエストする。各ハードウェアインタフェースモジ ュール７６−８８が記憶装置１６にロードされるにつれて、対応するソフトウェ アオブジェクトを確立するために、各モジュールの初期化ルーチンがコールされ る１０６。好ましいディバイスドライバ５０において、各ハードウェアインタフ ェースオブジェクトは、共通ヘッダ部分とハードウェア従属部分とを含むデータ 構造として構成される。共通ヘッダ部分は、表Ｖに示すフィールドを含むオブジ ェクトヘッダデータ構造（ＯＢＪＨＤＲ）であることが好ましい。 「ＯｂｊｅｃｔＶｅｒ」フィールドは、カプセル封入ハードウェアインタフェ ースによってサポートされたハードウェアサブエレメントの特定具体化を指定す る一意的な識別子を提供する。「Ｍｏｄｕｌｅ」フィールドは、カプセル封入さ れたハードウェアインタフェースモジュールの記憶場所を指示するオペレーティ ングシステムから戻されたメモリポインタを含む。「ＯｂｊＤａｔａＩｎｓｔａ ｎｃｅ」フィールドは、ハードウェアインタフェースオブジェクトのこの例示用 として予約されている専用データエリアへのポインタを提供する。「ＲｅｇＣｌ ａｓｓＨａｎｄｌｅｒ」フィールドは、関連ハードウェアサブエレメントが、モ ード設定動作呼出しの一部分としてプログラムされなければならないインタフェ ースレジスタを備えているかどうかを定義する。当該フィールドの値が空白（ナ ル）である場合には、リクエストされた任意のモード設定プログラミングは、ハ ードウェアインタフェースによってカプセル封入されたモジュールへハードコー ド化される。当該フィールドが空白（ナル）でない場合には、当該フィールドの 値は、レジスタ名および態様変更のサポート用に使用可能なインタフェース手順 の定義を含む構造へのポインタである。ＲｅｇＣｌａｓｓＨａｎｄｌｅｒの構造 を表ＶＩに示す。 オブジェクトヘッダの「ＯｂｊｅｃｔＩｎｉｔ」及び「ＯｂｊＵｎＩｎｉｔ」 フィールドは、現在のハードウェアインタフェースオブジェクトによってカプセ ル封入されたハードウェアインタフェースモジュールを初期化および解放するた めのコールアドレスを提供する。オブジェクトヘッダの「ＭｏｄｅＳｅｔ」フィ ールドは、態様変更をハードウェアインタフェースオブジェクトに合図するため に用いられるハードウェアインタフェースモジュールエントリポイントを確立す る。好ましい実施例において、このエントリポイントへの３つの異なるコールが 実施可能である。各コールは、１つのモード設定を呼び出すために、１つのモー ド設定が発生しようとしていること、及び、１つのモード設定が完成したことを 指示するためのコールのオペランドによって区別される。 最後に「ＳｅｔＤＰＭＳＳｔａｔｅ」フィールドは、システム１０のパワー管 理状態の特定モジュールに特有の変更をサポートするためのエントリポイントを 提供する。 従って、ハードウェアインタフェースモジュール初期化ルーチンは、ハードウ ェアインタフェースオブジェクトのハードウェアインタフェース従属部分用の記 憶装置を含み、当該オブジェクトのこの実例におけるオブジェクト特有のフィー ルドを初期化し、そして、当該ハードウェアインタフェースオブジェクトのこの 例示に対して専用状態が維持されるべきあらゆる実例データの割当を獲得するた めに、カプセル封入ハードウェアインタフェースオブジェクトの一例の作成を提 供する。当該実例データへのポインタは、オブジェクトヘッダにおける「Ｏｂｊ ＤａｔａＩｎｓｔａｎｃｅ」フィールドに記憶される。次に、初期化ルーチンは 、ポインタをハードウェアインタフェースオブジェクトに返す。このポインタは 、ボードオブジェクト基礎構造のメンバーフィールドに記憶される１０８。基礎 ハードウェアインタフェースオブジェクト、特にクロックオブジェクトの定義を 表ＶＩＩに示す。 表に示すように、クロックサブエレメントと関連したハードウェア特有機能は 無い。ただし、クロック周波数は、クロックサブエレメントの一般的なプログラ ム可能態様であり、更に、モードセットオペレーションに密接に関連している。 従って、オブジェクトヘッダ構造のＲｅｇＣｌａｓｓＨａｎｄｌｅｒフィールド は、コントローラ１９において生成されるクロック周波数を最終的に制御するク ロックサブエレメントのインタフェースレジスタへのアクセスをサポートするた めに必要なレジスタの定義を含むＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造へのポイ ンタを含む。 表ＶＩＩＩは、例えば、ハードウェアカーソルオブジェクトを定義する更に幾 分か複雑なオブジェクトを示す。 既に述べたように、オブジェクトヘッダは、カーソルオブジェクトのエレメン トとして含まれる。ＣｕｒｓｏｒＥｎａｂｌｅフィールドは、コールパラメータ の状態に応じてハードウェアカーソルの可視性をオン（出現）又はオフ（消滅） させるために、ハードウェアカーソルインタフェースモジュールへのエントリポ イントに対するポインタを提供する。ＣｕｒｓｏｒＳｅｔフィールドは、オペラ ンドによりコールに対して指定されたパターンに対するカーソルパターンの設定 を提供するエントリポイント１５に対するポインタを提供する。ＣｕｒｓｏｒＭ ｏｖｅフィールドは、コールと共に提供されるＸ及びＹオペランドによりディス プレイ３２上におけるカーソルのホットスポットを指定するためのルーチンへの エントリポイントを識別する。ＣｕｒｓｏｒＳｅｔＣｏｌｏｒフィールドは、デ ィスプレイ３２上に呈示された二色カーソルを色拡大するために用いられるルー チンを識別する。 他のハードウェアインタフェースオブジェクトには、ＤＡＣオブジェクト１３ ０（ＤＡＣＯＢＪ；表ＩＸ）、ビデオオブジェクト１３６、グラフィックスオブ ジェクト１３８（ＤＲＡＷＥＮＧＯＢＪ；表Ｘ）、及び、３Ｄグラフィックスオ ブジェクト１４０が含まれる。 ＤｒａｗＥｎｇＯｂｊによって参照される基礎構造には、多数の基礎的な製図 機能が含まれる。この基礎構造は、ＡＰＩコールに応答してＧＤＩオブジェクト からのコールの線形実行内における機能への直接アクセスを可能にするためにＧ ＤＩオブジェクトのコード空間内に保持された機能ポインタの１つのコピーを用 いて、製図エンジンオブジェクト内に確立される。基礎構造の定義を表ＸＩに示 す。 これらオブジェクトの定義によって示すように、ハードウェアインタフェース モジュール７６−８８の各々は、オブジェクト、及び、オブジェクト特有のエン トリポイントの固定した集合を提供するハードウェア特有の拡張（エキステンシ ョン）の容易な管理を可能にする標準化済み部分を含む対応するハードウェアイ ンタフェースオブジェクトを確立するために初期化する。これらオブジェクト特 有のエントリは、カプセル封入されたハードウェアインターフェイスモジュール の初期化ルーチンにより、ポインタリファレンスを用いて充填される。ポインタ リファレンスは、論理的に参照される機能を提供するカプセル封入されたモジュ ール内の機能を対象とする。現行色深度、スクリーン解像度、または、他のコン トローラ関連特性に基づいて、論理的機能特有の具体化が異なる場合には、カプ セル封入されたモジュールは、対応する特有のエントリポイントを用いて具体化 されることが好ましい。エントリポイントの適当な部分集合は、オブジェクトエ ントリポイントに初期化されたポインタリファレンスによって識別され、それに よって、ディバイスドライバ５０のオペレーション進行期間中に、当該コントロ ーラ１９の現行特性状態のランタイムテストを繰り返すことなしに、特性に適切 なオペレーションを暗黙確立する。 従って、個々のオブジェクトは、オブジェクト構造の共通ＯＢＪＨＤＲ態様に 基づき包括的に管理可能であり、同時に、基礎となる機能的および具体化細目か ら独立し、特に、例えば現行色深度及びスクリーン解像度のような特性に基づく 機能の種々異なる具体化例を含むそれぞれ特定タイプのハードウェアインタフェ ースオブジェクトに対して充分に定義されたエントリポイントインタフェースを 確立するためにも用いることが出来る。 本発明の好ましい実施例において、ボード識別子から識別されたｂｏａｒｄ． ｄｍｍファイルが、クロック、ＤＡＣ、または、ハードウェアカーソルの存在を 、ビデオディスプレイコントローラ１９における存在程明確には指定しない場合 には、ボードドライバ７４と静的にリンクした対応するデフォルトモジュールが 、デフォルトモジュールとして利用される。従って、ハードウェアインタフェー スモジュールの集合が識別され、ロードされ、そして、初期化された後で、ボー ドオブジェクトにおける空白（ナル）ポインタは、ボードドライバ７４によって 検出される。例えば、ハードウェアカーソルオブジェクトが存在しない場合には 、ボードドライバ７４は、オブジェクトを作成し、そして、ハードウェア従属エ ントリポイントを、ボードドライバ７４内の対応するデフォルトルーチンに初期 化する。それによって、ハードウェアカーソルの機能性は、ソフトウェアエミュ レーションを介してサポートされるか、或いは、更に一般的には、ハードウェア インタフェースオブジェクトのなかの別のオブジェクトの本質的な構成要素とし て サポートされる。いずれにしても、デフォルトオブジェクトはボードオブジェク トにリンクされ、その後で、動的にロード及びリンクされたハードウェアカーソ ルオブジェクトと同じ本質的な機能性を提供する。 Ｃ．上位レベル初期化完了 一旦、ハードウェアインタフェースオブジェクトの初期化が完了すると、ボー ドドライバ７４の初期化ルーチンはシェルモジュール７２に戻る。次に、シェル モジュール７２は、ＧＲＸ ＡＰＩオブジェクト７１を作成するために進行する １０９。ＧＲＸオブジェクトは、オペレーティングシステムインタフェースオブ ジェクト６４、６６、６８への内部汎用または仮想化インタフェースとして役立 つ。ＧＲＸオブジェクト７１は、表ＸＩＩに示す比較的簡単なインタフェースを 提供する。 ＧｒｘＡｐｉＦａｓｔＣｏｐｙコールエントリポイントは、オン‐スクリーン 及び、オフ‐スクリーンビデオメモリ内に配置されたビットマップを操作するた めに特にシェルモジュールを含む全てのオペレーティングシステムＡＰＩレベル モジュールによって使用可能な共通アクセスポイントを提供する。共通アクセス ポイントの確立は、ビデオメモリ管理を簡素化する。同様に、ＧｒｘＡｐｉＣｏ ｌｏｒＭａｔｃｈコールエントリポイントも、スクリーン３２の現行色深度にお ける論理的から物理的への色変換を実施するために、全てのオペレーティングシ ステムＡＰＩレベルモジュールによって使用可能な共通アクセスポイントを提供 する。 オペレーティングシステムインタフェースオブジェクト６４、６６、６８の確 立を開始するために１１０、ＧＲＸオブジェクト７１のＯＢＪＨＤＲ内の初期化 エントリポイントは、シェルモジュール７２によってコールされる。本発明の好 ましい実施例において、ＧＤＩ及びＤＤオブジェクト６４、６６は、ＧＲＸオブ ジェクト初期化ルーチン内において静的に識別される。その代わりに、又は、追 加的に、オペレーティングシステムインタフェースオブジェクトは、ｉｎｔｅｒ ｆａｃｅ．ｄａｔ構成（コンフィギュレーション）ファイルへの参照によるシェ ルモジュール７２によって識別可能である。識別されたオペレーティングシステ ムインタフェースモジュールは、シェルモジュール７２と静的にリンクしなかっ た場合、記憶装置１６に順次ロードされる１１２。 各オペレーティングシステムモジュールがロードされるにつれて１１２、モジ ュール初期化ルーチン１１４がコールされる。各オペレーティングシステムイン タフェースモジュールの初期化の結果として、は、対応するオペレーティングシ ステムインタフェースオブジェクトが作成される。ハードウェアインタフェース オブジェクトの場合と同様に、オペレーティングシステムインタフェースオブジ ェクトは、それぞれ、オペレーティングシステムインタフェースオブジェクトの 操作のための共通基準を確立するオブジェクトヘッダ基礎構造（ＣＢＪＨＤＲ） を含むことが好ましい。同様に、オブジェクトヘッダの使用は、ディバイスドラ イバ５０による態様変更を合図するために、コールに対するサポートを提供する 。その結果として、オペレーティングシステムオブジェクトは、必要に応じて、 当該オブジェクトの各例示に関する専用データスペースをサポートする。 ＧＤＩオブジェクト１２０は、表ＸＩＩＩに記載された定義を用いて作成され る。 ＧＤＩオブジェクト１２０は、標準Ｄｉｂエンジンの基礎構造インタフェース （ＤｉｂｅｎｇＯｂｊ）に関するリンク済み参照を含むか、或いは、提供する。 基礎構造を表ＸＩＶに定義する。 ＤｉｂｅｎｇＯｂｊの更なる標準基礎構造を表ＸＶ及びＸＶＩに定義する。 表ＸＶ及びＸＶＩは、直接ドローオブジェクト１２４を定義するオブジェクト を示す。 １６ビット及び３２ビット両環境における使用をサポートするためには、１６ ビット及び３２ビット両ＡＰＩコールをサポートするディバイスドライバ５０の 構成要素に対する１６ビット及び３２ビット両ポインタを提供するために、付加 ＯｂｊＩｎｓｔＤａｔａ基礎構造が用いられる。 最後に、各々のオペレーティングシステムインタフェースオブジェクトの初期 化が完了するにつれて、リンク１１６は、ＧＲＸオブジェクト７１とＧＤＩ及び ＤＤオブジェクト１２０、１２２との間で確立される。次に、ＧＲＸ初期化ルー チンはシェルへ戻る。同様に、全てのオペレーティングシステムインタフェース オブジェクトはシェルオブジェクトにリンクされる。次に、シェルモジュール７ ２の初期化ルーチンが戻る。 ＩＶ．操作状態コンフィギュレーション 各オペレーティングシステム及び対応する実行可能モジュールを論理的にカプ セル封入するハードウェアインタフェースオブジェクトを備え、単一文脈状態に おいて作動中のディバイスドライバ５０の論理的コンフィギュレーションを図４ に示す。シェルドライバ７４の論理的にカプセル封入されない部分は、一般化さ れたシェルライブラリ７２’として常駐状態を維持する。同様に、ボードドライ バ７４の論理的にカプセル封入されない部分は、ボードライブラリ７４’として 常駐状態を維持する。両ライブラリ７２’、７４’は共通資源として機能し、デ ィバイスドライバ５０の内部機能をサポートイする。従って、初期化されたディ バイスドライバ５０は、ドライバソフトウェア透視図から、ディバイスドライバ ５０によって提供されるオペレーティングシステムＡＰＩを凝集的に確立するオ ペレーティングシステムインタフェースオブジェクト及びディバイスドライバ５ ０とハードウェアインタフェースレジスタ３０との間にハードウェアインタフェ ースを確立するハードウェアインタフェースオブジェクトによって定義される。 Ａ．上位レベル関係 ＧＤＩオブジェクト１２０、直接ドローオブジェクト１２２、直接３Ｄオブジ ェクト１２４、及び、シャルオブジェクト１２６を含むオペレーティングシステ ムインタフェースオブジェクトは、オペレーティングシステム層５４に提供され る部分ＡＰＩの定義によって相互に論理的に分割されるオブジェクトの集合を表 す。既存のＡＰＩコールサポートの改訂、及び、あらゆる特定のオペレーティン グシステムインタフェースオブジェクトへの新規ＡＰＩコールの追加は、他のオ ペレーティングシステムインタフェースの具体化または動作（オペレーション） には、設計上、実質的に一切影響を及ぼさない。更に、オペレーティングシステ ム層５４による新規定義によるか、或いは、アプリケーション６０から直接発信 されたコールをサポートするためかいずれの場合であっても、新規部分ＡＰＩの サポートは、対応するオペレーティングシステムインタフェースオブジェクト及 びカプセル封入されたオペレーティングシステムインタフェースモジュールの定 義を介して容易に提供可能である。ただし、新規または改訂したＡＰＩコールが 、既存のオペレーティングシステムインタフェースオブジェクトによってサポー ト される他のＡＰＩコールのうちの任意のコール以外の非常に異なる機能に関係す るか、或いは、前記機能を必要とする場合には、追加ライブラリルーチンが、シ ェルライブラリ７２’に追加されることが必要となることも有り得る。 シェルライブラリ７２’は、オペレーティングシステムインターフェイスオブジ ェクトの全集合によって使用可能な１組の共通または仮想化されたサポート機能 を確立するために役立つルーチンのライブラリを提供するために、オペレーティ ングシステムインタフェースモジュールから論理的に分割される。オペレーティ ングシステムインタフェースオブジェクトの各々は、（１）明確に定義されたＡ ＰＩコールセットをサポートし、（２）サポートされた各ＡＰＩコールに関する パラメータ妥当性検査を提供し、（３）ディバイスドライバ５０の動作における 文脈変更に際して持続することが望まれるデータオブジェクトに関する専用デー タスペースを潜在的に管理し、（４）当該オブジェクトによってサポートされる ＡＰＩコールの各々を機能的に具体化するために、順序付けられた１つ又は複数 の仮想化されたコールをシェルライブラリ７２’に発行し、最後に（５）フォー マットし、そして、当該オブジェクトによってサポートされるＡＰＩコールの各 々に適した方法においてオペレーティングシステム層５４にデータを戻すことが 好ましい。 本発明によって認識されるように、ディバイスドライバ５０への多くのコール のバリアント（異形体）は、異なる特定のＡＰＩに向けられる。これらのバリア ントは、例えば特定の形式およびコールを備えた一連のオペランドデータのよう に、特有の態様が異なる。従って、特定のオペランドデータ妥当性検査は各ＡＰ Ｉコールに特有である。従って、各オブジェクトは、ＡＰＩコール特有のオペラ ンド妥当性検査、および、潜在的には、この或いは他のオペレーティングシステ ムインタフェースオブジェクトによってサポートされる機能的に類似する他のＡ ＰＩコールとは対照的に一体化される或るフォーマットへのオペランドデータの 変換を実施することが好ましい。従って、１つ又は複数のＡＰＩコールの集合は 、ディバイスドライバ５０に対して内部的に仮想化される。 各オペレーティングシステムインタフェースオブジェクトは、当該オペレーテ ィングシステムインタフェースオブジェクトによってサポートされるＡＰＩコー ルのオペランドとして、関係するか、導出されるか、或いは、提供されるデータ オブジェクトを保存する必要性に応じて、文脈特有のデータスペースを管理する 。 例えば、ＧＤＩオブジェクト１２０は、所定の文脈におけるディスプレイポイ ンタ３８の場合と関連したビットマップ済み解像度従属パターン又は色彩を定義 するデータオブジェクトを維持可能である。従って、既存の文脈のリザンプショ ンに際して、データオブジェクトは、この文脈においてディスプレイポインタ３ ８のインスタンスを能率的に再実現するために使用可能である。再実現は、一切 の参加を必要とすることなしに、或いは、あらゆるアプリケーションプログラム ６０又は当該オペレーティングシステム層５４への通知さえも必要とすることな しに、完全にサポートされることに特に注意されたい。この例におけるデータオ ブジェクトは、それは、ディスプレイポインタ３８のパターン又はカラーを初め にセットしたＡＰＩコールのオペランドとして提供されるオリジナルデータオブ ジェクトから導出される。例えば新規な色深度に関係する新規文脈が作成される 場合において、新規データオブジェクトは、前の文脈のデータオブジェクトから の色深度変換によって導出される。先在している文脈への文脈スイッチに際して 、データオブジェクトの先在インスタンスが再使用され、その結果として、当該 ディスプレイポインタ３８のインスタンスの再実現において情報は一切失われる ことはない。 同様に、ＧＤＩオブジェクト１２０のインスタンスは、パレット化されたカラ ーコンテキストにおいて、カラーパレットのみに限らず、順方向及び逆方向のパ レット変換表までも、パレット化されたコンテキストに特有のＰＤｅｖｉｃｅ構 造の一部として維持されることが好ましい。Ｗｉｎｄｏｗｓ’９５TMオペレーテ ィングシステムにおいて、オペレーティングシステム層５４は、少なくとも当該 オペレーティングシステム層５４から選定されたコールに関するディスプレイタ イプのディバイスドライバにパスされる或る情報を維持するために用いられるフ ィジカルディバイス（ＰＤｅｖｉｃｅ）構造への単一ポインタをサポートする。 ＰＤｅｖｉｃｅ構造の意図は、ハードウェア特有のコンフィギュレーションデー タを一般的に記憶するためにディバイスドライバ５０によって使用可能な増補可 能なデータ構造を提供することにある。本発明は、パレット化されたコンテキス トに特有の色変換表を記憶するために用いられるだけでなく、各コンテキストに 関する新規ＰＤｅｖｉｃｅ構造を一般的に複製し、そして、対応するコンテキス トの色深度と合致する構造を増補する。ＰＤｅｖｉｃｅ構造の好ましい構造を表 ＸＶＩＩに示す。 コンテキスト特有の持続性データオブジェクトとして効果的なカラーパレット 表のメンテナンスは、パレット化された文脈への文脈スイッチに際して、カラー パレット及び変換表の迅速な回復を可能にする。特に、パレット化されないコン テキスト期間中、及び、潜在的には、独立したカラーパレット及び変換表定義を 備えた独立ＰＤｅｖｉｃｅ構造を使用する他のパレット化されたコンテキスト期 間中において、ＰＤｅｖｉｃｅ構造の一部分としてカラーパレット変換表をメン テナンスすることは、同様に、パレットベース製図動作の継続をサポートする。 いずれにしても、パレット化されたコンテキストに対して論理的に実行するアプ リケーションからドライブされる進行中の製図動作は、カラーパレットデータ及 び対応するコンテキストの変換表に対して製図コマンドを変換または分解するこ とによって、現在活動中のコンテキストの色深度またはカラーパレットへ正しく 変換可能である。即ち、現在活動中でないコンテキストに対して論理的に実行す るアプリケーション６０の製図コマンドは、現行コンテキストの色深度において 製図コマンドを実施するために現在活動中でないコンテキストのデータオブジェ クトの参照により、必要に応じて効果的に再実現される。現在活動中でないコン テキストのデータオブジェクトは、データ構造、特に各コンテキストを定義する ために用いられるシェルオブジェクトを探索することによって位置付けすること が出来る。 本発明の好ましい実施例において、オペレーティングシステムインタフェース オブジェクトは、いくぶんの薄い層を表す。当該インタフェースオブジェクトに よってサポートされる特有のＡＰＩコールの各々に関する実行のスレッドを定義 するために適切であるように、ＡＰＩコールは、高レベルにおいて、シェルライ ブラリ７２’及びハードウェアオブジェクト１３０−１４０に対して実質的に線 形コールシーケンスへ仮想化されることが好ましい。一般に、シェルライブラリ ７２’におけるルーチンへの共通コールの使用を最大化することが望ましい。逆 に、オペレーティングシステムインタフェースオブジェクトの機能を実質的にデ ータ妥当性検査、基礎データ変換、及び、サポートされる各ＡＰＩコールに関す る線形実行スレッドの仕様に制限することが望ましい。 Ｗｉｎｄｏｗｓ’９５TM具体化においては、オペレーティングシステム層５４ が、かなり原子的なＡＰＩコールをディバイスドライバ５０へ発行する。従って 、殆ど全てのオペレーティングシステムインタフェースオブジェクトは、ＡＰＩ コールを実施するために必要な実行スレッドを機能的に具体化するために、シェ ルライブラリ７２’及びハードウェアインタフェースオブジェクトに対して少数 のコールを実施することになる。性能にとって好都合である場合、或いは、使用 が特定のＡＰＩコールに実質的に制限される場合、或る種の実行機能は、オペレ ーティングシステムインタフェースオブジェクトによって実施可能である。特に 、座標の初期クリッピング及び変換は、オブジェクトを描写するためのＡＰＩコ ールに応答するオペランドの妥当性検査と協調して、オペレーティングシステム インタフェースオブジェクトによって実施可能である。別の出所からの新規デー タオブジェクトの内容を導出するために色深度変換を実施し、次に、スクリーン ３２に対して製図動作を実現するために、更に実質的なルーチン、又は、例えば 、新規な継続性データオブジェクトの記憶を確立するために用いられるルーチン のような多重ＡＰＩコールによって一層必要になると推測されるルーチンが、シ ェルライブラリ７２’及びハードウェアインタフェースオブジェクトにおいて適 切 であるように、実行されることが好ましい。 従って、所要の新規データオブジェクトの作成を要求し、そして、当該オブジ ェクトに対するポインタを最終的に取り戻して受け取るために、例えば、最初の ＡＰＩコールは、オペレーティングシステム５４によって、対応するオペレーテ ィングシステムインタフェースオブジェクトに対して行われる。コールの仮想化 された線形スレッドは、結果として割当を要求し、記憶装置内にロックし、そし て、結果として得られるオブジェクトへポインタを戻すシェルライブラリ７２’ へのコールと共に始まる。これらのリクエストの実施に際して、シェルライブラ リ７２’は、オペレーティングシステム層５４への要求されるオペレーティング システムＡＰＩコールを中継する必要性に応じて、オペレーティングシステムイ ンタフェースオブジェクト１２８を順次にコールする。シェルライブラリ７２’ によってサポートされるこのような個々の機能の線形化は、プリエンプティブオ ペランドの妥当性検査およびオペレーティングシステムインタフェースオブジェ クトによって実施される仮想化によって可能になる。オペランドデータは、シェ ルライブラリ７２’又はハードウェアインタフェースオブジェクトの任意のオブ ジェクトが、特定のＡＰＩコールから後続する各処理過程に適したフォーム及び フォーマットにおいてコールされる以前に、確立される。従って、例外的条件を 扱うため、或いは、データが利用可能か、又は、処理用として受け入れ可能なフ ォーマットであるかどうかを決定するための全ての、或いは、殆ど全部の条件付 ブランチは、オペレーティングシステムインタフェースオブジェクトのレベル以 下が除去される。即ち、オペランドデータの存在、フォーム及びフォーマットに 関してチェックするための進行中の条件付きブランチング無しに、仮想化された ＡＰＩコールの具体化が実質的に線形化される。更に、現行色深度および機能に 適した解像度に対する機能ポインタを備えたハードウェアインタフェースオブジ ェクトを初期化すると、ディスプレイ３２の現行作動状態に関してチェック及び 調節するために進行中の条件付きブランチングを排除する。 次に、オペレーティングシステムオブジェクトに対するその次のＡＰＩコール は、新規に製作されたデータオブジェクトにおける識別されたデータオブジェク トの変換に向けられることもある。オペレーティングシステムインタフェースオ ブジェクトを介して行われるその次のＡＰＩコールは、以前に作成され、かつ、 変換されたＡＰＩコールによって識別されるデータオブジェクトを用いて、特有 の製図動作を指定することが出来る。各ＡＰＩ製図コールは、１つ又は複数のコ ールによる実質的に線形のシーケンスを、特定の製図動作を実現するために適切 であるように、シェルライブラリ７２’及びハードウェアインタフェースオブジ ェクトへ再び発行することにより、受取りオペレーティングシステムインタフェ ースオブジェクトによって実行される。 従って、オペレーティングシステムインタフェースオブジェクトの各々は、最 小複製コードを含んだ状態で、オペランド検証およびフォーマット変換を実施す ることによってコールの仮想化を最大にするように定義される。従って、シェル ライブラリ７２’は、オリジナルのオペランドデータの妥当性再検査、変換、ま たは、再フォーマット化を反復することに起因する実行性能的な罰を受けること なしに最大限に使用される。更に、オペレーティングシステムインタフェースオ ブジェクトは、コントローラ１９の動作特性に関して連続的に再評価および調節 する必要性なしに、即座に利用可能な機能ポインタを介して、ハードウェアイン タフェースオブジェクトへ直接コールアクセスする機能を備える。 シェルライブラリ７２’は、オペレーティングシステムインタフェースオブジ ェクトから受信した共通仮想化されたコールの効果的拡張および具体化を同様に 提供可能である。シェルライブラリ７２’へのこの種のコールは、結果的にハー ドウェア特有の機能を呼び出すために、ハードウェアインタフェースオブジェク トに向けられた一般的に短く実質的に線形のコールシーケンスに拡張されること が好ましい。シェルライブラリ７２’によってコールされたハードウェアインタ フェースオブジェクトの特定の集合または部分集合は、オペレーティングシステ ムインタフェースオブジェクトから受信した特定のコールに高度に依存する。た だし、シェルライブラリ７２’によって行われたコールの各々は、ハードウェア インタフェースオブジェクトデータ構造の仮想化された定義の結果として、ハー ドウェアインタフェースオブジェクトの集合と効果的な仮想関係を保持する。即 ち、ハードウェア金属製品インタフェースオブジェクトの構造定義は、当該オブ ジェクトによってカプセル封入された特定のハードウェアインタフェースモジュ ールの具体化から独立した、各オブジェクトタイプに関して実質的に固定される 。 従って、オペレーティングシステムインタフェースオブジェクト並びにシェル ライブラリ７２’からハードウェアインタフェースにオブジェクトまでのコール は、ハードウェアインターフェイスモジュールの実際の具体化から抽出される。 ＡＰＩコールを実現するために用いられる短く実質的に線形のコールシーケンス を使用することによって、 仮想化されたＡＰＩコールの実行速度は最大化され る。 Ｂ．下位レベル構成（コンフィギュレーション）の関係 ハードウェアインタフェースオブジェクトとオペレーティングシステムインタ フェースオブジェクトとは、両者共に、コントローラ１９のインタフェースレジ スタ３０とインターフェイスするために必要とされるハードウェア特有のオペレ ーションを定義する薄い層として実現されることが好ましいという点において類 似する。ハードウェアインタフェースオブジェクトは、（１）サポート支援支持 物‖特定タイプのハードウェアサブエレメントに特有の明確に定義されたオペレ ーションの集合をサポートし、（２）サポートされる各オペレーションの機能を 実現するために、関連ハードウェアインタフェースレジスタの少なくとも論理的 なプログラミングを提供し、（３）当該ディバイスドライバ５０のオペレーショ ンにおいてコンテキストを通じて持続することが望まれるデータオブジェクトに 関する専用データスペースを潜在的に管理し、そして、最後に（４）インタフェ ースレジスタ３０から直接的或いは間接的に読取られたデータを返すことに機能 的に制約されることが好ましい。 特定のタイプのハードウェアインタフェースオブジェクトによってサポートさ れるオペレーションは、オブジェクト構造の一部として定義される。一般に、ハ ードウェアインタフェースオブジェクトへのコールは、結果的に、インタフェー スレジスタ３０の１つ又は複数のレジスタに対するリファレンス及び参照された レジスタにプログラムされるべきデータ値のストリングを生成する。レジスタの プログラミングは、実際には、ボードライブラリ７４’へのコールに応答して実 施されることが好ましい。シェルライブラリ７２’の場合と同様に、ボードライ ブラリ７４’は、ハードウェアインタフェースオブジェクトによって使用される 一般化されるか或いは共通のルーチンを終結する。従って、コードの重複は全体 的に減じられ、そして、記憶装置１６のアドレススペース内のディスプレイバッ ファ２０をロードし、定義し、そして、管理するためのルーチンを含む詳細なレ ジスタインタフェースルーチンは、当該ディバイスドライバ５０の他の全ての態 様から実質的に分離された明確に定義された場所に主として配置される。この場 合における１つの重要な例外は、グラフィックスハードウェアインタフェースオ ブジェクト１３８に関係して発生する。性能上の目的から、このオブジェクトは 、レジスタインタフェース３０及びディスプレイバッファ２０に対して直接作動 することが好ましい。従って、ボードライブラリ７４’は、ディスプレイバッフ ァ２０の現行ロケーション及び定義を戻すルーチンを提供することが好ましい。 コントローラ１９の対応するサブエレメントのハードウェアインタフェースへの 直接アクセス機能を備えることにより、ビデオ及び３Ｄハードウェアインタフェ ースオブジェクト１３６、１４０も、同様に、利益を得るはずであることが予測 される。 従って、ハードウェアインタフェースオブジェクトを介してオペレーティング システムインタフェースの間に成立する効率的に成層化かつ仮想化された関係が 、本発明によって確立される。この仮想化された関係は、当該ディバイスドライ バ５０への２つの異なるＡＰＩコールの実行フローを追跡することにより、実演 により容易に示される。 Ｖ．操作状態コンテキスト及び態様の切換え（スイッチング） 本発明の好ましい実施例において、ビデオディスプレイコントローラ１９は、 多くの異なる水平及び垂直或いは空間的解像度、及び、多くの異なる色深度にお いて動作可能である。通常のコンピュータシステム１０は、異なる空間解像度お よび色深度に対して最適的に作動するアプリケーション６０の多様性をしばしば 実行する。実際問題として、コンピュータシステム１０において共同実行するこ とを試みるアプリケーション６０の空間および色深度に関する必要条件および操 作上の制限条件は、空間解像度と色深度が相互に排他的でない場合には、アプリ ケーション６０を継続実行するためにはしばしば最適でないような空間解像度及 び色深度に共同実行を制限することがあり得る。 ディバイスドライバ５０のアーキテクチャは、本発明に従い、ディバイスドラ イバ５０の作動状態において、単独およびコンテキストスイッチ（切換え）との 組合わせにより、モードスイッチ（切換え）動作を提供する。モードスイッチ及 びコンテキストスイチの両切換えは、アプリケーション６０及びオペレーティン グシステム層５４のコンテキスト状態から実質的に独立して実施され、そして、 特に管理される。既存のモードの特定のアスペクトに特有なデータが、モードス イッチを通じて継続しなければならない場合には、モードスイッチは単独で実施 可能である。コンテキストスイッチは、独立したコンテキストにおけるモードデ ータの継続的記憶を提供するために、モードスイッチと組合わされてディバイス ドライバ５０によって実施される。従って、ディバイスドライバコンテキストス イッチ（切換え）は、特定のコンテキストと関連した持続的データオブジェクト における状態およびモード特有データの記憶により、状態的コントローラのモー ド変更をサポートするために用いられる。ディバイスドライバ５０によるコンテ キスト文スイッチのコンテキスト及び動作の管理は、アプリケーションプログラ ム６０を変更することなく、オペレーティングシステム核５６に極く僅かな特有 の修正を施すことによりコンテキスト文切換えを可能にする。 Ａ．一定コンテキストモードのスイッチ（切換え） モードスイッチをサポートするためには、支援支持物にオペレーティングシス テム核５６は、そのウィンドウが現行ポインタの焦点調節を有するアプリケーシ ョン６０用として事前に選定された空間解像度へビデオコントローラ１９を切換 えるために、ディバイスドライバ５０に向けてＡＰＩコールを発信する核５６へ のパッチ６２をインストールすることによって修正される。更に進歩したオペレ ーティングシステム５４は、オペレーティングシステムパッチをインストールす る必要性なしに使用できる事象の生成を組み込み方式により提供可能である。パ ッチインモードにおいて設定されたＡＰＩコールはシェルオブジェクトにフック され、そして、物理的ディスプレイ３２の所望新規空間解像度を提供することが 好ましい。ＡＰＩコールは、所要空間解像度と組合わせた色深度も指定するはず である。所望色深度および空間解像度の両方が現行色深および空間解像度と同じ である場合には、単にＡＰＩコールが戻るだけである。空間解像度だけが異なる 場合には、モード切換え（スイッチ）の実施だけが必要である。モードスイッチ を実施するために必要とされるコントローラモード設定変更は、ディバイスドラ イバ５０のその時点現在のコンテキストにおいて実施される。 本発明の好ましい実施例によれば、１つの単一コンテキスト内におけるモード 設定変更は、主として、シェルオブジェクト１２６及びシェルライブラリ７２’ の制御の下に実施される。シェルオブジェクト１２６へのＡＰＩコールは、モー ド設定が実施されるべきであることを指定する。シェルオブジェクト１２６は、 所望の色深度及び空間解像度を獲得するために、Ｏ／Ｓオブジェクト１２８を介 して、オペレーティングシステム層５４にコールする。シェルオブジェクト１２ ６は、最初に、所望空間解像度を指定する返されたオペランドの妥当性を確認す る。次に、オペレーティングシステム及びハードウェアインタフェースオブジェ クトの各々を順次にコールするために、最初に「モード変更直前」オペランドを 用い、次に、「モード変更」オペランドを使用し、最後に「モード変更完了」オ ペランドを用いて、シェルライブラリ７２’のセットモードルーチンが、シェル オブジェクト１２６によって、コールされる。 「モード変更直前」オペランドを用いた最初のコールは、コントローラ１９に 対してドライバ５０の状態を静止させるために必要な事象のシーケンスをディバ イスドライバ５０内において開始する。特に、シェルライブラリ７２’のモード 設定ルーチンは、モード設定に参加することが必要な現行コンテキスト内におい てオペレーティングシステム及びハードウェアインタフェースオブジェクトの各 々を識別するために作動する。これらのインタフェースオブジェクトは、オブジ ェクト特有のＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造に対して有効または非無効の ポインタを有するオブジェクトとして識別される。次に、モード設定コールは、 参加している各オブジェクトに対して順々に配置される。これに応答して、各オ ブジェクトは、現行状態データを、例えば現行ＰＤｅｖｉｃｅ及びＧＤＩ＿Ｉｎ ｆｏｔａｂｌｅ構造のようなシステムデータ構造に、或いは、オブジェクト自体 の専用データスペースに、現行コンテキスト内に明確に定義された実行状態を確 立するために適切であるように、順々に保管するために実行する。最後の参加オ ブジェクトの戻りが完了すると、ディバイスドライバ５０の動作の実質的な静止 が完了する。次に、シェルライブラリ７２’は、シェルオブジェクト１２６に戻 る。 次に、「モード更変」を指定する第２のモード設定コールは、シェルオブ ジェクト１２６によって、シェルライブラリ７２’に発信される。「モード変更 」オペランドを用いてシェルライブラリ７２’によりコールされると、ボードラ イブラリ７４’は、空間解像度と色深度との所望組合わせに対応する「Ｓｅｃｔ ｉｏｎＮａｍｅ」を構成する。次に、所定の「ＳｅｃｔｉｏｎＮａｍｅ」によっ て識別されるセクションを位置決めするにはｓｙｓｔｅｍ．ｉｎｉファイルの場 合と全体的に同じ構造シンタックス（構文）を有することが好ましいｍｏｄｅｓ ．ｄｍｍコンフィギュレーションファイルを走査するために、オペレーティング システムインタフェースオブジェクト１２８を介して、Ｏ／Ｓ ＡＰＩコールが 行われる。Ｗｉｎｄｏｗｓ’９５TMの具体化例において、画素当たり８ビットの 色深度であって１０２４ｘ７６８の空間解像度を定義するＳｅｃｔｉｏｎＨｅａ ｄｅｒは、［１０２４，７６８，８］として指定される。 所定のＳｅｃｔｉｏｎＨｅａｄｅｒに後続するテキストは、シェルライブラリ ７２’によって読み取られ、そして、パーズ（オペランド解析）される。このテ キストは、オペレーションの新規コントローラモードを設定するためにコントロ ーラ１９の各参加サブエレメントに対して実施されなければならない特定のモー ド設定命令の構造化された仕様を表す。好ましい実施例において、モード設定命 令は、ＲＢＧＩＳＴＥＲＣＬＡＳＳ、ＣＯＭＭＡＮＤ、及び、アーギュメントの ようなコンマで区切られた項で構成されたライン指向文である。好ましい実施例 において、コントローラ１９のどのサブエレメントが特定の命令に応答してプロ グラムされるべきかを最終的に決定するために、ＲｅｇＣｌａｓｓＨａｎｄｌｅ ｒ構造の「クラス名」フィールドは、命令のＲＥＧＩＳＴＥＲＣＬＡＳＳ項に相 互関係を持つはずである。 現在４つの直接実行コマンドが有る、即ち、ラン（ＲＵＮ）、リード／マスク ／ライト（ＲＭＷ）、ディレイ（ＤＬＹ）、及び、Ｉｎｔ１０（Ｉ１０）である 。 本発明の好ましい実施例においてサポートされる第５番目の命令は、論理的に 含み、それによってパーズすることをシェルライブラリ７２’のパージングルー チンに指示する組込み指令疑似命令であり、ｍｏｄｅｓ．ｄｍｍファイルにおけ る組込み指令指定されたＳｅｃｔｉｏｎＮａｍｅの下で用いられる。ランコマン ドの命令フォーマットを次に示す： ＲＥＧＩＳＴＥＲＣＬＡＳＳ、ＲＵＮ、ＲＥＧＩＳＴＥＲＮＡＭＥ、 ｖａｌｕｅ１、ｖａｌｕｅ２、ｖａｌｕｅ３ ＲＥＧＩＳＴＥＲＮＡＭＥ項は、ＲＢＧＩＳＴＥＲＣＬＡＳＳ結合を使用し、 ＲｅｇｃｌａｓｓＭａｐ構造へのＲｅｇｃｌａｓｓＨａｎｄｌｅｒ構造を介して 追跡可能な論理名を提供する。論理ＲＥＧＩＳＴＥＲＮＡＭＥ名は、レジスタイ ンタフェース３０内の特定レジスタに究極的に分解される論理ポートアドレスに 対するＲｅｇｃｌａｓｓＭａｐにおいて定義される。命令の実行において、シェ ルライブラリ７２’のパージングルーチンは、ＲＥＧＩＳＴＥＲＮＡＭＥのポー トアドレスに第１の値「ｖａｌｕｅ１」を記入する。次に、ＲｅｇＣｌａｓｓＭ ａｐにおいて識別されるその次の順次的なポートアドレスには、第２の値「ｖａ ｌｕｅ２」が記入される。従って、論理的に順序付けられたポートのアドレスに は、特定のランコマンドによって提供される全ての値の記入が完了するまで、連 続した値が記入される。 リード／マスク／ライトコマンドの命令フォーマットを次に示す： ＲＥＧＩＳＴＥＲＣＬＡＳＳ、ＲＭＷ、ＲＥＧＩＳＴＥＲＮＡＭＥ、 ＡＮＤＭａｓｋ、ＸＯＲＭａｓｋ この命令の実行に際して、シェルライブラリ７２’のパージングルーチンは、 最初に、ＲＥＧＩＳＴＥＲＮＡＭＥに対応するポートアドレスから値を読み取り 、ＡＮＤＭａｓｋの値の２進ＡＮＤを実施し、そして、ＸＯＲＭａｓｋの結果の ２進ＸＯＲを実施する。次に、上記の結果が、ＲＥＧＩＳＴＥＲＮＡＭＥポート のアドルスへ戻って記入される。 ディレイコマンドの命令フォーマットを次に示す： ＳＨＥＬＬ、ＤＬＹ、ＤｅｌａｙＶａｌｕｅ この命令のＲｅｇｉｓｔｅｒＣｌａｓｓは常に「ＳＨＥＬＬ」である。その理 由は、一切のハードウェアインタフェースオブジェクトは、当該命令の実行には 直接的に関係していないことに因る。この命令の実行に際して、シェルライブラ リ７２’のパージングルーチンは、５０マイクロ秒の倍数であることが好ましい ＤｅｌａｙＶａｌｕｅによって指定された期間中、ソフトウェアベース又はハー ドウェアベースいずれかの待ちを実行する。ディレイ命令は、ハードウェアプロ グラミングのセットアップタイムは守られなければならないが、レジスタによる 読取り可能信号がハードウェアによって供給されない場合に有用である。遅延時 間が終了した後においては、パージングルーチンは単純に継続する。 Ｉｎｔ１０コマンドの命令フォーマットを次に示す： ＳＨＥＬＬ、１１０、ＥＡＸ、ＥＢＸ、ＥＣＸ、ＥＤＸ この場合にも、この命令のＲｅｇｉｓｔｅｒＣｌａｓｓは、常に「ＳＨＥＬＬ 」である。その理由は、一切のハードウェアインタフェースオブジェクトは、当 該命令の実行には直接的に関係していないことに因る。シェルライブラリ７２’ のパージングルーチンは、ソフトウェア割込み１０を実施し、そして、割込みに 際して対応するＣＰＵレジスタ内に、当該命令のアーギュメント（引き数）を提 供するためにＯ／Ｓオブジェクト１２８をコールすることによって、この命令を 実行する。 最後に、組み込みコマンド特有の命令フォーマットを次に示す： ＳＨＥＬＬ、ＩＮＣ、ＳｅｃｔｉｏｎＮａｍｅ 組み込みコマンドは、ｍｏｄｅｓ．ｄｉｍｍファイルの現行セクションのパー ジングを効果的に中断し、そして、「ＳｅｃｔｉｏｎＮａｍｅ」によって識別さ れるセクションをパーズすることをシェルライブラリ７２’のパージングルーチ ンに指示する。含まれるセクションのシェルライブラリ７２’によるパージング が終了した後で、中断されたセクションのパージングが再開する。 ｍｏｄｅｓ．ｄｉｍｍファイルによって提供された命令の実行に際して、シェ ルライブラリ７２’は、特定の命令を対応するハードウェアインタフェースオブ ジェクトと結合するために、ＲＢＧＩＳＴＥＲＣＬＡＳＳ項を利用する。命令は 最終的にコントローラ１９のオペレーティングモードのプログラミングに向けら れるので、本発明の好ましい実施例において、オペレーティングシステムインタ フェースオブジェクトは、命令の一切のＲＥＧＩＳＴＥＲＣＬＡＳＳ項によって 引用されることはない。 命令が実行されるにつれて、当該命令の実行に必要なリード／ライトオペレー ションを実施するために、対応するＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造におけ るＲｅａｄ＿ｒｅｇ及びＷｒｉｔｅ＿ｒｅｇエントリがパージングルーチンによ ってコールされる。ＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造はオブジェクトに特有 であるので、Ｒｅａｄ＿ｒｅｇ及びＷｒｉｔｅ＿ｒｅｇ機能は、同様に、ＲＥＧ ＩＳＴＥＲＮＡＭＥ項によって識別される特定のオブジェクトに特有である。 本発明の好ましい実施例において、命令の実行においてレジスタ／アーギュメ ントペアが獲得される場合には、各オブジェクトのＷｒｉｔｅ＿ｒｅｇ機能は、 レジスタ／アーギュメントペアを、実際に記入されるべきレジスタのハードウェ ア特有表現に効果的に変換することを提供する。レジスタ／アーギュメントペア は、当該命令の実行によって、フラットであって順序付けられた論理的レジスタ モデルに効果的に記入される。Ｗｒｉｔｅ＿ｒｅｇ機能は、当該ペアをサブエレ メントハードウェア特有モデルに変換する。例えば、ＤＡＣインタフェースオブ ジェクト１３０特有の情況において、論理レジスタ指標値、及び、索引論理レジ スタに記憶されるべき値を用いてプログラムされる次の順次ベースレジスタによ ってベース物理レジスタがプログラムされることを要求する多重化レジスタモデ ルへの変換が行われる。従って、ＤＡＣインターフェイスオブジェクト１３０の Ｗｒｉｔｅ＿ｒｅｇ機能へのコールにおいては順次レジスタが引用されるが、物 理ベースレジスタの単一ペア作成は当該機能によって記入される。 各オブジェクトのＲｅａｄ＿ｒｅｇ機能は、同様の変換を実施する。引用され た論理レジスタは、対応する物理ベースレジスタに対する基準に変換される。Ｄ ＡＣインターフェイスオブジェクト１３０の場合においては、正しい値が読み取 り可能であるように、論理レジスタを定義するインデックスを用いたベース物理 レジスタのプログラミングが変換に含まれる。 他のインタフェースオブジェクトは、コントローラ１９の他のサブエレメント のプログラミングに適するように、当該命令のフラットな順次レジスタモデルの 直列またはビット順次モデルへの変換を提供可能である。従って、順次レジスタ ／アーギュメントペアは、コントローラ１９の特有サブエレメントのプログラミ ングに適したプログラム値のビット直列シーケンスが後続する論理レジスタ指標 値に変換される。 一例として、Ｄｉａｍｏｎｄ Ｓｔｅａｌｔｈ ６４ Ｖｉｄｅｏ ＤＲＡＭ ビデオコントローラは、Ｓ３ Ｖｉｓｉｏｎ８６８グラフィックスアクセラレー タチップを利用して、グラフィックスモードを作動可能化するように選択的にプ ログラムすることが可能である： グラフィックスモードの非作動化： １０２４ｘ７６８ｘ８モードへのスイッチ： 好ましい実施例において、ハードウェアインタフェースオブジェクトのＷｒｉ ｔｅ＿ｒｅｇ及びＲｅａｄ＿ｒｅｇ機能は、レジスタインターフェイス３０に対 するハードウェア読み及び書きオペレーションを実際に実施するために、ボード ライブラリ７４’における多数の機能を利用する。この間接性追加レベルは、コ ントローラ１９の異なるハードウェアサブエレメントに関して、コントローラ１ ９の特定モデルに応じて異なる物理アドレスに存在することを可能にする。従っ て、特定のハードウェアインタフェースオブジェクトは、コントローラ１９のサ ブエレメントの特定プログラミングを十分に表すが、ボードライブラリ７４’は 、コンピュータシステム１０の物理アドレス空間内において、サブ‐エレメント を暗黙裡に位置決めする。従って、Ｗｒｉｔｅ＿ｒｅｇ機能コールを介してＤＡ Ｃインタフェースオブジェクトによって識別されるベース物理レジスタは、それ 自体、ＤＡＣサブエレメントに論理的に関係する。ボードライブラリ７４’は、 レジスタインターフェイス３０の物理システムアドレス空間内においてレジスタ を位置決めするために、ＤＡＣベース物理レジスタ用の物理アドレッシングオフ セットを供給する。 物理アドレッシングオフセットを確立するために、ボードライブラリ７４’は 、結果的に、コントローラの主要タイプのサブエレメントに特有であるような多 数の読み及び書きルーチンを提供する。例えば、クロックインタフェースオブジ ェクトは、コントローラ１９の明確に定義された特有のサブエレメントを制御す るが、通常は、ＤＡＣサブエレメントと関連したレジスタ内に設置されるか或い はこれを介してアクセス可能であるようなプログラム可能クロックゼネレータを 参 照する。従って、ＤＡＣ及びＣｌｏｃｋ両インタフェースオブジェクト用として ボードライブラリ７４’によって提供される物理アドレッシングオフセットは同 じであるはずである。 ボードライブラリ７４’は、フラットな順次物理レジスタセットをアドレスす るハードウェアインタフェースオブジェクトに関するＢｏａｒＲｅａｄ＿ｒｅｇ 及びＢｏａｒｄＷｒｉｔｅ＿ｒｅｇ機能をサポートすることが好ましい。Ｂｏａ ｒｄＲｅａｄ＿ＤＡＣ、ＢｏａｒｄＷｒｉｔｅ＿ＤＡＣ、及び、ＢｏａｒｄＷｒ ｉｔｅ＿ＤＡＣ＿Ａｒｒａｙ機能は、多重化レジスタの読み書きをサポートし、 そして、コントローラ１９によって確立される場合におけるＤＡＣサブエレメン トの物理レジスタアドレス空間内に配置されたカラーパレットアレイに記入する ために、ボードライブラリ７４’によって提供される。 最後に、コントローラ１９の直列プログラムされたサブエレメントへの直列記 入オペレーションをサポートするために、ＢｏａｒｄＷｒｉｔｅ＿Ｓｅｒｉａｌ Ｄｅｖｉｃｅ＿ｓｔａｒｔ及びＢｏａｒｄＷｒｉｔｅ＿ＳｅｒｉａｌＤｅｖｉｃ ｅ＿ｅｎｄ機能が提供される。 ｍｏｄｅｓ．ｄｍｍファイルから走査された命令が一旦実行されると、コント ローラ１９のオペレーティングモードは、所望の空間解像度および色深度の対応 するいうに変更される。次に、シェルライブラリ７２’は、当該コールに対する オペランドとしての「変更モード」を有するインタフェースオブジェクトの参加 集合のモード設定機能の各々に対してコールする。インタフェースオブジェクト は、コントローラ１９の新規オペレーティングモードを確立するために必要な任 意のサブエレメント特有のルーチンを実行するために、このコールを利用する。 レジスタインタフェース３０におけるレジスタに必要なあらゆるプログラミング 又はディスプレイバッファ２０の直接操作はこの時に実施される。最後のインタ フェースオブジェクトが、このモード設定コールから戻った場合には、シェルラ イブラリ７２’がシェルオブジェクト１２６へ戻る。 次に、「モード変更完了」オペランドを用いた、当該モード設定における各参 加インタフェースオブジェクトへの第３及び最終コールが、シェルライブラリ７ ２’によって行われる。オペレーティングシステムインタフェースオブジェクト に先立って、参加ハードウェアインタフェースオブジェクトがコールされる。各 インタフェースオブジェクトがコールされるにつれて、当該オブジェクトは、コ ントローラ１９の新規オペレーティングモードにおけるコントローラ１９のサブ エレメントのオペレーションをサポートするために必要な任意のハードウェア特 有オペレーションを実行する。一般に、ハードウェアインタフェースオブジェク トは、このコールに応答して単純に戻る。特定のオブジェクトが空間解像度、色 深度、または、他のディバイス特性に基づく具体化依存性を有する場合には、１ つの例外が存在する。例えば、Ｇｒａｐｈｉｃｓオブジェクト１３８のようなハ ードウェアインタフェースオブジェクトによってカプセル封入されたモジュール が、例えば色深度によって区別される同じ論理機能をサポートする多重ルーチン を提示する場合には、当該オブジェクト構造のコールエントリポイントにおける 機能ポインタは、新規色深度に適したルーチンをポイントするように更新される 。 オペレーティングシステムインタフェースオブジェクトは、ディスプレイ解像 度、色深度、または、当該コントローラ１９の新規オペレーティングモードの他 のディバイス特性に対応するように、現行コンテキストにおいて存在するデータ オブジェクトを再実現するために、この「変更モード」コールを利用することが 好ましい。特に、例えばＧＤＩオブジェクトのようなオペレーティングシステム インタフェースオブジェクトは、ディスプレイ３２に目に見える特徴を表示する ビットマップデータオブジェクトを管理し続けることが可能である。従って、特 定のオペレーティングシステムオブジェクトは、先ず、オペレーティングシステ ムインタフェースオブジェクトによって頻繁に使用される任意の変更済みハード ウェアインタフェースオブジェクト機能ポインタを、時宜を得たコールの発信を サポートするオペレーティングシステムインタフェースオブジェクトのローカル コード空間にコピーすることが好ましい。次に、新規ディスプレイ３２の空間解 像度にマッチするように実際のビットマップ解像度データオブジェクトを調節す るために、ビットマップの線形補間が実施されることが好ましい。 オペレーティングシステムインタフェースオブジェクトは、必要に応じて、対応 する更新オペレーションを、ディスプレイ３２を効果的にリフレッシュするよう に導くことにより最終的に「モード変更完了」モード設定コールに応答する。こ の種の更新は、コントローラ１９の新規オペレーティングモードにおいてディス プレイ３２上に見えるデータオブジェクトの再実現を完了したあらゆるオペレー ティングシステムインタフェースオブジェクトに関して特に実施される。一旦ス クリーンリフッレシュが完了すると、シェルライブラリモード設定ルーチンはシ ェルオブジェクトへ戻り、その結果として、前記のシェルオブジェクトがモード 設定ＡＰＩコールから戻る。このようにして、現行コンテキスト内においてモー ドを変更する過程が終了する。 Ａ．組合わせコンテキスト及びモードスイッチ（切換え） 好ましい実施例において、コンテキストスイッチ（文脈切換え）は、新規色深 度へのコントローラ１９モード設定をサポートするために、モードスイッチ（態 様切換え）と組合わされて実施される。コントローラ１９の現行オペレーティン グモードの色深度と異なる特定の色深度を予測して実行するアプリケーション６ ０の代わりのＡＰＩコールは、現行色深度に従わなければならない。特に、この 種のＡＰＩコールが、持続的パレット又はカラーマップの存在を信頼して、ディ バイスドライバ５０に対して行われる場合には、コンテキストのサポートが望ま しい。代替案として、オペレーティングシステムによってサポートされても差し 支えない。オペレーティングシステム核５６へのコール可能なエントリポイント は、目標色深度へのＯ／Ｓ ＡＰＩコールインタフェースにおけるか、或いは、 それ以上において、全ての常駐ビットマップの色深度変換を提供することが可能 である。ただし、この種変換の効率及び可逆性、及び、実際に可変であるビット マップの一定のフォーム及びフォーマットに関する持続的な仮定に基づくオペレ ーティングシステム層５４と相互作動するアプリケーションとディバイスドライ バとの間の潜在的非互換性に関して問題が存在する可能性がある。従って、ディ バイスドライバ自体内におけるコンテキストの切換え、即ち、分離されることは 、スイッチング交換切換えは、多くの異なるオペレーティングシステム具体化の 中においても一層強固かつ移植的であるものと推察される。 パレット及び他の持続的データは、各コンテキストによって維持され、従って 、この種のコンテキストが現在活動中でない場合であっても、基準として利用可 能 である。コンテキストは、ディバイスドライバ５０の初期化に際して、デフォル トによって作成される。追加コンテキストは、新規変更へのモード変更に関して ディバイスドライバ５０に対して行われたＡＰＩコールに応答して、必要に応じ て作成される。 さて、図５ａを参照することとし、シェルライブラリ７２’は、少なくとも初 期において、１つの単一シェルオブジェクト１５０、及び、潜在的に、追加シェ ルオブジェクト１５２、１５４、１５６を含むメモリプール１４８を管理する。 シェルオブジェクト１５０、１５２、１５４、１５６の各々は、ディバイスドラ イバ５０内の独立したコンテキストを表す。１つ又は複数のシェルオブジェクト １５０、１５２、１５４、１５６は、任意の時点において、１つ又は複数の現在 実行中のアプリケーション６０の色深度を表すために適切であるように、プール １４８内に存在可能である。その時に実行中の一切のアプリケーション６０がコ ンテキストによってサポートされる色深度を引用しない場合に、シェルオブジェ クト１５０によって表されるコンテキストを含むコンテキストは、後で閉じてい ても差し支えない。シェルオブジェクト１４８のプールを管理することに加えて 、シェルライブラリ７２’は、同様に、現行コンテキストポインタ１５８を維持 する。このポインタ１５８は、コントローラ１９の現行オペレーティングモード に対応するか、或いは、これを論理的に定義する特定のシェルオブジェクト１５ ０、１５２、１５４、１５６を識別するために用いられる。 図５ｂに全体的に示すように、ディバイスドライバ５０のオペレーションにお けるコンテキストを定義するためにシェルオブジェクトを使用することにより、 ディバイスドライバ５０内のそれぞれのコンテキストにおいて明白なインタフェ ースオブジェクト１７０、１７２の例示を可能にする。インタフェースオブジェ クト１７０、１７２のそれぞれの例示に関して、専用データ空間１７４、１７６ は、それぞれのインタフェースオブジェクト１７０、１７２に割当てられ、そし て、これと対応付けられる。ただし、特定のインターフェイスオブジェクト１７ ０の全ての例示は、共用インタフェースモジュール１７８を共同でカプセル封入 する。インタフェースモジュール１７８の実行に際して、専用データスペース１ ７４、１７６への参照は、それぞれのインタフェースオブジェクト１７０、１７ ２に設立された独立ポインタを介して作動可能化される。従って、インタフェー スモジュール１７８は、特定のコンテキストにおいて、正しいオブジェクトに暗 黙裡に接続される。即ち、モジュール１７８は、多重コンテキストの存在に関す るアスペクトを明白に管理することを要求されない。むしろ、コンテキストの管 理および操作機能は終結し、そして、シェルライブラリ７２’のルーチンによっ て実施される。 コンテキストスイッチを実施する過程は、図６ａ及び６ｂに示す過程段階に従 って発生する。コンテキストスイッチは、例えば、現行コンテキストの色深度と 異なる色深度へのモード変更のような現行モードの或る種のアスペクトに持続性 を要求するオペレーティングモードへのモード変更を少なくとも推論的に指定す るＡＰＩコールを受け取るシェルオブジェクトの現在活動中のコンテキスト例示 １５０と共に始まる。前の場合と同様に、シェルオブジェクト１５０は、ＡＰＩ コールのオペランドの初期妥当性検査を実施し、コンテキストスイッチが必要と されることを判定し、そして、新規コンテキスト作成コール１８０をシェルライ ブラリ７２’に発信する。シェルライブラリ７２’は、所望の色深度を有するコ ンテキストが既に存在するかどうかを判定するために１８４その時点においてコ ンテキストプール１４８内に存在する可能性のあるシェルオブジェクトの存在例 示の各々を調査する。例えば、シェルオブジェクト１５２のような、所望の色深 度を有するシェルオブジェクトの例示が存在する場合には、シェルライブラリ７ ２’への新規コンテキスト作成コールはシェルオブジェクト１５０に戻る。 ただし、その時点において所望のコンテキストが存在しない場合には、新規シ ェルオブジェクト例示が作成されるはずである１８６。この新規シェルオブジェ クトの作成に先立ち、コンテキスト変更が、以前にはサポートされなかった色深 度に関するサポートを必要とするような第１の変更である場合には、シェルライ ブラリ７２’は、対応する色深度変換に関するサポートを有するように修正可能 である。本発明の好ましい実施例において、シェルライブラリ７２’は、第２の 存在コンテキストの作成に関して、単に利便性に関わる問題として、全ての可能 な色深度変換に関するサポートを有するように修正される。詳細には、ただ１つ の単一コンテキストが用いられている場合であっても、色深度変換が、各々の、 及び、全ての製図オペレーションに適用可能であるかどうかに関する一定の条件 付きテストを排除するように、現行色深度と目標色深度とを判定し、両者の間の 変換を行うためのルーチンは、シェルライブラリ７２’のコードに直接パッチさ れる。 本発明の色深度ルーチンは、８、１６、２４、及び、３２ビットの色深度の間 におけるディバイス従属ビットマップの極めて迅速な変換を提供する。１６、２ ４、及び、３２ビット色深度の間の変換は、現行ディスプレイ色深度における各 ディスプレイ画素に関して記憶されたＲＧＥ色値順組（カラーバリュータプル） の間に直接マッピングすることにより実施される。先ず、ソースアプリケーショ ンのコンテキストＰＤｅｖｉｃｅ記憶されたカラーパレット及び変換表において ＲＧＢカラーバリュータプル（色値順組）を調べ、そして、次に、再び、現行デ ィスプレイ色深度への直接ＲＧＢカラーマッピングを実施することにより、画素 当たり８ビットのカラーインデックス（色指標）を用いてパレット化された色空 間からの変換が実施される。 １６、２４、または、３２ビットの色深度から８ビットパレット化フォームへ の変換は更にある程度複雑である。この変換には、変換されつつある各ＲＧＢタ プル（順組）のための最適条件（ベストフィット）に関する８ビット色空間の調 査が必要である。一般に、最適カラーマッピングを見付けるためには、最小平均 二乗アルゴリズムを使用することが出来る。重要な性能改良は、変換された色を キャッシュすることによって達成できる。例えば、３２ビットＲＧＢタプルを８ ビットパレットインデックスに変換する際には、８，１９２個の３２ビットキャ ッシュエントリを備えた基礎キャッシュテーブルを用いることが出来る。各１０ ビットＲＧＢ値が３ビットだけ精度低下されると、２１ビットタプルになる。従 って、現行カラーパレットに対して極めて迅速な最小平均二乗最適化を実施する ことによって決定される８ビットパレットインデックス値は、迅速変換参照表を 確立するために、各２１ビットタプルを用いてキャッシュすることが出来る。次 に、後続する色変換により、先ず、事前変換されたパレットインデックスに関す る表を探索することができる。従って、全ての色深度変換は、シェルライブラリ ７２’により、各ＡＰＩ開始製図オペレーションの一部分として直接サポートさ れることが可能である。 新規シェルオブジェクトの例示は、シェルインターフェイスモジュールの初期 化ルーチンをコールすることによって実施される。ディバイスドライバ５０のオ リジナルな初期化の場合と同様に、ここではシェルオブジェクト１５２の相当す る新規シェルオブジェクト例示は割当てられ、そして、初期化される。次に、ボ ードライブラリ７４’への初期化コールが行われる。ボードライブラリ７４’は 、シェルライブラリ７２’と同様に、コントローラ１９の全てのオペレーティン グモードを通じて定数であるので、ボードライブラリ７４’に対して必要なリフ ァレンスは、個々のハードウェアインタフェースオブジェクトに対する場合と異 なり、新規シェルオブジェクト１５２に接続される。次に、ボードライブラリ７ ４’は、オブジェクトの新規例示を作成し、そして、オブジェクトを新規シェル オブジェクト１５２のボード構造へ接続するために、ハードウェアインタフェー スモジュールの各々の初期化ルーチンを順々にコールする。例えば各モジュール のＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造の内容のように色深度スイッチを通じて 変化しない定数は、完全に再作成されるか、或いは、単にコピーされるか、或い は、現行コンテキスト文のオブジェクトから引用されるかのいずれかであること が可能である。例えば、グラフィックスハードウェアインタフェースオブジェク ト１３８の初期化に際して、新規専用ハードウェアアクセラレータコードデータ オブジェクトは作成可能である。このデータオブジェクトによって記憶されたコ ードは、初期化定数、または、コントローラ１９のグラフィックスサブエレメン トのハードウェアアクセラレータを初期化するためにダウンロードされるシーケ ンサコードであっても差し支えない。従って、異なるシーケンサコードの集合お よび部分集合は、異なるコンテキストにおけるグラフィックスインタフェースオ ブジェクトによって管理可能である。１つの単一オペレーティングモード内にお いて、アクセラレータコードがグラフィックスサブエレメントのオペレーション に際して、必要に応じて、おそらく、異なる製図コマンドの最適実行に関する加 速度アルゴリズムを調節するために動的に交換可能である場合には、この能力は 特別の意味を持つ。次に、ボードライブラリ初期化ルーチンは、シェルライブラ リ７２に戻る。 次に、残りのオペレーティングシステムインタフェースモジュールの初期化ル ーチンは、新規シェルオブジェクト１５２の初期化を完成するためにコールされ る。各モジュールは、対応するインタフェースオブジェクトの新規例示を作成し 、オブジェクトのために必要なあらゆる専用データ空間を作成し、その後で、当 該オブジェクトを新規シェルオブジェクト１５２に接続する。特に、直接ドロー オペレーティングシステムインタフェースオブジェクト１２２の初期化は、新規 コンテキスト特有のＰＤｅｖｉｃｅ構造、及び、潜在的に、新規ＧＤＩ＿Ｉｎｆ ｏｔａｂｌｅ構造の作成を提供する。ハードウェアインタフェースの場合と同様 に、これらの構造によって記憶されているデータは完全に再作成可能であり、或 いは、現行コンテキストの対応する構造からのデータは、新規構造を初期化する ために用いることが出来る。ただし、新規ＰＤｅｖｉｃｅ構造におけるデータは 、新規コンテキストの色深度を定義するために、明確に修正される。同様に、Ｇ ＤＩ＿Ｉｎｆｏｔａｂｌｅの画素深度フィールドは、新規色深度を反映するため に、同様に修正される。それ以降はシェルライブラリ７２’によって管理される これら２つの新規構造に対するポインタは、新規コンテキストのシェルオブジェ クト１５２と論理的に対応付けられる。 従って、当該シェルオブジェクト１５０によって表される現行コンテキストと 論理的に異なるコンテキストを定義するために、オペレーティングシステム及び ハードウェアインタフェースオブジェクト両方の完全な補集合が作成される。次 に、実行は、シェルライブラリ７２’からシェルオブジェクト１５０に戻る。 次に、シェルオブジェクト１５０は、新規コンテキストを実現するために、ボ ードライブラリ７２’にコールを発信する２００。好ましい実施例においてはコ ントローラ１９の所望オペレーティングモードに関する所望色深度及び空間解像 度を含むシェルオブジェクト１５０は、新規コンテキストの特性を識別するため に十分なオペランドを提供する。これに応答して、シェルライブラリ７２’は、 シェルオブジェクトを選択するために、例えばシェルオブジェクト１５２のよう な所望の新規コンテキストに対応するコンテキストプール１４８を探索する。 次に、コンテキストスイッチ（切換え）を実際に実施するための準備に際して 、シェルライブラリ７２’は、「モード変更直前」オペランドを有するモード設 定 コールをモード設定２０６に参加するはずの各インタフェースオブジェクトへ発 信する。以前と同様に、参加するインタフェースオブジェクトの各々は、モード スイッチばかりでなくコンテキストスイッチにおいてもあらゆる状態関連情報が 一貫して持続することを保証するために、これらの情報を対応する専用データス ペースに保管する。 参加インタフェースオブジェクトの最後のオブジェクトからの復帰に際して、 シェルライブラリ７２’は、現行コンテキストを定義するシェルオブジェクトと して新規シェルオブジェクト１５２をインストールする。同時に、シェルライブ ラリ７２’は、ＰＤｅｖｉｃｅ構造、及び、ディバイスドライバ５０への次のＡ ＰＩコールにおいてオペレーティングシステム層によって参照されるはずの構造 としてシェルオブジェクト１５２と論理的に関連したＧＤＩ＿Ｉｎｆｏｔａｂｌ ｅ構造を確立する。 次に、シェルライブラリ７２’のパージングルーチンは、モードスイッチを実 行するために必要な命令を実行するためにコールされる。これらの命令の処理及 び実行は、ディバイスドライバ５０によるコンテキストスイッチと関係しない１ つの単純なモードスイッチを実行するために必要な処理と一貫性をもつ。 モード設定命令が一旦実行されると、シェルライブラリ７２’は、「モード変 更」オペランドを有するモード設定コールを各参加オブジェクトへ発信する。以 前の場合と同様に、各オブジェクトは、例えば、新規シーケンサコードをグラフ ィックスアクセラレータサブエレメントへダウンロードするように、コントロー ラ１９の新規オペレーティングモードを実行またはサポートするために必要な任 意のオブジェクト特有のルーチンを実行可能である。 最後に、シェルライブラリ７２’は、「モード変更完了」オペランドを有する 各参加オブジェクトにモード設定コールを発信する。これに応答して、各参加オ ブジェクトは、例えば、ディスプレイバッファ２０における記憶装置の使用を再 割当てし、そして、ディスプレイ３２上にハードウェアカーソルの位置を確立す ることを含むコントローラ１９の作動環境を確立するために実行する。更に、フ ォールスクリーンリフレシャを要求するために、オペレーティングシステムオブ ジェクト１２８を介して、コールが行われる。これに応答して、オペレーティン グシステム核５６は、ディスプレイ３２上に見えるビットマップへポインタ基準 を提供するディバイスドライバ５０への一連のコールを調節する。ディバイスド ライバ５０を介して各ビットマップが処理されるにつれて、あらゆる必要な色深 度変換が、シェルライブラリ７２’によって適切に実施される。 最後の参加オブジェクトからの復帰に際して、シェルライブラリ７２’は、シ ェルオブジェクト１５２を効果的に介してオペレーティングシステム層５４へ戻 る。従って、ディバイスドライバ５０は、アプリケーション６０又はオペレーテ ィングシステム層５４から実質的に独立し、そして、これらの関連参加なしに、 モードスイッチ及びコンテキストスイッチの両方を完了する。 ＶＩ．操作状態の終結 図７に全体的に示すように、最後に、本発明は、ディバイスドライバ５０のオ ペレーションを終結させる過程を手お経する。詳細には、例えばＷｉｎｄｏｗｓ ’９５TMのように、オペレーティングシステム核５６の具体化例は、オペレーテ ィングシステム核５６の終結に際してコンピュータシステム１０内の各ディバイ スドライバへ発信される標準コールとしてシャットダウンＡＰＩコールを提供す る。シャットダウンＡＰＩコールを受信すると、例えばシェルオブジェクト１５ ２のような、現在活動中のコンテキストのシェルオブジェクトは、継続して受信 したＡＰＩコールの受入れを、オペレーティングシステムインターフェイスモジ ュールによって終結させることにより２２２、ディバイスドライバ５０によって これ以上の一切のＡＰＩコールの処理を作動不可能にするように作動する。従っ て、次に、ディバイスドライバ５０は、整然とした方法により、予期しないＡＰ Ｉコールの受信によって妨害されることなしに、シャットダウンを実施すること ができる。 次に、ｍｏｄｅｓ．ｄｍｍ構成コンフィギュレーションファイルのデフォルト セクションは、シェルライブラリ７２のパージングルーチンによって読取られ、 そして、実行される。このデフォルトセクションによって提供される命令は、コ ントローラ１９に関してデフォルトオペレーティングモードを設定するために２ ２４用いられる。このようにして、コントローラ１９は、オペレーティングシス テム核５６のシャットダウンに続いて使用される可能性に関して適切であるよう な公知の安定した状態に設定される。 次に、シェルライブラリ７２’は、ディバイスドライバ５０のインタフェース オブジェクト及びモジュールによって用いられているシステムメモリを解放する ように作動する。詳細には、シェルライブラリ７２’は、ディバイスドライバ５ ０の現在の各コンテキストを識別するために作動する。識別された各コンテキス ト２２８に関して、シェルライブラリ７２’は、特定のコンテキスト２３０に特 有の各ハードウェアインターフェイスオブジェクトを順次解放するために、ボー ドライブラリ７４’をコールする。結果としてボードライブラリ７４’は、識別 されたコンテキストのシェルオブジェクトに対応する各ハードウェアインタフェ ースオブジェクトをコールする。ハードウェアインターフェイスモジュールと対 応する最後のオブジェクトを解放した状態で、オブジェクト及びモジュールの両 方に対応したメモリスペースが解放される。いったん、全てのコンテキストに関 するハードウェアインタフェースオブジェクトの全てが一旦解放されると、ボー ドライブラリ７４’は、それ自体の記憶装置２３２を解放するために、再びコー ルされる。 シェルライブラリ７２’は、オブジェクト及び対応するモジュールに対応する メモリスペースを解放するために、現在の各コンテキストに関する各々のオペレ ーティングシステムインタフェースオブジェクト２３４をコールする。ディバイ スドライバ５０の現行コンテキストを定義するシェルオブジェクトも同様に解放 される。次に、シェルライブラリ７２’は、対応する記憶装置を効果的に解放し て終結し２３６、そして、オペレーティングシステム層５４の終結を継続するた めに、実行がオペレーティングシステム核５６へ戻る。 Ｖ．仮想化されたドライバオペレーション 好ましいＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ’９５環境においては、いわゆ るＤｏｓ−Ｂｏｘ保護された実行空間において実行中の遺産アプリケーションを サポートすることが必要である。本発明の好ましい具体化に関連して保護されて いる実行が、フルスクリーン又はウィンドウモードのいずれかにおいて提供され る。遺産アプリケーションは、フルスクリーンモードにおけるコントローラ１９ に対して直接アクセスすること、及び、プログラムすることが可能である。ウィ ンドウモードにおいて、遺産アプリケーションによって期待されるハードウェア レジスタをエミュレートするために、一般にＶｘＤドライバと呼ばれる仮想化デ ィバイスドライバが提供される。他のウィンドウアプリケーションと共存および 共同実行するためには、遺産アプリケーションによって動的に提供されるハード ウェアプログラミングのウィンドウ関係エミュレーションが、ＶｘＤドライバに よって提供されることが期待される。一般に、ＶｘＤドライバは、コントローラ １９特有の具体化の完全エミュレーションをサポートする特異モノリシックソフ トウェアモジュールとして再び実現される。結果として、通常のＶｘＤドライバ は、従来のディバイスドライバと関連する場合と同じ問題に遭遇する。 図８に全体的に示すように、本発明のディバイスドライバ５０のアーキテクチ ャは、特に仮想ディスプレイドライバ（ＶＤＤ）を含むＶｘＤドライバを実現す るために直接的かつ効果的に採用することが出来る。既に述べたように、ディバ イスドライバ５０は、オペレーティングシステム層５４内に従来の方法において 設定されたＷｉｎｄｏｗｓ（Ｗｉｎ１６）仮想マシン（ＶＭ）２４０をサポート して作動する。Ｄｏｓ ＶＭ ２４２は、ハードウェア３０への直接アクセスを 試行可能な遺産アプリケーションに関して、Ｄｏｓ−Ｂｏｘ保護された実行空間 を提供する。Ｄｏｓ ＶＭ２４２の中から又はこれによって発行されるハードウ ェアアクセス試行の結果をトラップし、かつ、適切にエミュレートするために、 当該ディバイスドライバ５０のバージョン５０’が提供される。Ｄｏｓ ＶＭ ２４２内におけるアプリケーションのウィンドウモード実行をサポートして作動 中のＶＤＤ ５０’は、オペレーティングシステムの通常使用を介して、Ｉ／Ｏ またはレジスタインタフェース３０に対応するメモリスペースを選択的に確立す る。このアクセストラップは、一般に、Ｄｏｓ ＶＭ ２４２がフルスクリーン モードに切り換えられるか、或いは、実行が他の仮想マシン２４０、２４４に移 動する場合に解放（リリース）される。ウィンドウモードにおけるＤｏｓ ＶＭ ２４２へ実行が戻る場合、或いは、フルスクリーンモードからウィンドウモー ドに切り換えられた時にアクセストラップが再表明（リアサート）される。 アクセストラップがアクセス試行を検出すると、当該トラップによって獲得さ れたアクセス特性情報がＶＤＤ ５０’に提供される。詳細には、図９に示すよ うに、ボードライブラリ７４３１には、論理的に接続２４６を介して、オペレー ティングシステム５４により、アクセス試行情報が提供される。ＶＤＤ ５０’ の構成要素は、ディスプレイドライバ５０の単一コンテキストバージョンを実現 することが好ましい。ただし、Ｄｏｓ ＶＭ ２４２の下における多重コントロ ーラ１９を適切にサポートするために、多重コンテキストは容易にサポートされ ることが可能である。 単一コンテキスト内において、ハードウェアインタフェースオブジェクト１３ ０’、１３２’、１３４’、及び、１３８’は、ハードウェアへ直接アクセスし ようとする連続試行に基づくディスプレイの意図的状態の表現を維持するように 、アクセス特性データを記憶するために作動する。ハードウェアインタフェース オブジェクトと対応するＲｅｇｃｌａｓｓＭａｐ構造は、ハードウェアサブエレ メントの各クラスに対応する状態情報に関する記憶空間へのポインタを用いて増 補されることが好ましい。同様に、ハードウェアインタフェースオブジェクトは 、意図したスクリーンの外観の適切な表現のディスプレイを生じさせるために、 Ｏ／Ｓオブジェクト１２８’の支援によってオペレーティングシステムコールを 生成するエミュレーションルーチンを提供する。これらのコールは、オペレーテ ィングシステム層５４に適用され、その結果として、ディスプレイドライバ５４ へ適宜ルートされる。フルスクリーンモードへのスイッチに際して、ハードウェ アインタフェースオブジェクトによって維持されるディスプレイ状態は、状態デ ータをレジスタインターフェイス３０へ適用することによって、意図したディス プレイ状態を確立するために直接使用することが可能である。 ディバイスドライバ５０’のパーザー（構文解析系）ルーチンは、アクセス特 性情報を分析するために、逆に効果的に使用れる。アクセストラップは、暗黙裡 におけるクラストラップハンドラへのアドレス割当によって、ディバイスクラス へのアクセス試行を特徴付けるために役立つことが好ましい。従って、クラス、 アドレス、及び、アクセスを備えた値は、トラップハンドラによって収集され、 そして、逆パーザー（構文解析系）ルーチンに提供される。従って、トラップさ れた各アクセス試行により、アクセス関連データは、対応するＲｅｇＣｌａｓｓ Ｍａｐ識別された記憶装置に記憶される。同様に、逆パーザー（構文解析系）は 、ｍｏｄｅｓ．ｄｍｍファイルに記憶されているクラスレジスタ命令から究極的 に決定されたレジスタ定義に対する分析を実施する。分析結果は、記入されるこ とを意図したレジスタがインデックスレジスタであるか、又は、他の管理機能レ ジスタであるか、或いは、データレジスタであるかの論理的判定である。意図さ れたレジスタが インデックスレジスタ又は他の管理機能レジスタである場合に は、その結果としての状態変化が記録される。意図されたレジスタがデータレジ スタである場合には、レジスタの新規状態が記録され、その後で、いくらかのエ ミュレーションが必要かどうかに関して判定が行われる。記入中の特定レジスタ に応じて、一切のエミュレーションを必要としないか、或いは、フルインデック ス及びデータアクセスオペレーションが実施されることもあり得る。 従って、実質的には、同一ハードウェア及びオペレーティングシステムインタ フェースオブジェクト定義が用いられることが好ましく、そして、更に、カプセ ル封入されたハードウェアインターフェイスモジュールによって実現されるディ スプレイ特性エミュレーションルーチンの中から選択するためには、異なるディ スプレイ特性をサポートする複数の機能の中から選択する場合と同一の方法を用 いても差し支えない。パーザー（構文解析系）ルーチンが識別可能なモード集合 を検出した場合には、既に説明したようにモード設定オペレーションを実施する ために、Ｏ／Ｓオブジェクト１２８’を介してシェルオブジェクト１２６’がコ ールされても差し支えない。オペレーティングシステムオブジェクト１２０’、 １２２’、１２６’によって実現される実質的な線形コールシーケンスは、直接 的に作動可能化される。従って、オペレーティングシステムインタフェースオブ ジェクトと残りのＶＤＤ ５０’との間の機能コール関係は、ディバイスドライ バ５０の場合と同じである。 Ｖ．結論 以上のように、複雑かつ多機能的な周辺コントローラ並びに仮想ディバイスド ライバのサポートに適した高度に最適化されたディバイスドライバアーキテクチ ャについて説明した。ここに説明したディバイスドライバのアーキテクチャは、 サブエレメント別に詳述する方式に基づいてハードウェアから直接決定されるこ とが好ましい方法において周辺コントローラのハードウェアコンフィギュレーシ ョンに明確にマッチするように、ロードタイムにおいて当該ディバイスドライバ の動的コンフィギュレーションを直接サポートし、特有のサブエレメント設計に 従ってモジュール変更の機能的分離を本質的にサポートするモジュール式アーキ テクチャを採用し、コントローラの作動状態のモードスイッチを実施するための 効率的なメカニズムを提供し、モードスイッチの動作を選択的に用いた独立コン テキストのサポートを介して、モードスイッチから独立した持続性データのメン テナンス及び管理を実施するための効率的なメカニズムを提供し、ビデオディス プレイコントローラアプリケーションにおいて色深度変換の効率的な管理を提供 する。更に、アーキテクチャはモジュール式であって複雑であるにも拘わらず、 モジュール間のサポートされる相互作動的関係は、オペレーティングシステムＡ ＰＩコールを仮想化および実現するために実質的に線形化されたコールシーケン スを作動可能化する。 本発明の好ましい実施例について既に説明した観点から、開示された実施例の 多くの修正及び変形は、当該技術分野における習熟者によって容易に察知可能な はずである。従って、本発明が、添付されている請求の範囲内において、以上に 詳細に述べられた場合とは異なって実現可能であることが理解されるはずである 。

───────────────────────────────────────────────────── 【要約の続き】 作動可能化する。ハードウェアインタフェースの状態 は、個別のコンテキストにおいて仮想化および維持さ れ、実質的にディバイスドライバ（５０）専用のコンテ キスト切換えを介して、選択されたオペレーティングシ ステム事象に応答してハードウェアインタフェースの状 態のアプリケーション特有の動的変更を可能にする。

Claims (1)

1. 【特許請求の範囲】 １．プロセッサ及び記憶装置を含むコンピュータシステムに添付されたハード ウェアコントローラの作動状態の制御された操作を提供する過程であって、前記 のコンピュータシステムがディバイスドライバを介して前記ハードウェアコント ローラへ結合するオペレーティングシステムを実行し、前記過程において、 ａ）前記プロセッサの動作によって前以て決定済みの第１作動状態から前記ハ ードウェアコントローラの前以て決定済みの第２の作動状態へのモードスイッチ 事象の発生を決定する過程と、 ｂ）前記ディバイスドライバによって前記の記憶装置内に予約された前以て決 定済みの第１の場所における前記のハードウェアコントローラの前以て決定済み の前記第１の作動状態に対応する第１のコンテキストを定義するデータを選択的 に記憶する過程と、 ｃ）前以て決定済みの前記第２の作動状態に対応する第２のコンテキスト定義 するデータを前記ディバイスドライバによって前記の記憶装置内に予約された前 以て決定済みの第２の場所から選択的に復元する過程と、 ｄ）前以て決定済みの前記第２の作動状態を確立するために前記第２のコンテ キストを定義する前記のデータを前記のハードウェアコントローラに供給する過 程とを有する過程。 ２．請求項１記載の過程において、選択的に復元する前記の過程が、 ａ）前以て決定済みの前記第２の場所が前記ディバイスドライバによって予約 されているかどうかを決定する過程と、 ｂ）前以て定義済みの前記第２の場所が既に予約済みでない場合には前記ディ バイスドライバのために前以て決定済みの前記第２の場所を予約する過程と、 ｃ）前記第２のコンテキストを定義するデータを初期化する過程とを有する過 程。 ３．請求項１記載の過程において、選択的に記憶し、そして、選択的に復元す る前記の過程のうちの任意の過程がスキップされる過程。 ４．請求項１または３記載の過程において、前記第２のコンテキストを定義す る前記データが前記のディバイスドライバにとって外部のデータファイルから動 的に獲得される過程。 ５．プログラム可能なコントローラにオペレーティングインタフェースを提供 するためにコンピュータシステムのオペレーティングシステムと共に使用するた めのディバイスドライバにおいて、 ａ）モード設定オペレーションを開始するために前以て決定済みＡＰＩコール にエントリポイントサポートを提供するための、オペレーティングシステムに結 合可能な第１のインタフェースモジュールと、 ｂ）システムコンフィギュレーションデータを読取るために前以て決定済みの オペレーティングシステムコールにエントリポイントサポートを提供するための 、前記のオペレーティングシステムに結合可能な第２のインタフェースモジュー ルと、 ｃ）前以て決定済みのハードウェアインタフェースレジスタプログラミングル ーチンにエントリポイントサポートを提供するための、プログラム可能なコント ローラに結合可能な第３のインタフェースモジュールと、 ｄ）前記の第１、第２、及び、第３のインターフェイスモジュールに結合可能 なライブラリモジュールとを有し、前記のライブラリモジュールが前記第１のイ ンタフェースモジュールによる前以て決定済みの前記ＡＰＩコールの受信に応答 し、前記のライブラリモジュールは前記の作動モード設定データに対応する前以 て決定済みのシステムコンフィギュレーションデータを読取るための前記の前以 て決定済みのオペレーティングシステムコールを開始するために前記第２のイン タフェースモジュールにコールを提供し、前記のライブラリモジュールは前以て 決定済みの前記システムコンフィギュレーションデータにおいて提供される前以 て決定済みの命令を実行することによってレジスタプログラミングデータを生成 するためのパーザー（構文解析系）を含み、前記のレジスタプログラミングデー タが前記第３のインタフェースモジュールの前以て決定済みの前記ハードウェア インタフェースレジスタプログラミングルーチンに提供されるディバイスドライ バ。 ６．請求項５記載のディバイスドライバにおいて、前記のライブラリモジュー ルが、前記コンピュータシステムの記憶装置内において、少なくとも前記ディバ イスドライバのインスタレーション及び初期化に際して前記オペレーティングシ ステムにより前記の第１、第２、、及び、第３のモジュールに結合されるディバ イスドライバ。 ７．請求項６記載のディバイスドライバにおいて、前記第３のモジュールが前 記の第３のモジュールによってサポートされた実行可能な機能に対する複数のコ ールエントリポイントを有するプログラム可能なモジュールインタフェースを有 し、前記第３のモジュールが前記第３のモジュールの前記複数のコールエントリ ポイントの前以て決定済みの部分集合に前記複数のコールエントリポイントの初 期化を提供するディバイスドライバ。 ８．請求項７記載のディバイスドライバにおいて、前記第３のモジュールが前 記のモード設定オペレーションと一貫性を有する前記第３のモジュールの前記複 数のコールエントリポイントの代替部分集合に前記複数のコールエントリポイン トの再初期化を提供するディバイスドライバ。 ９．請求項８記載のディバイスドライバにおいて、前記第１のモジュールが前 記のプログラム可能なモジュールインタフェースのコピーを有し、前記コピーが 前以て決定済みの前記部分集合、または、前記第３のモジュールのプログラム可 能な前記モジュールインタフェースにおいて提供される前記複数のコールエント リポイントの前記代替部分集合に適合するディバイスドライバ。 １０．コンピュータシステムに結合されたプログラム可能なコントローラの作 動状態のモード設定を実施する過程において、前記のプログラム可能なコントロ ーラが前記コンピュータシステムにレジスタインタフェースを提供し、前記のコ ンピュータシステムによって実行されたオペレーティングシステムは前記のプロ グラム可能なコントローラのオペレーティングモードの前以て決定済みの特性を 定義する前以て決定されたデータを有するモードスイッチコールを提供し、 ａ）前記のモードスイッチコールに応答して前記プログラム可能なコントロー ラのモード設定を実施することを決定する過程と、 ｂ）前以て決定済みの前記データに基づき前記モード設定のための目標モード を決定する過程と、 ｃ）前記目標モードに対応する前以て決定済みのコンフィギュレーションデー タを獲得する過程と、 ｄ）前以て決定済みの前記コンフィギュレーションデータ内に含まれる複数の 命令を識別して実行するために前以て決定済みの前記コンフィギュレーションデ ータをパーズする過程とを有し、前記複数の命令の実行により前記のプログラム 可能なコントローラのモード設定を実施するために適したレジスタプログラミン グデータを前記の目標モードに提供し、 ｅ）前記のレジスタプログラミングデータを前記のレジスタインタフェースへ 提供する過程を有する過程。