JP4344403B2 - コンテキスト仮想化ディバイスドライバアーキテクチャ - Google Patents

Description

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

表に示すように、シェルオブジェクトには、いくらかの大域フラグデータ、ＡＰＴコールエントリポイント、ディバイスドライバ５０の構成要素を表す高レベルソフトウェアオブジェクトへのポインタ、及び、多数のシェルライブラリルーチン又はディバイスドライバ５０の内部オペレーションをサポートするために用いられる機能が含まれる。
オペレーティングシステムオブジェクトは、オペレーティングシステム層５４サポート機能へのＡＰＩコールアクセスを提供する。オペレーティングシステムオブジェクトのエレメントを表ＩＩに識別する。

サポートされるエントリポイント別に示すように、Ｏ／Ｓオブジェクトは、オペレーティングシステム層５４へのコールインタフェースを供給する。下位レベル及びＢＩＯＳ機能へのコールインタフェース、及び、プラットホーム特有機能へのコールインタフェースを提供する。このプラットホーム特有コールインタフェースは、プラットホーム可搬性の細部を隠すために役立つ多数のユーティリティ又はライブラリルーチンを意味する。Ｏ／Ｓオブジェクトの他の機能と必ずしも関連しているとは限らないが、１つのモジュールに全てのプラットホーム特有コール及び機能を収集するために、これらのルーチンはこのモジュールに集中され、それによって、プラットホーム可搬性の変化を実質的にこの１つのモジュールに制限する。更に、これらのルーチンは、当該モジュールの残りの部分と同様に、アセンブラコーディングを用いて、全体的に最も良好に具体化される。
Ｂ．下位レベル初期化
シェルモジュール７２は、次に、ディバイスドライバ５０の残りの部分の動的ローディングを開始する。正しいボードドライバ７４を識別するために、シェルモジュール７２は、特定のボードタイプを識別するためのビデオディスプレイコントローラ１９の初期評価９４を実施する。ボード識別子は、コントローラ１９に物理的に常駐し、そして、シェルオブジェクトの「ＢｏａｒｄＤａｔａ」フィールドに記憶されているデータ構造から、コントローラ１９を介して読み取られることが好ましい。好ましい実施例において、ボード識別子は、最初、レジスタインタフェース３０を介してアクセス可能なビデオディスプレイコントローラ１９に設置されている通常のオンボードＲＯＭ２９に記憶される。表ＩＩＩは、ボード識別子データ構造の好ましい構造を提供する。

「ＩＤ」フィールドは、ボード識別子構造がディバイスドライバ５０に適合することを確認する静的データ値を提供する。「Ｒｅｖｉｓｉｏｎ」フィールドは、将来、代替構造が具体化された場合に、ボード識別子構造の特定構造を定義するために用いられる。「ＳｔｒｕｃｔｕｒｅＳｉｚｅ」フィールドは、構造のサイズを定義する。「ＢｏａｒｄＦａｍｉｌｙ」フィールドは、この特定な場合におけるビデオディスプレイコントローラ１９をサポートするために必要なディバイスドライバ５０の一部分としてロードされることが必要なボードドライバ７４を主として識別するために用いることのできる値を記憶する。少なくとも「ＢｏａｒｄＦａｍｉｌｙ」値を含むボード識別子構造の値は、ｂｏａｒｄ．ｄａｔファイルにおいてキー名探索（ルックアップ）を実施するためのキーとして用いられる。キーは、有意ボード識別子フィールド値の単純連結として形成されることが好ましい。ｂｏａｒｄ．ｄａｔファイルは、特定の場合におけるボードドライバ７４の対応ファイル名にキーを相関関係付けるフラットファイルであることが好ましい。
特定のボードドライバ７４が９４において一旦識別されると、当該キー値に対応するボードドライバ７４をロードするために、シェルモジュール７２は、オペレーティングシステムモジュール７０を介してコールを発行する。これに応答して、オペレーティングシステム層５４は、９６において、リクエストされたボードドライバ７４を記憶装置１６にロードし、そして、メモリポインタをシェルモジュール７２に戻す。次に、ボードドライバ７４の初期化エントリポイントがコールされる。
ボードドライバ７４の初期化の一部分として、ボードオブジェクト９８が作成される。ボードオブジェクトは、厳密には、オペレーティングシステムもハードウェアインタフェースモジュールも表さないが、オペレーティングシステム又はハードウェアインタフェースモジュールを表すオブジェクトによって便宜上用いられる基礎データ構造形を確立する。ボードオブジェクトの構造を表ＩＶに示す。

ボードオブジェクト初期化の一部分として、ボード識別子構造へのポインタ「ＢｏａｒｄＤａｔａ」は、シェル７２から獲得される１００。ビデオディスプレイコントローラ１９に所在する各サブエレメントの特定のタイプを識別するために、ボード識別子構造における更なるフィールドが調査される。プリセットされたコード化済みの値は、特定の場合におけるサブエレメントを識別するために用いられる。ボード識別子のフィールドは、一般に、コントローラ１９のサブエレメントの固定された態様に対応することが好ましい。例えば、ＤＡＣのタイプ又はビデオメモリ、ＶＲＡＭ又はＤＲＡＭのタイプは、ボード識別子構造を介して提供されても差し支えない。
おそらくフィールドがアップグレード可能であるために、サブエレメントの態様が固定されていない場合には、特定の態様は、従来の方法によって決定されることが必要である。例えば、コントローラが一度使用されさえすれば、ビデオディスプレイコントローラ１９において利用可能なディスプレイＲＡＭの量（ビデオメモリサイズ）は変更可能である。ただし、ボード識別子は、静的であり、そして、コントローラ１９の製造に際して確立される。従って、従来のメモリ走査ルーチンは、そのような場合においてビデオディスプレイコントローラ１９に所在するビデオメモリの全体量を正確に決定するために利用することが出来る。ディスプレイコントローラ１９は、おそらく、当該コントローラ１９が遺産的に具体化されたことにより、同様に、ボード識別子２９を持っていないこともあり得る。従って、この場合、当該コントローラ１９に所在するサブエレメントの妥当な識別は、通常のＩｎｔ１０ Ｂｉｏｓコールを介して獲得された情報から推論可能である。
ボード識別子構造における最後のフィールドは「ＢｏａｒｄＤｅｐｅｎｄｅｎｔＩｎｆｏ」フィールドである。このフィールドは、特定のボードタイプ及びモデルの追加操作特性にフラグを立てるために使用されることが好ましいワード-ワイドビットマップデータエリアを提供する。これらのフラグは、従属的かつボードドライバ７４によって一意的に復号された具体化である。特に、これらのフラグビットは、識別されなければボード識別子の他のフィールドによってカバーされることのない詳細な構成（コンフィギュレーション）オプションを識別するために使用可能である。例えば、１つのフラグビットは、ディバイスドライバ５０のより後の方のバージョンと共に使用可能な些細なサブエレメントオプションの存在を識別するために使用可能である。
従って、ボードドライバ７４は、ボード識別子構造から、ビデオディスプレイコントローラ１９を最適サポートするために必要なハードウェアインタフェースモジュールの特定の集合を決定する１０２。次に、ボードドライバ７４は、オペレーティングシステムモジュール７０を介してボードモジュールと静的にリンクしていないハードウェアインタフェースモジュールの識別済み集合を順次にローディングすること１０４をリクエストする。各ハードウェアインタフェースモジュール７６−８８が記憶装置１６にロードされるにつれて、対応するソフトウェアオブジェクトを確立するために、各モジュールの初期化ルーチンがコールされる１０６。好ましいディバイスドライバ５０において、各ハードウェアインタフェースオブジェクトは、共通ヘッダ部分とハードウェア従属部分とを含むデータ構造として構成される。共通ヘッダ部分は、表Ｖに示すフィールドを含むオブジェクトヘッダデータ構造（ＯＢＪＨＤＲ）であることが好ましい。

「ＯｂｊｅｃｔＶｅｒ」フィールドは、カプセル封入ハードウェアインタフェースによってサポートされたハードウェアサブエレメントの特定具体化を指定する一意的な識別子を提供する。「Ｍｏｄｕｌｅ」フィールドは、カプセル封入されたハードウェアインタフェースモジュールの記憶場所を指示するオペレーティングシステムから戻されたメモリポインタを含む。「ＯｂｊＤａｔａＩｎｓｔａｎｃｅ」フィールドは、ハードウェアインタフェースオブジェクトのこの例示用として予約されている専用データエリアへのポインタを提供する。「ＲｅｇＣｌａｓｓＨａｎｄｌｅｒ」フィールドは、関連ハードウェアサブエレメントが、モード設定動作呼出しの一部分としてプログラムされなければならないインタフェースレジスタを備えているかどうかを定義する。当該フィールドの値が空白（ナル）である場合には、リクエストされた任意のモード設定プログラミングは、ハードウェアインタフェースによってカプセル封入されたモジュールへハードコード化される。当該フィールドが空白（ナル）でない場合には、当該フィールドの値は、レジスタ名および態様変更のサポート用に使用可能なインタフェース手順の定義を含む構造へのポインタである。ＲｅｇＣｌａｓｓＨａｎｄｌｅｒの構造を表ＶＩに示す。

オブジェクトヘッダの「ＯｂｊｅｃｔＩｎｉｔ」及び「ＯｂｊＵｎＩｎｉｔ」フィールドは、現在のハードウェアインタフェースオブジェクトによってカプセル封入されたハードウェアインタフェースモジュールを初期化および解放するためのコールアドレスを提供する。オブジェクトヘッダの「ＭｏｄｅＳｅｔ」フィールドは、態様変更をハードウェアインタフェースオブジェクトに合図するために用いられるハードウェアインタフェースモジュールエントリポイントを確立する。好ましい実施例において、このエントリポイントへの３つの異なるコールが実施可能である。各コールは、１つのモード設定を呼び出すために、１つのモード設定が発生しようとしていること、及び、１つのモード設定が完成したことを指示するためのコールのオペランドによって区別される。
最後に「ＳｅｔＤＰＭＳＳｔａｔｅ」フィールドは、システム１０のパワー管理状態の特定モジュールに特有の変更をサポートするためのエントリポイントを提供する。
従って、ハードウェアインタフェースモジュール初期化ルーチンは、ハードウェアインタフェースオブジェクトのハードウェアインタフェース従属部分用の記憶装置を含み、当該オブジェクトのこの実例におけるオブジェクト特有のフィールドを初期化し、そして、当該ハードウェアインタフェースオブジェクトのこの例示に対して専用状態が維持されるべきあらゆる実例データの割当を獲得するために、カプセル封入ハードウェアインタフェースオブジェクトの一例の作成を提供する。当該実例データへのポインタは、オブジェクトヘッダにおける「ＯｂｊＤａｔａＩｎｓｔａｎｃｅ」フィールドに記憶される。次に、初期化ルーチンは、ポインタをハードウェアインタフェースオブジェクトに返す。このポインタは、ボードオブジェクト基礎構造のメンバーフィールドに記憶される１０８。
基礎ハードウェアインタフェースオブジェクト、特にクロックオブジェクトの定義を表ＶＩＩに示す。

表に示すように、クロックサブエレメントと関連したハードウェア特有機能は無い。ただし、クロック周波数は、クロックサブエレメントの一般的なプログラム可能態様であり、更に、モードセットオペレーションに密接に関連している。従って、オブジェクトヘッダ構造のＲｅｇＣｌａｓｓＨａｎｄｌｅｒフィールドは、コントローラ１９において生成されるクロック周波数を最終的に制御するクロックサブエレメントのインタフェースレジスタへのアクセスをサポートするために必要なレジスタの定義を含むＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造へのポインタを含む。
表ＶＩＩＩは、例えば、ハードウェアカーソルオブジェクトを定義する更に幾分か複雑なオブジェクトを示す。

