JPH10333924A - ファイル・オブジェクトの生成をバリデーションし、ファイル・オブジェクトへのメッセージをルーチングする方法、コンピュータ・プログラム・プロダクト，およびデータ構造を記録した記憶媒体 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 階層的に関係づけられているデバイス・ドラ
イバを開発するとき余分なコードの開発をしないで済む
ようにする。 【解決手段】 各ファイル・オブジェクトはファイル・
オブジェクト・コンテキストを用意している。ドライバ
・オブジェクトのデフォルト・ハンドラは、利用可能な
コンテキスト情報に基づいて着信ＩＲＰを処理してその
ＩＲＰを適切なハンドラへ「ルーチング」するマルチプ
レクシング機能を指している。各ファイル・オブジェク
トは特定の要求を満たすためにＩＲＰハンドラによって
使用される複数のディスパッチ機能参照への参照をもっ
ている。ファイル・オブジェクト作成要求も有効性が検
査され、適切なタイプのファイル・オブジェクトだけ
が、コンテキスト情報に従って階層構造に作成されるよ
うにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明の分野はコンピュータ
・ソフトウェア・ドライバの開発に属するものである。
本発明は、ドライバのコード生成を単純化し、標準化ア
クセス・ポイントを提供するツール、ソフトウェア・フ
レームワーク、規則などに関する。より具体的には、本
発明はファイル・オブジェクト間の階層関係を作成する
ための標準化メソッド、コンピュータ・プログラム・プ
ロダクト、およびデータ構造に関する。

【０００２】