既に述べたように、オブジェクトヘッダは、カーソルオブジェクトのエレメントとして含まれる。ＣｕｒｓｏｒＥｎａｂｌｅフィールドは、コールパラメータの状態に応じてハードウェアカーソルの可視性をオン（出現）又はオフ（消滅）させるために、ハードウェアカーソルインタフェースモジュールへのエントリポイントに対するポインタを提供する。ＣｕｒｓｏｒＳｅｔフィールドは、オペランドによりコールに対して指定されたパターンに対するカーソルパターンの設定を提供するエントリポイント１５に対するポインタを提供する。ＣｕｒｓｏｒＭｏｖｅフィールドは、コールと共に提供されるＸ及びＹオペランドによりディスプレイ３２上におけるカーソルのホットスポットを指定するためのルーチンへのエントリポイントを識別する。ＣｕｒｓｏｒＳｅｔＣｏｌｏｒフィールドは、ディスプレイ３２上に呈示された二色カーソルを色拡大するために用いられるルーチンを識別する。
他のハードウェアインタフェースオブジェクトには、ＤＡＣオブジェクト１３０（ＤＡＣＯＢＪ；表ＩＸ）、ビデオオブジェクト１３６、グラフィックスオブジェクト１３８（ＤＲＡＷＥＮＧＯＢＪ；表Ｘ）、及び、３Ｄグラフィックスオブジェクト１４０が含まれる。

ＤｒａｗＥｎｇＯｂｊによって参照される基礎構造には、多数の基礎的な製図機能が含まれる。この基礎構造は、ＡＰＩコールに応答してＧＤＩオブジェクトからのコールの線形実行内における機能への直接アクセスを可能にするためにＧＤＩオブジェクトのコード空間内に保持された機能ポインタの１つのコピーを用いて、製図エンジンオブジェクト内に確立される。基礎構造の定義を表ＸＩに示す。

これらオブジェクトの定義によって示すように、ハードウェアインタフェースモジュール７６−８８の各々は、オブジェクト、及び、オブジェクト特有のエントリポイントの固定した集合を提供するハードウェア特有の拡張（エキステンション）の容易な管理を可能にする標準化済み部分を含む対応するハードウェアインタフェースオブジェクトを確立するために初期化する。これらオブジェクト特有のエントリは、カプセル封入されたハードウェアインターフェイスモジュールの初期化ルーチンにより、ポインタリファレンスを用いて充填される。ポインタリファレンスは、論理的に参照される機能を提供するカプセル封入されたモジュール内の機能を対象とする。現行色深度、スクリーン解像度、または、他のコントローラ関連特性に基づいて、論理的機能特有の具体化が異なる場合には、カプセル封入されたモジュールは、対応する特有のエントリポイントを用いて具体化されることが好ましい。エントリポイントの適当な部分集合は、オブジェクトエントリポイントに初期化されたポインタリファレンスによって識別され、それによって、ディバイスドライバ５０のオペレーション進行期間中に、当該コントローラ１９の現行特性状態のランタイムテストを繰り返すことなしに、特性に適切なオペレーションを暗黙確立する。
従って、個々のオブジェクトは、オブジェクト構造の共通ＯＢＪＨＤＲ態様に基づき包括的に管理可能であり、同時に、基礎となる機能的および具体化細目から独立し、特に、例えば現行色深度及びスクリーン解像度のような特性に基づく機能の種々異なる具体化例を含むそれぞれ特定タイプのハードウェアインタフェースオブジェクトに対して充分に定義されたエントリポイントインタフェースを確立するためにも用いることが出来る。
本発明の好ましい実施例において、ボード識別子から識別されたｂｏａｒｄ．ｄｍｍファイルが、クロック、ＤＡＣ、または、ハードウェアカーソルの存在を、ビデオディスプレイコントローラ１９における存在程明確には指定しない場合には、ボードドライバ７４と静的にリンクした対応するデフォルトモジュールが、デフォルトモジュールとして利用される。従って、ハードウェアインタフェースモジュールの集合が識別され、ロードされ、そして、初期化された後で、ボードオブジェクトにおける空白（ナル）ポインタは、ボードドライバ７４によって検出される。例えば、ハードウェアカーソルオブジェクトが存在しない場合には、ボードドライバ７４は、オブジェクトを作成し、そして、ハードウェア従属エントリポイントを、ボードドライバ７４内の対応するデフォルトルーチンに初期化する。それによって、ハードウェアカーソルの機能性は、ソフトウェアエミュレーションを介してサポートされるか、或いは、更に一般的には、ハードウェアインタフェースオブジェクトのなかの別のオブジェクトの本質的な構成要素としてサポートされる。いずれにしても、デフォルトオブジェクトはボードオブジェクトにリンクされ、その後で、動的にロード及びリンクされたハードウェアカーソルオブジェクトと同じ本質的な機能性を提供する。
Ｃ．上位レベル初期化完了
一旦、ハードウェアインタフェースオブジェクトの初期化が完了すると、ボードドライバ７４の初期化ルーチンはシェルモジュール７２に戻る。次に、シェルモジュール７２は、ＧＲＸ ＡＰＩオブジェクト７１を作成するために進行する１０９。ＧＲＸオブジェクトは、オペレーティングシステムインタフェースオブジェクト６４、６６、６８への内部汎用または仮想化インタフェースとして役立つ。ＧＲＸオブジェクト７１は、表ＸＩＩに示す比較的簡単なインタフェースを提供する。

ＧｒｘＡｐｉＦａｓｔＣｏｐｙコールエントリポイントは、オン-スクリーン及び、オフ-スクリーンビデオメモリ内に配置されたビットマップを操作するために特にシェルモジュールを含む全てのオペレーティングシステムＡＰＩレベルモジュールによって使用可能な共通アクセスポイントを提供する。共通アクセスポイントの確立は、ビデオメモリ管理を簡素化する。同様に、ＧｒｘＡｐｉＣｏｌｏｒＭａｔｃｈコールエントリポイントも、スクリーン３２の現行色深度における論理的から物理的への色変換を実施するために、全てのオペレーティングシステムＡＰＩレベルモジュールによって使用可能な共通アクセスポイントを提供する。
オペレーティングシステムインタフェースオブジェクト６４、６６、６８の確立を開始するために１１０、ＧＲＸオブジェクト７１のＯＢＪＨＤＲ内の初期化エントリポイントは、シェルモジュール７２によってコールされる。本発明の好ましい実施例において、ＧＤＩ及びＤＤオブジェクト６４、６６は、ＧＲＸオブジェクト初期化ルーチン内において静的に識別される。その代わりに、又は、追加的に、オペレーティングシステムインタフェースオブジェクトは、ｉｎｔｅｒｆａｃｅ．ｄａｔ構成（コンフィギュレーション）ファイルへの参照によるシェルモジュール７２によって識別可能である。識別されたオペレーティングシステムインタフェースモジュールは、シェルモジュール７２と静的にリンクしなかった場合、記憶装置１６に順次ロードされる１１２。
各オペレーティングシステムモジュールがロードされるにつれて１１２、モジュール初期化ルーチン１１４がコールされる。各オペレーティングシステムインタフェースモジュールの初期化の結果として、は、対応するオペレーティングシステムインタフェースオブジェクトが作成される。ハードウェアインタフェースオブジェクトの場合と同様に、オペレーティングシステムインタフェースオブジェクトは、それぞれ、オペレーティングシステムインタフェースオブジェクトの操作のための共通基準を確立するオブジェクトヘッダ基礎構造（ＣＢＪＨＤＲ）を含むことが好ましい。同様に、オブジェクトヘッダの使用は、ディバイスドライバ５０による態様変更を合図するために、コールに対するサポートを提供する。その結果として、オペレーティングシステムオブジェクトは、必要に応じて、当該オブジェクトの各例示に関する専用データスペースをサポートする。
ＧＤＩオブジェクト１２０は、表ＸＩＩＩに記載された定義を用いて作成される。

ＧＤＩオブジェクト１２０は、標準Ｄｉｂエンジンの基礎構造インタフェース（ＤｉｂｅｎｇＯｂｊ）に関するリンク済み参照を含むか、或いは、提供する。基礎構造を表ＸＩＶに定義する。

ＤｉｂｅｎｇＯｂｊの更なる標準基礎構造を表ＸＶ及びＸＶＩに定義する。

表ＸＶ及びＸＶＩは、直接ドローオブジェクト１２４を定義するオブジェクトを示す。

１６ビット及び３２ビット両環境における使用をサポートするためには、１６ビット及び３２ビット両ＡＰＩコールをサポートするディバイスドライバ５０の構成要素に対する１６ビット及び３２ビット両ポインタを提供するために、付加ＯｂｊＩｎｓｔＤａｔａ基礎構造が用いられる。
最後に、各々のオペレーティングシステムインタフェースオブジェクトの初期化が完了するにつれて、リンク１１６は、ＧＲＸオブジェクト７１とＧＤＩ及びＤＤオブジェクト１２０、１２２との間で確立される。次に、ＧＲＸ初期化ルーチンはシェルへ戻る。同様に、全てのオペレーティングシステムインタフェースオブジェクトはシェルオブジェクトにリンクされる。次に、シェルモジュール７２の初期化ルーチンが戻る。
ＩＶ．操作状態コンフィギュレーション
各オペレーティングシステム及び対応する実行可能モジュールを論理的にカプセル封入するハードウェアインタフェースオブジェクトを備え、単一文脈状態において作動中のディバイスドライバ５０の論理的コンフィギュレーションを図４に示す。シェルドライバ７４の論理的にカプセル封入されない部分は、一般化されたシェルライブラリ７２’として常駐状態を維持する。同様に、ボードドライバ７４の論理的にカプセル封入されない部分は、ボードライブラリ７４’として常駐状態を維持する。両ライブラリ７２’、７４’は共通資源として機能し、ディバイスドライバ５０の内部機能をサポートイする。従って、初期化されたディバイスドライバ５０は、ドライバソフトウェア透視図から、ディバイスドライバ５０によって提供されるオペレーティングシステムＡＰＩを凝集的に確立するオペレーティングシステムインタフェースオブジェクト及びディバイスドライバ５０とハードウェアインタフェースレジスタ３０との間にハードウェアインタフェースを確立するハードウェアインタフェースオブジェクトによって定義される。
Ａ．上位レベル関係
ＧＤＩオブジェクト１２０、直接ドローオブジェクト１２２、直接３Ｄオブジェクト１２４、及び、シャルオブジェクト１２６を含むオペレーティングシステムインタフェースオブジェクトは、オペレーティングシステム層５４に提供される部分ＡＰＩの定義によって相互に論理的に分割されるオブジェクトの集合を表す。既存のＡＰＩコールサポートの改訂、及び、あらゆる特定のオペレーティングシステムインタフェースオブジェクトへの新規ＡＰＩコールの追加は、他のオペレーティングシステムインタフェースの具体化または動作（オペレーション）には、設計上、実質的に一切影響を及ぼさない。更に、オペレーティングシステム層５４による新規定義によるか、或いは、アプリケーション６０から直接発信されたコールをサポートするためかいずれの場合であっても、新規部分ＡＰＩのサポートは、対応するオペレーティングシステムインタフェースオブジェクト及びカプセル封入されたオペレーティングシステムインタフェースモジュールの定義を介して容易に提供可能である。ただし、新規または改訂したＡＰＩコールが、既存のオペレーティングシステムインタフェースオブジェクトによってサポートされる他のＡＰＩコールのうちの任意のコール以外の非常に異なる機能に関係するか、或いは、前記機能を必要とする場合には、追加ライブラリルーチンが、シェルライブラリ７２’に追加されることが必要となることも有り得る。
シェルライブラリ７２’は、オペレーティングシステムインターフェイスオブジェクトの全集合によって使用可能な１組の共通または仮想化されたサポート機能を確立するために役立つルーチンのライブラリを提供するために、オペレーティングシステムインタフェースモジュールから論理的に分割される。オペレーティングシステムインタフェースオブジェクトの各々は、（１）明確に定義されたＡＰＩコールセットをサポートし、（２）サポートされた各ＡＰＩコールに関するパラメータ妥当性検査を提供し、（３）ディバイスドライバ５０の動作における文脈変更に際して持続することが望まれるデータオブジェクトに関する専用データスペースを潜在的に管理し、（４）当該オブジェクトによってサポートされるＡＰＩコールの各々を機能的に具体化するために、順序付けられた１つ又は複数の仮想化されたコールをシェルライブラリ７２’に発行し、最後に（５）フォーマットし、そして、当該オブジェクトによってサポートされるＡＰＩコールの各々に適した方法においてオペレーティングシステム層５４にデータを戻すことが好ましい。
本発明によって認識されるように、ディバイスドライバ５０への多くのコールのバリアント（異形体）は、異なる特定のＡＰＩに向けられる。これらのバリアントは、例えば特定の形式およびコールを備えた一連のオペランドデータのように、特有の態様が異なる。従って、特定のオペランドデータ妥当性検査は各ＡＰＩコールに特有である。従って、各オブジェクトは、ＡＰＩコール特有のオペランド妥当性検査、および、潜在的には、この或いは他のオペレーティングシステムインタフェースオブジェクトによってサポートされる機能的に類似する他のＡＰＩコールとは対照的に一体化される或るフォーマットへのオペランドデータの変換を実施することが好ましい。従って、１つ又は複数のＡＰＩコールの集合は、ディバイスドライバ５０に対して内部的に仮想化される。
各オペレーティングシステムインタフェースオブジェクトは、当該オペレーティングシステムインタフェースオブジェクトによってサポートされるＡＰＩコールのオペランドとして、関係するか、導出されるか、或いは、提供されるデータオブジェクトを保存する必要性に応じて、文脈特有のデータスペースを管理する。
例えば、ＧＤＩオブジェクト１２０は、所定の文脈におけるディスプレイポインタ３８の場合と関連したビットマップ済み解像度従属パターン又は色彩を定義するデータオブジェクトを維持可能である。従って、既存の文脈のリザンプションに際して、データオブジェクトは、この文脈においてディスプレイポインタ３８のインスタンスを能率的に再実現するために使用可能である。再実現は、一切の参加を必要とすることなしに、或いは、あらゆるアプリケーションプログラム６０又は当該オペレーティングシステム層５４への通知さえも必要とすることなしに、完全にサポートされることに特に注意されたい。この例におけるデータオブジェクトは、それは、ディスプレイポインタ３８のパターン又はカラーを初めにセットしたＡＰＩコールのオペランドとして提供されるオリジナルデータオブジェクトから導出される。例えば新規な色深度に関係する新規文脈が作成される場合において、新規データオブジェクトは、前の文脈のデータオブジェクトからの色深度変換によって導出される。先在している文脈への文脈スイッチに際して、データオブジェクトの先在インスタンスが再使用され、その結果として、当該ディスプレイポインタ３８のインスタンスの再実現において情報は一切失われることはない。
同様に、ＧＤＩオブジェクト１２０のインスタンスは、パレット化されたカラーコンテキストにおいて、カラーパレットのみに限らず、順方向及び逆方向のパレット変換表までも、パレット化されたコンテキストに特有のＰＤｅｖｉｃｅ構造の一部として維持されることが好ましい。Ｗｉｎｄｏｗｓ’９５TMオペレーティングシステムにおいて、オペレーティングシステム層５４は、少なくとも当該オペレーティングシステム層５４から選定されたコールに関するディスプレイタイプのディバイスドライバにパスされる或る情報を維持するために用いられるフィジカルディバイス（ＰＤｅｖｉｃｅ）構造への単一ポインタをサポートする。ＰＤｅｖｉｃｅ構造の意図は、ハードウェア特有のコンフィギュレーションデータを一般的に記憶するためにディバイスドライバ５０によって使用可能な増補可能なデータ構造を提供することにある。本発明は、パレット化されたコンテキストに特有の色変換表を記憶するために用いられるだけでなく、各コンテキストに関する新規ＰＤｅｖｉｃｅ構造を一般的に複製し、そして、対応するコンテキストの色深度と合致する構造を増補する。ＰＤｅｖｉｃｅ構造の好ましい構造を表ＸＶＩＩに示す。