【従来の技術】あるソフトウェア・ドライバ実行可能コ
ードの実装は、異なる機能部分への複数のエントリ・ポ
イント(entry point) を含んでいる場合がある。Micros
oft(登録商標）社のWindows NT（商標）などのオペレー
ティング・システムによってロードされ、その制御下に
置かれると、特定のシステム・オブジェクトが作成さ
れ、これらは、ドライバ（ドライバ・オブジェクト）、
ドライバによってサポートされる他のコンポーネントに
よってアクセス可能な「デバイス」または特定の機能定
義（デバイス・オブジェクト）、およびコンポーネント
によって実際に使用されるドライバ機能のインスタンス
（ファイル・オブジェクトの形態になっているのが代表
的）を表している。

【０００３】Windows NTを含む、大部分のオペレーティ
ング・システムは、ドライバが単一タイプの機能を実行
し、そのドライバに関連して作成されるすべてのデバイ
ス・オブジェクトがその機能を同じように実行するもの
と暗黙に想定されている。さらに、作成されたファイル
・オブジェクトは、それがデバイス・オブジェクトの下
で作成されたものであるか、他のファイル・オブジェク
トの下で作成されたものであるかに関係なく、同じよう
な方法でサービスを受けるものと想定されている。上記
のような想定があるために、Windows NTオペレーティン
グ・システムや他の類似オペレーティング・システム
は、同じドライバ・オブジェクトを使用して作成された
すべての兄弟(sibling) デバイス・オブジェクトとすべ
てのエントリ・ポイントを共用するために、単一のドラ
イバ・オブジェクトを使用している。

【０００４】このような想定がある結果として、各ドラ
イバ開発者は、階層的に関係づけられたファイル・オブ
ジェクトが特定のルール集合に従って作成されるような
システムでは、初期ファイル・オブジェクト要求をバリ
デーションする(validate)ための特定のコードを書かな
ければならない。そのようなファイル・オブジェクト階
層の一例としては、以下で詳しく説明するドライバ接続
システム(driver connection system)がある。なお、こ
のドライバ接続システムは単なる例示であり、これに限
定されるものではなく、以下に説明されている本発明を
利用する他のシステムはいずれも、特許請求の範囲に記
載されている本発明の範囲に属するものである。

【０００５】この問題は、デバイス・ドライバを書く標
準化システムがドライバ接続システムで見られるような
使い方がされるとき、さらに悪化する。すべてのドライ
バ開発者は同じルール集合に従って書いているので、特
定のコードがファイル・オブジェクト作成を取り扱うた
めに必要になるだけでなく、標準化規則(standardized
convention) に従ってドライバを書いている各開発者に
よってなん度も繰返し開発されることになる。

【０００６】すべてのファイル・オブジェクトは同じよ
うにサービスを受けるとの基本的想定の結果として起こ
るもう１つの問題は、処理要求が特定のファイル・オブ
ジェクトの正しいハンドラへルーチング(routing) され
ることを保証することである。異なる機能をドライバに
分け与えることができ、そのような機能は、「ファイ
ル」の状態(state) を管理するためのシステムにおいて
基礎となるファイル・オブジェクトを作成し、ファイル
・ハンドル(handle)を入出力要求を方向づけるアクセス
・メカニズムとして提供する特定デバイスで、その「フ
ァイル」をオープンすることでアクセスされるので、異
なる処理要求ハンドラは、要求を受け取るように指定さ
れたファイル（およびファイル・オブジェクト）に応じ
て使用されている。同種オペレーションの想定を解消す
るためには、かかるルーチングを行う特殊なコードを書
かなければならないのが通常である。この場合も、多数
の異なる製造者が階層的に関係づけられた機能をもつド
ライバを書くことができる標準化システムでは、特殊コ
ードを初めからなん度も書かなければならないので、そ
の影響は倍増することになる。

【０００７】以上のような理由から、ファイル・オブジ
ェクトが階層的に関係づけられたシステムにおいてファ
イル・オブジェクトの作成要求をバリデーションする標
準化メカニズムと、処理要求を与えられたファイル・オ
ブジェクトの正しいハンドラへルーチングする方法とが
要望されている。

【０００８】

【発明が解決しようとする課題】本発明の目的は、多数
のサード・パーティ・ソフトウェア・ドライバ開発者に
よって使用できるシステム・デバイス・オブジェクトと
ファイル・オブジェクトに置かれていて、参照によって
アクセス可能なコンテキスト情報に基づいてファイル・
オブジェクト作成要求をバリデーションするための標準
化メカニズムを提供することである。

【０００９】本発明の別の目的は、処理要求を標準化さ
れた方法で与えられたファイル・オブジェクトの適切な
ハンドラへルーチングし、多数のサード・パーティ開発
者による相互操作デバイス・ドライバの開発を容易化す
ることである。

【００１０】本発明のさらに別の目的は、ソフトウェア
・ドライバを開発するためのコーディング作業量を軽減
化し、処理要求を標準化された方法で処理できるドライ
バの開発を支援する、サード・パーティ・ドライバ開発
者のためのフレームワークを提供することである。

【００１１】本発明のその他の目的および利点は以下の
説明に記載されているが、その一部はその説明から理解
されるものと、本発明を実施することにより知得し得る
ものとがある。本発明の目的と利点は、請求の範囲に個
々に記載されているインストリューメント(instrument)
の手段および組合せにより実現し、得られるものであ
る。

【００１２】

【課題を解決するための手段】上記目的を達成するため
に、また、以下に実施の形態として示され、以下に広い
意味で説明されている本発明によれば、ファイル・オブ
ジェクトの作成とファイル・オブジェクトへのメッセー
ジのルーチングをバリデーションする方法、コンピュー
タ・プログラム・プロダクト、およびデータ構造が提供
されている。すべてのサード・パーティ・ソフトウェア
・ドライバ開発者は標準化されたデータ構造に従って、
コーディングするためのシステム・レベルの規則が確立
されているので、ソフトウェア・ドライバの開発が容易
化され、同一ドライバ内に異種タイプの機能を置くこ
と、バリデーションされたファイル・オブジェクト作成
を通して機能を階層的に関係づけること、処理メッセー
ジを正しいハンドラ・ルーチンへ転送することが容易化
されている。

【００１３】本発明は複数の要求処理マルチプレクシン
グ機能を意図し、各々は受信されたメッセージのタイプ
（作成、入出力制御、クローズなど）に応じてドライバ
・オブジェクトから参照されるようになっている。これ
らのマルチプレクシング機能はサード・パーティ開発者
によって開発されるのではなく、システム開発者や他の
エンティティによってシステムの一部として用意されて
いる。ドライバ開発者は標準マルチプレクシング機能を
利用すると、確立された規則に従い、事前定義のデータ
構造を利用するソフトウェア・ドライバを書くことがで
きるという利点が得られる。

【００１４】本発明によれば、デバイス・オブジェクト
とファイル・オブジェクト内のプライベート(private)
記憶エリアは、サード・パーティ・ドライバ開発者によ
って書かれた事前定義のデータ構造を参照するために使
用される。ドライバ開発者はデータ構造を作成すると、
そこにデータを「入れる(fill)」ことになり、この中に
は、特定のファイル・オブジェクト・タイプとメッセー
ジ・タイプに必要とされる特定のメッセージ・ハンドラ
を書くことが含まれるが、ファイル・オブジェクト作成
をバリデーションするためのコードや着信メッセージを
正しいメッセージ・ハンドラ機能へルーチングするため
のコードは一切書く必要がない。バリデーションとルー
チングの機能はすでに用意されているマルチプレクシン
グ・ディスパッチ機能の中に入っている。

【００１５】例えば、デバイス・オブジェクトのプライ
ベート・データ・エリアは有効(valid) ファイル・オブ
ジェクト・タイプのテーブルと、対応するタイプのファ
イル・オブジェクトを作成する適切な作成ハンドラを指
すポインタとを含んでいるバリデーション(validation)
・テーブルのデータ構造をポインタまたは他の手段を通
して参照する。作成メッセージが作成マルチプレクシン
グ・ディスパッチ機能によって受信されると、バリデー
ション・テーブルのデータ構造がアクセスされ、要求の
有効性が判断され、有効であれば、正しい作成ハンドラ
がアクセスされる。

【００１６】そのメッセージが「親」ファイル・オブジ
ェクトが存在することを示していれば、作成マルチプレ
クシング・ディスパッチ機能は別のデータ構造への参照
を得るために親ファイル・オブジェクトのプライベート
・データ・エリアをアクセスする。ファイル・オブジェ
クト・データ構造はその特定ファイル・オブジェクトの
すべての適切なメッセージ・ハンドラを指すポインタを
含んでいる。

【００１７】作成メッセージ・ハンドラの場合には、有
効ファイル・オブジェクトと、対応するタイプのファイ
ル・オブジェクトを作成する適切な作成ハンドラを指す
ポインタとを含んでいるバリデーション・テーブルのデ
ータ構造への参照がポインタまたは他の手段を通して行
なわれる。作成メッセージが作成マルチプレクシング・
ディスパッチ機能によって受信されると、バリデーショ
ン・テーブルのデータ構造がファイル・オブジェクト・
データ構造からアクセスされ、要求の有効性が判断さ
れ、有効であれば、正しい作成ハンドラがアクセスされ
る。

【００１８】ファイル・オブジェクトおよびデバイス・
オブジェクトと関連づけられたバリデーション・テーブ
ルがあるために、どの作成要求またはメッセージも作成
マルチプレクシング・ディスパッチ機能によってバリデ
ーションしてから、適切な作成ハンドラへ送ることがで
きる。無効なメッセージが受信されると、作成マルチプ
レクシング・ディスパッチ機能はエラー・ステータスを
送り返し、要求を破棄する。この場合も、ドライバ開発
者はバリデーション・コードを書くことから解放され、
対応するデータ構造内のファイル・オブジェクトの有効
なタイプを、比較のために使用されるインデックス範囲
または実際のタイプ・ストリングによって知らせるだけ
で済む。

【００１９】各ファイル・オブジェクト・データ構造
は、前述したように、その特定ファイル・オブジェクト
に関係するメッセージ・ハンドラへの参照も各メッセー
ジ・タイプ別に含んでいる。このようにすると、特定の
メッセージ・タイプのマルチプレクシング・ディスパッ
チ機能はメッセージを与えられたファイル・オブジェク
トの正しいハンドラへルーチングすることができる。こ
の場合も、ドライバ開発者はルーチング・コードを書く
必要がなく、マルチプレクシング・ディスパッチ機能と
ファイル・オブジェクト・データ構造を使用して適切な
メッセージ・ハンドラを参照するだけで済む。

【００２０】本発明の上記およびその他の目的と特徴は
以下の説明および請求の範囲に詳しく記載されている通
りであるが、以下に説明する本発明を実施することによ
って知得することも可能である。

【００２１】本発明の上記およびその他の利点と目的が
どのようにして得られるかという方法を示すために、以
下では、添付図面に図示されている具体的実施の形態を
参照して、以上で簡単に説明してきた本発明を詳しく説
明することにする。添付図面は本発明の代表的な実施の
形態を示したにずぎず、従って、本発明の範囲を限定す
るものではないとの了解の下で、以下、添付図面を使用
しながら本発明をもっと具体的にかつ詳しく記述し説明
することにする。

【００２２】

【発明の実施の形態】本明細書で用いられている「ユー
ザ・モード(user mode) 」という用語は、ユーザが書い
たプログラムの大部分が実行されるときの、オペレーテ
ィング・システムにおける動作レベルのことである。ユ
ーザ・モードの動作レベルはセキュリティ・レベルが最
も高く、あるアプリケーション・プログラムまたはプロ
セスが別のアプリケーション・プログラムまたはプロセ
スに干渉するのを防止するために大量のオーバヘッドが
消費されるのが代表的である。さらに、システム・リソ
ースへのアクセスは特定のインタフェースを通して厳格
に制御され、実行優先度は最低ではないとしても、最低
優先度の１つであるのが一般である。

【００２３】本明細書で用いられている「カーネル・モ
ード(kernel mode) 」という用語はユーザ・モードの動
作モードよりも制約が非常に少ない、オペレーティング
・システムにおける動作レベルのことである。カーネル
・モードのプログラムまたはプロセスの例としては、ハ
ードウェア・コンポーネントを制御するソフトウェア・
ドライバ(software driver) を含む。代表例として、カ
ーネル・モードのプログラムはパフォーマンスに影響さ
れやすく、従って、動作上のオーバヘッドはユーザ・モ
ードのプログラムよりも少なくなっている。さらに、ハ
ードウェアや多くのシステム・リソースへのアクセスは
無制約であるか、あるいはユーザ・モードのプログラム
の場合よりも制約がはるかに少なくなっている。多くの
場合、カーネル・モードで実行されるプログラム・コー
ドは、規則(convention)に対するプログラマの規律正し
さと準拠とを信頼して、システムが良好に動作するよう
にする（例えば、別のプログラムのアドレス空間を破壊
しないようにする）。カーネル・モードを表わす別の用
語として、「トラステッド(trusted) 」コードがある。

【００２４】本明細書で用いられている「ドライバ(dri
ver)」という用語はカーネル・モードで実行されるのが
代表的である、ソフトウェア・ドライバ・プログラムの
ことである。ドライバという用語は、オペレーティング
・システム上にロードされる実際の実行可能プログラム
またはある種の機能を分け与えるプログラム部分を意味
する場合もある。ドライバは、多くの場合、ある形態の
ハードウェアと関連づけられているが、必ずしもそうで
ある必要はない。

【００２５】本明細書で用いられている「フィルタ(fil
ter)」という用語はソフトウェア・ドライバ内に置かれ
ている機能部分のことであり、この中には、ドライバ自
体も含まれ、そこでは、接続ポイントがフィルタを通し
てデータを送信するために公開されている。例えば、ソ
フトウェア・ドライバはいくつかの異なるフィルタをサ
ポートする場合もあれば、１つの単一機能をもっている
場合もある。さらに、内部的には１つに接続され、外部
的には入出力用に接続ポイントを公開している異なるド
ライバからの複数のフィルタは単一フィルタとして集合
的に参照される場合もある。また、もっと総称的な意味
では、フィルタという用語は、伸張(decompression) な
どのように、それがカーネル・モードで実行されるソフ
トウェア・ドライバ・フィルタで起こるか、ユーザ・モ
ードで実行される別のプログラム・コードで起こるかに
関係なく、実行されるオペレーションを意味する場合も
ある。

【００２６】本明細書で用いられている「ドライバ・オ
ブジェクト(driver object) 」という用語は、ソフトウ
ェア・ドライバを管理し、これをシステム・リソースと
して知らせるオペレーティング・システムによって定義
されているオペレーティング・システムのエンティティ
のことである。

【００２７】本明細書で用いられている「デバイス・オ
ブジェクト(device object) 」という用語はシステムに
よって定義されたシステム・レベルのエンティティのこ
とであり、これは利用が可能であるドライバの機能の一
部をシステム・リソースとして知らせ、ドライバの機能
と他のシステム・コンポーネントが利用できるかどうか
を定義している。ドライバ・オブジェクトとデバイス・
オブジェクトはどちらも、代表的にドライバ・ソフトウ
ェアのロード時と初期化時に作成される。

【００２８】本明細書で用いられている「ファイル・オ
ブジェクト(file object) 」という用語は、デバイス・
オブジェクトによって指定されたリソースの呼出しを管
理するオペレーティング・システムのエンティティのこ
とであり、これはオペレーティング・システムによって
定義されている。ファイル・オブジェクトはドライバ・
オブジェクトの使用状況に関するコンテキストを提供す
る。さらに、ファイル・オブジェクトは、以前のファイ
ル・オブジェクトが新しいファイル・オブジェクトの作
成時に「親」と指定されていれば、別のファイル・オブ
ジェクトと階層的に関係づけることが可能である。ファ
イル・オブジェクトは、代表的にデータ・ストリーム上
に操作するすべての入出力オペレーションの管理に使用
される。

【００２９】本明細書で用いられている「データ(dat
a)」という用語は、相互接続されたカーネル・モードの
フィルタを通して処理される一切の情報のことである。
そのようなデータは、ビデオ、オーディオ、テキスト、
ＭＩＤＩなどを表すメディア・データを含むが、他のア
プリケーションの場合には制御情報やパラメータも含ん
でいる場合がある。例えば、カーネル・モード・フィル
タ・グラフはプロセス制御オペレーションで使用される
ことがあるが、そこでは、異なるフィルタ間で受け渡し
される制御情報はマシン類をアクチュエートする制御信
号を創り出すために使用されている。メディア処理シス
テムの例が示されているが、他のアプリケーションも、
本明細書に説明されている相互接続カーネル・モード・
フィルタのシステムから、同じような方法で利点を得る
ことが可能である。

【００３０】本明細書では、本発明の説明は、Microsof
t(登録商標）社から提供されているWindows NT（商標）
オペレーティング・システムのコンテキスト内で記載さ
れている。さらに、本明細書に説明されている好適実施
の形態を理解するためには、Windows NTの入出力アーキ
テクチャの知識が前提になっている。入出力システムお
よび NT オペレーティング・システム全般について解説
した好適書としては、Helen Custer著「Windows NTの内
部(Inside Windows NT) 」(Microsoft Press発行）があ
るが、本書は引用により本明細書の一部を構成するもの
である。

【００３１】ドライバおよびファイル・オブジェクト、
デバイス・オブジェクト、ドライバ・オブジェクトなど
のシステム・エンティティの以下の説明では、Windows
NTオペレーティング・システム上でこれらがどのような
働き方をするかが解説されているが、この分野の精通者
ならば理解されるように、本発明は、類似のコンポーネ
ントを持つ他のオペレーティング・システム上で実装す
ることが可能であり、これらのオペレーティング・シス
テムが同じ用語を使用しているかどうかとは無関係であ
る。例えば、別のオペレーティング・システムがファイ
ル・オブジェクトとして動作するエンティティを持って
いれば、そのエンティティはその実際の名称に関係な
く、ファイル・オブジェクトと解釈することができる。

【００３２】まず、図１を参照して説明すると、図示の
システム例は、サウンド・データのストリームをディス
ク・ドライブから読み取り、そのサウンド・データをレ
ンダリング(rendering) して、従来のモデルに従ってス
ピーカから聞こえるようにするものである。あるデータ
量はハード・ドライブ２０にストアされるが、これはデ
ィジタル化されたサウンド・サンプルの形態でサウンド
を表している。ほかにも、サウンド・データ・ストリー
ムのソースとしては、電話回線を利用して送られてくる
ディジタル化情報、ネットワークや他の通信パケットか
らのディジタル化情報、この分野で公知の他のソースが
考えられる。データ・ストリームはディジタル化サンプ
ルから構成され、これらのサンプルはデータ・フォーマ
ットと規則によって、または各サンプルに付加される明
示的タイムスタンプ情報によってタイム・インターバル
情報が関連づけられている。カーネル・モードのディス
ク・ドライバ２２はディスク・ドライブ・ハードウェア
２０と相互作用し、ユーザ・モードのリーダ(reader)プ
ログラム・コンポーネント２４の制御下に置かれてい
る。制御エージェント(controlling agent) ２６はサウ
ンド・データのレンダリングを行うために異なるコンポ
ーネントを管理するが、動的グラフ作成機能(dynamic g
raph building capability) を備えている場合は、異な
るソフトウェア・コンポーネントが動的に割当てられ
て、エンド・ユーザの指定に従ってカスタム・フィルタ
リングまたは他の処理経路を提供できるようにする。

【００３３】リーダ・コンポーネント２４はオペレーテ
ィング・システムの標準入出力制御インタフェースを使
用してディスク・ドライバ２２と相互作用し、圧縮サウ
ンド・データをディスク・ドライブ２０から読み取っ
て、ユーザ・モード・プロセスのアドレス空間(address
space) の一部としてユーザ・モードで割当てたバッフ
ァに入れる働きをする。次に、デコンプレッサ(decompr
essor)・コンポーネント２８は圧縮データを処理に適し
た伸張(decompressed)フォーマットに伸張する。図示の
ように、このステップ全体は、付随の低優先度の、プロ
セス動作(processbehavior)安全メカニズムを使用して
ユーザ・モードで実行される。

【００３４】効果フィルタ(effects filter)３０はデー
タに操作を加えて、ある種の特殊効果が得られるように
し、カーネル・モードで動作する附属の効果フィルタ３
２をもっている。さらに、効果プロセッサ３４が存在す
る場合もあれば、効果フィルタ全体が実際のハードウェ
ア・プロセッサをエミュレートするソフトウェアで動作
する場合もある。効果フィルタ３２をアクセスするため
には、効果コンポーネント３０はシステム入出力制御メ
カニズムを使用して、データと制御を効果フィルタに転
送する。この場合も、カーネル・モード／ユーザ・モー
ド境界を交差して、この遷移が行われる。

【００３５】効果フィルタ３２は効果プロセッサ３４を
制御し、必要または望ましいとされる特殊効果がそのデ
ータ上に作られるようにする。これは、効果コンポーネ
ント３０から全データをコピーし、そのコピーを効果フ
ィルタ３２に、実際のシステム構成によっては、再度効
果プロセッサ３４にも移すことにより行われる。多くの
ソフトウェア効果コンポーネントはハードウェア・プロ
セッサが関連づけられているが、他のコンポーネント
は、ホスト・プロセッサ上で実行されるシステム・ソフ
トウェア内で完全に機能している。

【００３６】効果コンポーネント３０の処理の完了時に
コントロールとデータがユーザ・モードに戻されると、
これは、次に、サウンド・レンダリング・コンポーネン
ト３６に転送される。サウンド・レンダリング・コンポ
ーネント３６はコントロールとデータをサウンド・レン
ダリング・ドライバ３８に転送し、これを受けてサウン
ド・レンダリング・ドライバは、処理され、フィルタリ
ングされたデータをスピーカ４２からのサウンドとして
レンダリングするようにサウンド・カード４０を制御す
る。以上から容易に理解されるように、ユーザ・モード
とカーネル・モード間の転送は多種類存在するために、
サウンド・データのレンダリングを非効率化している。
連続するサウンドまたはビデオ・ストリームのように、
マルチメディア・データはタイミングに影響されやすい
性質のため、これらの非効率性とコントロールの遷移を
少なくすると共に、異なるバッファ間でなん度もデータ
をコピーすることを少なくすると、好都合である。

【００３７】本明細書で用いられている本発明の一実施
の形態は、Windows NTオペレーティング・システム・ア
ーキテクチャ上で提供されるサービスから構成されてい
る。このサービスはシステムのユーザがアクセスする、
いくつかの異なるソフトウェア・コンポーネントに分割
されている。第１は、ユーザ・モードのＡＰＩであり、
これは、接続ピン・インスタンスと、クロック・メカニ
ズムやバッファ割当てメカニズムなどの特定の機能を表
している他のファイル・オブジェクトとを作成するため
のルーチンを含んでいる。ほかにも、もっと重要なもの
として、ドライバ開発者が標準化アーキテクチャに従う
ドライバを作成するのを支援するルーチンとデータ構造
が完備されている。システムに用意されているこれらの
機能を利用すると、異なるドライバ開発者は特定のアー
キテクチャに準拠して相互に相互作用するコンプライア
ント・ドライバを作成することができる。ユーザ・モー
ド・エージェントはＮＴエグゼクティブおよび入出力マ
ネージャのシステム・サービスと通信する、ユーザ・モ
ードで実行中の環境サブシステムを通してコンプライア
ント・ドライバと通信する。これは、他のすべての入出
力に対する同じ標準入出力メカニズムであり、好適実施
の形態の本実装では、既存のシステム・サービスを可能
な限り利用するようになっている。

【００３８】本発明を利用する図１のシステムのアーキ
テクチャは図２に示すようになっている。制御エージェ
ント４４は知らされているドライバに照会し、データ・
フォーマットと接続フォーマットに従って相互接続を行
い、レンダリングを完全にカーネル・モードで行うよう
にする。さらに、制御エージェントは重要なイベントの
通知を受けるので、必要に応じて制御を行うことができ
る。このようなイベントの例としては、処理の終了、デ
ータ・スターベーション事態などを含む。

【００３９】この構成では、サウンド・データは前述し
たように、ディスク・ドライバ４８によってディスク・
ドライブ４６から読み取られる。リーダ・ドライバ５０
はディスク・ドライバ４８を制御し、従来の使い方と同
じようにＮＴ層(NT layered)入出力アーキテクチャに従
ってディスク・ドライバ４８と「垂直方向」に関連づけ
られている。「垂直方向」と「水平方向」の用語は、Ｎ
Ｔ層入出力アーキテクチャの一部として現在行われてい
るドライバ接続（垂直方向）と、サード・パーティ制御
エージェントによって動的に行われる相互接続カーネル
・モード・ドライバに従う接続（水平方向）とを区別す
るために用いられている。

【００４０】リーダ・ドライバ５０は以下で説明する接
続メソッドに従ってデコンプレッサ・ドライバ５２とも
「水平方向」に相互接続され、制御エージェント４４に
よって管理されている。デコンプレッサ５２は伸張をカ
ーネル・モードで行ってから、データとコントロールを
効果フィルタ５４に引き渡す。効果フィルタは必要に応
じて効果プロセッサ５６を利用して特殊効果を適用して
からデータとコントロールをサウンド・レンダリング・
ドライバ５８に引き渡し、このドライバはサウンド・カ
ードを制御し、データをスピーカ６２からのサウンドと
してレンダリングする。図２から理解されるように、処
理をカーネル・モードのままにしておくと、ユーザ・モ
ードとカーネル・モードとの間の複数の遷移がなくな
り、処理をユーザ・モードで行うと通常起こるオーバヘ
ッド量が減少するので、効率面の利点が得られる。

【００４１】次に、図３を参照して説明する。図３は、
本発明の一実施の形態に従う相互接続ソフトウェア・ド
ライバに関係するシステム・オブジェクトの階層的性質
を示すロジック図である。ドライバ・オブジェクト６４
は、メモリにロードされるときの、実行可能ソフトウェ
ア・コード・イメージを表すために作成される。ドライ
バ・コード・イメージはドライバの機能全体を含んでお
り、ドライバ・オブジェクト６４はシステムに置かれて
いる場所、サポートされるドライバの種類などのイメー
ジに関する情報を含んでいる。

【００４２】制御エージェントによって独立にアクセス
できる機能の各タイプ別に、デバイス・オブジェクト６
６_a 〜６６_N が入出力ディレクトリ構造に作成され、こ
れらのオブジェクトは利用可能で、ユーザ・モードのク
ライアントによってアクセスされる異なる機能を表して
いる。これらは、フィルタまたは独立に利用できる他の
機能部分を表しているのが代表的である。ドライバ・オ
ブジェクト６４とデバイス・オブジェクト６６_a 〜６６
_N は囲みボックス６８で示すように、ドライバ・コード
のインストール時に作成される。

【００４３】歴史的には、デバイス・オブジェクトは物
理ハードウェアの各エレメントごとに存在する。しかる
に、最新の入出力システムの柔軟性は、デバイス・オブ
ジェクトが完全にソフトウェアで実装されたフィルタを
表すことを可能にさせている。そのため、デバイス・オ
ブジェクトは専らソフトウェアで実装されたフィルタの
各インスタンスごとに作成することが容易になってい
る。従って、ソフトウェア・フィルタは、デバイス・オ
ブジェクトで表された各インスタンスがデバイス・オブ
ジェクトと１対１の対応関係をもつように実装すること
も、単一のデバイス・オブジェクトがより伝統的な手法
に従い、各々がフィルタのクライアント・インスタンス
を表している複数のファイル・オブジェクトを管理する
ように実装することも可能になっている。

【００４４】デバイス・オブジェクト、図示の例では、
デバイス・オブジェクト６６_a 上には、ファイル・オブ
ジェクトが作成され、これはデバイス・オブジェクトで
表された機能の独立インスタンスを表している。デバイ
ス・オブジェクトはフィルタを表し、そのフィルタの複
数のインスタンスを管理するのに対し、ファイル・オブ
ジェクトは特定のエンティティによって使用される、そ
のフィルタの実際のインスタンスを表している。従っ
て、ファイル・オブジェクト７０はデバイス・オブジェ
クト６６_a によって定義されたフィルタのインスタンス
である。

【００４５】フィルタを使用するには、制御エージェン
トまたは他のユーザ・モード・クライアントは入出力デ
ィレクトリ構造内で利用可能なデバイス上でファイルを
オープンする。適切なコンテキスト情報を収めているフ
ァイル・オブジェクトが作成され、そのファイルへのハ
ンドルがユーザ・モード・クライアントに返される。フ
ァイル・オブジェクトは、作成時に「親」ファイル・オ
ブジェクトを指定することによって階層的に関係づける
ことが可能であるが、ファイル・オブジェクトはすべて
が同一デバイス・オブジェクトの子であるような、兄弟
(sibling) 関係も持っている。

【００４６】ファイル・オブジェクト内のコンテキスト
情報は、ユーザ・モード・クライアントとの入出力イン
タフェースを管理する情報、ファイル・オブジェクトが
表わしているエンティティの「状態(state) 」などから
なっている。コンテキスト情報には、システムが必要と
する情報があり、さらに、特殊な意味をもたせることが
できる、ユーザ定義可能エリアも含まれている。ユーザ
定義可能エリアの使い方の例は、下述するバリデーショ
ン(validation)とＩＲＰルーチング(routing)・メソッ
ドのインプリメーテンションの説明個所に示されてい
る。

【００４７】接続ピン・インスタンスを提供するために
は、フィルタ・インスタンスを表すファイル・オブジェ
クト７０が親として使用され、特定フィルタの接続ピン
・インスタンスを表す子ファイル・オブジェクトが作成
される。ファイル・オブジェクト７０は接続ピン・ファ
クトリの定義と可用性に関して照会されるのに対し、実
際のファイル・オブジェクトは特定のファイル・オブジ
ェクトを適切な情報コンテキストとして使用して、ピン
・ファクトリの各インスタンスごとに作成され、接続ピ
ン・インスタンスが有効に、かつ正しく作成されるよう
にする。例えば、ファイル・オブジェクト７２と７４は
ファイル・オブジェクト７０で表されたフィルタの接続
ピン・インスタンスを表し、ファイル・オブジェクト７
０と階層的に関係づけられている。それぞれファイル・
オブジェクト７２と７４で表された接続ピン・インスタ
ンスはフィルタ・インスタンス（ファイル・オブジェク
ト７０で表されている）に入ったあとで、そこから出る
データ・パスにすることができ、これは一連のチェイン
・フィルタまたは他のドライバ機能を形成するときに他
の接続ピン・インスタンスと接続するために使用でき
る。

【００４８】ピン・インスタンスがフィルタ・インスタ
ンスを表す別のファイル・オブジェクトと階層関係をも
つファイル・オブジェクトで表されて、ピン・インスタ
ンスのコンテキスト情報を提供するようにするのとまっ
たく同じように、他のファイル・オブジェクトをピン・
インスタンスと階層的に関係づけて他の機能を表すよう
にすると、正しいコンテキスト情報が得られるようにな
る。コンテキスト情報は、ピン・データ・フォーマッ
ト、通信タイプなどのように、作成時に使用される個々
のパラメータに従って、あるピン・インスタンスを他の
ピン・インスタンスと区別するために必要である。

【００４９】バッファ割当てメカニズム、タイミング・
メカニズムなどのように、個別コンテキストかユーザ・
モードのコントロールのどちらかをハンドルを通して要
求する他の操作エンティティも、ファイル・オブジェク
トで表すことができる。さらに、ファイル・オブジェク
ト（例えば、特定の接続ピン・インスタンスと関連づけ
られたバッファ割当てメカニズム）間の階層関係は、必
要ならば、子ファイル・オブジェクトの作成時に親ファ
イル・オブジェクトを指定することにより確立すること
ができる。これらの親子関係は、操作エンティティを表
すファイル・オブジェクト間の関係と構造を決定するた
めに存在する。さらに、特定タイプの「親」ファイル・
オブジェクトはある種のタイプの「子」ファイル・オブ
ジェクトだけを作ることができるので、以下で説明する
ように作成バリデーション・メカニズムが必要になる。
この場合も、このようなファイル・オブジェクトは対応
するハンドルがユーザ・モードで利用可能になってお
り、これらのハンドルはNtCreateFileなどのシステムＡ
ＰＩコールを通してクライアントに返される。

【００５０】ファイル・オブジェクトへのハンドルはカ
ーネル・モード・ドライバと通信するために、制御エー
ジェントなどのユーザ・モード・クライアントによって
使用される。ファイル・オブジェクト、デバイス・オブ
ジェクト、およびドライバ・オブジェクトの階層的チェ
インは、入出力サブシステムが階層関係をもつファイル
・オブジェクトとデバイス・オブジェクトを通ってドラ
イバ・オブジェクトまで戻り、実際のドライバ・コード
に入るエントリ・ポイント(entry point) に到達するこ
とができるようにする。このようなエントリ・ポイント
はソフトウェア・ドライバ・コードの中の機能を指す参
照（例えば、ポインタ）になっている。さらに、特定の
ファイル・オブジェクトと、ソフトウェア・ドライバ・
コードへのエントリ・ポイントをもつドライバ・オブジ
ェクトとの間のオブジェクト通路(pathway) 上にあるオ
ブジェクトの各々は、入出力サブシステムがＩＲＰを作
成するときに重要なコンテキスト情報のほかに、下述す
るルーチングおよびバリデーション・メカニズムに従っ
てＩＲＰを正しくルーチングするときに使用されるデー
タ構造への参照も提供する。

【００５１】ファイル・オブジェクトと他のシステム・
オブジェクトに対するハンドルはプロセス専用であり、
ユーザ・モード・プロセスが基礎となるオブジェクトと
通信するときの手段となる。注目すべきことは、ファイ
ル・オブジェクトなどの、基礎となる単一システム・オ
ブジェクトを参照するために複数のハンドルが作成でき
ることである。このことは、複数のアプリケーションが
ファイル・オブジェクトで表されたピン・インスタンス
に情報を供給できることを意味する。

【００５２】異なるドライバを相互接続するとき重要と
なる情報エレメントの１つとして、デバイス・オブジェ
クト・スタックの深さ(depth) パラメータがある。これ
は特定のドライバ・オブジェクトのＩＲＰスタック・ロ
ケーションを示している。このようにすると、入出力マ
ネージャを使用して、相互接続されたドライバ間で単一
のＩＲＰを使用し受け渡しできるので、ＩＲＰを別々に
作成し、それを種々の相互接続ドライバ間で送信するよ
りもパフォーマンス向上を提供できることになる。別の
方法として、各ドライバは適切な入出力マネージャのコ
ールを通して、各連続通信ごとに新しいＩＲＰを作成
し、各々の新ＩＲＰを相互接続されたドライバのチェイ
ン上の次のドライバへ送信させることも可能である。

【００５３】次に、図４〜図６を参照して説明する。図
は、異なるタイプのファイル・オブジェクト作成のバリ
デーションと適切なハンドラへの入出力要求パケット
（I/ORequest Packet：ＩＲＰ）のルーチングを可能に
するシステム・ドライバ・オブジェクト、デバイス・オ
ブジェクト、およびファイル・オブジェクトのエクステ
ンションを示している。図４は、１つまたは２つ以上の
フィルタまたは他のドライバ機能を実装している実行可
能コードを表すドライバ・オブジェクト７６を示してい
る。ドライバ・オブジェクト内では、Windows NTアーキ
テクチャはソフトウェア・ドライバ開発者が用意した作
成ハンドラへの参照を要求している。この実施の形態に
よれば、マルチプレクシング・ディスパッチ機能(multi
plexing dispatch function)７８は作成ハンドラとして
ドライバ・オブジェクト７６から参照され、メッセージ
を作成されるファイル・オブジェクトのタイプに応じて
特定の作成ハンドラへルーチングするために使用され
る。マルチプレクシング・ディスパッチ機能７８のオペ
レーションは図８に示すフローチャートを参照して以下
で説明する。

【００５４】同じように、ドライバ・オブジェクトから
の他のハンドラはマルチプレクシング・ディスパッチ機
能を示し、どのように実装するかに応じて、これらは同
じ機能にすることが可能である。言い換えれば、以下で
詳しく説明するように、各タイプの入出力ハンドラ参照
（例えば、読取り、書込み、デバイス制御など）はデバ
イス・オブジェクト内のエクステンション・データとフ
ァイル・オブジェクト内のコンテキスト情報を使用し
て、メッセージを適切なハンドラへルーチングするマル
チプレクシング・ディスパッチ機能を指している。バリ
デーション・テーブルを参照するデバイス・オブジェク
ト内のエクステンション・データは、作成オペレーショ
ンで親ファイル・オブジェクトの指定がないとき使用さ
れる。指定があれば、親ファイル・オブジェクトのコン
テキスト情報は正しいバリデーション・テーブルを示し
ている。

【００５５】図５は、ドライバ開発者によって所望によ
り利用でき、ドライバ専用情報を含んでいる特定のデバ
イス・エクステンション・エリア８２をもつドライバ・
オブジェクト８０を示している。ドライバ・オブジェク
ト８０のデバイス・エクステンション・エリア８２内の
定義されたロケーションには、ファイル・タイプ・バリ
デーション・テーブル８４と呼ばれ、ファイル・オブジ
ェクト・タイプ８６のストリング表現を含んでいるデー
タ構造への参照と、表現される各ファイル・タイプ別の
関連する作成ハンドラ８８への参照が置かれている。作
成マルチプレクシング・ディスパッチ機能はファイル・
タイプ・バリデーション・テーブル８４を使用して、作
成されるファイル・オブジェクト・タイプを検査し、そ
のあと、コントロールを適切な作成ハンドラへ引き渡
す。これについては、以下の図８の説明個所で詳しく説
明する。検査されるストリングはＩＲＰ作成要求に見出
され、ユーザ・モードのNtCreateFile関数コールと共に
使用されるファイル名ストリングから創られる。NtCrea
teFile関数コールは、ピン・インスタンスまたは他のメ
カニズムを作成するためにユーザ・モード関数セルの中
で行われる。

【００５６】図６は、ソフトウェア・ドライバ開発者が
使用するために解放されているファイル・コンテキスト
・エリア９２をもつファイル・オブジェクト９０を示し
ている。参照はファイル・コンテキスト・エリア９２か
らＩＲＰ要求ハンドラ・テーブル９４へ行われる。ＩＲ
Ｐ要求９６の異なるタイプは特定のハンドラ９８と関連
づけられ、適切なマルチプレクシング・ディスパッチ機
能はこの情報を使用して正しいハンドラにアクセスす
る。正しい作成ハンドラを決定する場合には、ファイル
・タイプ・バリデーション・テーブル１００と呼ばれる
データ構造が参照され、そこには、ファイル・オブジェ
クト・タイプ１０２のストリング表現と、表現される各
ファイル・タイプ別の関連する作成ハンドラへの参照１
０４が入っている。子ファイル・オブジェクト（つま
り、デバイス・オブジェクトではなく別のファイル・オ
ブジェクトを親としてもつファイル・オブジェクト）の
場合は、タイプはファイル・オブジェクト・タイプ１０
２内のストリングと比較されるストリングで表されてい
る。一致するものが見つかると、関連する作成ハンドラ
は、参照１０４のうち、一致したファイル・オブジェク
ト・タイプ・ストリングと関連づけられている参照を使
用してアクセスされる。一致するものが見つからなけれ
ば、要求は無効であるので、エラー表示が出されること
になる。

【００５７】次に、図７を参照して説明すると、図は作
成バリデーションとメカニズムをセットアップするため
のインストレーション・プロシージャを示している。ス
テップ１０６で、インストール・プログラムは適切なマ
ルチプレクシング・ディスパッチ機能への参照をドライ
バ・オブジェクトの中に作成する。図４に示すように、
作成ハンドラは汎用マルチプレクシング・ディスパッチ
機能を指している。同様に、ドライバ・オブジェクト７
６の中の他のすべてのハンドラ参照は、特定ハンドラと
密接な関係をもつ他の汎用(generic) マルチプレクシン
グ・ディスパッチ機能を必要に応じて指している。別の
方法として、各ハンドラ参照は同一マルチプレクシング
・ディスパッチ機能を指すことも可能であり、その場合
は、このディスパッチ機能はＩＲＰ要求を処理したあ
と、それを適切なハンドラへルーチングすることができ
る。この方法によるマルチプレクシング機能は異なる種
類の要求（例えば、作成、書込みなど）を受け付ける必
要があるため、複雑化することが避けられない。

【００５８】次に、ステップ１０８で、ソフトウェア・
ドライバ実行可能コードのインストールの一部として作
成された各デバイス・オブジェクトは、図５に示すよう
にファイル・タイプ・バリデーション・テーブル８４を
参照するように調整される。最後に、ステップ１１０
で、ＩＲＰ要求の処理は、適切なデバイス・オブジェク
ト８０から参照されたファイル・タイプ・バリデーショ
ン・テーブル８４を使用してマルチプレクシング・ディ
スパッチ機能から開始される。

【００５９】ファイル・オブジェクトが作成されると、
適切なＩＲＰディスパッチ・テーブル９４が作成され、
必要ならば、インデックスされたファイル・オブジェク
ト・タイプ・バリデーション・テーブル１００と一緒に
参照される。ファイル・オブジェクト・タイプ・バリデ
ーション・テーブルの作成は、ファイル・オブジェクト
・タイプに従って用意された作成ハンドラ内で行われ
る。データ構造が作成され、これはＩＲＰディスパッチ
・テーブル９４とファイル・オブジェクト・タイプ・バ
リデーション・テーブル１００を表しており、それを指
す参照は作成される特定ファイル・オブジェクト９０の
ファイル・コンテキスト情報９２と一緒に特定ロケーシ
ョンにストアされる。

【００６０】次に、図８を参照して説明すると、図は作
成マルチプレクシング・ディスパッチ機能のオペレーシ
ョンとそのバリデーション・メカニズムを示すフローチ
ャートであり、そこには、システム・ドライバ・オブジ
ェクト、デバイス・オブジェクト、およびファイル・オ
ブジェクトから参照されるデータ構造との相互作用も示
されている。ステップ１１２で、ユーザ・モード・プロ
セスはファイル・オブジェクトを作成する入出力要求を
送信する。この入出力作成要求はNtCreateFileのシステ
ムＡＰＩを呼び出すことによって行われる。ステップ１
１４で、入出力マネージャはドライバ・オブジェクト７
６内の参照に基づいてＩＲＰをマルチプレクシング・デ
ィスパッチ機能７８に送信する（図４参照）。

【００６１】マルチプレクシング・ディスパッチ機能７
８が作成要求のＩＲＰを受け取ると、ステップ１１６で
テストが行われ、親ファイル・オブジェクトがあるかど
うかが判断される。この判断を行うために必要な情報は
ＩＲＰ自体の中にあるが、これはユーザ・モード・プロ
セスによって元来用意されたものである。ユーザ・モー
ド・プロセスは「親」ファイル・オブジェクトを参照す
るハンドルを作成要求の一部として用意し、ＮＴシステ
ムは「親」ファイル・オブジェクトへの正しい参照をも
つＩＲＰを作成する。

【００６２】親ファイル・オブジェクトがなければ、右
へのブランチがとられ、マルチプレクシング・ディスパ
ッチ機能７８は適切なデバイス・オブジェクト８０から
のデバイス・エクステンション８２を使用して、ファイ
ル・タイプ・バリデーション・テーブル８４をステップ
１１８で参照する（図５参照）。バリデーション・テー
ブル８４を使用して、マルチプレクシング・ディスパッ
チ機能７８は要求の中のストリングをファイル・オブジ
ェクト・タイプ８６のストリングと比較することによっ
て、ステップ１２０でファイル・オブジェクト・タイプ
を検査する。

【００６３】ステップ１２２でストリングが一致してい
ると判断されると、適切な作成ハンドラがステップ１２
４でアクセスされる。一致していなければ、作成要求は
ステップ１２６で拒否される。ステップ１２４でアクセ
スされた作成ハンドラはステップ１２６でファイル・オ
ブジェクトを作成するか、あるいは作成させる。作成さ
れたファイル・オブジェクトを使用して、適切な作成ハ
ンドラは、以前に作成していたＩＲＰディスパッチ・テ
ーブル９４を指すファイル・オブジェクト参照をファイ
ル・コンテキスト９２の中に作成する。

【００６４】再びステップ１１６に戻って、親ファイル
・オブジェクトが存在するかどうかが判断される。親フ
ァイル・オブジェクトが存在するとステップ１１６で判
断され、それが作成要求に関連するＩＲＰに入っていれ
ば、マルチプレクシング・ディスパッチ機能７８は親フ
ァイル・オブジェクト９０からのファイル・コンテキス
ト９２を使用して、ステップ１３０でＩＲＰディスパッ
チ・テーブル９２を参照する（図６）。作成要求の場合
は、マルチプレクシング・ディスパッチ機能７８はステ
ップ１３２でファイル・タイプ・バリデーション・テー
ブル１００を参照する。ファイル・タイプ・バリデーシ
ョン・テーブル１００を使用して、マルチプレクシング
・ディスパッチ機能７８は、上記と同じように、要求の
中のストリングをファイル・オブジェクト・タイプ１０
２のストリングと比較することによってステップ１３３
でファイル・オブジェクト・タイプを検査する。

【００６５】ストリングが一致しているとステップ１３
４で判断されると、適切な作成ハンドラがステップ１３
８でアクセスされる。一致していなければ、作成要求は
ステップ１３６で拒否される。適切な作成ハンドラを使
用して、ファイル・オブジェクトは１４０で作成され、
作成ハンドラは新しく作成されたファイル・オブジェク
トの新しいＩＲＰディスパッチ・テーブル９４を作成
し、新しく作成されたＩＲＰディスパッチ・テーブル９
４を指す参照を新しく作成されたファイル・オブジェク
ト９０のファイル・コンテキスト・エリア９２の中にス
テップ１４２で作成する。注意すべきことは、親ファイ
ル・オブジェクトおよび有効に作成された子ファイル・
オブジェクトとの相互作用を説明するために、どちらの
場合も、図６に示す同じファイル・オブジェクト構造が
使用されていることである。どちらの場合も同じ構造が
存在するが（新しいファイル・オブジェクトが作成され
たあと）、これらはその使い方が異なり、含んでいる情
報も異なっている。

【００６６】接続ピン・インスタンスが作成されるとい
つでも、接続ピンＩＤが引き渡され、これはピン・イン
スタンスの作成を「サポート」するファイル内のピン・
ファクトリを示している。この分野の精通者ならば理解
されるように、接続ピンＩＤは、ファイル・オブジェク
トが検査されるのとまったく同じように、バリデーショ
ンテーブルでストリングとして検査することも可能であ
り、また、その実装方法もさまざまである。

【００６７】異なるドライバ間の接続を行うためには、
あるドライバがそのような相互接続をサポートしている
ことを確かめるための共通メカニズムが必要である。こ
の共通メカニズムは、接続ピン・ファクトリ機能を含む
フィルタ機能を明らかにすることを可能にするものでな
ければならない。さらに、この種のメカニズムは、ドラ
イバ開発者の柔軟性を向上するように拡張可能であるこ
とも必要である。

【００６８】コンプライアント・ドライバを定義し、機
能を明らかにすることを可能にするために本実施の形態
で選択されている１つのメカニズムは関連アイテムの
「集合」と名づけられている。これは既存の入出力通信
メカニズムと一緒に使用すると便利なメカニズムであ
る。集合は集合全体を特定するＧＵＩＤ（グローバルに
ユニークな識別子）と集合内の各機能エレメントのＲＵ
ＩＤ（相対的にユニークな識別子、例えば、集合自体内
の相対的な識別子）を持つものとして論理的に定義され
ている。集合識別子および選択されたＲＵＩＤアイテム
と一緒にオペレーションするために必要な他のデータ構
造は、フィルタ・ハンドルをパラメータとして使用して
入出力制御コールの一部として引き渡される。機能の完
全なシステムを実装するためには、少数のＩＯＣＴＬを
割当てるだけで十分である。実装されるとき、３つの異
なる種類の集合がその機能に応じて確立されるので、必
要になるＩＯＣＴＬは総計４個である。他の実装では、
集合の使い方が異なる場合がある。特定のＩＯＣＴＬ
は、選択されたエレメント（ＲＵＩＤを使用する）をな
んらかの方法で解釈または使用するように入出力制御の
ハンドラに通知する。さらに、制御フラグをＧＵＩＤお
よびＲＵＩＤと一緒に渡して、制御情報をもっと詳しく
指定することができる。

【００６９】最初の集合タイプはプロパティ集合であ
り、これはドライバ内または関連ハードウェア上に置か
れている値または設定値と一緒に使用される。そのよう
な設定値の例としては、転送レート、ボリューム・レベ
ル（音量）などがある。１つのＩＯＣＴＬがプロパティ
集合と関連づけられ、制御フラグは"get" プロパティ・
コマンドと"set" プロパティ・コマンドとを区別してい
る。このようにすると、同じデータ構造が特定のプロパ
ティを設定または取得するように使用でき、ドライバは
必要なアクションを使用されたＩＯＣＴＬに基づいて決
定することができる。正しいプロパティは、ユニークな
ＧＵＩＤとＲＵＩＤの組合せからなる集合識別子(set i
dentifier)によって特定される。

【００７０】メソッド集合は使用されるもう１つの集合
タイプであり、これはドライバによって実行できるアク
ションの集合である。メソッド集合を特定するために必
要なＩＯＣＴＬは１つだけであり、アクチュエートされ
る正しいメソッドは集合識別子のユニークなＧＵＩＤと
ＲＵＩＤの組合せによって特定される。メソッドはドラ
イバを制御するために使用され、ドライバを使用するた
めの初期化、バッファのクリアといった機能を含んでい
る。

【００７１】イベント集合は、デバイス変更通知、デー
タ・スターベーション通知などのドライバ処理や、ユー
ザ・モード・アプリケーションで使用すると便利である
集合によって定義された他の通知に関連するイベントを
管理するために使用される。２つのＩＯＣＴＬが使用さ
れ、１つは特定のイベントをイネーブルにするためのも
のであり、もう１つは特定のイベントをディスエーブル
にするためのものである。ＲＵＩＤで識別された、与え
られたイベントに必要なデータ構造は、イベントをイネ
ーブルにするか、ディスエーブルにするかに関係なく共
用することができる。

【００７２】集合を使用するには、入出力制御オペレー
ションは特定のＩＯＣＴＬおよび集合ＧＩＤ、 ＲＵＩＤ
をもつデータ構造と他の必要なデータ（例えば、制御フ
ラグ、データ構造など）を指す参照を使用して開始され
る。例えば、サウンド・カード・ドライバでボリューム
・プロパティを設定することは、入出力制御オペレーシ
ョンをプロパティ集合ＩＯＣＴＬ、集合プロパティ・オ
ペレーションを示す制御フラグ、ボリューム設定値をも
つプロパティ集合の適切なＧＵＩＤ、ボリューム・プロ
パティを示しているその集合内の特定ＲＵＩＤ、および
新しいボリューム設定値を使用することを必然的に伴な
う。

【００７３】サポートされる集合についてタイプ別に照
会するには、ヌルＧＵＩＤとサポートされる集合の列挙
を示す制御フラグとをもつ、特定の集合タイプのＩＯＣ
ＴＬ（例えば、プロパティＩＯＣＴＬ、メソッドＩＯＣ
ＴＬ、またはイベント・イネーブルＩＯＣＴＬ）が入出
力コマンドの一部として出され、サポートされる集合Ｇ
ＵＩＤのリストが返される。ある集合内のサポートされ
るプロパティ、メソッドまたはイベントについて照会す
るには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、ヌルＲ
ＵＩＤ、およびサポートされるエレメントの列挙を示す
制御フラグが入出力オペレーションと共に使用される。
サポートされるＲＵＩＤのリストは入出力オペレーショ
ンの結果として返される。このリストから、サード・パ
ーティ・エージェントは、実装されている集合のどのオ
プション・エレメント（もしある場合）がサポートされ
るかを判断することができる。

【００７４】ＧＵＩＤでユニークに識別された集合の仕
様書は、ドライバ開発者とサード・パーティ制御エージ
ェントのどちらもが実装ガイドとして利用できるメカニ
ズムをドキュメント化している。サード・パーティ開発
者は、あるドライバの機能を照会に対する応答に基づい
て知り、事前プログラムされた知識を抽象的集合定義に
基づいて知ることになる。同様に、ドライバ開発者は、
知った機能をどのようなサード・パーティ・エージェン
トに対して提供する集合または集合グループを実装する
ときのガイドとして抽象的集合定義を使用することがで
きる。

【００７５】ここで説明している接続機能を提供するた
めには、コンプライアント・ドライバはある種の集合を
サポートしていなければならない。以下の表は、プロパ
ティ集合フォーマットでサポートされ、本発明を実装す
るときに使用できるいくつかの重要な情報を示してい
る。最初の表は、フィルタによって実装される接続ピン
・ファクトリに関するプロパティに関し、２番目の表
は、特定の接続ピン・ファクトリをテンプレートとして
使用して作成される実際の接続ピン・インスタンスに関
するプロパティを示している。

【００７６】

【表１】

【００７７】

【表２】

【００７８】

【表３】

【００７９】

【表４】

【００８０】

【表５】

【００８１】

【表６】

【００８２】上記の表は単なる例示であり、これに限定
されるものではない、この分野の精通者ならば理解され
るように、異なるドライバ間の接続を作成するためには
多数の異なるプロパティとスキーマを実装することが可
能である。１つの重要な要素は標準化係数(standardiza
tion factor)であり、異なるドライバ製造者または開発
グループは同一のプロパティ集合を実装する能力をもっ
ているので、相互接続できるドライバを作成できるよう
にすることである。

【００８３】もう１つの有用なプロパティ集合は、ある
フィルタ上の入力と出力の接続ピン・ファクトリの内部
関係に関するトポロジ情報を与える。この情報はあるフ
ィルタ上の入力ピン・ファクトリおよび対応する出力ピ
ン・ファクトリの関係だけでなく、入力と出力のピン・
ファクトリの間でどのようなタイプの処理が行われるか
も記載している。行われる処理の例としては、異なるデ
ータ変換、データ伸張、エコー打消し(cancellation)な
どがある。このような情報は複数のフィルタを使用して
仮定上の接続パスをトレースしてから実際の接続ピン・
インスタンスおよび接続を作成する自動化フィルタ・グ
ラフ作成機能で使用すると、便利である。基本的には、
トポロジ情報はフィルタの内部構造を説明し、これをプ
ロパティ集合メカニズムを通してサード・パーティ・エ
ージェントからの照会に公開する。

【００８４】従って、コンプライアント・ドライバは指
定されたプロパティ集合を実装しているものにすぎな
い。そのため、サード・パーティ制御エージェントは、
あるプロパティ集合がサポートされていることが分かっ
たとき、コンプライアント・フィルタに対し照会と設定
を行うことができる。全体目標は、異なるフィルタを１
つに接続してフィルタ・グラフを作る方法に関する十分
な情報を得ることである。

【００８５】汎用集合メカニズムを使用すると、最小限
の機能を実装してコンプライアント・ドライバのシステ
ムをサポートできるが、その場合でも、拡張性は無制限
である。集合は、特定の集合が実装されている限り、相
互操作可能で相互接続可能なドライバのシステムを作成
するために多数の異なるドライバ開発者によって独立に
コーディングできる仕様書の中で定義することができ
る。さらに、この仕様書には、サポートしなければなら
ない必須のプロパティ、メソッド、およびイベントを定
義できるだけでなく、ドライバ機能と拡張機能に応じて
実装できるオプションのプロパティ、メソッド、および
イベントも定義できる。最小限に要求される基本的共通
性のほかに、ドライバ開発者は独自の集合を定義し、こ
れらにＧＵＩＤを割当てることにより追加の機能を組み
入れることも可能である。

【００８６】次に、図９および図１０を参照して説明す
る。図は２つのカーネル・モード・フィルタを接続する
プロセスを図形化して示している。図９はロジック・ブ
ロック説明図であり、そこでは各フィルタ・インスタン
スと接続ピン・インスタンスはファイル・オブジェクト
で表されている。図１０はファイル・オブジェクトおよ
び適切な接続を作成するときのステップを示すフローチ
ャートである。

【００８７】ステップ１４４からスタートして、フィル
タＡ１４６のインスタンスおよびフィルタＢ１４８のイ
ンスタンスはユーザ・モード・エージェントによって作
成される。これらは特定のデバイスでファイルを作成す
る標準ファイル・システムＡＰＩを使用して作成され
る。フィルタＡ１４６とフィルタＢ１４８がコンプライ
アント・フィルタまたはドライバとなっているのは、こ
れらが適切なプロパティ、メソッド、およびイベント集
合を実装して接続ピン・インスタンスの作成をサポート
し、サポートされる集合とそのフィルタ用に定義された
接続ピン・ファクトリに関してそれぞれのフィルタの機
能に照会するようになっているからである。

【００８８】サード・パーティ制御エージェントは、ス
テップ１５０でフィルタＡ１４６とフィルタＢ１４８に
それぞれ照会し、利用可能な接続ピン・ファクトリおよ
びそれから作成できる接続ピン・インスタンスの属性を
判断する。これらの属性には、前述したように、各フィ
ルタ１４６と１４８のそれぞれのピン・ファクトリのタ
イプ別の接続フォーマットとデータ・フォーマットがあ
る。照会は、以下で詳しく説明する集合ベース照会メカ
ニズムを使用して行われる。

【００８９】上記情報の照会を終えると、サード・パー
ティ制御エージェントは、以前に照会したデータ・フォ
ーマットと接続フォーマットの範囲に基づいて最適接続
フォーマットを決定する。この決定はステップ１５２で
行われ、選択した接続パスの要求事項に応じて同じフィ
ルタをサード・パーティ・エージェントが異なった使い
方をできるようにする。サード・パーティ制御エージェ
ントはデータ交差プロパティ(data intersection prope
rty)、トポロジ情報、および接続ピン・ファクトリを両
方のフィルタで使用して、作成される実際のフィルタ・
グラフに応じてデータ・フォーマットと接続配置の最良
の選択方法を決定する。

【００９０】入力フィルタ・ピン・インスタンス１５４
はステップ１５２で判断された最適検出情報を使用し
て、ステップ１５６でサード・パーティ・エージェント
によって作成される。入力ピン・インスタンス１５４は
ファイル・オブジェクトであるので、ハンドルが作成プ
ロセスから返されるが、これは入出力要求を入力インス
タンス１５４へ送るために使用できる。さらに、入力ピ
ン・インスタンス１５４の作成が有効性の検査をされて
いるが、この作成には、図４〜図６、図７および図８を
参照して前述したルーチングおよびバリデーション・メ
カニズムが使用される。

【００９１】接続を完成するために、出力ピン・インス
タンス１５８は、以前に作成された入力ピン・インスタ
ンス１５４のハンドルをNtCreateFileコールの中でパラ
メータとして使用してステップ１６０で作成される。出
力ピン・インスタンス１５８がこのようにして作成され
る効果として、システム・ファイル管理機能と入出力管
理機能を使用して内部ＩＲＰスタック構造が作成され
る。このスタック構造により、オリジナルの書込みコマ
ンドは、さまざまな方法で接続された接続ピン・インス
タンスとフィルタによって適当な順序で連続処理するこ
とが可能になるので、異なるフィルタ間の直接データ・
フローが容易化される。これを行うためには、入力ピン
・インスタンスを供給する関連出力ピン・インスタンス
の前に入力ピン・インスタンスが作成されていることが
必要である。

【００９２】デバイス・オブジェクトのスタック深さパ
ラメータは、このドライバに送られるＩＲＰ用にスタッ
ク・ロケーションをいくつ作成するかを制御する。スタ
ック深さパラメータは、デバイス・オブジェクトが初め
て作られるときは１つであると想定されているが、複数
のドライバが１つにチェイニングされているかどうかに
応じて、あとで変更することも可能である。現システム
では、この変更は、必要ならば、出力ピン・インスタン
スが初期「停止」状態から「取得」または他の状態に遷
移するとき行われる。接続ピン・インスタンスの状態遷
移はＩＲＰを正しく作成し、処理するための正しいスタ
ック深さパラメータ情報を決定するメカニズムである。

【００９３】チェイニングされた接続ピン・インスタン
ス集合を正しく割当てるためには、接続ピン・インスタ
ンスを特定の順序で停止状態から出るように遷移させる
必要がある。つまり、最後の入力ピン・インスタンス
（この例では、入力ピン・インスタンス１５４）から始
まって、関連の（例えば、接続された）出力ピン・イン
スタンス（この例では、出力ピン・インスタンス１５
８) まで連続的に逆方向に戻っていく必要がある。多数
のフィルタが１つにチェイニングされていれば、最も深
いフィルタまたはブリッジの入力ピン・インスタンスが
遷移の開始ポイントであって、ブリッジまたはフィルタ
上の初期出力ピン・インスタンスが設定されるまで逆方
向に連続的に構築していかなければならない。言い換え
れば、停止状態から出る遷移はチェインを逆昇るように
行われ、各接続ピン・インスタンスが前の接続ピン・イ
ンスタンスの後で必要になるスタック・サイズを得るよ
うにしなければならない。代表例として、必ずしもそう
する必要はないが、接続ピン・インスタンスは停止状態
から取得状態へ遷移するが、以下での説明の便宜上、取
得状態への遷移はスタック深さパラメータの調整に関し
ては、停止状態から出る遷移と同じ目的を果たすように
なっている。

【００９４】すべてのピン・インスタンスが取得状態に
なったあとは、ストリーム読取りと書込みをフィルタ・
グラフに対して出すことができる。なお、注目すべきこ
とは、ここで説明しているシステムが、関連入力と出力
ピン・インスタンスの接続をどの順序でも行うことがで
き、停止状態からの遷移だけはボトムアップ方式、つま
り、最も深いものから先に行わなければならないことで
ある。さらに、フィルタ・グラフは初期作成後に変更が
行えるように再構成可能になっている。変更が行われる
ときは、状態遷移は停止状態にある接続ピン・インスタ
ンスだけで行い、正しいスタック深さパラメータ情報が
得られるようにする必要がある。

【００９５】フィルタ上に見出される接続ピン・ファク
トリは、フィルタが特定フォーマットでデータを消費お
よび／または作成できる場所を表している。例えば、特
定の接続ピン・ファクトリは、１６ビットの４４キロヘ
ルツＰＣＭオーディオや８ビットの２２キロヘルツＰＣ
Ｍオーディオなどの、いくつかの異なるデータ・フォー
マットをサポートすることができる。前述したように、
接続ピン・ファクトリやそのデータ・フォーマットなど
の異なる機能については、適切なプロパティ集合メカニ
ズムとシステム入出力機能を使用してフィルタから照会
することができる。実際の接続ピン・インスタンスはピ
ン・ファクトリから受信した情報に基づいて作成され
る。

【００９６】単一のストリーム書込みまたはストリーム
読取りオペレーションがユーザ・モード・エージェント
から出されると、接続されたフィルタを通してデータの
連続処理が行われるストリーミング環境では、ＩＲＰ制
御用の２つのメイン・メソッドがＮＴオペレーティング
・システムのネーティブ機能の一部として使用すること
ができる。第１のメソッドでは、個別ＩＲＰは各フィル
タによって作成され、次のフィルタへ送られて処理さ
れ、このフィルタは新しいＩＲＰを作成し、チェインを
下って次々と処理されていく。他のメソッドでは、単一
のＩＲＰが使用され、入出力マネージャと相互作用する
ために用意された標準プロシージャを使用して連続フィ
ルタ間で受け渡しされていく。チェイン上の各連続フィ
ルタごとに新しいＩＲＰを作成していく第１のメソッド
が使用される場合は、フィルタ間の相互接続順序が重要
でないのは、フィルタはＩＲＰのデスティネーション(d
estination) だけを知っていればよく、入出力マネージ
ャをコールしてＩＲＰを指定のフィルタへ送ることがで
きるからである。ＩＲＰが再使用される場合に重要なこ
とは、停止状態からの接続ピン・インスタンスの遷移が
再使用ＩＲＰを受け取る最後のフィルタから始まるよう
に行われ、再使用ＩＲＰを受け取る最初のフィルタま
で、または処理のためにＩＲＰを作成したフィルタまで
逆方向に処理していくことである。

【００９７】相互接続カーネル・モード・フィルタの本
実施の形態と実装例は、ＩＲＰ共用を利用してドライバ
開発の複雑さを軽減し、より堅牢なドライバが作成され
ることを可能にし、処理を効率化するという利点があ
る。「ボトム・アップ」のピン・インスタンス状態遷移
パスは、正しいスタック順序が連続ドライバによって処
理されるＩＲＰに作成され、各ドライバ・オブジェクト
が適切なスタック深さパラメータ集合をもつことを保証
する。さらに、受信側入力ピン・ファクトリの現状態
は、状態遷移シーケンスを正しくたどっていたかどうか
を確かめるためにチェックされる。そのような理由か
ら、特定の接続ピン・ファクトリの通信プロパティは起
こり得るフロー方向を判断し、接続ピン・インスタンス
の状態遷移を正しく分配する上で支援する。

【００９８】出力ピン・インスタンス（またはＩＲＰソ
ース）を作成するとき、別のフィルタ上の入力ピン・イ
ンスタンス（またはＩＲＰシンク(sink)）を表すファイ
ル・オブジェクトへの参照はNtCreateFileコールの一部
として引き渡される。適切な作成ハンドラはマルチプレ
クシング・ディスパッチ機能とデバイス・オブジェクト
／ファイル・オブジェクト階層を使用して、前述したよ
うに実行される。この作成ハンドラは入力ピン・インス
タンスをもつフィルタ（例えば、図９のフィルタＢ１４
８）のデバイス・オブジェクトを、入力接続ピン・イン
スタンス・ファイル・オブジェクト（例えば、入力ピン
・インスタンス１５４）を通してアクセスすることがで
きる。デバイス・オブジェクトから、前のスタック深さ
パラメータを読み取ることができ、出力ピン・インスタ
ンスをもつフィルタのデバイス・オブジェクトのスタッ
ク深さパラメータが増加される。例えば、フィルタＡ１
４６に関連するデバイス・オブジェクトは、図９に示す
接続ではフィルタＢ１４８に関連するデバイス・オブジ
ェクトのそれから増加されるスタック深さパラメータを
もっている。これは停止状態から出る遷移のとき行われ
るのが通常であり、ＩＲＰは接続ピン・インスタンスが
停止状態にある間はルーチングされない。

【００９９】フィルタがＩＲＰを処理するとき、その特
定フィルタ用に指定された情報を含んでいる、ＩＲＰス
タック内のどのスタック・フレームまたはロケーション
をアクセスすべきかを、関連デバイス・オブジェクトの
スタック深さパラメータを参照するか、あるいはそれを
使用することによって知る。さらに、現フィルタは、デ
バイス・オブジェクトのスタック深さパラメータを減ら
して次のフィルタのＩＲＰスタック・ロケーションに位
置づけることによって、処理チェイン上の次のフィルタ
用のＩＲＰを準備する。

【０１００】フィルタ・コードはＩＲＰスタック内の次
のロケーションを準備し、入出力マネージャをコールし
てＩＲＰを、指定された通りに次のフィルタに渡すこと
を受け持っている。このようにすると、フィルタは、特
定の接続ピン・インスタンスを表す、どのファイル・オ
ブジェクトがＩＲＰと関連データを受け取って処理する
かを指定することができる。従って、ＩＲＰの順次処理
のためにそれぞれのデバイス・オブジェクトをスタック
するためのIoAttachDeviceのような標準入出力マネージ
ャ・コールは使用されない。

【０１０１】注目すべきことは、接続ピン・インスタン
ス間の接続を作成することは、その接続を表すために新
しいデバイス・オブジェクトを作成することを意味しな
いことである。基礎となる単一のデバイス・オブジェク
トはフィルタのインスタンスとそのフィルタ上のすべて
の接続ピン・インスタンスをサポートするために使用さ
れる。正しいデータ処理のために必要な具体的情報はフ
ァイル・オブジェクトのコンテキスト・エリアに保存さ
れていて、コンテキスト情報はそのまま残されている
が、非ページ・メモリ使用量は最小限に保たれている。
さらに注目すべきことは、ＩＲＰベースの媒体について
説明してきたが、相互接続フィルタ間の通信のための他
の媒体も使用できることである。そのようなものとし
て、非ホスト・ハードウェアとハードウェア間通信での
直接関数コールがある。

【０１０２】次に、図１１と図１２および図１３を参照
して、図１（従来技術）と図２（相互接続カーネル・モ
ード・ドライバのハイレベル・ロジック図）に示すソフ
トウェア・ドライバの正しい作成、接続、および状態遷
移順序について説明する。図１１はボックス１６２で囲
んだロジック構造とそこに含まれる処理ステップを示し
ている。図１２は接続ピン・インスタンスを作成して、
カーネル・モード・フィルタの相互接続を完成する様子
を示し、図１３に示すフローチャートにボックス１６４
で囲んだ処理ステップを含んでいる。

【０１０３】すべての相互接続が行われている図１２の
状態にあるとき、カーネル・モード・フィルタ・システ
ムは処理を行うために読み書きの準備状態にある。入出
力システムは正しい状態遷移プロセスによって正しく設
定されたＩＲＰスタック情報を使用して、ストリーム読
取りと書込みをそれぞれの接続ピン・インスタンスを通
して異なるフィルタ・エレメントに引き渡す。なお、グ
ラフを作成するために使用されたエージェント以外の、
ある種の外部ソフトウェアは、ブリッジまたはフィルタ
自体とハードウェアも含めて、ストリーム読取りとライ
トのデータを提供する。

【０１０４】ステップ１６８からスタートしたあと、制
御エージェント１７０はステップ１８０で、リーダ・フ
ィルタ１７２、デコンプレッサ・フィルタ１７４、効果
フィルタ１７６、およびサウンド・レンダリング・フィ
ルタ１７８のインスタンスを作成する。さらに、リーダ
・フィルタ１７２とディスク・ドライバ１８２との間の
接続が行われて、データがディスク・ドライブから持ち
込まれるようにする。各フィルタ・インスタンスの作成
は標準入出力コールを使用してデバイス入出力ディレク
トリ階層に見出される適切なデバイス上のファイルをオ
ープンすることにより、ユーザ・モード制御エージェン
ト１７０によって行われる。このコールからは、各フィ
ルタのインスタンスを表すファイル・オブジェクトへの
ハンドルが返される。

【０１０５】ステップ１８４で、サード・パーティ・エ
ージェントは効果フィルタ１７２、デコンプレッサ・フ
ィルタ１７４、効果フィルタ１７６、およびサウンド・
レンダリング・フィルタ１７８に照会し、接続ピン・フ
ァクトリの機能を判断する。これらの機能は、どのよう
な種類の入出力ピン・インスタンスが作成できるか、特
定のフィルタは各接続ピン・ファクトリのインスタンス
をいくつサポートするか、各接続ピン・ファクトリでサ
ポートされるデータ・フォーマット、通信パスの媒体ま
たはタイプなどがある。これらの機能は以前に詳しく説
明したプロパティ集合メカニズムを使用して照会され、
カーネル・モード・フィルタは、適切な「集合」（例え
ば、プロパティ集合）をサポートしているのでアーキテ
クチャに従っていることが前提になっている。

【０１０６】ステップ１８４でのこのようなすべての照
会情報は、チェインニングされた接続パスが、適切な接
続ピン・インスタンスを作成し、接続することによりそ
れぞれのフィルタ間で可能であるかどうかを判断するた
めに使用される。サード・パーティ・エージェントは、
相互接続のために必要なピン・インスタンスのタイプを
判断し、与えられた目的を達成するフィルタ・グラフを
作成する。

【０１０７】サポートされるデータ・フォーマットに基
づく接続フォーマットの決定はステップ１８６で行われ
る。フィルタ上のトポロジ情報、データ・フォーマッ
ト、およびデータ交差プロパティを使用すると、仮定上
の(hypothetical)フィルタ・グラフを作成することがで
きる。接続順序は重要でないので、そのようにする必要
はないが、フィルタ・グラフを作成しようとするとき時
間を節約することができる。この仮定上のフィルタ・グ
ラフがエラーなしで作成されるのであれば、サード・パ
ーティ・エージェントは、相互接続する接続ピン・イン
スタンスの作成を信頼して行うことができるという安心
が得られる。実際のピン・インスタンスが作成されてい
なければ、ある種の照会からはエラーが返されるので、
かかる接続ピン・インスタンスを作成してから仮定上の
フィルタ・グラフを作成するようにすると、実行可能で
あるとの信頼できる指示が返されることになる。この場
合も、仮定上のフィルタ・グラフは相互接続を行う前に
テストすることが可能である。

【０１０８】正しい接続情報が分かっているとステップ
１８６で決定されると、入力ピン・インスタンスを作成
し、相互接続して、図１３のボックス１６４で囲まれた
処理ステップのループで表すことができる。このループ
はデータ・ストリームのソースから最も遠くに離れた入
力ピン・インスタンスから始まる処理ステップを含んで
いる。この最後の入力ピン・インスタンスは「最も深
い」ピン・インスタンスと呼ばれ、これは最初に作成さ
れ、そのあとに関連する出力ピン・インスタンスを続け
ることができる。従って、接続は、以前に作成された入
力ピン・インスタンスのハンドルを使用して出力ピン・
インスタンスを作成したものである。

【０１０９】このパターンは、すべての入力ピン・イン
スタンスが関連出力ピン・インスタンスとの接続の前
に、それ以後連続して作成されるように続けられる。こ
のような接続シナリオは単なる例示であり、それぞれの
出力と入力ピン・インスタンスを接続して、本発明によ
るカーネル・モード・フィルタ間の接続を形成する他の
可能な方法を限定するものではない。フィルタは、入力
ピン・インスタンスからのハンドルが別のフィルタ上の
接続された出力ピン・インスタンスの作成期間に使用さ
れる限り、実装に従ってどの順序でも接続することが可
能である。さらに、前述したように、初期作成後（およ
び使用後も）フィルタ・グラフに変更を行うことが可能
である。

【０１１０】ループの最初の繰り返しでは、入力ピン・
インスタンス１８８はステップ１９０で作成される。作
成機能からハンドルを受け取ると、サード・パーティ制
御エージェント１７０はそのハンドルをNtCreateFileコ
ールでパラメータとして使用してステップ１９４で出力
ピン・インスタンス１９２を作成する。最初の繰り返し
でこれを行うと、サウンド・レンダリング・フィルタ１
７８は、それぞれ対応する接続ピン・インスタンス１８
８と１９２を通して効果フィルタ１７６に実効的に接続
される。現実装では、NtCreateFileコールはユーザ・モ
ード・クライアントが利用できるＡＰＩの関数コールの
一部として「ラップ(wrapped) 」される。これにより、
サード・パーティ・エージェントのユーザ・モード開発
者は詳細を知る必要から解放されるので、すべての関係
機能を単一ユーザ・モードＡＰＩに集中させることがで
きる。

【０１１１】ステップ１９６で、サード・パーティ・エ
ージェントは作成すべき入力ピン・インスタンスが他に
も残っているかどうかを判断する。残っていれば、入力
ピン・インスタンスを作成し、そのあとに別のフィルタ
上の対応する出力ピン・インスタンスを続けなければな
らない。最終的には、すべての接続が行われ、サード・
パーティ制御エージェント１７０はストリーム化データ
処理に対してフィルタ・グラフを準備する。

【０１１２】以上のようにして、入力ピン・インスタン
ス２０２はステップ１９０でボックス１６４で囲まれた
ループの２回目の繰り返しで作成され、他方、出力ピン
・インスタンス２０４は入力ピン・インスタンス２０２
のハンドルをステップ１９４でその作成の一部として使
用する。最後に、この特定の例では、３回目と最後の繰
り返しで、入力ピン・インスタンス２０６が作成され、
そのあとに出力ピン・インスタンス２０８が続いて接続
が完結する。

【０１１３】ステップ１９７で、サード・パーティ制御
エージェント１７０は、フィルタ・グラフによるストリ
ーム化データ処理に備えて各接続ピン・インスタンスを
停止状態から取得状態へ遷移させる。それぞれのフィル
タのデバイス・オブジェクトの各々でスタック深さパラ
メータを正しく設定するためには、状態遷移は「最も深
い」または最後の接続ピン・インスタンス（例えば、処
理のためのデータを受け取る最後の入力ピン・インスタ
ンス）から始めて、最初の接続ピン・インスタンス（例
えば、データをグラフに送り込む最初の出力ピン・イン
スタンス）に到達するまで相互接続カーネル・モード・
フィルタのチェインを順次に「さかのぼる」ように行う
必要がある。最初のフィルタまたはブリッジはＩＲＰを
作成し、スタック・ロケーションはＩＲＰがグラフ内の
各カーネル・モード・フィルタに効率よく連続して受け
渡されるように十分に割当てられる。

【０１１４】最後に、サード・パーティ制御エージェン
ト１７０はストリーム読取りと書込みを出し、ステップ
１９８でデータを処理してからステップ２００で終了す
る。

【０１１５】前述したように、出力ピン・インスタンス
の各作成には、そこに接続された入力ピン・インスタン
スを表すファイル・オブジェクトのハンドルが必要であ
る。このファイル・オブジェクト参照は、出力ピン・イ
ンスタンスの作成ハンドラが入力ピン・インスタンスに
対応するデバイス・オブジェクトへの参照を、現在また
は将来のアクセスのためにセーブしておくことができる
ようにする。

【０１１６】もっと具体的に説明すると、これにより、
入力ピン・インスタンスを管理するデバイス・オブジェ
クトのスタック深さパラメータは、停止状態から取得ま
たは他の状態へ状態遷移するとき出力ピン・インスタン
スのドライバによってアクセスすることが可能になる。
入力ピン・インスタンスに関連するスタック深さパラメ
ータの値はアクセスされ、増加され、出力ピン・インス
タンスに対応するデバイス・オブジェクトのスタック深
さパラメータの中にセーブされる。

【０１１７】スタック深さパラメータは、共用ＩＲＰス
タック構造のどこに特定フィルタ用のスタック・フレー
ム情報が置かれているかを判断するために使用される
が、これは各フィルタごとに異なっている。フィルタを
このように相互接続し、状態遷移を正しいシーケンスで
行うと、通信をユーザ・モードにしなくても、カーネル
・モードの相互接続フィルタのチェインを下るように単
一ＩＲＰを受け渡してくことができる。

【０１１８】以上の説明から理解されるように、同一の
接続ピン・ファクトリを基礎にした複数のインスタンス
をもつことが可能である。例えば、オーディオ・ミキシ
ング・フィルタは複数のピン・インスタンスをミックス
して単一の出力ピン・インスタンスにしてから処理する
ことができる。各入力インスタンスは同一タイプであ
り、フィルタは１つのタイプの入力ピンだけをサポート
することができる。このような構成の別の例として、複
数の入力を１つの出力にする例がある。

【０１１９】逆のことを行うことも可能である。つま
り、スプリッタ・フィルタは単一入力接続ピン・インス
タンスをもち、複数の出力ピン・インスタンスを提供す
ることによりデータ・ストリームを倍にすることが可能
である。この分野の精通者ならば理解されるように、上
述してきた接続メカニズムから実際の実装とその要求条
件に応じて種々態様に変形し、種々態様に組み合わせる
ことが可能である。

【０１２０】ドライバ開発者が独立に実装できる共通メ
カニズム（例えば、プロパティ集合、メソッド集合、お
よびイベント集合）を、すべてのコンプライアント・フ
ィルタにサポートさせることによって均一性と標準化が
達成されているので、制御エージェントは異種ソフトウ
ェア・プロバイダから提供されるコンプライアント・フ
ィルタを都合よく接続することができる。さらに、接続
ピン・ファクトリの観点から見た機能の多くはある状況
では必要であっても、別の状況では必要でない場合があ
る。必要とされる接続ピン・インスタンスの決定は異な
るフィルタ間の相互接続を実際に行うサード・パーティ
制御エージェントによって最初に行われる。

【０１２１】この分野の精通者ならば理解されるよう
に、本発明の種々方法はコンピュータ・プログラム・コ
ード手段として、磁気ディスク、CD-ROM、およびこの分
野で共通している他の媒体やまだ未開発の他の共通媒体
などの、コンピュータ読取り可能媒体上にストアされる
コンピュータ命令として組み込んでおくことが可能であ
る。さらに、コンピュータ・ハードウェア・メモリに置
かれる重要なデータ構造は、上記のようなコンピュータ
・プログラム・コード手段のオペレーションにより作成
することができる。

【０１２２】本発明は本発明の基本的特徴の精神から逸
脱しない限り、他の実施形態で実現することも可能であ
る。上述してきた各種実施の形態はすべての点で説明し
た通りであるが、これらの実施の形態に限定されるもの
ではない。従って、本発明の範囲は上述してきた説明に
よってではなく、特許請求の範囲に記載されている事項
によってのみ限定されるものである。特許請求の範囲の
均等の意味と範囲に属する一切の変更は本発明の範囲に
属するものである。

【図面の簡単な説明】

【図１】制御エージェントの指示を受けてサウンド・デ
ータをディスク・ファイルから持ち込み、サウンド・デ
ータをなんらかの形態で処理し、サウンド・データをレ
ンダリングしてスピーカから再生させる相互接続フィル
タとドライバのシステムを示す従来技術のデータ・フロ
ー図である。

【図２】図１に示すシステムと目的が同じであり、サウ
ンド・データをディスク・ドライバから読み取り、その
データを処理し、そのデータをレンダリングしてスピー
カから聞こえるようにし、処理フィルタとレンダリング
は、この場合も制御エージェントの指示を受けて相互接
続カーネル・モード・ドライバによって処理されるよう
した本発明によるシステムを示す図である。

【図３】オペレーティング・システムで作成され、使用
されるドライバ・オブジェクト、デバイス・オブジェク
トおよびファイル・オブジェクト間の関係を示す垂直関
係モデルを示す図である。

【図４】ドライバ・オブジェクトのロジック・ブロック
図であり、本発明のシステムに従ってメッセージを適切
なプロセス・ハンドリング・コードへ転送し、新しいフ
ァイル・オブジェクトの作成をバリデーションするため
のデータ構造およびプログラム・コードとの論理的関係
を示す図である。

【図５】デバイス・オブジェクトのロジック・ブロック
図であり、本発明のシステムに従ってメッセージを適切
なプロセス・ハンドリング・コードへ転送し、新しいフ
ァイル・オブジェクトの作成をバリデーションするため
のデータ構造およびプログラム・コードとの論理的関係
を示す図である。

【図６】ファイル・オブジェクトのロジック・ブロック
図であり、本発明のシステムに従ってメッセージを適切
なプロセス・ハンドリング・コードへ転送し、新しいフ
ァイル・オブジェクトの作成をバリデーションするため
のデータ構造およびプログラム・コードとの論理的関係
を示す図である。

【図７】ルーチングとバリデーション・コンポーネント
リの初期セットアップとカーネル・モード・ドライバに
よる入出力メッセージの処理を示すフローチャートであ
る。

【図８】制御エージェントの処理、ルーチングとバリデ
ーション・メカニズム、および新しいファイル・オブジ
ェクトを作成する具体的な作成ハンドラ・ルーチンを示
す詳細フローチャートである。

【図９】オペレーティング・システムでファイル・オブ
ジェクト構造を利用して、接続を標準化された方法で行
う接続フィルタ間の水平関係を示すロジック図である。

【図１０】図９のカーネル・モード・フィルタまたはド
ライバを作成し、接続するためにユーザ・モードの制御
エージェントによってとられる処理ステップを示すフロ
ーチャートであり、制御エージェントから受け取った入
出力要求を処理するために接続を行い、その処理が異な
るドライバ（フィルタ）間で続けられる様子を示してい
る。

【図１１】ユーザ・モードの制御エージェントの指示を
受けてカーネル・モード・フィルタのチェインを作成す
るために使用され、サウンド・データをハード・ドライ
ブから読み取り、カーネル・モード・フィルタでそのデ
ータを処理し、そのデータをレンダリングしてスピーカ
から聞こえるようにするシステムを実装するためのカー
ネル・モード・ドライバと接続を示す概要ロジック図で
ある。

【図１２】ユーザ・モードの制御エージェントの指示を
受けてカーネル・モード・フィルタのチェインを作成す
るために使用され、サウンド・データをハード・ドライ
ブから読み取り、カーネル・モード・フィルタでそのデ
ータを処理し、そのデータをレンダリングしてスピーカ
から聞こえるようにするシステムを実装するためのカー
ネル・モード・ドライバと接続を示す概要ロジック図で
ある。

【図１３】図１１と図１２に示すシステム用に相互接続
カーネル・モード・ドライバを作成するための処理ステ
ップを示すフローチャートである。

【符号の説明】

４４ 制御エージェント ４６ ディスク・ドライブ ４８ ディスク・ドライバ ５０ リーダ・ドライバ ５２ デコンプレッサ・ドライバ ５４ 効果フィルタ ５６ 効果プロセッサ ５８ レンダリング・ドライバ ６２ スピーカ ６４，７６，８０ ドライバ・オブジェクト ６６ デバイス・オブジェクト ７０，７２，７４，９０ ファイル・オブジェクト ７８ 汎用マルチプレクシング・ディスパッチ機能 ８２ デバイス・エクステンション・エリア ８４，１００ ファイル・タイプ・バリデーション・テ
ーブル ８６，１０２ ファイル・オブジェクト・タイプ ８８ 作成ハンドラ ９２ ファイル・コンテキスト・エリア ９４ ＩＲＰ要求ハンドラ・テーブル ９６ ＩＲＰ要求 ９８ ハンドラ １０４ 参照 １４６ フィルタＡ １４８ フィルタＢ １５４ 入力フィルタ・ピン・インスタンス １５８ 出力ピン・インスタンス

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ブライアン エイ． ウッドラフ アメリカ合衆国 98045 ワシントン州 ニュー ベンド サウス ウエスト 10テ ィーエイチ ストリート 1020 (54)【発明の名称】 ファイル・オブジェクトの生成をバリデーションし、ファイル・オブジェクトへのメッセージを ルーチングする方法、コンピュータ・プログラム・プロダクト，およびデータ構造を記録した記 憶媒体

Claims (7)

【特許請求の範囲】
1. 【請求項１】 デバイス・オブジェクトとファイル・オ
   ブジェクトが階層的に関係するシステムにおいて適切な
   ファイル・オブジェクトのハンドラへメッセージをルー
   チングする方法において、 各々がプライベート・データ・エリアを有する１つまた
   は２つ以上のデバイス・オブジェクトを作成するステッ
   プであって、前記プライベート・データ・エリアは階層
   的に関係づけることができる許容ファイル・オブジェク
   ト・タイプを含むコンテキスト情報と各ファイル・オブ
   ジェクト・タイプ別の関連メッセージ・ハンドラを含む
   ものと、 各々がプライベート・データ・エリアを有する１つまた
   は２つ以上のファイル・オブジェクトを形成するステッ
   プであって、前記プライベート・データ・エリアは階層
   的に関係づけることができる許容ファイル・オブジェク
   ト・タイプを含むコンテキスト情報と各ファイル・オブ
   ジェクト・タイプ別の関連メッセージ・ハンドラを含ん
   でおり、前記ファイル・オブジェクトの各々は親オブジ
   ェクト・コンテキストに従って親オブジェクトと階層的
   に関係づけられて、有効に作成されたデバイス・オブジ
   ェクトとファイル・オブジェクトのシステムを作成する
   ものと、 システム内の前記１つまたは２つ以上のデバイス・オブ
   ジェクトと前記１つまたは２つ以上のファイル・オブジ
   ェクトの階層的に関係づけられたコンテキスト情報に基
   づいてメッセージを指定したファイル・オブジェクトへ
   ルーチングする少なくとも１つのマルチプレクシング機
   能を提供するステップとを備えたことを特徴とする方
   法。
2. 【請求項２】 ファイル・オブジェクト作成要求をバリ
   デーションする方法において、 特定タイプのファイル・オブジェクトを作成する要求を
   受け取るステップと、 前記特定要求をコンテキスト情報に基づいてバリデーシ
   ョンするステップと、 ファイル・オブジェクトを作成する前記要求が有効であ
   れば、要求されたファイル・オブジェクトを作成するス
   テップとを備えたことを特徴とする方法。
3. 【請求項３】 請求項２に記載の方法において、要求さ
   れたファイル・オブジェクトの作成は、特定の作成ハン
   ドラによって行なわれることを特徴とする方法。
4. 【請求項４】 請求項２に記載の方法において、前記方
   法はファイル・オブジェクト作成要求を受け取り、ドラ
   イバ・オブジェクトから参照される標準化マルチプレク
   シング・ディスパッチ機能の一部して実装されているこ
   とを特徴とする方法。
5. 【請求項５】 請求項２に記載の方法において、親ファ
   イル・オブジェクトが存在するかどうかを判断するステ
   ップをさらに備え、前記コンテキスト情報は親ファイル
   ・オブジェクトに関する情報を備えたことを特徴とする
   方法。
6. 【請求項６】 ファイル・オブジェクト作成要求をルー
   チングし、バリデーションする方法において、 特定タイプのファイル・オブジェクトを作成する要求を
   マルチプレクシング・ディスパッチ機能で受け取るステ
   ップと、 関連する親ファイル・オブジェクトがその要求に示され
   ているかどうかを前記マルチプレクシング機能によって
   判断するステップと、 親ファイル・オブジェクトが示されていなければデバイ
   ス・オブジェクト情報に基づいて、親ファイル・オブジ
   ェクトが示されていれば親ファイル・オブジェクト情報
   に基づいて、ファイル・オブジェクトを作成する前記要
   求をバリデーションするステップと、 ファイル・オブジェクトを作成する前記要求が有効であ
   れば、要求されたファイル・オブジェクトを作成ハンド
   ラによって作成するステップとを備えたことを特徴とす
   る方法。
7. 【請求項７】 記憶媒体にストアされ、データ構造を表
   している複数のデータ・フィールドをもつコンピュータ
   読取り可能な記憶媒体において、 複数の許容ファイル・オブジェクト・タイプを表し、フ
   ァイル・オブジェクト作成要求をバリデーションするた
   めに使用されるデータを含んでいる第１データ・フィー
   ルドと、 複数の作成ハンドラへの参照を表すデータを含んでいる
   第２データ・フィールドであって、各作成ハンドラは許
   容ファイル・オブジェクト・タイプに対応していて、対
   応する許容オブジェクト・タイプのファイル・オブジェ
   クトを作成するために使用されるものとを備えたことを
   特徴とするコンピュータ読取り可能な記憶媒体。