コンテキスト特有の持続性データオブジェクトとして効果的なカラーパレット表のメンテナンスは、パレット化された文脈への文脈スイッチに際して、カラーパレット及び変換表の迅速な回復を可能にする。特に、パレット化されないコンテキスト期間中、及び、潜在的には、独立したカラーパレット及び変換表定義を備えた独立ＰＤｅｖｉｃｅ構造を使用する他のパレット化されたコンテキスト期間中において、ＰＤｅｖｉｃｅ構造の一部分としてカラーパレット変換表をメンテナンスすることは、同様に、パレットベース製図動作の継続をサポートする。いずれにしても、パレット化されたコンテキストに対して論理的に実行するアプリケーションからドライブされる進行中の製図動作は、カラーパレットデータ及び対応するコンテキストの変換表に対して製図コマンドを変換または分解することによって、現在活動中のコンテキストの色深度またはカラーパレットへ正しく変換可能である。即ち、現在活動中でないコンテキストに対して論理的に実行するアプリケーション６０の製図コマンドは、現行コンテキストの色深度において製図コマンドを実施するために現在活動中でないコンテキストのデータオブジェクトの参照により、必要に応じて効果的に再実現される。現在活動中でないコンテキストのデータオブジェクトは、データ構造、特に各コンテキストを定義するために用いられるシェルオブジェクトを探索することによって位置付けすることが出来る。
本発明の好ましい実施例において、オペレーティングシステムインタフェースオブジェクトは、いくぶんの薄い層を表す。当該インタフェースオブジェクトによってサポートされる特有のＡＰＩコールの各々に関する実行のスレッドを定義するために適切であるように、ＡＰＩコールは、高レベルにおいて、シェルライブラリ７２’及びハードウェアオブジェクト１３０−１４０に対して実質的に線形コールシーケンスへ仮想化されることが好ましい。一般に、シェルライブラリ７２’におけるルーチンへの共通コールの使用を最大化することが望ましい。逆に、オペレーティングシステムインタフェースオブジェクトの機能を実質的にデータ妥当性検査、基礎データ変換、及び、サポートされる各ＡＰＩコールに関する線形実行スレッドの仕様に制限することが望ましい。
Ｗｉｎｄｏｗｓ’９５TM具体化においては、オペレーティングシステム層５４が、かなり原子的なＡＰＩコールをディバイスドライバ５０へ発行する。従って、殆ど全てのオペレーティングシステムインタフェースオブジェクトは、ＡＰＩコールを実施するために必要な実行スレッドを機能的に具体化するために、シェルライブラリ７２’及びハードウェアインタフェースオブジェクトに対して少数のコールを実施することになる。性能にとって好都合である場合、或いは、使用が特定のＡＰＩコールに実質的に制限される場合、或る種の実行機能は、オペレーティングシステムインタフェースオブジェクトによって実施可能である。特に、座標の初期クリッピング及び変換は、オブジェクトを描写するためのＡＰＩコールに応答するオペランドの妥当性検査と協調して、オペレーティングシステムインタフェースオブジェクトによって実施可能である。別の出所からの新規データオブジェクトの内容を導出するために色深度変換を実施し、次に、スクリーン３２に対して製図動作を実現するために、更に実質的なルーチン、又は、例えば、新規な継続性データオブジェクトの記憶を確立するために用いられるルーチンのような多重ＡＰＩコールによって一層必要になると推測されるルーチンが、シェルライブラリ７２’及びハードウェアインタフェースオブジェクトにおいて適切であるように、実行されることが好ましい。
従って、所要の新規データオブジェクトの作成を要求し、そして、当該オブジェクトに対するポインタを最終的に取り戻して受け取るために、例えば、最初のＡＰＩコールは、オペレーティングシステム５４によって、対応するオペレーティングシステムインタフェースオブジェクトに対して行われる。コールの仮想化された線形スレッドは、結果として割当を要求し、記憶装置内にロックし、そして、結果として得られるオブジェクトへポインタを戻すシェルライブラリ７２’へのコールと共に始まる。これらのリクエストの実施に際して、シェルライブラリ７２’は、オペレーティングシステム層５４への要求されるオペレーティングシステムＡＰＩコールを中継する必要性に応じて、オペレーティングシステムインタフェースオブジェクト１２８を順次にコールする。シェルライブラリ７２’によってサポートされるこのような個々の機能の線形化は、プリエンプティブオペランドの妥当性検査およびオペレーティングシステムインタフェースオブジェクトによって実施される仮想化によって可能になる。オペランドデータは、シェルライブラリ７２’又はハードウェアインタフェースオブジェクトの任意のオブジェクトが、特定のＡＰＩコールから後続する各処理過程に適したフォーム及びフォーマットにおいてコールされる以前に、確立される。従って、例外的条件を扱うため、或いは、データが利用可能か、又は、処理用として受け入れ可能なフォーマットであるかどうかを決定するための全ての、或いは、殆ど全部の条件付ブランチは、オペレーティングシステムインタフェースオブジェクトのレベル以下が除去される。即ち、オペランドデータの存在、フォーム及びフォーマットに関してチェックするための進行中の条件付きブランチング無しに、仮想化されたＡＰＩコールの具体化が実質的に線形化される。更に、現行色深度および機能に適した解像度に対する機能ポインタを備えたハードウェアインタフェースオブジェクトを初期化すると、ディスプレイ３２の現行作動状態に関してチェック及び調節するために進行中の条件付きブランチングを排除する。
次に、オペレーティングシステムオブジェクトに対するその次のＡＰＩコールは、新規に製作されたデータオブジェクトにおける識別されたデータオブジェクトの変換に向けられることもある。オペレーティングシステムインタフェースオブジェクトを介して行われるその次のＡＰＩコールは、以前に作成され、かつ、変換されたＡＰＩコールによって識別されるデータオブジェクトを用いて、特有の製図動作を指定することが出来る。各ＡＰＩ製図コールは、１つ又は複数のコールによる実質的に線形のシーケンスを、特定の製図動作を実現するために適切であるように、シェルライブラリ７２’及びハードウェアインタフェースオブジェクトへ再び発行することにより、受取りオペレーティングシステムインタフェースオブジェクトによって実行される。
従って、オペレーティングシステムインタフェースオブジェクトの各々は、最小複製コードを含んだ状態で、オペランド検証およびフォーマット変換を実施することによってコールの仮想化を最大にするように定義される。従って、シェルライブラリ７２’は、オリジナルのオペランドデータの妥当性再検査、変換、または、再フォーマット化を反復することに起因する実行性能的な罰を受けることなしに最大限に使用される。更に、オペレーティングシステムインタフェースオブジェクトは、コントローラ１９の動作特性に関して連続的に再評価および調節する必要性なしに、即座に利用可能な機能ポインタを介して、ハードウェアインタフェースオブジェクトへ直接コールアクセスする機能を備える。
シェルライブラリ７２’は、オペレーティングシステムインタフェースオブジェクトから受信した共通仮想化されたコールの効果的拡張および具体化を同様に提供可能である。シェルライブラリ７２’へのこの種のコールは、結果的にハードウェア特有の機能を呼び出すために、ハードウェアインタフェースオブジェクトに向けられた一般的に短く実質的に線形のコールシーケンスに拡張されることが好ましい。シェルライブラリ７２’によってコールされたハードウェアインタフェースオブジェクトの特定の集合または部分集合は、オペレーティングシステムインタフェースオブジェクトから受信した特定のコールに高度に依存する。ただし、シェルライブラリ７２’によって行われたコールの各々は、ハードウェアインタフェースオブジェクトデータ構造の仮想化された定義の結果として、ハードウェアインタフェースオブジェクトの集合と効果的な仮想関係を保持する。即ち、ハードウェア金属製品インタフェースオブジェクトの構造定義は、当該オブジェクトによってカプセル封入された特定のハードウェアインタフェースモジュールの具体化から独立した、各オブジェクトタイプに関して実質的に固定される。
従って、オペレーティングシステムインタフェースオブジェクト並びにシェルライブラリ７２’からハードウェアインタフェースにオブジェクトまでのコールは、ハードウェアインターフェイスモジュールの実際の具体化から抽出される。ＡＰＩコールを実現するために用いられる短く実質的に線形のコールシーケンスを使用することによって、仮想化されたＡＰＩコールの実行速度は最大化される。
Ｂ．下位レベル構成（コンフィギュレーション）の関係
ハードウェアインタフェースオブジェクトとオペレーティングシステムインタフェースオブジェクトとは、両者共に、コントローラ１９のインタフェースレジスタ３０とインターフェイスするために必要とされるハードウェア特有のオペレーションを定義する薄い層として実現されることが好ましいという点において類似する。ハードウェアインタフェースオブジェクトは、（１）サポート支援支持物‖特定タイプのハードウェアサブエレメントに特有の明確に定義されたオペレーションの集合をサポートし、（２）サポートされる各オペレーションの機能を実現するために、関連ハードウェアインタフェースレジスタの少なくとも論理的なプログラミングを提供し、（３）当該ディバイスドライバ５０のオペレーションにおいてコンテキストを通じて持続することが望まれるデータオブジェクトに関する専用データスペースを潜在的に管理し、そして、最後に（４）インタフェースレジスタ３０から直接的或いは間接的に読取られたデータを返すことに機能的に制約されることが好ましい。
特定のタイプのハードウェアインタフェースオブジェクトによってサポートされるオペレーションは、オブジェクト構造の一部として定義される。一般に、ハードウェアインタフェースオブジェクトへのコールは、結果的に、インタフェースレジスタ３０の１つ又は複数のレジスタに対するリファレンス及び参照されたレジスタにプログラムされるべきデータ値のストリングを生成する。レジスタのプログラミングは、実際には、ボードライブラリ７４’へのコールに応答して実施されることが好ましい。シェルライブラリ７２’の場合と同様に、ボードライブラリ７４’は、ハードウェアインタフェースオブジェクトによって使用される一般化されるか或いは共通のルーチンを終結する。従って、コードの重複は全体的に減じられ、そして、記憶装置１６のアドレススペース内のディスプレイバッファ２０をロードし、定義し、そして、管理するためのルーチンを含む詳細なレジスタインタフェースルーチンは、当該ディバイスドライバ５０の他の全ての態様から実質的に分離された明確に定義された場所に主として配置される。この場合における１つの重要な例外は、グラフィックスハードウェアインタフェースオブジェクト１３８に関係して発生する。性能上の目的から、このオブジェクトは、レジスタインタフェース３０及びディスプレイバッファ２０に対して直接作動することが好ましい。従って、ボードライブラリ７４’は、ディスプレイバッファ２０の現行ロケーション及び定義を戻すルーチンを提供することが好ましい。コントローラ１９の対応するサブエレメントのハードウェアインタフェースへの直接アクセス機能を備えることにより、ビデオ及び３Ｄハードウェアインタフェースオブジェクト１３６、１４０も、同様に、利益を得るはずであることが予測される。
従って、ハードウェアインタフェースオブジェクトを介してオペレーティングシステムインタフェースの間に成立する効率的に成層化かつ仮想化された関係が、本発明によって確立される。この仮想化された関係は、当該ディバイスドライバ５０への２つの異なるＡＰＩコールの実行フローを追跡することにより、実演により容易に示される。
Ｖ．操作状態コンテキスト及び態様の切換え（スイッチング）
本発明の好ましい実施例において、ビデオディスプレイコントローラ１９は、多くの異なる水平及び垂直或いは空間的解像度、及び、多くの異なる色深度において動作可能である。通常のコンピュータシステム１０は、異なる空間解像度および色深度に対して最適的に作動するアプリケーション６０の多様性をしばしば実行する。実際問題として、コンピュータシステム１０において共同実行することを試みるアプリケーション６０の空間および色深度に関する必要条件および操作上の制限条件は、空間解像度と色深度が相互に排他的でない場合には、アプリケーション６０を継続実行するためにはしばしば最適でないような空間解像度及び色深度に共同実行を制限することがあり得る。
ディバイスドライバ５０のアーキテクチャは、本発明に従い、ディバイスドライバ５０の作動状態において、単独およびコンテキストスイッチ（切換え）との組合わせにより、モードスイッチ（切換え）動作を提供する。モードスイッチ及びコンテキストスイチの両切換えは、アプリケーション６０及びオペレーティングシステム層５４のコンテキスト状態から実質的に独立して実施され、そして、特に管理される。既存のモードの特定のアスペクトに特有なデータが、モードスイッチを通じて継続しなければならない場合には、モードスイッチは単独で実施可能である。コンテキストスイッチは、独立したコンテキストにおけるモードデータの継続的記憶を提供するために、モードスイッチと組合わされてディバイスドライバ５０によって実施される。従って、ディバイスドライバコンテキストスイッチ（切換え）は、特定のコンテキストと関連した持続的データオブジェクトにおける状態およびモード特有データの記憶により、状態的コントローラのモード変更をサポートするために用いられる。ディバイスドライバ５０によるコンテキスト文スイッチのコンテキスト及び動作の管理は、アプリケーションプログラム６０を変更することなく、オペレーティングシステム核５６に極く僅かな特有の修正を施すことによりコンテキスト文切換えを可能にする。
Ａ．一定コンテキストモードのスイッチ（切換え）
モードスイッチをサポートするためには、支援支持物にオペレーティングシステム核５６は、そのウィンドウが現行ポインタの焦点調節を有するアプリケーション６０用として事前に選定された空間解像度へビデオコントローラ１９を切換えるために、ディバイスドライバ５０に向けてＡＰＩコールを発信する核５６へのパッチ６２をインストールすることによって修正される。更に進歩したオペレーティングシステム５４は、オペレーティングシステムパッチをインストールする必要性なしに使用できる事象の生成を組み込み方式により提供可能である。パッチインモードにおいて設定されたＡＰＩコールはシェルオブジェクトにフックされ、そして、物理的ディスプレイ３２の所望新規空間解像度を提供することが好ましい。ＡＰＩコールは、所要空間解像度と組合わせた色深度も指定するはずである。所望色深度および空間解像度の両方が現行色深および空間解像度と同じである場合には、単にＡＰＩコールが戻るだけである。空間解像度だけが異なる場合には、モード切換え（スイッチ）の実施だけが必要である。モードスイッチを実施するために必要とされるコントローラモード設定変更は、ディバイスドライバ５０のその時点現在のコンテキストにおいて実施される。
本発明の好ましい実施例によれば、１つの単一コンテキスト内におけるモード設定変更は、主として、シェルオブジェクト１２６及びシェルライブラリ７２’の制御の下に実施される。シェルオブジェクト１２６へのＡＰＩコールは、モード設定が実施されるべきであることを指定する。シェルオブジェクト１２６は、所望の色深度及び空間解像度を獲得するために、Ｏ／Ｓオブジェクト１２８を介して、オペレーティングシステム層５４にコールする。シェルオブジェクト１２６は、最初に、所望空間解像度を指定する返されたオペランドの妥当性を確認する。次に、オペレーティングシステム及びハードウェアインタフェースオブジェクトの各々を順次にコールするために、最初に「モード変更直前」オペランドを用い、次に、「モード変更」オペランドを使用し、最後に「モード変更完了」オペランドを用いて、シェルライブラリ７２’のセットモードルーチンが、シェルオブジェクト１２６によって、コールされる。
「モード変更直前」オペランドを用いた最初のコールは、コントローラ１９に対してドライバ５０の状態を静止させるために必要な事象のシーケンスをディバイスドライバ５０内において開始する。特に、シェルライブラリ７２’のモード設定ルーチンは、モード設定に参加することが必要な現行コンテキスト内においてオペレーティングシステム及びハードウェアインタフェースオブジェクトの各々を識別するために作動する。これらのインタフェースオブジェクトは、オブジェクト特有のＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造に対して有効または非無効のポインタを有するオブジェクトとして識別される。次に、モード設定コールは、参加している各オブジェクトに対して順々に配置される。これに応答して、各オブジェクトは、現行状態データを、例えば現行ＰＤｅｖｉｃｅ及びＧＤＩ＿Ｉｎｆｏｔａｂｌｅ構造のようなシステムデータ構造に、或いは、オブジェクト自体の専用データスペースに、現行コンテキスト内に明確に定義された実行状態を確立するために適切であるように、順々に保管するために実行する。最後の参加オブジェクトの戻りが完了すると、ディバイスドライバ５０の動作の実質的な静止が完了する。次に、シェルライブラリ７２’は、シェルオブジェクト１２６に戻る。次に、「モード更変」を指定する第２のモード設定コールは、シェルオブジェクト１２６によって、シェルライブラリ７２’に発信される。「モード変更」オペランドを用いてシェルライブラリ７２’によりコールされると、ボードライブラリ７４’は、空間解像度と色深度との所望組合わせに対応する「ＳｅｃｔｉｏｎＮａｍｅ」を構成する。次に、所定の「ＳｅｃｔｉｏｎＮａｍｅ」によって識別されるセクションを位置決めするにはｓｙｓｔｅｍ．ｉｎｉファイルの場合と全体的に同じ構造シンタックス（構文）を有することが好ましいｍｏｄｅｓ．ｄｍｍコンフィギュレーションファイルを走査するために、オペレーティングシステムインタフェースオブジェクト１２８を介して、Ｏ／Ｓ ＡＰＩコールが行われる。Ｗｉｎｄｏｗｓ’９５TMの具体化例において、画素当たり８ビットの色深度であって１０２４ｘ７６８の空間解像度を定義するＳｅｃｔｉｏｎＨｅａｄｅｒは、［１０２４，７６８，８］として指定される。
所定のＳｅｃｔｉｏｎＨｅａｄｅｒに後続するテキストは、シェルライブラリ７２’によって読み取られ、そして、パーズ（オペランド解析）される。このテキストは、オペレーションの新規コントローラモードを設定するためにコントローラ１９の各参加サブエレメントに対して実施されなければならない特定のモード設定命令の構造化された仕様を表す。好ましい実施例において、モード設定命令は、ＲＢＧＩＳＴＥＲＣＬＡＳＳ、ＣＯＭＭＡＮＤ、及び、アーギュメントのようなコンマで区切られた項で構成されたライン指向文である。好ましい実施例において、コントローラ１９のどのサブエレメントが特定の命令に応答してプログラムされるべきかを最終的に決定するために、ＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造の「クラス名」フィールドは、命令のＲＥＧＩＳＴＥＲＣＬＡＳＳ項に相互関係を持つはずである。
現在４つの直接実行コマンドが有る、即ち、ラン（ＲＵＮ）、リード／マスク／ライト（ＲＭＷ）、ディレイ（ＤＬＹ）、及び、Ｉｎｔ１０（Ｉ１０）である。
本発明の好ましい実施例においてサポートされる第５番目の命令は、論理的に含み、それによってパーズすることをシェルライブラリ７２’のパージングルーチンに指示する組込み指令疑似命令であり、ｍｏｄｅｓ．ｄｍｍファイルにおける組込み指令指定されたＳｅｃｔｉｏｎＮａｍｅの下で用いられる。ランコマンドの命令フォーマットを次に示す：
ＲＥＧＩＳＴＥＲＣＬＡＳＳ、ＲＵＮ、ＲＥＧＩＳＴＥＲＮＡＭＥ、
ｖａｌｕｅ１、ｖａｌｕｅ２、ｖａｌｕｅ３
ＲＥＧＩＳＴＥＲＮＡＭＥ項は、ＲＢＧＩＳＴＥＲＣＬＡＳＳ結合を使用し、ＲｅｇｃｌａｓｓＭａｐ構造へのＲｅｇｃｌａｓｓＨａｎｄｌｅｒ構造を介して追跡可能な論理名を提供する。論理ＲＥＧＩＳＴＥＲＮＡＭＥ名は、レジスタインタフェース３０内の特定レジスタに究極的に分解される論理ポートアドレスに対するＲｅｇｃｌａｓｓＭａｐにおいて定義される。命令の実行において、シェルライブラリ７２’のパージングルーチンは、ＲＥＧＩＳＴＥＲＮＡＭＥのポートアドレスに第１の値「ｖａｌｕｅ１」を記入する。次に、ＲｅｇＣｌａｓｓＭａｐにおいて識別されるその次の順次的なポートアドレスには、第２の値「ｖａｌｕｅ２」が記入される。従って、論理的に順序付けられたポートのアドレスには、特定のランコマンドによって提供される全ての値の記入が完了するまで、連続した値が記入される。
リード／マスク／ライトコマンドの命令フォーマットを次に示す：
ＲＥＧＩＳＴＥＲＣＬＡＳＳ、ＲＭＷ、ＲＥＧＩＳＴＥＲＮＡＭＥ、
ＡＮＤＭａｓｋ、ＸＯＲＭａｓｋ
この命令の実行に際して、シェルライブラリ７２’のパージングルーチンは、最初に、ＲＥＧＩＳＴＥＲＮＡＭＥに対応するポートアドレスから値を読み取り、ＡＮＤＭａｓｋの値の２進ＡＮＤを実施し、そして、ＸＯＲＭａｓｋの結果の２進ＸＯＲを実施する。次に、上記の結果が、ＲＥＧＩＳＴＥＲＮＡＭＥポートのアドレスへ戻って記入される。
ディレイコマンドの命令フォーマットを次に示す：
ＳＨＥＬＬ、ＤＬＹ、ＤｅｌａｙＶａｌｕｅ
この命令のＲｅｇｉｓｔｅｒＣｌａｓｓは常に「ＳＨＥＬＬ」である。その理由は、一切のハードウェアインタフェースオブジェクトは、当該命令の実行には直接的に関係していないことに因る。この命令の実行に際して、シェルライブラリ７２’のパージングルーチンは、５０マイクロ秒の倍数であることが好ましいＤｅｌａｙＶａｌｕｅによって指定された期間中、ソフトウェアベース又はハードウェアベースいずれかの待ちを実行する。ディレイ命令は、ハードウェアプログラミングのセットアップタイムは守られなければならないが、レジスタによる読取り可能信号がハードウェアによって供給されない場合に有用である。遅延時間が終了した後においては、パージングルーチンは単純に継続する。
Ｉｎｔ１０コマンドの命令フォーマットを次に示す：
ＳＨＥＬＬ、Ｉ１０、ＥＡＸ、ＥＢＸ、ＥＣＸ、ＥＤＸ
この場合にも、この命令のＲｅｇｉｓｔｅｒＣｌａｓｓは、常に「ＳＨＥＬＬ」である。その理由は、一切のハードウェアインタフェースオブジェクトは、当該命令の実行には直接的に関係していないことに因る。シェルライブラリ７２’のパージングルーチンは、ソフトウェア割込み１０を実施し、そして、割込みに際して対応するＣＰＵレジスタ内に、当該命令のアーギュメント（引き数）を提供するためにＯ／Ｓオブジェクト１２８をコールすることによって、この命令を実行する。
最後に、組み込みコマンド特有の命令フォーマットを次に示す：
ＳＨＥＬＬ、ＩＮＣ、ＳｅｃｔｉｏｎＮａｍｅ
組み込みコマンドは、ｍｏｄｅｓ．ｄｉｍｍファイルの現行セクションのパージングを効果的に中断し、そして、「ＳｅｃｔｉｏｎＮａｍｅ」によって識別されるセクションをパーズすることをシェルライブラリ７２’のパージングルーチンに指示する。含まれるセクションのシェルライブラリ７２’によるパージングが終了した後で、中断されたセクションのパージングが再開する。
ｍｏｄｅｓ．ｄｉｍｍファイルによって提供された命令の実行に際して、シェルライブラリ７２’は、特定の命令を対応するハードウェアインタフェースオブジェクトと結合するために、ＲＢＧＩＳＴＥＲＣＬＡＳＳ項を利用する。命令は最終的にコントローラ１９のオペレーティングモードのプログラミングに向けられるので、本発明の好ましい実施例において、オペレーティングシステムインタフェースオブジェクトは、命令の一切のＲＥＧＩＳＴＥＲＣＬＡＳＳ項によって引用されることはない。
命令が実行されるにつれて、当該命令の実行に必要なリード／ライトオペレーションを実施するために、対応するＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造におけるＲｅａｄ＿ｒｅｇ及びＷｒｉｔｅ＿ｒｅｇエントリがパージングルーチンによってコールされる。ＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造はオブジェクトに特有であるので、Ｒｅａｄ＿ｒｅｇ及びＷｒｉｔｅ＿ｒｅｇ機能は、同様に、ＲＥＧＩＳＴＥＲＮＡＭＥ項によって識別される特定のオブジェクトに特有である。
本発明の好ましい実施例において、命令の実行においてレジスタ／アーギュメントペアが獲得される場合には、各オブジェクトのＷｒｉｔｅ＿ｒｅｇ機能は、レジスタ／アーギュメントペアを、実際に記入されるべきレジスタのハードウェア特有表現に効果的に変換することを提供する。レジスタ／アーギュメントペアは、当該命令の実行によって、フラットであって順序付けられた論理的レジスタモデルに効果的に記入される。Ｗｒｉｔｅ＿ｒｅｇ機能は、当該ペアをサブエレメントハードウェア特有モデルに変換する。例えば、ＤＡＣインタフェースオブジェクト１３０特有の情況において、論理レジスタ指標値、及び、索引論理レジスタに記憶されるべき値を用いてプログラムされる次の順次ベースレジスタによってベース物理レジスタがプログラムされることを要求する多重化レジスタモデルへの変換が行われる。従って、ＤＡＣインターフェイスオブジェクト１３０のＷｒｉｔｅ−ｒｅｇ機能へのコールにおいては順次レジスタが引用されるが、物理ベースレジスタの単一ペア作成は当該機能によって記入される。
各オブジェクトのＲｅａｄ＿ｒｅｇ機能は、同様の変換を実施する。引用された論理レジスタは、対応する物理ベースレジスタに対する基準に変換される。ＤＡＣインターフェイスオブジェクト１３０の場合においては、正しい値が読み取り可能であるように、論理レジスタを定義するインデックスを用いたベース物理レジスタのプログラミングが変換に含まれる。
他のインタフェースオブジェクトは、コントローラ１９の他のサブエレメントのプログラミングに適するように、当該命令のフラットな順次レジスタモデルの直列またはビット順次モデルへの変換を提供可能である。従って、順次レジスタ／アーギュメントペアは、コントローラ１９の特有サブエレメントのプログラミングに適したプログラム値のビット直列シーケンスが後続する論理レジスタ指標値に変換される。
一例として、Ｄｉａｍｏｎｄ Ｓｔｅａｌｔｈ ６４ Ｖｉｄｅｏ ＤＲＡＭビデオコントローラは、Ｓ３ Ｖｉｓｉｏｎ８６８グラフィックスアクセラレータチップを利用して、グラフィックスモードを作動可能化するように選択的にプログラムすることが可能である：

グラフィックスモードの非作動化：

１０２４ｘ７６８ｘ８モードへのスイッチ：

好ましい実施例において、ハードウェアインタフェースオブジェクトのＷｒｉｔｅ＿ｒｅｇ及びＲｅａｄ＿ｒｅｇ機能は、レジスタインターフェイス３０に対するハードウェア読み及び書きオペレーションを実際に実施するために、ボードライブラリ７４’における多数の機能を利用する。この間接性追加レベルは、コントローラ１９の異なるハードウェアサブエレメントに関して、コントローラ１９の特定モデルに応じて異なる物理アドレスに存在することを可能にする。従って、特定のハードウェアインタフェースオブジェクトは、コントローラ１９のサブエレメントの特定プログラミングを十分に表すが、ボードライブラリ７４’は、コンピュータシステム１０の物理アドレス空間内において、サブ-エレメントを暗黙裡に位置決めする。従って、Ｗｒｉｔｅ＿ｒｅｇ機能コールを介してＤＡＣインタフェースオブジェクトによって識別されるベース物理レジスタは、それ自体、ＤＡＣサブエレメントに論理的に関係する。ボードライブラリ７４’は、レジスタインターフェイス３０の物理システムアドレス空間内においてレジスタを位置決めするために、ＤＡＣベース物理レジスタ用の物理アドレッシングオフセットを供給する。
物理アドレッシングオフセットを確立するために、ボードライブラリ７４’は、結果的に、コントローラの主要タイプのサブエレメントに特有であるような多数の読み及び書きルーチンを提供する。例えば、クロックインタフェースオブジェクトは、コントローラ１９の明確に定義された特有のサブエレメントを制御するが、通常は、ＤＡＣサブエレメントと関連したレジスタ内に設置されるか或いはこれを介してアクセス可能であるようなプログラム可能クロックゼネレータを参照する。従って、ＤＡＣ及びＣｌｏｃｋ両インタフェースオブジェクト用としてボードライブラリ７４’によって提供される物理アドレッシングオフセットは同じであるはずである。
ボードライブラリ７４’は、フラットな順次物理レジスタセットをアドレスするハードウェアインタフェースオブジェクトに関するＢｏａｒＲｅａｄ＿ｒｅｇ及びＢｏａｒｄＷｒｉｔｅ＿ｒｅｇ機能をサポートすることが好ましい。ＢｏａｒｄＲｅａｄ＿ＤＡＣ、ＢｏａｒｄＷｒｉｔｅ＿ＤＡＣ、及び、ＢｏａｒｄＷｒｉｔｅ＿ＤＡＣ＿Ａｒｒａｙ機能は、多重化レジスタの読み書きをサポートし、そして、コントローラ１９によって確立される場合におけるＤＡＣサブエレメントの物理レジスタアドレス空間内に配置されたカラーパレットアレイに記入するために、ボードライブラリ７４’によって提供される。
最後に、コントローラ１９の直列プログラムされたサブエレメントへの直列記入オペレーションをサポートするために、ＢｏａｒｄＷｒｉｔｅ＿ＳｅｒｉａｌＤｅｖｉｃｅ＿ｓｔａｒｔ及びＢｏａｒｄＷｒｉｔｅ＿ＳｅｒｉａｌＤｅｖｉｃｅ＿ｅｎｄ機能が提供される。
ｍｏｄｅｓ．ｄｍｍファイルから走査された命令が一旦実行されると、コントローラ１９のオペレーティングモードは、所望の空間解像度および色深度の対応するいうに変更される。次に、シェルライブラリ７２’は、当該コールに対するオペランドとしての「変更モード」を有するインタフェースオブジェクトの参加集合のモード設定機能の各々に対してコールする。インタフェースオブジェクトは、コントローラ１９の新規オペレーティングモードを確立するために必要な任意のサブエレメント特有のルーチンを実行するために、このコールを利用する。レジスタインタフェース３０におけるレジスタに必要なあらゆるプログラミング又はディスプレイバッファ２０の直接操作はこの時に実施される。最後のインタフェースオブジェクトが、このモード設定コールから戻った場合には、シェルライブラリ７２’がシェルオブジェクト１２６へ戻る。
次に、「モード変更完了」オペランドを用いた、当該モード設定における各参加インタフェースオブジェクトへの第３及び最終コールが、シェルライブラリ７２’によって行われる。オペレーティングシステムインタフェースオブジェクトに先立って、参加ハードウェアインタフェースオブジェクトがコールされる。各インタフェースオブジェクトがコールされるにつれて、当該オブジェクトは、コントローラ１９の新規オペレーティングモードにおけるコントローラ１９のサブエレメントのオペレーションをサポートするために必要な任意のハードウェア特有オペレーションを実行する。一般に、ハードウェアインタフェースオブジェクトは、このコールに応答して単純に戻る。特定のオブジェクトが空間解像度、色深度、または、他のディバイス特性に基づく具体化依存性を有する場合には、１つの例外が存在する。例えば、Ｇｒａｐｈｉｃｓオブジェクト１３８のようなハードウェアインタフェースオブジェクトによってカプセル封入されたモジュールが、例えば色深度によって区別される同じ論理機能をサポートする多重ルーチンを提示する場合には、当該オブジェクト構造のコールエントリポイントにおける機能ポインタは、新規色深度に適したルーチンをポイントするように更新される。
オペレーティングシステムインタフェースオブジェクトは、ディスプレイ解像度、色深度、または、当該コントローラ１９の新規オペレーティングモードの他のディバイス特性に対応するように、現行コンテキストにおいて存在するデータオブジェクトを再実現するために、この「変更モード」コールを利用することが好ましい。特に、例えばＧＤＩオブジェクトのようなオペレーティングシステムインタフェースオブジェクトは、ディスプレイ３２に目に見える特徴を表示するビットマップデータオブジェクトを管理し続けることが可能である。従って、特定のオペレーティングシステムオブジェクトは、先ず、オペレーティングシステムインタフェースオブジェクトによって頻繁に使用される任意の変更済みハードウェアインタフェースオブジェクト機能ポインタを、時宜を得たコールの発信をサポートするオペレーティングシステムインタフェースオブジェクトのローカルコード空間にコピーすることが好ましい。次に、新規ディスプレイ３２の空間解像度にマッチするように実際のビットマップ解像度データオブジェクトを調節するために、ビットマップの線形補間が実施されることが好ましい。
オペレーティングシステムインタフェースオブジェクトは、必要に応じて、対応する更新オペレーションを、ディスプレイ３２を効果的にリフレッシュするように導くことにより最終的に「モード変更完了」モード設定コールに応答する。この種の更新は、コントローラ１９の新規オペレーティングモードにおいてディスプレイ３２上に見えるデータオブジェクトの再実現を完了したあらゆるオペレーティングシステムインタフェースオブジェクトに関して特に実施される。一旦スクリーンリフッレシュが完了すると、シェルライブラリモード設定ルーチンはシェルオブジェクトへ戻り、その結果として、前記のシェルオブジェクトがモード設定ＡＰＩコールから戻る。このようにして、現行コンテキスト内においてモードを変更する過程が終了する。
Ａ．組合わせコンテキスト及びモードスイッチ（切換え）
好ましい実施例において、コンテキストスイッチ（文脈切換え）は、新規色深度へのコントローラ１９モード設定をサポートするために、モードスイッチ（態様切換え）と組合わされて実施される。コントローラ１９の現行オペレーティングモードの色深度と異なる特定の色深度を予測して実行するアプリケーション６０の代わりのＡＰＩコールは、現行色深度に従わなければならない。特に、この種のＡＰＩコールが、持続的パレット又はカラーマップの存在を信頼して、ディバイスドライバ５０に対して行われる場合には、コンテキストのサポートが望ましい。代替案として、オペレーティングシステムによってサポートされても差し支えない。オペレーティングシステム核５６へのコール可能なエントリポイントは、目標色深度へのＯ／Ｓ ＡＰＩコールインタフェースにおけるか、或いは、それ以上において、全ての常駐ビットマップの色深度変換を提供することが可能である。ただし、この種変換の効率及び可逆性、及び、実際に可変であるビットマップの一定のフォーム及びフォーマットに関する持続的な仮定に基づくオペレーティングシステム層５４と相互作動するアプリケーションとディバイスドライバとの間の潜在的非互換性に関して問題が存在する可能性がある。従って、ディバイスドライバ自体内におけるコンテキストの切換え、即ち、分離されることは、スイッチング交換切換えは、多くの異なるオペレーティングシステム具体化の中においても一層強固かつ移植的であるものと推察される。
パレット及び他の持続的データは、各コンテキストによって維持され、従って、この種のコンテキストが現在活動中でない場合であっても、基準として利用可能である。コンテキストは、ディバイスドライバ５０の初期化に際して、デフォルトによって作成される。追加コンテキストは、新規変更へのモード変更に関してディバイスドライバ５０に対して行われたＡＰＩコールに応答して、必要に応じて作成される。
さて、図５ａを参照することとし、シェルライブラリ７２’は、少なくとも初期において、１つの単一シェルオブジェクト１５０、及び、潜在的に、追加シェルオブジェクト１５２、１５４、１５６を含むメモリプール１４８を管理する。シェルオブジェクト１５０、１５２、１５４、１５６の各々は、ディバイスドライバ５０内の独立したコンテキストを表す。１つ又は複数のシェルオブジェクト１５０、１５２、１５４、１５６は、任意の時点において、１つ又は複数の現在実行中のアプリケーション６０の色深度を表すために適切であるように、プール１４８内に存在可能である。その時に実行中の一切のアプリケーション６０がコンテキストによってサポートされる色深度を引用しない場合に、シェルオブジェクト１５０によって表されるコンテキストを含むコンテキストは、後で閉じていても差し支えない。シェルオブジェクト１４８のプールを管理することに加えて、シェルライブラリ７２’は、同様に、現行コンテキストポインタ１５８を維持する。このポインタ１５８は、コントローラ１９の現行オペレーティングモードに対応するか、或いは、これを論理的に定義する特定のシェルオブジェクト１５０、１５２、１５４、１５６を識別するために用いられる。
図５ｂに全体的に示すように、ディバイスドライバ５０のオペレーションにおけるコンテキストを定義するためにシェルオブジェクトを使用することにより、ディバイスドライバ５０内のそれぞれのコンテキストにおいて明白なインタフェースオブジェクト１７０、１７２の例示を可能にする。インタフェースオブジェクト１７０、１７２のそれぞれの例示に関して、専用データ空間１７４、１７６は、それぞれのインタフェースオブジェクト１７０、１７２に割当てられ、そして、これと対応付けられる。ただし、特定のインターフェイスオブジェクト１７０の全ての例示は、共用インタフェースモジュール１７８を共同でカプセル封入する。インタフェースモジュール１７８の実行に際して、専用データスペース１７４、１７６への参照は、それぞれのインタフェースオブジェクト１７０、１７２に設立された独立ポインタを介して作動可能化される。従って、インタフェースモジュール１７８は、特定のコンテキストにおいて、正しいオブジェクトに暗黙裡に接続される。即ち、モジュール１７８は、多重コンテキストの存在に関するアスペクトを明白に管理することを要求されない。むしろ、コンテキストの管理および操作機能は終結し、そして、シェルライブラリ７２’のルーチンによって実施される。
コンテキストスイッチを実施する過程は、図６ａ及び６ｂに示す過程段階に従って発生する。コンテキストスイッチは、例えば、現行コンテキストの色深度と異なる色深度へのモード変更のような現行モードの或る種のアスペクトに持続性を要求するオペレーティングモードへのモード変更を少なくとも推論的に指定するＡＰＩコールを受け取るシェルオブジェクトの現在活動中のコンテキスト例示１５０と共に始まる。前の場合と同様に、シェルオブジェクト１５０は、ＡＰＩコールのオペランドの初期妥当性検査を実施し、コンテキストスイッチが必要とされることを判定し、そして、新規コンテキスト作成コール１８０をシェルライブラリ７２’に発信する。シェルライブラリ７２’は、所望の色深度を有するコンテキストが既に存在するかどうかを判定するために１８４その時点においてコンテキストプール１４８内に存在する可能性のあるシェルオブジェクトの存在例示の各々を調査する。例えば、シェルオブジェクト１５２のような、所望の色深度を有するシェルオブジェクトの例示が存在する場合には、シェルライブラリ７２’への新規コンテキスト作成コールはシェルオブジェクト１５０に戻る。
ただし、その時点において所望のコンテキストが存在しない場合には、新規シェルオブジェクト例示が作成されるはずである１８６。この新規シェルオブジェクトの作成に先立ち、コンテキスト変更が、以前にはサポートされなかった色深度に関するサポートを必要とするような第１の変更である場合には、シェルライブラリ７２’は、対応する色深度変換に関するサポートを有するように修正可能である。本発明の好ましい実施例において、シェルライブラリ７２’は、第２の存在コンテキストの作成に関して、単に利便性に関わる問題として、全ての可能な色深度変換に関するサポートを有するように修正される。詳細には、ただ１つの単一コンテキストが用いられている場合であっても、色深度変換が、各々の、及び、全ての製図オペレーションに適用可能であるかどうかに関する一定の条件付きテストを排除するように、現行色深度と目標色深度とを判定し、両者の間の変換を行うためのルーチンは、シェルライブラリ７２’のコードに直接パッチされる。
本発明の色深度ルーチンは、８、１６、２４、及び、３２ビットの色深度の間におけるディバイス従属ビットマップの極めて迅速な変換を提供する。１６、２４、及び、３２ビット色深度の間の変換は、現行ディスプレイ色深度における各ディスプレイ画素に関して記憶されたＲＧＥ色値順組（カラーバリュータプル）の間に直接マッピングすることにより実施される。先ず、ソースアプリケーションのコンテキストＰＤｅｖｉｃｅ記憶されたカラーパレット及び変換表においてＲＧＢカラーバリュータプル（色値順組）を調べ、そして、次に、再び、現行ディスプレイ色深度への直接ＲＧＢカラーマッピングを実施することにより、画素当たり８ビットのカラーインデックス（色指標）を用いてパレット化された色空間からの変換が実施される。
１６、２４、または、３２ビットの色深度から８ビットパレット化フォームへの変換は更にある程度複雑である。この変換には、変換されつつある各ＲＧＢタプル（順組）のための最適条件（ベストフィット）に関する８ビット色空間の調査が必要である。一般に、最適カラーマッピングを見付けるためには、最小平均二乗アルゴリズムを使用することが出来る。重要な性能改良は、変換された色をキャッシュすることによって達成できる。例えば、３２ビットＲＧＢタプルを８ビットパレットインデックスに変換する際には、８，１９２個の３２ビットキャッシュエントリを備えた基礎キャッシュテーブルを用いることが出来る。各１０ビットＲＧＢ値が３ビットだけ精度低下されると、２１ビットタプルになる。従って、現行カラーパレットに対して極めて迅速な最小平均二乗最適化を実施することによって決定される８ビットパレットインデックス値は、迅速変換参照表を確立するために、各２１ビットタプルを用いてキャッシュすることが出来る。次に、後続する色変換により、先ず、事前変換されたパレットインデックスに関する表を探索することができる。従って、全ての色深度変換は、シェルライブラリ７２’により、各ＡＰＩ開始製図オペレーションの一部分として直接サポートされることが可能である。
新規シェルオブジェクトの例示は、シェルインターフェイスモジュールの初期化ルーチンをコールすることによって実施される。ディバイスドライバ５０のオリジナルな初期化の場合と同様に、ここではシェルオブジェクト１５２の相当する新規シェルオブジェクト例示は割当てられ、そして、初期化される。次に、ボードライブラリ７４’への初期化コールが行われる。ボードライブラリ７４’は、シェルライブラリ７２’と同様に、コントローラ１９の全てのオペレーティングモードを通じて定数であるので、ボードライブラリ７４’に対して必要なリファレンスは、個々のハードウェアインタフェースオブジェクトに対する場合と異なり、新規シェルオブジェクト１５２に接続される。次に、ボードライブラリ７４’は、オブジェクトの新規例示を作成し、そして、オブジェクトを新規シェルオブジェクト１５２のボード構造へ接続するために、ハードウェアインタフェースモジュールの各々の初期化ルーチンを順々にコールする。例えば各モジュールのＲｅｇＣｌａｓｓＨａｎｄｌｅｒ構造の内容のように色深度スイッチを通じて変化しない定数は、完全に再作成されるか、或いは、単にコピーされるか、或いは、現行コンテキスト文のオブジェクトから引用されるかのいずれかであることが可能である。例えば、グラフィックスハードウェアインタフェースオブジェクト１３８の初期化に際して、新規専用ハードウェアアクセラレータコードデータオブジェクトは作成可能である。このデータオブジェクトによって記憶されたコードは、初期化定数、または、コントローラ１９のグラフィックスサブエレメントのハードウェアアクセラレータを初期化するためにダウンロードされるシーケンサコードであっても差し支えない。従って、異なるシーケンサコードの集合および部分集合は、異なるコンテキストにおけるグラフィックスインタフェースオブジェクトによって管理可能である。１つの単一オペレーティングモード内において、アクセラレータコードがグラフィックスサブエレメントのオペレーションに際して、必要に応じて、おそらく、異なる製図コマンドの最適実行に関する加速度アルゴリズムを調節するために動的に交換可能である場合には、この能力は特別の意味を持つ。次に、ボードライブラリ初期化ルーチンは、シェルライブラリ７２に戻る。
次に、残りのオペレーティングシステムインタフェースモジュールの初期化ルーチンは、新規シェルオブジェクト１５２の初期化を完成するためにコールされる。各モジュールは、対応するインタフェースオブジェクトの新規例示を作成し、オブジェクトのために必要なあらゆる専用データ空間を作成し、その後で、当該オブジェクトを新規シェルオブジェクト１５２に接続する。特に、直接ドローオペレーティングシステムインタフェースオブジェクト１２２の初期化は、新規コンテキスト特有のＰＤｅｖｉｃｅ構造、及び、潜在的に、新規ＧＤＩ＿Ｉｎｆｏｔａｂｌｅ構造の作成を提供する。ハードウェアインタフェースの場合と同様に、これらの構造によって記憶されているデータは完全に再作成可能であり、或いは、現行コンテキストの対応する構造からのデータは、新規構造を初期化するために用いることが出来る。ただし、新規ＰＤｅｖｉｃｅ構造におけるデータは、新規コンテキストの色深度を定義するために、明確に修正される。同様に、ＧＤＩ＿Ｉｎｆｏｔａｂｌｅの画素深度フィールドは、新規色深度を反映するために、同様に修正される。それ以降はシェルライブラリ７２’によって管理されるこれら２つの新規構造に対するポインタは、新規コンテキストのシェルオブジェクト１５２と論理的に対応付けられる。
従って、当該シェルオブジェクト１５０によって表される現行コンテキストと論理的に異なるコンテキストを定義するために、オペレーティングシステム及びハードウェアインタフェースオブジェクト両方の完全な補集合が作成される。次に、実行は、シェルライブラリ７２’からシェルオブジェクト１５０に戻る。
次に、シェルオブジェクト１５０は、新規コンテキストを実現するために、ボードライブラリ７２’にコールを発信する２００。好ましい実施例においてはコントローラ１９の所望オペレーティングモードに関する所望色深度及び空間解像度を含むシェルオブジェクト１５０は、新規コンテキストの特性を識別するために十分なオペランドを提供する。これに応答して、シェルライブラリ７２’は、シェルオブジェクトを選択するために、例えばシェルオブジェクト１５２のような所望の新規コンテキストに対応するコンテキストプール１４８を探索する。
次に、コンテキストスイッチ（切換え）を実際に実施するための準備に際して、シェルライブラリ７２’は、「モード変更直前」オペランドを有するモード設定コールをモード設定２０６に参加するはずの各インタフェースオブジェクトへ発信する。以前と同様に、参加するインタフェースオブジェクトの各々は、モードスイッチばかりでなくコンテキストスイッチにおいてもあらゆる状態関連情報が一貫して持続することを保証するために、これらの情報を対応する専用データスペースに保管する。
参加インタフェースオブジェクトの最後のオブジェクトからの復帰に際して、シェルライブラリ７２’は、現行コンテキストを定義するシェルオブジェクトとして新規シェルオブジェクト１５２をインストールする。同時に、シェルライブラリ７２’は、ＰＤｅｖｉｃｅ構造、及び、ディバイスドライバ５０への次のＡＰＩコールにおいてオペレーティングシステム層によって参照されるはずの構造としてシェルオブジェクト１５２と論理的に関連したＧＤＩ＿Ｉｎｆｏｔａｂｌｅ構造を確立する。
次に、シェルライブラリ７２’のパージングルーチンは、モードスイッチを実行するために必要な命令を実行するためにコールされる。これらの命令の処理及び実行は、ディバイスドライバ５０によるコンテキストスイッチと関係しない１つの単純なモードスイッチを実行するために必要な処理と一貫性をもつ。
モード設定命令が一旦実行されると、シェルライブラリ７２’は、「モード変更」オペランドを有するモード設定コールを各参加オブジェクトへ発信する。以前の場合と同様に、各オブジェクトは、例えば、新規シーケンサコードをグラフィックスアクセラレータサブエレメントへダウンロードするように、コントローラ１９の新規オペレーティングモードを実行またはサポートするために必要な任意のオブジェクト特有のルーチンを実行可能である。
最後に、シェルライブラリ７２’は、「モード変更完了」オペランドを有する各参加オブジェクトにモード設定コールを発信する。これに応答して、各参加オブジェクトは、例えば、ディスプレイバッファ２０における記憶装置の使用を再割当てし、そして、ディスプレイ３２上にハードウェアカーソルの位置を確立することを含むコントローラ１９の作動環境を確立するために実行する。更に、フォールスクリーンリフレシャを要求するために、オペレーティングシステムオブジェクト１２８を介して、コールが行われる。これに応答して、オペレーティングシステム核５６は、ディスプレイ３２上に見えるビットマップへポインタ基準を提供するディバイスドライバ５０への一連のコールを調節する。ディバイスドライバ５０を介して各ビットマップが処理されるにつれて、あらゆる必要な色深度変換が、シェルライブラリ７２’によって適切に実施される。
最後の参加オブジェクトからの復帰に際して、シェルライブラリ７２’は、シェルオブジェクト１５２を効果的に介してオペレーティングシステム層５４へ戻る。従って、ディバイスドライバ５０は、アプリケーション６０又はオペレーティングシステム層５４から実質的に独立し、そして、これらの関連参加なしに、モードスイッチ及びコンテキストスイッチの両方を完了する。
ＶＩ．操作状態の終結
図７に全体的に示すように、最後に、本発明は、ディバイスドライバ５０のオペレーションを終結させる過程を手お経する。詳細には、例えばＷｉｎｄｏｗｓ’９５TMのように、オペレーティングシステム核５６の具体化例は、オペレーティングシステム核５６の終結に際してコンピュータシステム１０内の各ディバイスドライバへ発信される標準コールとしてシャットダウンＡＰＩコールを提供する。シャットダウンＡＰＩコールを受信すると、例えばシェルオブジェクト１５２のような、現在活動中のコンテキストのシェルオブジェクトは、継続して受信したＡＰＩコールの受入れを、オペレーティングシステムインターフェイスモジュールによって終結させることにより２２２、ディバイスドライバ５０によってこれ以上の一切のＡＰＩコールの処理を作動不可能にするように作動する。従って、次に、ディバイスドライバ５０は、整然とした方法により、予期しないＡＰＩコールの受信によって妨害されることなしに、シャットダウンを実施することができる。
次に、ｍｏｄｅｓ．ｄｍｍ構成コンフィギュレーションファイルのデフォルトセクションは、シェルライブラリ７２のパージングルーチンによって読取られ、そして、実行される。このデフォルトセクションによって提供される命令は、コントローラ１９に関してデフォルトオペレーティングモードを設定するために２２４用いられる。このようにして、コントローラ１９は、オペレーティングシステム核５６のシャットダウンに続いて使用される可能性に関して適切であるような公知の安定した状態に設定される。
次に、シェルライブラリ７２’は、ディバイスドライバ５０のインタフェースオブジェクト及びモジュールによって用いられているシステムメモリを解放するように作動する。詳細には、シェルライブラリ７２’は、ディバイスドライバ５０の現在の各コンテキストを識別するために作動する。識別された各コンテキスト２２８に関して、シェルライブラリ７２’は、特定のコンテキスト２３０に特有の各ハードウェアインターフェイスオブジェクトを順次解放するために、ボードライブラリ７４’をコールする。結果としてボードライブラリ７４’は、識別されたコンテキストのシェルオブジェクトに対応する各ハードウェアインタフェースオブジェクトをコールする。ハードウェアインターフェイスモジュールと対応する最後のオブジェクトを解放した状態で、オブジェクト及びモジュールの両方に対応したメモリスペースが解放される。いったん、全てのコンテキストに関するハードウェアインタフェースオブジェクトの全てが一旦解放されると、ボードライブラリ７４’は、それ自体の記憶装置２３２を解放するために、再びコールされる。
シェルライブラリ７２’は、オブジェクト及び対応するモジュールに対応するメモリスペースを解放するために、現在の各コンテキストに関する各々のオペレーティングシステムインタフェースオブジェクト２３４をコールする。ディバイスドライバ５０の現行コンテキストを定義するシェルオブジェクトも同様に解放される。次に、シェルライブラリ７２’は、対応する記憶装置を効果的に解放して終結し２３６、そして、オペレーティングシステム層５４の終結を継続するために、実行がオペレーティングシステム核５６へ戻る。
Ｖ．仮想化されたドライバオペレーション
好ましいＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ’９５環境においては、いわゆるＤｏｓ−Ｂｏｘ保護された実行空間において実行中の遺産アプリケーションをサポートすることが必要である。本発明の好ましい具体化に関連して保護されている実行が、フルスクリーン又はウィンドウモードのいずれかにおいて提供される。遺産アプリケーションは、フルスクリーンモードにおけるコントローラ１９に対して直接アクセスすること、及び、プログラムすることが可能である。ウィンドウモードにおいて、遺産アプリケーションによって期待されるハードウェアレジスタをエミュレートするために、一般にＶｘＤドライバと呼ばれる仮想化ディバイスドライバが提供される。他のウィンドウアプリケーションと共存および共同実行するためには、遺産アプリケーションによって動的に提供されるハードウェアプログラミングのウィンドウ関係エミュレーションが、ＶｘＤドライバによって提供されることが期待される。一般に、ＶｘＤドライバは、コントローラ１９特有の具体化の完全エミュレーションをサポートする特異モノリシックソフトウェアモジュールとして再び実現される。結果として、通常のＶｘＤドライバは、従来のディバイスドライバと関連する場合と同じ問題に遭遇する。
図８に全体的に示すように、本発明のディバイスドライバ５０のアーキテクチャは、特に仮想ディスプレイドライバ（ＶＤＤ）を含むＶｘＤドライバを実現するために直接的かつ効果的に採用することが出来る。既に述べたように、ディバイスドライバ５０は、オペレーティングシステム層５４内に従来の方法において設定されたＷｉｎｄｏｗｓ（Ｗｉｎ１６）仮想マシン（ＶＭ）２４０をサポートして作動する。Ｄｏｓ ＶＭ ２４２は、ハードウェア３０への直接アクセスを試行可能な遺産アプリケーションに関して、Ｄｏｓ−Ｂｏｘ保護された実行空間を提供する。Ｄｏｓ ＶＭ２４２の中から又はこれによって発行されるハードウェアアクセス試行の結果をトラップし、かつ、適切にエミュレートするために、当該ディバイスドライバ５０のバージョン５０’が提供される。Ｄｏｓ ＶＭ ２４２内におけるアプリケーションのウィンドウモード実行をサポートして作動中のＶＤＤ ５０’は、オペレーティングシステムの通常使用を介して、Ｉ／Ｏまたはレジスタインタフェース３０に対応するメモリスペースを選択的に確立する。このアクセストラップは、一般に、Ｄｏｓ ＶＭ ２４２がフルスクリーンモードに切り換えられるか、或いは、実行が他の仮想マシン２４０、２４４に移動する場合に解放（リリース）される。ウィンドウモードにおけるＤｏｓ ＶＭ ２４２へ実行が戻る場合、或いは、フルスクリーンモードからウィンドウモードに切り換えられた時にアクセストラップが再表明（リアサート）される。
アクセストラップがアクセス試行を検出すると、当該トラップによって獲得されたアクセス特性情報がＶＤＤ ５０’に提供される。詳細には、図９に示すように、ボードライブラリ７４３１には、論理的に接続２４６を介して、オペレーティングシステム５４により、アクセス試行情報が提供される。ＶＤＤ ５０’の構成要素は、ディスプレイドライバ５０の単一コンテキストバージョンを実現することが好ましい。ただし、Ｄｏｓ ＶＭ ２４２の下における多重コントローラ１９を適切にサポートするために、多重コンテキストは容易にサポートされることが可能である。
単一コンテキスト内において、ハードウェアインタフェースオブジェクト１３０’、１３２’、１３４’、及び、１３８’は、ハードウェアへ直接アクセスしようとする連続試行に基づくディスプレイの意図的状態の表現を維持するように、アクセス特性データを記憶するために作動する。ハードウェアインタフェースオブジェクトと対応するＲｅｇｃｌａｓｓＭａｐ構造は、ハードウェアサブエレメントの各クラスに対応する状態情報に関する記憶空間へのポインタを用いて増補されることが好ましい。同様に、ハードウェアインタフェースオブジェクトは、意図したスクリーンの外観の適切な表現のディスプレイを生じさせるために、Ｏ／Ｓオブジェクト１２８’の支援によってオペレーティングシステムコールを生成するエミュレーションルーチンを提供する。これらのコールは、オペレーティングシステム層５４に適用され、その結果として、ディスプレイドライバ５４へ適宜ルートされる。フルスクリーンモードへのスイッチに際して、ハードウェアインタフェースオブジェクトによって維持されるディスプレイ状態は、状態データをレジスタインターフェイス３０へ適用することによって、意図したディスプレイ状態を確立するために直接使用することが可能である。
ディバイスドライバ５０’のパーザー（構文解析系）ルーチンは、アクセス特性情報を分析するために、逆に効果的に使用れる。アクセストラップは、暗黙裡におけるクラストラップハンドラへのアドレス割当によって、ディバイスクラスへのアクセス試行を特徴付けるために役立つことが好ましい。従って、クラス、アドレス、及び、アクセスを備えた値は、トラップハンドラによって収集され、そして、逆パーザー（構文解析系）ルーチンに提供される。従って、トラップされた各アクセス試行により、アクセス関連データは、対応するＲｅｇＣｌａｓｓＭａｐ識別された記憶装置に記憶される。同様に、逆パーザー（構文解析系）は、ｍｏｄｅｓ．ｄｍｍファイルに記憶されているクラスレジスタ命令から究極的に決定されたレジスタ定義に対する分析を実施する。分析結果は、記入されることを意図したレジスタがインデックスレジスタであるか、又は、他の管理機能レジスタであるか、或いは、データレジスタであるかの論理的判定である。意図されたレジスタがインデックスレジスタ又は他の管理機能レジスタである場合には、その結果としての状態変化が記録される。意図されたレジスタがデータレジスタである場合には、レジスタの新規状態が記録され、その後で、いくらかのエミュレーションが必要かどうかに関して判定が行われる。記入中の特定レジスタに応じて、一切のエミュレーションを必要としないか、或いは、フルインデックス及びデータアクセスオペレーションが実施されることもあり得る。
従って、実質的には、同一ハードウェア及びオペレーティングシステムインタフェースオブジェクト定義が用いられることが好ましく、そして、更に、カプセル封入されたハードウェアインターフェイスモジュールによって実現されるディスプレイ特性エミュレーションルーチンの中から選択するためには、異なるディスプレイ特性をサポートする複数の機能の中から選択する場合と同一の方法を用いても差し支えない。パーザー（構文解析系）ルーチンが識別可能なモード集合を検出した場合には、既に説明したようにモード設定オペレーションを実施するために、Ｏ／Ｓオブジェクト１２８’を介してシェルオブジェクト１２６’がコールされても差し支えない。オペレーティングシステムオブジェクト１２０’、１２２’、１２６’によって実現される実質的な線形コールシーケンスは、直接的に作動可能化される。従って、オペレーティングシステムインタフェースオブジェクトと残りのＶＤＤ ５０’との間の機能コール関係は、ディバイスドライバ５０の場合と同じである。
Ｖ．結論
以上のように、複雑かつ多機能的な周辺コントローラ並びに仮想ディバイスドライバのサポートに適した高度に最適化されたディバイスドライバアーキテクチャについて説明した。ここに説明したディバイスドライバのアーキテクチャは、サブエレメント別に詳述する方式に基づいてハードウェアから直接決定されることが好ましい方法において周辺コントローラのハードウェアコンフィギュレーションに明確にマッチするように、ロードタイムにおいて当該ディバイスドライバの動的コンフィギュレーションを直接サポートし、特有のサブエレメント設計に従ってモジュール変更の機能的分離を本質的にサポートするモジュール式アーキテクチャを採用し、コントローラの作動状態のモードスイッチを実施するための効率的なメカニズムを提供し、モードスイッチの動作を選択的に用いた独立コンテキストのサポートを介して、モードスイッチから独立した持続性データのメンテナンス及び管理を実施するための効率的なメカニズムを提供し、ビデオディスプレイコントローラアプリケーションにおいて色深度変換の効率的な管理を提供する。更に、アーキテクチャはモジュール式であって複雑であるにも拘わらず、モジュール間のサポートされる相互作動的関係は、オペレーティングシステムＡＰＩコールを仮想化および実現するために実質的に線形化されたコールシーケンスを作動可能化する。
本発明の好ましい実施例について既に説明した観点から、開示された実施例の多くの修正及び変形は、当該技術分野における習熟者によって容易に察知可能なはずである。従って、本発明が、添付されている請求の範囲内において、以上に詳細に述べられた場合とは異なって実現可能であることが理解されるはずである。

Claims (7)

1. 該コンピュータシステム上で実行されるオペレーティングシステムのオペレーティングシステム層とは実質的に独立して、コンピュータシステムの記憶空間内のオペレーティングシステムインターフェースオブジェクトの管理を提供するディバイスドライバであって、
   該ディバイスドライバは、
   複数のオペレーティングシステムインターフェースオブジェクトを含む上位インターフェース層であって、該上位インターフェース層は、該オペレーティングシステムからコールを受信するように結合されており、該複数のオペレーティングシステムインターフェースオブジェクトのそれぞれは、対応するコンテキスト特有データ空間を含む、上位インターフェース層と、
   複数のハードウェアインターフェースオブジェクトを含む下位インターフェース層であって、該下位インターフェース層は、該上位インターフェース層に結合されており、該複数のハードウェアインターフェースオブジェクトのそれぞれは、プログラム可能なコントローラ上のサブエレメントの群のうちの１つのサブエレメントに特有な１セットの動作をサポートする、下位インターフェース層と、
   シェルライブラリを含むディバイスドライバマネージャであって、該ディバイスドライバマネージャは、該上位インターフェース層に結合されており、かつ、該下位インターフェース層に結合されている、ディバイスドライバマネージャと
   を備え、
   該ディバイスドライバマネージャは、
   該対応する複数のオペレーティングシステムインターフェースオブジェクトの複数のコンテキスト特有データ空間を管理し、
   該オペレーティングシステムからのファンクションコールに応答して、該オペレーティングシステムからの関与とは独立して、該ディバイスドライバの新しいオペレーティングコンテキストであって、該複数のオペレーティングシステムインターフェースオブジェクトおよび該複数のハードウェアインターフェースオブジェクトから構成される新しいオペレーティングコンテキストを作成し、
   該オペレーティングシステムからの関与とは独立して、該ディバイスドライバの第１のオペレーティングコンテキストから第２のオペレーティングコンテキストへのスイッチングを制御し、
   該ディバイスドライバの該新しいオペレーティングコンテキストの該複数のコンテキスト特有データ空間を該対応する複数のオペレーティングシステムインタフェースオブジェクトに割り当て、
   該複数のハードウェアインターフェースオブジェクトが作成されたときに、該ディバイスドライバの該新しいオペレーティングコンテキストを処理することによって、（ｉ）対応するハードウェアインターフェースオブジェクトにおけるハードウェアインターフェース依存部分を格納し、（ｉｉ）複数のオブジェクト特有フィールドを初期化し、（ｉｉｉ）該複数のハードウェアインターフェースオブジェクトのそれぞれのプライベートデータを割り当てる、ディバイスドライバ。
2. 前記ディバイスドライバマネージャは、前記下位インターフェース層と前記シェルライブラリとに結合されているボードライブラリをさらに含む、請求項１に記載のディバイスドライバ。
3. 前記複数のオペレーティングシステムインターフェースオブジェクトのうちの少なくとも１つは、シェルオブジェクトである、請求項２に記載のディバイスドライバ。
4. 前記新しいオペレーティングコンテキストは、前記シェルオブジェクトによって作成される、請求項３に記載のディバイスドライバ。
5. 各オペレーティングコンテキストを作成することは、
   前記複数のコンテキスト特有データ空間を前記対応する複数のオペレーティングシステムインターフェースオブジェクトに割り当てることによって、前記シェルライブラリにより作成することであって、該複数のコンテキスト特有データ空間を該対応する複数のオペレーティングシステムインタフェースオブジェクトに割り当てることよって前記新しいオペレーティングコンテキストを作成するように前記シェルオブジェクトを用いることを含む作成することと、
   （ｉ）ハードウェアインターフェース依存部分を格納し、（ｉｉ）複数のオブジェクト特有フィールドを初期化し、（ｉｉｉ）前記複数のハードウェアインターフェースオブジェクトのそれぞれのデータを割り当てることによって、前記ボードライブラリにより作成することと
   を含む、請求項４に記載のディバイスドライバ。
6. 前記ディバイスドライバマネージャは、さらに、
   前記上位インターフェース層から新しいコンテキストコールを受け取ると、第１のオペレーティングコンテキストから第２のオペレーティングコンテキストへのスイッチングを制御し、
   該新しいコンテキストコールを受け取った際に、前記対応する複数のオペレーティングシステムインターフェースオブジェクトに割り当てられた前記複数のコンテキスト特有データ空間が前記シェルオブジェクトによって作成された該第２のオペレーティングコンテキストを含まない場合には、オペレーティングコンテキストを作成する、請求項５に記載のディバイスドライバ。
7. 前記シェルライブラリは、現在のコンテキストポインタを維持する、請求項６に記載のディバイスドライバ。

Images