JP4684376B2 - カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法，コンピュータ・プログラム・プロダクト、システムおよび記録媒体 - Google Patents
カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法，コンピュータ・プログラム・プロダクト、システムおよび記録媒体 Download PDFInfo
- Publication number
- JP4684376B2 JP4684376B2 JP16477097A JP16477097A JP4684376B2 JP 4684376 B2 JP4684376 B2 JP 4684376B2 JP 16477097 A JP16477097 A JP 16477097A JP 16477097 A JP16477097 A JP 16477097A JP 4684376 B2 JP4684376 B2 JP 4684376B2
- Authority
- JP
- Japan
- Prior art keywords
- filter
- driver
- data
- connection pin
- kernel mode
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
- G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明の分野はコンピュータ・ソフトウェア・ドライバの開発に属するものでである。本発明はドライバのコード生成を単純化すると共に、標準化されたアクセス・ポイントを提供するツール、ソフトウェア・フレームワーク、規則などに関する。より具体的には、本発明は異なる開発者によって書かれたソフトウェア・ドライバをカーネル・モードで相互接続し、カーネル・モードからユーザ・モードへまたはユーザ・モードからカーネル・モードへの非効率な遷移を行うことなく、異なるドライバ間で連続処理を可能にする標準化されたメソッド、コンピュータ・プログラム・プロダクト、およびデータ構造に関する。
【０００２】
【従来の技術】
ソフトウェア・ドライバはハードウェアを制御するように、またはソフトウェア機能を提供するように作られているのが通常であり、システム・オーバヘッドを軽減し、制約を相対的に少なくしてオペレーティング・システムの下で実行されている。そのようにすると、正常な動作(behavior)を保証し、無効なアクセスまたはオペレーティング・システムの下で実行中の別のプロセスとの干渉を「トラップ(trap)」するために実行されるシステム・コードが少なくなるので、ドライバがハードウェアをアクセスし、タイム・クリティカル処理要求(time critical processing request)をサービスすることが高速化している。
【０００３】
オペレーティング・システムは、アクセスの量と実装（実装）されているセキュリティ機能に応じていくつかの異なる動作レベルまたは「モード(mode)」をもっているのが通常である。例えば、通常のアプリケーション・プログラムは最低優先度で実行され、他のアプリケーションとの干渉を防止するためのセキュリティ・デバイスを適所に完備している。ハードウェアは制御下に置かれたインタフェースを通してのみアクセスされる。説明の便宜上、これを「ユーザ・モード(user mode) 」と総称することにするが、下述する本発明の実装例の一部として使用されているWindows NTオペレーティング・システムはユーザ・モードをサポートしている。同様に、他の大部分のオペレーティング・システムは、その複雑度に関係なく、「ユーザ・モード」と同等の動作モードを持っている。
【０００４】
他方、ドライバは実行優先度がはるかに高く、セキュリティ保護が低いオペレーティング・システムのモードで実行されるので、ドライバは、多くの場合、ドライバが直接に取り扱う実際のハードウェアへアクセスすることが可能になっている。多くのアプリケーションは、このよりゆるやかで、よりパフォーマンス指向のモードで実行させると利点が得られるが、これはWindows NT用語では、一般に「カーネル・モード(kernel mode) 」と呼ばれており、本明細書でもそのように呼ぶことにする。この場合も、他の堅牢な(robust)オペレーティング・システムは機能的に同等のモードをもっている。
【０００５】
ソフトウェア・ドライバの一般的概念は特定のハードウェアを制御することを意図しているので、ドライバは相互から切り離されて開発され、ハードウェア・メーカによって提供されるのが通常である。例えは、アドイン・ハードウェア・カード(add-in hardware card)に関連する、ある種の入出力サービスをデバイスの定義を通して提供するソフトウェア・ドライバは他のどのドライバとも通信する必要もなければ、その存在を知っている必要もない。
【０００６】
事情によっては、ドライバの開発のこのような専用的アプローチと、ドライバ間で通信できる機能の関連する欠如は、カーネル・モードで動作させることが好ましい処理をユーザ・モードで動作させざるを得なくさせるので、パフォーマンス面で不利になることが起こる。
【０００７】
本明細書の中で用いられている、カーネル・モード・ドライバを容易に使用することができない現行プログラムの代表的な例の１つとして、ユーザがフィルタと呼ばれる異なる処理ブロックを選択し、これらを１つに結合して、マルチメディア・データのストリームを連続的に操作できるようにするグラフ作成機能がある。データはサウンドまたはビデオを表す一連のサンプルであるのが代表的であり、処理ブロックは、圧縮データの伸張(decompression) 処理、特殊効果(special effects) 処理、CODEC 機能、データをアナログ信号に変換するレンダリング・ブロック(rendering block) などがある。
【０００８】
上記のようなフィルタは、プログラムのグラフ作成機能部分が相互接続され、そのオペレーションを制御し、ユーザの入力と処理ブロックの再配置(rearrangement) に応じられるようにユーザ・モードに置かれているのが代表的である。マルチメディア・データのストリームには一貫性があり、大量のデータが生成されるために、パフォーマンスは重要な問題になっている。汎用オペレーティング・システムでは、ユーザ・モードとカーネル・モードとの間で受渡しや切替えを繰り返し行い、このような遷移(transition)がセキュリティ上有効であるかどうかの検査を暗黙的に行う結果、システム・パフォーマンスが低下するので、ある種のマルチメディア・アプリケーションが使用できないことになる。
【０００９】
さらに、処理ブロックは多くの時間、ハードウェアと結びつけられているため、ユーザ・モードとカーネル・モードのコンポーネント間の遷移がなん度も行われることになる。このような遷移が行われると、マルチメディア処理システムの総パフォーマンスを低下させる、別の形態のオーバヘッドを含むことになる。ユーザ・モードとカーネル・モードとの間で遷移を行うと、異なるバッファ間でデータをコピーするときに関連するオーバヘッドが生じ、これは処理をカーネル・モードのままにしておけば生じるはずがないものである。
【００１０】
カーネル・モードからユーザ・モードへの遷移を行うときに起こる、もう１つの欠点は、オペレーティング・システムで作業タスクをスケジューリングする方法が制限されることである。作業をカーネル・モードのままにしておくことが可能であれば、ソフトウェア割込みや据置きプロシージャ・コール(deferred procedure call‐ＤＰＣ）といった、よりパフォーマンス指向のスケジューリング方法を利用できるので、システム・パフォーマンスはさらに最適化される。
【００１１】
さらに、異なるドライバ開発者が相互に接続可能なドライバを、共通の相互接続方式と定義に従って作成できるようにすると好都合な場合がある。このようにすると、共通インタフェースに対して書かれたどのドライバ機能も、機能処理ブロックのシステム中に相互接続できるので、すべてのデータ遷移はカーネル・モードで行われることになる。さらに、公知の規格を使用すると、多くの異なるドライバ開発者は相互操作可能で、相互接続可能なドライバ・ソフトウェアを開発することが可能になる。
【００１２】
【発明が解決しようとする課題】
本発明の目的は、ソフトウェア・ドライバを標準化された方式で相互接続し、データ処理期間にオペレーティング・システムのモード遷移を防止することによって、システム・パフォーマンスを向上することである。
【００１３】
さらに、本発明の目的は、サード・パーティ開発者によって拡張可能である、相互接続可能なソフトウェア・ドライバ用のベース・メカニズムを提供することである。
【００１４】
本発明の別の目的は、より多くのパフォーマンス・クリティカル処理をカーネル・モードで発生させるようにすることである。
【００１５】
さらに、本発明の別の目的は、ユーザ・モードのエージェントがソフトウェア・ドライバを相互接続できるようにすることである。
【００１６】
本発明のその他の目的および利点は以下の説明に記載されているが、その一部はその説明から理解されるものと、本発明を実施することにより知得し得るものとがある。本発明の目的と利点は、請求の範囲に個々に記載されているインストリューメント(instrument)の手段および組合せにより実現し、得られるものである。
【００１７】
【課題を解決するための手段】
上記目的を達成するために、また以下に具現化され、広義に説明されている本発明によれば、ソフトウェア・ドライバをカーネル・モードで相互接続するための方法およびコンピュータ・プログラム・プロダクトが提供されている。ある与えられたドライバまたはフィルタは、他のドライバに置かれた他のピン・インスタンス(pin instance)と相互接続できる、ある種のタイプのピン・インスタンスを作成する接続「ピン・ファクトリ(pin factory) 」をサポートし、定義することにより、ユーザ・モードのエージェントに頼らなくても、処理メッセージがドライバによってカーネル・モードで連続処理されるようにしている。このようにすると、データは完全にカーネル・モードでフローし、データはユーザ・モードにクロスするというオーバヘッドが不要になるので効率的に処理される。
【００１８】
コンプライアント・ドライバ(compliant driver)を接続することを希望するユーザ・モードのエージェントはドライバにその機能があるかどうかを照会する。そのような機能としては、接続ピン・インスタンスをインスタンシェイト(instantiate) するのにどのような種類の接続ピン・ファクトリが使用できるかということがあり、この中には、処理されるデータのタイプ、データ・フォーマット、転送レート、転送媒体またはモード、接続ピン・インスタンスの入力または出力の性質といった関連特性が含まれている。
【００１９】
ユーザ・モードで実行されるのが代表的であるエージェントが１つまたは２つ以上のコンプライアント・ドライバの機能について照会したあと、そのエージェントは、複数のドライバを１つに「チェイニング」してデータがドライバ間で最適に処理されるようにする最良の接続特性を決定する。この決定ステップは、すべてのドライバ機能の照会を終えて、最適な接続基準が選択できるようになったあとで行われる。
【００２０】
次に、ユーザ・モードのエージェントは、各ドライバ上の必要な接続ピンのインスタンスをピン・ファクトリを使用して作成することによってドライバを相互接続する。エージェントは、データ・フォーマットと接続フォーマットを接続ピン・インスタンス作成の一部として指定する。さらに、以前に作成された接続ピン・インスタンスへの参照は、他の接続ピン・インスタンスを作成する要求の中で指定され、接続ピン・インスタンス間の接続が行えるようにする。
【００２１】
ＮＴオペレーティング・システムの下で実装されている例示的実施の形態では、実際の接続ピン・インスタンスは「ファイル」へのハンドル(handle)を返す作成入出力オペレーションによって作成される。この作成入出力要求は、接続ピン・インスタンスのデータ・フォーマットと接続フォーマットを示しているデータ構造へのドライバ・インスタンス・ハンドルと参照を含めている。
【００２２】
コンプライアント・ドライバを作成するためには、ドライバ開発者は、ユーザ・モードのエージェントが機能について照会し、ドライバ間の相互接続を行えるようにする、ある種の標準機能をサポートしている。Windows NTオペレーティング・システム上で構築されている、ある実施の形態では、これは、必要とする機能を実装している「集合(set) 」（つまり、プロパティ、メソッド、およびイベントの集合）の使用によって達成されている。
【００２３】
集合は、集合全体を特定するＧＵＩＤ(globally unique identifier)（グローバルにユニークな識別子）と、集合内の各機能エレメントのＲＵＩＤ(relatively unique identifier)（相対的にユニークな識別子、例えば、集合自体内で相対的な識別子）をもつものとして論理的に定義されている。各集合は１つまたは２つのＩＯＣＴＬｓ(IO Controls)(入出力コントロール）だけと関連づけられ、ＩＯＣＴＬは、集合の仕様と組み合わされて、ドライバとのすべてのインタラクションを制御する。
【００２４】
本実施の形態では、３タイプの集合が使用されている。つまり、プロパティ集合、メソッド集合、およびイベント集合である。プロパティ集合はサウンド・ボリューム、転送レートなどの、値または設定値をドライバ内で管理するために使用され、コールがプロパティ値を得ようとしているのか、および／またはプロパティ値を設定しようしているのかを示すフラグと一緒に単一のＩＯＣＴＬを使用する。メソッド集合は、メモリの割当て、バッファのフラッシング(flushing)などのように、ドライバが実行できるオペレーションを管理するために使用され、単一のＩＯＣＴＬを使用して特定のメソッドをコールする。イベント集合は、デバイス変更通知、データ・スターベーション(data starvation) 通知などのように、ドライバの処理に関連するイベントを管理するために使用され、２つのＩＯＣＴＬを使用する。１つは特定のイベントをイネーブル(enable)にするためのもので、もう１つは特定のイベントをディスエイブル(disable) にするためのものである。
【００２５】
集合を使用するには、入出力制御オペレーションは特定のＩＯＣＴＬと、集合のＧＵＩＤ、ＲＵＩＤをもつデータ構造への参照およびその他の必要なデータを使用して開始される。例えば、サウンド・カード・ドライバでボリューム・プロパティを設定する場合は、集合プロパティのＩＯＣＴＬを使用し、ボリューム設定値をもつプロパティ集合の適切なＧＵＩＤを指定し、その集合内の特定ＲＵＩＤがボリューム・プロパティを示していることを指示し、新しいボリューム設定値を含んでいる入出力制御オペレーションが行われることになる。
【００２６】
サポートされる集合について照会するには、ヌルＧＵＩＤが特定集合タイプの特定ＩＯＣＴＬ（例えば、プロパティ集合ＩＯＣＴＬ、メソッド集合ＩＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）で照会フラグと一緒に使用され、サポートされる集合ＧＵＩＤのリストが返される。ある集合内のサポートされたプロパティ、メソッド、またはイベントについて照会するには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、および照会フラグが、サポートされたＲＵＩＤのリストを返すオペレーションと一緒に使用される。
【００２７】
汎用集合メカニズムを使用すると、コンプライアント・ドライバをサポートするために最小限の機能を実装することができるが、それでも拡張性は無制限である。集合は、特定の集合が実装されている限り、相互動作可能で、相互接続可能なドライバのシステムを作成するために、多数の異なるドライバ開発者によって独立してコーディングすることができる仕様書に定義することができる。さらに、この仕様書には、サポートする必要のある必須のプロパティ、メソッドおよびイベントを定義できるだけでなく、ドライバの機能と拡張機能に依存して実装できるオプションのプロパティ、メソッド、およびイベントも定義することができる。要求される基本的最小限の共通性のほかに、ドライバ開発者は独自の集合を定義し、その集合にＧＵＩＤを割当てることによって追加の機能を組み込むことも可能である。サポートされる機能（つまり、サポートされるＧＵＩＤとＲＵＩＤの照会を行うこと）を列挙できるようにすると、ユーザ・モードのエージェントなどの、呼出し側(caller)は期待を調整することも、基礎となるフィルタの機能に依存して適切な補償を行うこともできる。
【００２８】
本発明の上記およびその他の目的と特徴は以下の説明および請求の範囲に詳しく記載されている通りであるが、以下に説明する本発明を実施することによって知得することも可能である。
【００２９】
本発明の上記およびその他の利点と目的がどのようにして得られるかという方法を示すために、以下では、添付図面に図示されている具体的実施の形態を参照して、以上で簡単に説明してきた本発明を詳しく説明することにする。添付図面は本発明の代表的な実施の形態を示したにずぎず、従って、本発明の範囲を限定するものではないとの了解の下で、以下、添付図面を使用しながら本発明をもっと具体的にかつ詳しく記述し説明することにする。
【００３０】
【発明の実施の形態】
本明細書で用いられている「ユーザ・モード(user mode) 」という用語は、ユーザが書いたプログラムの大部分が実行されるときの、オペレーティング・システムにおける動作レベルのことである。ユーザ・モードの動作レベルはセキュリティ・レベルが最も高く、あるアプリケーション・プログラムまたはプロセスが別のアプリケーション・プログラムまたはプロセスに干渉するのを防止するために大量のオーバヘッドが消費されるのが代表的である。さらに、システム・リソースへのアクセスは特定のインタフェースを通して厳格に制御され、実行優先度は最低ではないとしても、最低優先度の１つであるのが一般である。
【００３１】
本明細書で用いられている「カーネル・モード(kernel mode) 」という用語はユーザ・モードの動作モードよりも制約が非常に少ない、オペレーティング・システムにおける動作レベルのことである。カーネル・モードのプログラムまたはプロセスの例としては、ハードウェア・コンポーネントを制御するソフトウェア・ドライバ(software driver) を含む。代表例として、カーネル・モードのプログラムはパフォーマンスに影響されやすく、従って、動作上のオーバヘッドはユーザ・モードのプログラムよりも少なくなっている。さらに、ハードウェアや多くのシステム・リソースへのアクセスは無制約であるか、あるいはユーザ・モードのプログラムの場合よりも制約がはるかに少なくなっている。多くの場合、カーネル・モードで実行されるプログラム・コードは、規則(convention)に対するプログラマの規律正しさと準拠とを信頼して、システムが良好に動作するようにする（例えば、別のプログラムのアドレス空間を破壊しないようにする）。カーネル・モードを表わす別の用語として、「トラステッド(trusted) 」コードがある。
【００３２】
本明細書で用いられている「ドライバ(driver)」という用語はカーネル・モードで実行されるのが代表的である、ソフトウェア・ドライバ・プログラムのことである。ドライバという用語は、オペレーティング・システム上にロードされる実際の実行可能プログラムまたはある種の機能を分け与えるプログラム部分を意味する場合もある。ドライバは、多くの場合、ある形態のハードウェアと関連づけられているが、必ずしもそうである必要はない。
【００３３】
本明細書で用いられている「フィルタ(filter)」という用語はソフトウェア・ドライバ内に置かれている機能部分のことであり、この中には、ドライバ自体も含まれ、そこでは、接続ポイントがフィルタを通してデータを送信するために公開されている。例えば、ソフトウェア・ドライバはいくつかの異なるフィルタをサポートする場合もあれば、１つの単一機能をもっている場合もある。さらに、内部的には１つに接続され、外部的には入出力用に接続ポイントを公開している異なるドライバからの複数のフィルタは単一フィルタとして集合的に参照される場合もある。また、もっと総称的な意味では、フィルタという用語は、伸張(decompression) などのように、それがカーネル・モードで実行されるソフトウェア・ドライバ・フィルタで起こるか、ユーザ・モードで実行される別のプログラム・コードで起こるかに関係なく、実行されるオペレーションを意味する場合もある。
【００３４】
本明細書で用いられている「ドライバ・オブジェクト(driver object) 」という用語は、ソフトウェア・ドライバを管理し、これをシステム・リソースとして知らせるオペレーティング・システムによって定義されているオペレーティング・システムのエンティティのことである。
【００３５】
本明細書で用いられている「デバイス・オブジェクト(device object) 」という用語はシステムによって定義されたシステム・レベルのエンティティのことであり、これは利用が可能であるドライバの機能の一部をシステム・リソースとして知らせ、ドライバの機能と他のシステム・コンポーネントが利用できるかどうかを定義している。ドライバ・オブジェクトとデバイス・オブジェクトはどちらも、代表的にドライバ・ソフトウェアのロード時と初期化時に作成される。
【００３６】
本明細書で用いられている「ファイル・オブジェクト(file object) 」という用語は、デバイス・オブジェクトによって指定されたリソースの呼出しを管理するオペレーティング・システムのエンティティのことであり、これはオペレーティング・システムによって定義されている。ファイル・オブジェクトはドライバ・オブジェクトの使用状況に関するコンテキストを提供する。さらに、ファイル・オブジェクトは、以前のファイル・オブジェクトが新しいファイル・オブジェクトの作成時に「親」と指定されていれば、別のファイル・オブジェクトと階層的に関係づけることが可能である。ファイル・オブジェクトは、代表的にデータ・ストリーム上に操作するすべての入出力オペレーションの管理に使用される。
【００３７】
本明細書で用いられている「データ(data)」という用語は、相互接続されたカーネル・モードのフィルタを通して処理される一切の情報のことである。そのようなデータは、ビデオ、オーディオ、テキスト、ＭＩＤＩなどを表すメディア・データを含むが、他のアプリケーションの場合には制御情報やパラメータも含んでいる場合がある。例えば、カーネル・モード・フィルタ・グラフはプロセス制御オペレーションで使用されることがあるが、そこでは、異なるフィルタ間で受け渡しされる制御情報はマシン類をアクチュエートする制御信号を創り出すために使用されている。メディア処理システムの例が示されているが、他のアプリケーションも、本明細書に説明されている相互接続カーネル・モード・フィルタのシステムから、同じような方法で利点を得ることが可能である。
【００３８】
本明細書では、本発明の説明は、Microsoft(登録商標）社から提供されているWindows NT（商標）オペレーティング・システムのコンテキスト内で記載されている。さらに、本明細書に説明されている好適実施の形態を理解するためには、Windows NTの入出力アーキテクチャの知識が前提になっている。入出力システムおよび NT オペレーティング・システム全般について解説した好適書としては、Helen Custer著「Windows NTの内部(Inside Windows NT)」(Microsoft Press発行）がある。
【００３９】
ドライバおよびファイル・オブジェクト、デバイス・オブジェクト、ドライバ・オブジェクトなどのシステム・エンティティの以下の説明では、Windows NTオペレーティング・システム上でこれらがどのような働き方をするかが解説されているが、この分野の精通者ならば理解されるように、本発明は、類似のコンポーネントを持つ他のオペレーティング・システム上で実装することが可能であり、これらのオペレーティング・システムが同じ用語を使用しているかどうかとは無関係である。例えば、別のオペレーティング・システムがファイル・オブジェクトとして動作するエンティティを持っていれば、そのエンティティはその実際の名称に関係なく、ファイル・オブジェクトと解釈することができる。
【００４０】
まず、図１を参照して説明すると、図示のシステム例は、サウンド・データのストリームをディスク・ドライブから読み取り、そのサウンド・データをレンダリング(rendering) して、従来のモデルに従ってスピーカから聞こえるようにするものである。あるデータ量はハード・ドライブ２０にストアされるが、これはディジタル化されたサウンド・サンプルの形態でサウンドを表している。ほかにも、サウンド・データ・ストリームのソースとしては、電話回線を利用して送られてくるディジタル化情報、ネットワークや他の通信パケットからのディジタル化情報、この分野で公知の他のソースが考えられる。データ・ストリームはディジタル化サンプルから構成され、これらのサンプルはデータ・フォーマットと規則によって、または各サンプルに付加される明示的タイムスタンプ情報によってタイム・インターバル情報が関連づけられている。カーネル・モードのディスク・ドライバ２２はディスク・ドライブ・ハードウェア２０と相互作用し、ユーザ・モードのリーダ(reader)プログラム・コンポーネント２４の制御下に置かれている。制御エージェント(controlling agent) ２６はサウンド・データのレンダリングを行うために異なるコンポーネントを管理するが、動的グラフ作成機能(dynamic graph building capability) を備えている場合は、異なるソフトウェア・コンポーネントが動的に割当てられて、エンド・ユーザの指定に従ってカスタム・フィルタリングまたは他の処理経路を提供できるようにする。
【００４１】
リーダ・コンポーネント２４はオペレーティング・システムの標準入出力制御インタフェースを使用してディスク・ドライバ２２と相互作用し、圧縮サウンド・データをディスク・ドライブ２０から読み取って、ユーザ・モード・プロセスのアドレス空間(address space) の一部としてユーザ・モードで割当てたバッファに入れる働きをする。次に、デコンプレッサ(decompressor)・コンポーネント２８は圧縮データを処理に適した伸張(decompressed)フォーマットに伸張する。図示のように、このステップ全体は、付随の低優先度の、プロセス動作(process behavior)安全メカニズムを使用してユーザ・モードで実行される。
【００４２】
効果フィルタ(effects filter)３０はデータに操作を加えて、ある種の特殊効果が得られるようにし、カーネル・モードで動作する附属の効果フィルタ３２をもっている。さらに、効果プロセッサ３４が存在する場合もあれば、効果フィルタ全体が実際のハードウェア・プロセッサをエミュレートするソフトウェアで動作する場合もある。効果フィルタ３２をアクセスするためには、効果コンポーネント３０はシステム入出力制御メカニズムを使用して、データと制御を効果フィルタに転送する。この場合も、カーネル・モード／ユーザ・モード境界を交差して、この遷移が行われる。
【００４３】
効果フィルタ３２は効果プロセッサ３４を制御し、必要または望ましいとされる特殊効果がそのデータ上に作られるようにする。これは、効果コンポーネント３０から全データをコピーし、そのコピーを効果フィルタ３２に、実際のシステム構成によっては、再度効果プロセッサ３４にも移すことにより行われる。多くのソフトウェア効果コンポーネントはハードウェア・プロセッサが関連づけられているが、他のコンポーネントは、ホスト・プロセッサ上で実行されるシステム・ソフトウェア内で完全に機能している。
【００４４】
効果コンポーネント３０の処理の完了時にコントロールとデータがユーザ・モードに戻されると、これは、次に、サウンド・レンダリング・コンポーネント３６に転送される。サウンド・レンダリング・コンポーネント３６はコントロールとデータをサウンド・レンダリング・ドライバ３８に転送し、これを受けてサウンド・レンダリング・ドライバは、処理され、フィルタリングされたデータをスピーカ４２からのサウンドとしてレンダリングするようにサウンド・カード４０を制御する。以上から容易に理解されるように、ユーザ・モードとカーネル・モード間の転送は多種類存在するために、サウンド・データのレンダリングを非効率化している。連続するサウンドまたはビデオ・ストリームのように、マルチメディア・データはタイミングに影響されやすい性質のため、これらの非効率性とコントロールの遷移を少なくすると共に、異なるバッファ間でなん度もデータをコピーすることを少なくすると、好都合である。
【００４５】
本明細書で用いられている本発明の一実施の形態は、Windows NTオペレーティング・システム・アーキテクチャ上で提供されるサービスから構成されている。このサービスはシステムのユーザがアクセスする、いくつかの異なるソフトウェア・コンポーネントに分割されている。第１は、ユーザ・モードのＡＰＩであり、これは、接続ピン・インスタンスと、クロック・メカニズムやバッファ割当てメカニズムなどの特定の機能を表している他のファイル・オブジェクトとを作成するためのルーチンを含んでいる。ほかにも、もっと重要なものとして、ドライバ開発者が標準化アーキテクチャに従うドライバを作成するのを支援するルーチンとデータ構造が完備されている。システムに用意されているこれらの機能を利用すると、異なるドライバ開発者は特定のアーキテクチャに準拠して相互に相互作用するコンプライアント・ドライバを作成することができる。ユーザ・モードのエージェントはＮＴエグゼクティブおよび入出力マネージャのシステム・サービスと通信する、ユーザ・モードで実行中の環境サブシステムを通してコンプライアント・ドライバと通信する。これは、他のすべての入出力に対する同じ標準入出力メカニズムであり、好適実施の形態の本実装では、既存のシステム・サービスを可能な限り利用するようになっている。
【００４６】
本発明を利用する図１のシステムのアーキテクチャは図２に示すようになっている。制御エージェント４４は知らされているドライバに照会し、データ・フォーマットと接続フォーマットに従って相互接続を行い、レンダリングを完全にカーネル・モードで行うようにする。さらに、制御エージェントは重要なイベントの通知を受けるので、必要に応じて制御を行うことができる。このようなイベントの例としては、処理の終了、データ・スターベーション事態などを含む。
【００４７】
この構成では、サウンド・データは前述したように、ディスク・ドライバ４８によってディスク・ドライブ４６から読み取られる。リーダ・ドライバ５０はディスク・ドライバ４８を制御し、従来の使い方と同じようにＮＴ層(NT layered)入出力アーキテクチャに従ってディスク・ドライバ４８と「垂直方向」に関連づけられている。「垂直方向」と「水平方向」の用語は、ＮＴ層入出力アーキテクチャの一部として現在行われているドライバ接続（垂直方向）と、ユーザ・モードのエージェントによって動的に行われる相互接続カーネル・モード・ドライバに従う接続（水平方向）とを区別するために用いられている。
【００４８】
リーダ・ドライバ５０は以下で説明する接続メソッドに従ってデコンプレッサ・ドライバ５２とも「水平方向」に相互接続され、制御エージェント４４によって管理されている。デコンプレッサ５２は伸張をカーネル・モードで行ってから、データとコントロールを効果フィルタ５４に引き渡す。効果フィルタは必要に応じて効果プロセッサ５６を利用して特殊効果を適用してからデータとコントロールをサウンド・レンダリング・ドライバ５８に引き渡し、このドライバはサウンド・カードを制御し、データをスピーカ６２からのサウンドとしてレンダリングする。図２から理解されるように、処理をカーネル・モードのままにしておくと、ユーザ・モードとカーネル・モードとの間の複数の遷移がなくなり、処理をユーザ・モードで行うと通常起こるオーバヘッド量が減少するので、効率面の利点が得られる。
【００４９】
次に、図３を参照して説明する。図３は、本発明の一実施の形態に従う相互接続ソフトウェア・ドライバに関係するシステム・オブジェクトの階層的性質を示すロジック図である。ドライバ・オブジェクト６４は、メモリにロードされるときの、実行可能ソフトウェア・コード・イメージを表すために作成される。ドライバ・コード・イメージはドライバの機能全体を含んでおり、ドライバ・オブジェクト６４はシステムに置かれている場所、サポートされるドライバの種類などのイメージに関する情報を含んでいる。
【００５０】
制御エージェントによって独立にアクセスできる機能の各タイプ別に、デバイス・オブジェクト６６a 〜６６N が入出力ディレクトリ構造に作成され、これらのオブジェクトは利用可能で、ユーザ・モードのクライアントによってアクセスされる異なる機能を表している。これらは、フィルタまたは独立に利用できる他の機能部分を表しているのが代表的である。ドライバ・オブジェクト６４とデバイス・オブジェクト６６a 〜６６N は囲みボックス６８で示すように、ドライバ・コードのインストール時に作成される。
【００５１】
歴史的には、デバイス・オブジェクトは物理ハードウェアの各エレメントごとに存在する。しかるに、最新の入出力システムの柔軟性は、デバイス・オブジェクトが完全にソフトウェアで実装されたフィルタを表すことを可能にさせている。そのため、デバイス・オブジェクトは専らソフトウェアで実装されたフィルタの各インスタンスごとに作成することが容易になっている。従って、ソフトウェア・フィルタは、デバイス・オブジェクトで表された各インスタンスがデバイス・オブジェクトと１対１の対応関係をもつように実装することも、単一のデバイス・オブジェクトがより伝統的な手法に従い、各々がフィルタのクライアント・インスタンスを表している複数のファイル・オブジェクトを管理するように実装することも可能になっている。
【００５２】
デバイス・オブジェクト、図示の例では、デバイス・オブジェクト６６a 上には、ファイル・オブジェクトが作成され、これはデバイス・オブジェクトで表された機能の独立インスタンスを表している。デバイス・オブジェクトはフィルタを表し、そのフィルタの複数のインスタンスを管理するのに対し、ファイル・オブジェクトは特定のエンティティによって使用される、そのフィルタの実際のインスタンスを表している。従って、ファイル・オブジェクト７０はデバイス・オブジェクト６６a によって定義されたフィルタのインスタンスである。
【００５３】
フィルタを使用するには、制御エージェントまたは他のユーザ・モード・クライアントは入出力ディレクトリ構造内で利用可能なデバイス上でファイルをオープンする。適切なコンテキスト情報を収めているファイル・オブジェクトが作成され、そのファイルへのハンドルがユーザ・モード・クライアントに返される。ファイル・オブジェクトは、作成時に「親」ファイル・オブジェクトを指定することによって階層的に関係づけることが可能であるが、ファイル・オブジェクトはすべてが同一デバイス・オブジェクトの子であるような、兄弟(sibling) 関係も持っている。
【００５４】
ファイル・オブジェクト内のコンテキスト情報は、ユーザ・モード・クライアントとの入出力インタフェースを管理する情報、ファイル・オブジェクトが表わしているエンティティの「状態(state) 」などからなっている。コンテキスト情報には、システムが必要とする情報があり、さらに、特殊な意味をもたせることができる、ユーザ定義可能エリアも含まれている。ユーザ定義可能エリアの使い方の例は、下述するバリデーション(validation)とＩＲＰルーチング(routing) ・メソッドのインプリメーテンションの説明個所に示されている。
【００５５】
接続ピン・インスタンスを提供するためには、フィルタ・インスタンスを表すファイル・オブジェクト７０が親として使用され、特定フィルタの接続ピン・インスタンスを表す子ファイル・オブジェクトが作成される。ファイル・オブジェクト７０は接続ピン・ファクトリの定義と可用性に関して照会されるのに対し、実際のファイル・オブジェクトは特定のファイル・オブジェクトを適切な情報コンテキストとして使用して、ピン・ファクトリの各インスタンスごとに作成され、接続ピン・インスタンスが有効に、かつ正しく作成されるようにする。例えば、ファイル・オブジェクト７２と７４はファイル・オブジェクト７０で表されたフィルタの接続ピン・インスタンスを表し、ファイル・オブジェクト７０と階層的に関係づけられている。それぞれファイル・オブジェクト７２と７４で表された接続ピン・インスタンスはフィルタ・インスタンス（ファイル・オブジェクト７０で表されている）に入ったあとで、そこから出るデータ・パスにすることができ、これは一連のチェイン・フィルタまたは他のドライバ機能を形成するときに他の接続ピン・インスタンスと接続するために使用できる。
【００５６】
ピン・インスタンスがフィルタ・インスタンスを表す別のファイル・オブジェクトと階層関係をもつファイル・オブジェクトで表されて、ピン・インスタンスのコンテキスト情報を提供するようにするのとまったく同じように、他のファイル・オブジェクトをピン・インスタンスと階層的に関係づけて他の機能を表すようにすると、正しいコンテキスト情報が得られるようになる。コンテキスト情報は、ピン・データ・フォーマット、通信タイプなどのように、作成時に使用される個々のパラメータに従って、あるピン・インスタンスを他のピン・インスタンスと区別するために必要である。
【００５７】
バッファ割当てメカニズム、タイミング・メカニズムなどのように、個別コンテキストかユーザ・モードのコントロールのどちらかをハンドルを通して要求する他の操作エンティティも、ファイル・オブジェクトで表すことができる。さらに、ファイル・オブジェクト（例えば、特定の接続ピン・インスタンスと関連づけられたバッファ割当てメカニズム）間の階層関係は、必要ならば、子ファイル・オブジェクトの作成時に親ファイル・オブジェクトを指定することにより確立することができる。これらの親子関係は、操作エンティティを表すファイル・オブジェクト間の関係と構造を決定するために存在する。さらに、特定タイプの「親」ファイル・オブジェクトはある種のタイプの「子」ファイル・オブジェクトだけを作ることができるので、以下で説明するように作成バリデーション・メカニズムが必要になる。この場合も、このようなファイル・オブジェクトは対応するハンドルがユーザ・モードで利用可能になっており、これらのハンドルはNtCreateFileなどのシステムＡＰＩコールを通してクライアントに返される。
【００５８】
ファイル・オブジェクトへのハンドルはカーネル・モード・ドライバと通信するために、制御エージェントなどのユーザ・モード・クライアントによって使用される。ファイル・オブジェクト、デバイス・オブジェクト、およびドライバ・オブジェクトの階層的チェインは、入出力サブシステムが階層関係をもつファイル・オブジェクトとデバイス・オブジェクトを通ってドライバ・オブジェクトまで戻り、実際のドライバ・コードに入るエントリ・ポイント(entry point) に到達することができるようにする。このようなエントリ・ポイントはソフトウェア・ドライバ・コードの中の機能を指す参照（例えば、ポインタ）になっている。さらに、特定のファイル・オブジェクトと、ソフトウェア・ドライバ・コードへのエントリ・ポイントをもつドライバ・オブジェクトとの間のオブジェクト通路(pathway) 上にあるオブジェクトの各々は、入出力サブシステムがＩＲＰを作成するときに重要なコンテキスト情報のほかに、下述するルーチングおよびバリデーション・メカニズムに従ってＩＲＰを正しくルーチングするときに使用されるデータ構造への参照も提供する。
【００５９】
ファイル・オブジェクトと他のシステム・オブジェクトに対するハンドルはプロセス専用であり、ユーザ・モード・プロセスが基礎となるオブジェクトと通信するときの手段となる。注目すべきことは、ファイル・オブジェクトなどの、基礎となる単一システム・オブジェクトを参照するために複数のハンドルが作成できることである。このことは、複数のアプリケーションがファイル・オブジェクトで表されたピン・インスタンスに情報を供給できることを意味する。
【００６０】
異なるドライバを相互接続するとき重要となる情報エレメントの１つとして、デバイス・オブジェクト・スタックの深さ(depth) パラメータがある。これは特定のドライバ・オブジェクトのＩＲＰスタック・ロケーションを示している。このようにすると、入出力マネージャを使用して、相互接続されたドライバ間で単一のＩＲＰを使用し受け渡しできるので、ＩＲＰを別々に作成し、それを種々の相互接続ドライバ間で送信するよりもパフォーマンス向上を提供できることになる。別の方法として、各ドライバは適切な入出力マネージャのコールを通して、各連続通信ごとに新しいＩＲＰを作成し、各々の新ＩＲＰを相互接続されたドライバのチェイン上の次のドライバへ送信させることも可能である。
【００６１】
次に、図４〜図６を参照して説明する。図は、異なるタイプのファイル・オブジェクト作成のバリデーションと適切なハンドラへの入出力要求パケット（I/O Request Packet：ＩＲＰ）のルーチングを可能にするシステム・ドライバ・オブジェクト、デバイス・オブジェクト、およびファイル・オブジェクトのエクステンションを示している。図４は、１つまたは２つ以上のフィルタまたは他のドライバ機能を実装している実行可能コードを表すドライバ・オブジェクト７６を示している。ドライバ・オブジェクト内では、Windows NTアーキテクチャはソフトウェア・ドライバ開発者が用意した作成ハンドラへの参照を要求している。この実施の形態によれば、マルチプレクシング・ディスパッチ機能(multiplexing dispatch function)７８は作成ハンドラとしてドライバ・オブジェクト７６から参照され、メッセージを作成されるファイル・オブジェクトのタイプに応じて特定の作成ハンドラへルーチングするために使用される。マルチプレクシング・ディスパッチ機能７８のオペレーションは図８に示すフローチャートを参照して以下で説明する。
【００６２】
同じように、ドライバ・オブジェクトからの他のハンドラはマルチプレクシング・ディスパッチ機能を示し、どのように実装するかに応じて、これらは同じ機能にすることが可能である。言い換えれば、以下で詳しく説明するように、各タイプの入出力ハンドラ参照（例えば、読取り、書込み、デバイス制御など）はデバイス・オブジェクト内のエクステンション・データとファイル・オブジェクト内のコンテキスト情報を使用して、メッセージを適切なハンドラへルーチングするマルチプレクシング・ディスパッチ機能を指している。バリデーション・テーブルを参照するデバイス・オブジェクト内のエクステンション・データは、作成オペレーションで親ファイル・オブジェクトの指定がないとき使用される。指定があれば、親ファイル・オブジェクトのコンテキスト情報は正しいバリデーション・テーブルを示している。
【００６３】
図５は、ドライバ開発者によって所望により利用でき、ドライバ専用情報を含んでいる特定のデバイス・エクステンション・エリア８２をもつドライバ・オブジェクト８０を示している。ドライバ・オブジェクト８０のデバイス・エクステンション・エリア８２内の定義されたロケーションには、ファイル・タイプ・バリデーション・テーブル８４と呼ばれ、ファイル・オブジェクト・タイプ８６のストリング表現を含んでいるデータ構造への参照と、表現される各ファイル・タイプ別の関連する作成ハンドラ８８への参照が置かれている。作成マルチプレクシング・ディスパッチ機能はファイル・タイプ・バリデーション・テーブル８４を使用して、作成されるファイル・オブジェクト・タイプを検査し、そのあと、コントロールを適切な作成ハンドラへ引き渡す。これについては、以下の図８の説明個所で詳しく説明する。検査されるストリングはＩＲＰ作成要求に見出され、ユーザ・モードのNtCreateFile関数コールと共に使用されるファイル名ストリングから創られる。NtCreateFile関数コールは、ピン・インスタンスまたは他のメカニズムを作成するためにユーザ・モード関数セルの中で行われる。
【００６４】
図６は、ソフトウェア・ドライバ開発者が使用するために解放されているファイル・コンテキスト・エリア９２をもつファイル・オブジェクト９０を示している。参照はファイル・コンテキスト・エリア９２からＩＲＰ要求ハンドラ・テーブル９４へ行われる。ＩＲＰ要求９６の異なるタイプは特定のハンドラ９８と関連づけられ、適切なマルチプレクシング・ディスパッチ機能はこの情報を使用して正しいハンドラにアクセスする。正しい作成ハンドラを決定する場合には、ファイル・タイプ・バリデーション・テーブル１００と呼ばれるデータ構造が参照され、そこには、ファイル・オブジェクト・タイプ１０２のストリング表現と、表現される各ファイル・タイプ別の関連する作成ハンドラへの参照１０４が入っている。子ファイル・オブジェクト（つまり、デバイス・オブジェクトではなく別のファイル・オブジェクトを親としてもつファイル・オブジェクト）の場合は、タイプはファイル・オブジェクト・タイプ１０２内のストリングと比較されるストリングで表されている。一致するものが見つかると、関連する作成ハンドラは、参照１０４のうち、一致したファイル・オブジェクト・タイプ・ストリングと関連づけられている参照を使用してアクセスされる。一致するものが見つからなければ、要求は無効であるので、エラー表示が出されることになる。
【００６５】
次に、図７を参照して説明すると、図は作成バリデーションとメカニズムをセットアップするためのインストレーション・プロシージャを示している。ステップ１０６で、インストール・プログラムは適切なマルチプレクシング・ディスパッチ機能への参照をドライバ・オブジェクトの中に作成する。図４に示すように、作成ハンドラは汎用マルチプレクシング・ディスパッチ機能を指している。同様に、ドライバ・オブジェクト７６の中の他のすべてのハンドラ参照は、特定ハンドラと密接な関係をもつ他の汎用(generic) マルチプレクシング・ディスパッチ機能を必要に応じて指している。別の方法として、各ハンドラ参照は同一マルチプレクシング・ディスパッチ機能を指すことも可能であり、その場合は、このディスパッチ機能はＩＲＰ要求を処理したあと、それを適切なハンドラへルーチングすることができる。この方法によるマルチプレクシング機能は異なる種類の要求（例えば、作成、書込みなど）を受け付ける必要があるため、複雑化することが避けられない。
【００６６】
次に、ステップ１０８で、ソフトウェア・ドライバ実行可能コードのインストールの一部として作成された各デバイス・オブジェクトは、図５に示すようにファイル・タイプ・バリデーション・テーブル８４を参照するように調整される。最後に、ステップ１１０で、ＩＲＰ要求の処理は、適切なデバイス・オブジェクト８０から参照されたファイル・タイプ・バリデーション・テーブル８４を使用してマルチプレクシング・ディスパッチ機能から開始される。
【００６７】
ファイル・オブジェクトが作成されると、適切なＩＲＰディスパッチ・テーブル９４が作成され、必要ならば、インデックスされたファイル・オブジェクト・タイプ・バリデーション・テーブル１００と一緒に参照される。ファイル・オブジェクト・タイプ・バリデーション・テーブルの作成は、ファイル・オブジェクト・タイプに従って用意された作成ハンドラ内で行われる。データ構造が作成され、これはＩＲＰディスパッチ・テーブル９４とファイル・オブジェクト・タイプ・バリデーション・テーブル１００を表しており、それを指す参照は作成される特定ファイル・オブジェクト９０のファイル・コンテキスト情報９２と一緒に特定ロケーションにストアされる。
【００６８】
次に、図８を参照して説明すると、図は作成マルチプレクシング・ディスパッチ機能のオペレーションとそのバリデーション・メカニズムを示すフローチャートであり、そこには、システム・ドライバ・オブジェクト、デバイス・オブジェクト、およびファイル・オブジェクトから参照されるデータ構造との相互作用も示されている。ステップ１１２で、ユーザ・モード・プロセスはファイル・オブジェクトを作成する入出力要求を送信する。この入出力作成要求はNtCreateFileのシステムＡＰＩを呼び出すことによって行われる。ステップ１１４で、入出力マネージャはドライバ・オブジェクト７６内の参照に基づいてＩＲＰをマルチプレクシング・ディスパッチ機能７８に送信する（図４参照）。
【００６９】
マルチプレクシング・ディスパッチ機能７８が作成要求のＩＲＰを受け取ると、ステップ１１６でテストが行われ、親ファイル・オブジェクトがあるかどうかが判断される。この判断を行うために必要な情報はＩＲＰ自体の中にあるが、これはユーザ・モード・プロセスによって元来用意されたものである。ユーザ・モード・プロセスは「親」ファイル・オブジェクトを参照するハンドルを作成要求の一部として用意し、ＮＴシステムは「親」ファイル・オブジェクトへの正しい参照をもつＩＲＰを作成する。
【００７０】
親ファイル・オブジェクトがなければ、右へのブランチがとられ、マルチプレクシング・ディスパッチ機能７８は適切なデバイス・オブジェクト８０からのデバイス・エクステンション８２を使用して、ファイル・タイプ・バリデーション・テーブル８４をステップ１１８で参照する（図５参照）。バリデーション・テーブル８４を使用して、マルチプレクシング・ディスパッチ機能７８は要求の中のストリングをファイル・オブジェクト・タイプ８６のストリングと比較することによって、ステップ１２０でファイル・オブジェクト・タイプを検査する。
【００７１】
ステップ１２２でストリングが一致していると判断されると、適切な作成ハンドラがステップ１２４でアクセスされる。一致していなければ、作成要求はステップ１２６で拒否される。ステップ１２４でアクセスされた作成ハンドラはステップ１２６でファイル・オブジェクトを作成するか、あるいは作成させる。作成されたファイル・オブジェクトを使用して、適切な作成ハンドラは、以前に作成していたＩＲＰディスパッチ・テーブル９４を指すファイル・オブジェクト参照をファイル・コンテキスト９２の中に作成する。
【００７２】
再びステップ１１６に戻って、親ファイル・オブジェクトが存在するかどうかが判断される。親ファイル・オブジェクトが存在するとステップ１１６で判断され、それが作成要求に関連するＩＲＰに入っていれば、マルチプレクシング・ディスパッチ機能７８は親ファイル・オブジェクト９０からのファイル・コンテキスト９２を使用して、ステップ１３０でＩＲＰディスパッチ・テーブル９２を参照する（図６）。作成要求の場合は、マルチプレクシング・ディスパッチ機能７８はステップ１３２でファイル・タイプ・バリデーション・テーブル１００を参照する。ファイル・タイプ・バリデーション・テーブル１００を使用して、マルチプレクシング・ディスパッチ機能７８は、上記と同じように、要求の中のストリングをファイル・オブジェクト・タイプ１０２のストリングと比較することによってステップ１３３でファイル・オブジェクト・タイプを検査する。
【００７３】
ストリングが一致しているとステップ１３４で判断されると、適切な作成ハンドラがステップ１３８でアクセスされる。一致していなければ、作成要求はステップ１３６で拒否される。適切な作成ハンドラを使用して、ファイル・オブジェクトは１４０で作成され、作成ハンドラは新しく作成されたファイル・オブジェクトの新しいＩＲＰディスパッチ・テーブル９４を作成し、新しく作成されたＩＲＰディスパッチ・テーブル９４を指す参照を新しく作成されたファイル・オブジェクト９０のファイル・コンテキスト・エリア９２の中にステップ１４２で作成する。注意すべきことは、親ファイル・オブジェクトおよび有効に作成された子ファイル・オブジェクトとの相互作用を説明するために、どちらの場合も、図６に示す同じファイル・オブジェクト構造が使用されていることである。どちらの場合も同じ構造が存在するが（新しいファイル・オブジェクトが作成されたあと）、これらはその使い方が異なり、含んでいる情報も異なっている。
【００７４】
接続ピン・インスタンスが作成されるといつでも、接続ピンＩＤが引き渡され、これはピン・インスタンスの作成を「サポート」するファイル内のピン・ファクトリを示している。この分野の精通者ならば理解されるように、接続ピンＩＤは、ファイル・オブジェクトが検査されるのとまったく同じように、バリデーションテーブルでストリングとして検査することも可能であり、また、その実装方法もさまざまである。
【００７５】
異なるドライバ間の接続を行うためには、あるドライバがそのような相互接続をサポートしていることを確かめるための共通メカニズムが必要である。この共通メカニズムは、接続ピン・ファクトリ機能を含むフィルタ機能を明らかにすることを可能にするものでなければならない。さらに、この種のメカニズムは、ドライバ開発者の柔軟性を向上するように拡張可能であることも必要である。
【００７６】
コンプライアント・ドライバを定義し、機能を明らかにすることを可能にするために本実施の形態で選択されている１つのメカニズムは関連アイテムの「集合」と名づけられている。これは既存の入出力通信メカニズムと一緒に使用すると便利なメカニズムである。集合は集合全体を特定するＧＵＩＤ（グローバルにユニークな識別子）と集合内の各機能エレメントのＲＵＩＤ（相対的にユニークな識別子、例えば、集合自体内の相対的な識別子）を持つものとして論理的に定義されている。集合識別子および選択されたＲＵＩＤアイテムと一緒にオペレーションするために必要な他のデータ構造は、フィルタ・ハンドルをパラメータとして使用して入出力制御コールの一部として引き渡される。機能の完全なシステムを実装するためには、少数のＩＯＣＴＬを割当てるだけで十分である。実装されるとき、３つの異なる種類の集合がその機能に応じて確立されるので、必要になるＩＯＣＴＬは総計４個である。他の実装では、集合の使い方が異なる場合がある。特定のＩＯＣＴＬは、選択されたエレメント（ＲＵＩＤを使用する）をなんらかの方法で解釈または使用するように入出力制御のハンドラに通知する。さらに、制御フラグをＧＵＩＤおよびＲＵＩＤと一緒に渡して、制御情報をもっと詳しく指定することができる。
【００７７】
最初の集合タイプはプロパティ集合であり、これはドライバ内または関連ハードウェア上に置かれている値または設定値と一緒に使用される。そのような設定値の例としては、転送レート、ボリューム・レベル（音量）などがある。１つのＩＯＣＴＬがプロパティ集合と関連づけられ、制御フラグは"get" プロパティ・コマンドと"set" プロパティ・コマンドとを区別している。このようにすると、同じデータ構造が特定のプロパティを設定または取得するように使用でき、ドライバは必要なアクションを使用されたＩＯＣＴＬに基づいて決定することができる。正しいプロパティは、ユニークなＧＵＩＤとＲＵＩＤの組合せからなる集合識別子(set identifier)によって特定される。
【００７８】
メソッド集合は使用されるもう１つの集合タイプであり、これはドライバによって実行できるアクションの集合である。メソッド集合を特定するために必要なＩＯＣＴＬは１つだけであり、アクチュエートされる正しいメソッドは集合識別子のユニークなＧＵＩＤとＲＵＩＤの組合せによって特定される。メソッドはドライバを制御するために使用され、ドライバを使用するための初期化、バッファのクリアといった機能を含んでいる。
【００７９】
イベント集合は、デバイス変更通知、データ・スターベーション通知などのドライバ処理や、ユーザ・モード・アプリケーションで使用すると便利である集合によって定義された他の通知に関連するイベントを管理するために使用される。２つのＩＯＣＴＬが使用され、１つは特定のイベントをイネーブルにするためのものであり、もう１つは特定のイベントをディスエーブルにするためのものである。ＲＵＩＤで識別された、与えられたイベントに必要なデータ構造は、イベントをイネーブルにするか、ディスエーブルにするかに関係なく共用することができる。
【００８０】
集合を使用するには、入出力制御オペレーションは特定のＩＯＣＴＬおよび集合ＧＩＤ、 ＲＵＩＤをもつデータ構造と他の必要なデータ（例えば、制御フラグ、データ構造など）を指す参照を使用して開始される。例えば、サウンド・カード・ドライバでボリューム・プロパティを設定することは、入出力制御オペレーションをプロパティ集合ＩＯＣＴＬ、集合プロパティ・オペレーションを示す制御フラグ、ボリューム設定値をもつプロパティ集合の適切なＧＵＩＤ、ボリューム・プロパティを示しているその集合内の特定ＲＵＩＤ、および新しいボリューム設定値を使用することを必然的に伴なう。
【００８１】
サポートされる集合についてタイプ別に照会するには、ヌルＧＵＩＤとサポートされる集合の列挙を示す制御フラグとをもつ、特定の集合タイプのＩＯＣＴＬ（例えば、プロパティＩＯＣＴＬ、メソッドＩＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）が入出力コマンドの一部として出され、サポートされる集合ＧＵＩＤのリストが返される。ある集合内のサポートされるプロパティ、メソッドまたはイベントについて照会するには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、ヌルＲＵＩＤ、およびサポートされるエレメントの列挙を示す制御フラグが入出力オペレーションと共に使用される。サポートされるＲＵＩＤのリストは入出力オペレーションの結果として返される。このリストから、ユーザ・モードのエージェントは、実装されている集合のどのオプション・エレメント（もしある場合）がサポートされるかを判断することができる。
【００８２】
ＧＵＩＤでユニークに識別された集合の仕様書は、ドライバ開発者とユーザ・モードのエージェントのどちらもが実装ガイドとして利用できるメカニズムをドキュメント化している。サード・パーティ開発者は、あるドライバの機能を照会に対する応答に基づいて知り、事前プログラムされた知識を抽象的集合定義に基づいて知ることになる。同様に、ドライバ開発者は、知った機能をどのようなユーザ・モードのエージェントに対して提供する集合または集合グループを実装するときのガイドとして抽象的集合定義を使用することができる。
【００８３】
ここで説明している接続機能を提供するためには、コンプライアント・ドライバはある種の集合をサポートしていなければならない。以下の表は、プロパティ集合フォーマットでサポートされ、本発明を実装するときに使用できるいくつかの重要な情報を示している。最初の表は、フィルタによって実装される接続ピン・ファクトリに関するプロパティに関し、２番目の表は、特定の接続ピン・ファクトリをテンプレートとして使用して作成される実際の接続ピン・インスタンスに関するプロパティを示している。
【００８４】
【表１】
【００８５】
【表２】
【００８６】
【表１】
【００８７】
【表２】
【００８８】
【表５】
【００８９】
【表３】
【００９０】
上記の表は単なる例示であり、これに限定されるものではない、この分野の精通者ならば理解されるように、異なるドライバ間の接続を作成するためには多数の異なるプロパティとスキーマを実装することが可能である。１つの重要な要素は標準化係数(standardization factor)であり、異なるドライバ製造者または開発グループは同一のプロパティ集合を実装する能力をもっているので、相互接続できるドライバを作成できるようにすることである。
【００９１】
もう１つの有用なプロパティ集合は、あるフィルタ上の入力と出力の接続ピン・ファクトリの内部関係に関するトポロジ情報を与える。この情報はあるフィルタ上の入力ピン・ファクトリおよび対応する出力ピン・ファクトリの関係だけでなく、入力と出力のピン・ファクトリの間でどのようなタイプの処理が行われるかも記載している。行われる処理の例としては、異なるデータ変換、データ伸張、エコー打消し(cancellation)などがある。このような情報は複数のフィルタを使用して仮定上の接続パスをトレースしてから実際の接続ピン・インスタンスおよび接続を作成する自動化フィルタ・グラフ作成機能で使用すると、便利である。基本的には、トポロジ情報はフィルタの内部構造を説明し、これをプロパティ集合メカニズムを通してユーザ・モードのエージェントからの照会に公開する。
【００９２】
従って、コンプライアント・ドライバは指定されたプロパティ集合を実装しているものにすぎない。そのため、ユーザ・モードのエージェントは、あるプロパティ集合がサポートされていることが分かったとき、コンプライアント・フィルタに対し照会と設定を行うことができる。全体目標は、異なるフィルタを１つに接続してフィルタ・グラフを作る方法に関する十分な情報を得ることである。
【００９３】
汎用集合メカニズムを使用すると、最小限の機能を実装してコンプライアント・ドライバのシステムをサポートできるが、その場合でも、拡張性は無制限である。集合は、特定の集合が実装されている限り、相互操作可能で相互接続可能なドライバのシステムを作成するために多数の異なるドライバ開発者によって独立にコーディングできる仕様書の中で定義することができる。さらに、この仕様書には、サポートしなければならない必須のプロパティ、メソッド、およびイベントを定義できるだけでなく、ドライバ機能と拡張機能に応じて実装できるオプションのプロパティ、メソッド、およびイベントも定義できる。最小限に要求される基本的共通性のほかに、ドライバ開発者は独自の集合を定義し、これらにＧＵＩＤを割当てることにより追加の機能を組み入れることも可能である。
【００９４】
次に、図９および図１０を参照して説明する。図は２つのカーネル・モード・フィルタを接続するプロセスを図形化して示している。図９はロジック・ブロック説明図であり、そこでは各フィルタ・インスタンスと接続ピン・インスタンスはファイル・オブジェクトで表されている。図１０はファイル・オブジェクトおよび適切な接続を作成するときのステップを示すフローチャートである。
【００９５】
ステップ１４４からスタートして、フィルタＡ１４６のインスタンスおよびフィルタＢ１４８のインスタンスはユーザ・モードのエージェントによって作成される。これらは特定のデバイスでファイルを作成する標準ファイル・システムＡＰＩを使用して作成される。フィルタＡ１４６とフィルタＢ１４８がコンプライアント・フィルタまたはドライバとなっているのは、これらが適切なプロパティ、メソッド、およびイベント集合を実装して接続ピン・インスタンスの作成をサポートし、サポートされる集合とそのフィルタ用に定義された接続ピン・ファクトリに関してそれぞれのフィルタの機能に照会するようになっているからである。
【００９６】
ユーザ・モードのエージェントは、ステップ１５０でフィルタＡ１４６とフィルタＢ１４８にそれぞれ照会し、利用可能な接続ピン・ファクトリおよびそれから作成できる接続ピン・インスタンスの属性を判断する。これらの属性には、前述したように、各フィルタ１４６と１４８のそれぞれのピン・ファクトリのタイプ別の接続フォーマットとデータ・フォーマットがある。照会は、以下で詳しく説明する集合ベース照会メカニズムを使用して行われる。
【００９７】
上記情報の照会を終えると、ユーザ・モードのエージェントは、以前に照会したデータ・フォーマットと接続フォーマットの範囲に基づいて最適接続フォーマットを決定する。この決定はステップ１５２で行われ、選択した接続パスの要求事項に応じて同じフィルタをユーザ・モードのエージェントが異なった使い方をできるようにする。ユーザ・モードのエージェントはデータ交差プロパティ(data intersection property)、トポロジ情報、および接続ピン・ファクトリを両方のフィルタで使用して、作成される実際のフィルタ・グラフに応じてデータ・フォーマットと接続配置の最良の選択方法を決定する。
【００９８】
入力フィルタ・ピン・インスタンス１５４はステップ１５２で判断された最適検出情報を使用して、ステップ１５６でユーザ・モードのエージェントによって作成される。入力ピン・インスタンス１５４はファイル・オブジェクトであるので、ハンドルが作成プロセスから返されるが、これは入出力要求を入力インスタンス１５４へ送るために使用できる。さらに、入力ピン・インスタンス１５４の作成が有効性の検査をされているが、この作成には、図４〜図６、図７および図８を参照して前述したルーチングおよびバリデーション・メカニズムが使用される。
【００９９】
接続を完成するために、出力ピン・インスタンス１５８は、以前に作成された入力ピン・インスタンス１５４のハンドルをNtCreateFileコールの中でパラメータとして使用してステップ１６０で作成される。出力ピン・インスタンス１５８がこのようにして作成される効果として、システム・ファイル管理機能と入出力管理機能を使用して内部ＩＲＰスタック構造が作成される。このスタック構造により、オリジナルの書込みコマンドは、さまざまな方法で接続された接続ピン・インスタンスとフィルタによって適当な順序で連続処理することが可能になるので、異なるフィルタ間の直接データ・フローが容易化される。これを行うためには、入力ピン・インスタンスを供給する関連出力ピン・インスタンスの前に入力ピン・インスタンスが作成されていることが必要である。
【０１００】
デバイス・オブジェクトのスタック深さパラメータは、このドライバに送られるＩＲＰ用にスタック・ロケーションをいくつ作成するかを制御する。スタック深さパラメータは、デバイス・オブジェクトが初めて作られるときは１つであると想定されているが、複数のドライバが１つにチェイニングされているかどうかに応じて、あとで変更することも可能である。現システムでは、この変更は、必要ならば、出力ピン・インスタンスが初期「停止」状態から「取得」または他の状態に遷移するとき行われる。接続ピン・インスタンスの状態遷移はＩＲＰを正しく作成し、処理するための正しいスタック深さパラメータ情報を決定するメカニズムである。
【０１０１】
チェイニングされた接続ピン・インスタンス集合を正しく割当てるためには、接続ピン・インスタンスを特定の順序で停止状態から出るように遷移させる必要がある。つまり、最後の入力ピン・インスタンス（この例では、入力ピン・インスタンス１５４）から始まって、関連の（例えば、接続された）出力ピン・インスタンス（この例では、出力ピン・インスタンス１５８) まで連続的に逆方向に戻っていく必要がある。多数のフィルタが１つにチェイニングされていれば、最も深いフィルタまたはブリッジの入力ピン・インスタンスが遷移の開始ポイントであって、ブリッジまたはフィルタ上の初期出力ピン・インスタンスが設定されるまで逆方向に連続的に構築していかなければならない。言い換えれば、停止状態から出る遷移はチェインを逆昇るように行われ、各接続ピン・インスタンスが前の接続ピン・インスタンスの後で必要になるスタック・サイズを得るようにしなければならない。代表例として、必ずしもそうする必要はないが、接続ピン・インスタンスは停止状態から取得状態へ遷移するが、以下での説明の便宜上、取得状態への遷移はスタック深さパラメータの調整に関しては、停止状態から出る遷移と同じ目的を果たすようになっている。
【０１０２】
すべてのピン・インスタンスが取得状態になったあとは、ストリーム読取りと書込みをフィルタ・グラフに対して出すことができる。なお、注目すべきことは、ここで説明しているシステムが、関連入力と出力ピン・インスタンスの接続をどの順序でも行うことができ、停止状態からの遷移だけはボトムアップ方式、つまり、最も深いものから先に行わなければならないことである。さらに、フィルタ・グラフは初期作成後に変更が行えるように再構成可能になっている。変更が行われるときは、状態遷移は停止状態にある接続ピン・インスタンスだけで行い、正しいスタック深さパラメータ情報が得られるようにする必要がある。
【０１０３】
フィルタ上に見出される接続ピン・ファクトリは、フィルタが特定フォーマットでデータを消費および／または作成できる場所を表している。例えば、特定の接続ピン・ファクトリは、１６ビットの４４キロヘルツＰＣＭオーディオや８ビットの２２キロヘルツＰＣＭオーディオなどの、いくつかの異なるデータ・フォーマットをサポートすることができる。前述したように、接続ピン・ファクトリやそのデータ・フォーマットなどの異なる機能については、適切なプロパティ集合メカニズムとシステム入出力機能を使用してフィルタから照会することができる。実際の接続ピン・インスタンスはピン・ファクトリから受信した情報に基づいて作成される。
【０１０４】
単一のストリーム書込みまたはストリーム読取りオペレーションがユーザ・モード・エージェントから出されると、接続されたフィルタを通してデータの連続処理が行われるストリーミング環境では、ＩＲＰ制御用の２つのメイン・メソッドがＮＴオペレーティング・システムのネーティブ機能の一部として使用することができる。第１のメソッドでは、個別ＩＲＰは各フィルタによって作成され、次のフィルタへ送られて処理され、このフィルタは新しいＩＲＰを作成し、チェインを下って次々と処理されていく。他のメソッドでは、単一のＩＲＰが使用され、入出力マネージャと相互作用するために用意された標準プロシージャを使用して連続フィルタ間で受け渡しされていく。チェイン上の各連続フィルタごとに新しいＩＲＰを作成していく第１のメソッドが使用される場合は、フィルタ間の相互接続順序が重要でないのは、フィルタはＩＲＰのデスティネーション(destination) だけを知っていればよく、入出力マネージャをコールしてＩＲＰを指定のフィルタへ送ることができるからである。ＩＲＰが再使用される場合に重要なことは、停止状態からの接続ピン・インスタンスの遷移が再使用ＩＲＰを受け取る最後のフィルタから始まるように行われ、再使用ＩＲＰを受け取る最初のフィルタまで、または処理のためにＩＲＰを作成したフィルタまで逆方向に処理していくことである。
【０１０５】
相互接続カーネル・モード・フィルタの本実施の形態と実装例は、ＩＲＰ共用を利用してドライバ開発の複雑さを軽減し、より堅牢なドライバが作成されることを可能にし、処理を効率化するという利点がある。「ボトム・アップ」のピン・インスタンス状態遷移パスは、正しいスタック順序が連続ドライバによって処理されるＩＲＰに作成され、各ドライバ・オブジェクトが適切なスタック深さパラメータ集合をもつことを保証する。さらに、受信側入力ピン・ファクトリの現状態は、状態遷移シーケンスを正しくたどっていたかどうかを確かめるためにチェックされる。そのような理由から、特定の接続ピン・ファクトリの通信プロパティは起こり得るフロー方向を判断し、接続ピン・インスタンスの状態遷移を正しく分配する上で支援する。
【０１０６】
出力ピン・インスタンス（またはＩＲＰソース）を作成するとき、別のフィルタ上の入力ピン・インスタンス（またはＩＲＰシンク(sink)）を表すファイル・オブジェクトへの参照はNtCreateFileコールの一部として引き渡される。適切な作成ハンドラはマルチプレクシング・ディスパッチ機能とデバイス・オブジェクト／ファイル・オブジェクト階層を使用して、前述したように実行される。この作成ハンドラは入力ピン・インスタンスをもつフィルタ（例えば、図９のフィルタＢ１４８）のデバイス・オブジェクトを、入力接続ピン・インスタンス・ファイル・オブジェクト（例えば、入力ピン・インスタンス１５４）を通してアクセスすることができる。デバイス・オブジェクトから、前のスタック深さパラメータを読み取ることができ、出力ピン・インスタンスをもつフィルタのデバイス・オブジェクトのスタック深さパラメータが増加される。例えば、フィルタＡ１４６に関連するデバイス・オブジェクトは、図９に示す接続ではフィルタＢ１４８に関連するデバイス・オブジェクトのそれから増加されるスタック深さパラメータをもっている。これは停止状態から出る遷移のとき行われるのが通常であり、ＩＲＰは接続ピン・インスタンスが停止状態にある間はルーチングされない。
【０１０７】
フィルタがＩＲＰを処理するとき、その特定フィルタ用に指定された情報を含んでいる、ＩＲＰスタック内のどのスタック・フレームまたはロケーションをアクセスすべきかを、関連デバイス・オブジェクトのスタック深さパラメータを参照するか、あるいはそれを使用することによって知る。さらに、現フィルタは、デバイス・オブジェクトのスタック深さパラメータを減らして次のフィルタのＩＲＰスタック・ロケーションに位置づけることによって、処理チェイン上の次のフィルタ用のＩＲＰを準備する。
【０１０８】
フィルタ・コードはＩＲＰスタック内の次のロケーションを準備し、入出力マネージャをコールしてＩＲＰを、指定された通りに次のフィルタに渡すことを受け持っている。このようにすると、フィルタは、特定の接続ピン・インスタンスを表す、どのファイル・オブジェクトがＩＲＰと関連データを受け取って処理するかを指定することができる。従って、ＩＲＰの順次処理のためにそれぞれのデバイス・オブジェクトをスタックするためのIoAttachDeviceのような標準入出力マネージャ・コールは使用されない。
【０１０９】
注目すべきことは、接続ピン・インスタンス間の接続を作成することは、その接続を表すために新しいデバイス・オブジェクトを作成することを意味しないことである。基礎となる単一のデバイス・オブジェクトはフィルタのインスタンスとそのフィルタ上のすべての接続ピン・インスタンスをサポートするために使用される。正しいデータ処理のために必要な具体的情報はファイル・オブジェクトのコンテキスト・エリアに保存されていて、コンテキスト情報はそのまま残されているが、非ページ・メモリ使用量は最小限に保たれている。さらに注目すべきことは、ＩＲＰベースの媒体について説明してきたが、相互接続フィルタ間の通信のための他の媒体も使用できることである。そのようなものとして、非ホスト・ハードウェアとハードウェア間通信での直接関数コールがある。
【０１１０】
次に、図１１と図１２および図１３を参照して、図１（従来技術）と図２（相互接続カーネル・モード・ドライバのハイレベル・ロジック図）に示すソフトウェア・ドライバの正しい作成、接続、および状態遷移順序について説明する。図１１はボックス１６２で囲んだロジック構造とそこに含まれる処理ステップを示している。図１２は接続ピン・インスタンスを作成して、カーネル・モード・フィルタの相互接続を完成する様子を示し、図１３に示すフローチャートにボックス１６４で囲んだ処理ステップを含んでいる。
【０１１１】
すべての相互接続が行われている図１２の状態にあるとき、カーネル・モード・フィルタ・システムは処理を行うために読み書きの準備状態にある。入出力システムは正しい状態遷移プロセスによって正しく設定されたＩＲＰスタック情報を使用して、ストリーム読取りと書込みをそれぞれの接続ピン・インスタンスを通して異なるフィルタ・エレメントに引き渡す。なお、グラフを作成するために使用されたエージェント以外の、ある種の外部ソフトウェアは、ブリッジまたはフィルタ自体とハードウェアも含めて、ストリーム読取りのデータを提供する。
【０１１２】
ステップ１６８からスタートしたあと、制御エージェント１７０はステップ１８０で、リーダ・フィルタ１７２、デコンプレッサ・フィルタ１７４、効果フィルタ１７６、およびサウンド・レンダリング・フィルタ１７８のインスタンスを作成する。さらに、リーダ・フィルタ１７２とディスク・ドライバ１８２との間の接続が行われて、データがディスク・ドライブから持ち込まれるようにする。各フィルタ・インスタンスの作成は標準入出力コールを使用してデバイス入出力ディレクトリ階層に見出される適切なデバイス上のファイルをオープンすることにより、ユーザ・モード制御エージェント１７０によって行われる。このコールからは、各フィルタのインスタンスを表すファイル・オブジェクトへのハンドルが返される。
【０１１３】
ステップ１８４で、ユーザ・モードのエージェントは効果フィルタ１７２、デコンプレッサ・フィルタ１７４、効果フィルタ１７６、およびサウンド・レンダリング・フィルタ１７８に照会し、接続ピン・ファクトリの機能を判断する。これらの機能は、どのような種類の入出力ピン・インスタンスが作成できるか、特定のフィルタは各接続ピン・ファクトリにいくつのインスタンスをサポートするか、各接続ピン・ファクトリでサポートされるデータ・フォーマット、通信パスの媒体またはタイプなどがある。これらの機能は以前に詳しく説明したプロパティ集合メカニズムを使用して照会され、カーネル・モード・フィルタは、適切な「集合」（例えば、プロパティ、メソッド、およびイベントの集合）をサポートしているのでアーキテクチャに従っていることが前提になっている。
【０１１４】
ステップ１８４でのこのようなすべての照会情報は、チェインニングされた接続パスが、適切な接続ピン・インスタンスを作成し、接続することによりそれぞれのフィルタ間で可能であるかどうかを判断するために使用される。ユーザ・モードのエージェントは、相互接続のために必要なピン・インスタンスのタイプを判断し、与えられた目的を達成するフィルタ・グラフを作成する。
【０１１５】
サポートされるデータ・フォーマットに基づく接続フォーマットの決定はステップ１８６で行われる。フィルタ上のトポロジ情報、データ・フォーマット、およびデータ交差プロパティを使用すると、仮定上の(hypothetical)フィルタ・グラフを作成することができる。接続順序は重要でないので、そのようにする必要はないが、フィルタ・グラフを作成しようとするとき時間を節約することができる。この仮定上のフィルタ・グラフがエラーなしで作成されるのであれば、ユーザ・モードのエージェントは、相互接続する接続ピン・インスタンスの作成を信頼して行うことができるという安心が得られる。実際のピン・インスタンスが作成されていなければ、ある種の照会からはエラーが返されるので、かかる接続ピン・インスタンスを作成してから仮定上のフィルタ・グラフを作成するようにすると、実行可能であるとの信頼できる指示が返されることになる。この場合も、仮定上のフィルタ・グラフは相互接続を行う前にテストすることが可能である。
【０１１６】
正しい接続情報が分かっているとステップ１８６で決定されると、入力ピン・インスタンスを作成し、相互接続して、図１３のボックス１６４で囲まれた処理ステップのループで表すことができる。このループはデータ・ストリームのソースから最も遠くに離れた入力ピン・インスタンスから始まる処理ステップを含んでいる。この最後の入力ピン・インスタンスは「最も深い」ピン・インスタンスと呼ばれ、これは最初に作成され、そのあとに関連する出力ピン・インスタンスを続けることができる。従って、接続は、以前に作成された入力ピン・インスタンスのハンドルを使用して出力ピン・インスタンスを作成したものである。
【０１１７】
このパターンは、すべての入力ピン・インスタンスが関連出力ピン・インスタンスとの接続の前に、それ以後連続して作成されるように続けられる。このような接続シナリオは単なる例示であり、それぞれの出力と入力ピン・インスタンスを接続して、本発明によるカーネル・モード・フィルタ間の接続を形成する他の可能な方法を限定するものではない。フィルタは、入力ピン・インスタンスからのハンドルが別のフィルタ上の接続された出力ピン・インスタンスの作成期間に使用される限り、実装に従ってどの順序でも接続することが可能である。さらに、前述したように、初期作成後（および使用後も）フィルタ・グラフに変更を行うことが可能である。
【０１１８】
ループの最初の繰り返しでは、入力ピン・インスタンス１８８はステップ１９０でユーザ・モードのエージェント１７０により作成される。作成機能からハンドルを受け取ると、ユーザ・モードのエージェント１７０はそのハンドルをNtCreateFileコールでパラメータとして使用してステップ１９４で出力ピン・インスタンス１９２を作成する。最初の繰り返しでこれを行うと、サウンド・レンダリング・フィルタ１７８は、それぞれ対応する接続ピン・インスタンス１８８と１９２を通して効果フィルタ１７６に実効的に接続される。現実装では、NtCreateFileコールはユーザ・モードのエージェントが利用できるＡＰＩの関数コールの一部として「ラップ(wrapped) 」される。これにより、ユーザ・モードのエージェントの開発者は詳細を知る必要から解放されるので、すべての関係機能を単一ユーザ・モードＡＰＩに集中させることができる。
【０１１９】
ステップ１９６で、ユーザ・モードのエージェントは作成すべき入力ピン・インスタンスが他にも残っているかどうかを判断する。残っていれば、入力ピン・インスタンスを作成し、そのあとに別のフィルタ上の対応する出力ピン・インスタンスを続けなければならない。最終的には、すべての接続が行われ、ユーザ・モードのエージェント１７０はストリーム化データ処理に対してフィルタ・グラフを準備する。
【０１２０】
以上のようにして、入力ピン・インスタンス２０２はステップ１９０でボックス１６４で囲まれたループの２回目の繰り返しで作成され、他方、出力ピン・インスタンス２０４は入力ピン・インスタンス２０２のハンドルをステップ１９４でその作成の一部として使用する。最後に、この特定の例では、３回目と最後の繰り返しで、入力ピン・インスタンス２０６が作成され、そのあとに出力ピン・インスタンス２０８が続いて接続が完結する。
【０１２１】
ステップ１９７で、ユーザ・モードのエージェント１７０は、フィルタ・グラフによるストリーム化データ処理に備えて各接続ピン・インスタンスを停止状態から取得状態へ遷移させる。それぞれのフィルタのデバイス・オブジェクトの各々でスタック深さパラメータを正しく設定するためには、状態遷移は「最も深い」または最後の接続ピン・インスタンス（例えば、処理のためのデータを受け取る最後の入力ピン・インスタンス）から始めて、最初の接続ピン・インスタンス（例えば、データをグラフに送り込む最初の出力ピン・インスタンス）に到達するまで相互接続カーネル・モード・フィルタのチェインを順次に「さかのぼる」ように行う必要がある。最初のフィルタまたはブリッジはＩＲＰを作成し、スタック・ロケーションはＩＲＰがグラフ内の各カーネル・モード・フィルタに効率よく連続して受け渡されるように十分に割当てられる。
【０１２２】
最後に、ユーザ・モードのエージェント１７０はストリーム読取りと書込みを出し、ステップ１９８でデータを処理してからステップ２００で終了する。
【０１２３】
前述したように、出力ピン・インスタンスの各作成には、そこに接続された入力ピン・インスタンスを表すファイル・オブジェクトのハンドルが必要である。このファイル・オブジェクト参照は、出力ピン・インスタンスの作成ハンドラが入力ピン・インスタンスに対応するデバイス・オブジェクトへの参照を、現在または将来のアクセスのためにセーブしておくことができるようにする。
【０１２４】
もっと具体的に説明すると、これにより、入力ピン・インスタンスを管理するデバイス・オブジェクトのスタック深さパラメータは、停止状態から取得または他の状態へ状態遷移するとき出力ピン・インスタンスのドライバによってアクセスすることが可能になる。入力ピン・インスタンスに関連するスタック深さパラメータの値はアクセスされ、増加され、出力ピン・インスタンスに対応するデバイス・オブジェクトのスタック深さパラメータの中にセーブされる。
【０１２５】
スタック深さパラメータは、共用ＩＲＰスタック構造のどこに特定フィルタ用のスタック・フレーム情報が置かれているかを判断するために使用されるが、これは各フィルタごとに異なっている。フィルタをこのように相互接続し、状態遷移を正しいシーケンスで行うと、通信をユーザ・モードにしなくても、カーネル・モードの相互接続フィルタのチェインを下るように単一ＩＲＰを受け渡してくことができる。
【０１２６】
以上の説明から理解されるように、同一の接続ピン・ファクトリを基礎にした複数のインスタンスをもつことが可能である。例えば、オーディオ・ミキシング・フィルタは複数のピン・インスタンスをミックスして単一の出力ピン・インスタンスにしてから処理することができる。各入力インスタンスは同一タイプであり、フィルタは１つのタイプの入力ピンだけをサポートすることができる。このような構成の別の例として、複数の入力を１つの出力にする例がある。
【０１２７】
逆のことを行うことも可能である。つまり、スプリッタ・フィルタは単一入力接続ピン・インスタンスをもち、複数の出力ピン・インスタンスを提供することによりデータ・ストリームを倍にすることが可能である。この分野の精通者ならば理解されるように、上述してきた接続メカニズムから実際の実装とその要求条件に応じて種々態様に変形し、種々態様に組み合わせることが可能である。
【０１２８】
ドライバ開発者が独立に実装できる共通メカニズム（例えば、プロパティ集合、メソッド集合、およびイベント集合）を、すべてのコンプライアント・フィルタにサポートさせることによって均一性と標準化が達成されているので、制御エージェントは異種ソフトウェア・プロバイダから提供されるコンプライアント・フィルタを都合よく接続することができる。さらに、接続ピン・ファクトリの観点から見た機能の多くはある状況では必要であっても、別の状況では必要でない場合がある。必要とされる接続ピン・インスタンスの決定は異なるフィルタ間の相互接続を実際に行うサード・パーティ制御エージェントによって最初に行われる。
【０１２９】
この分野の精通者ならば理解されるように、本発明の種々方法はコンピュータ・プログラム・コード手段として、磁気ディスク、CD-ROM、およびこの分野で共通している他の媒体やまだ未開発の他の共通媒体などの、コンピュータ読取り可能媒体上にストアされるコンピュータ命令として組み込んでおくことが可能である。さらに、コンピュータ・ハードウェア・メモリに置かれる重要なデータ構造は、上記のようなコンピュータ・プログラム・コード手段のオペレーションにより作成することができる。
【０１３０】
本発明は本発明の基本的特徴の精神から逸脱しない限り、他の実施形態で実現することも可能である。上述してきた各種実施の形態はすべての点で説明した通りであるが、これらの実施の形態に限定されるものではない。従って、本発明の範囲は上述してきた説明によってではなく、特許請求の範囲に記載されている事項によってのみ限定されるものである。特許請求の範囲の均等の意味と範囲に属する一切の変更は本発明の範囲に属するものである。
【図面の簡単な説明】
【図１】制御エージェントの指示を受けてサウンド・データをディスク・ファイルから持ち込み、サウンド・データをなんらかの形態で処理し、サウンド・データをレンダリングしてスピーカから再生させる相互接続フィルタとドライバのシステムを示す従来技術のデータ・フロー図である。
【図２】図１に示すシステムと目的が同じであり、サウンド・データをディスク・ドライバから読み取り、そのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにし、処理フィルタとレンダリングは、この場合も制御エージェントの指示を受けて相互接続カーネル・モード・ドライバによって処理されるようした本発明によるシステムを示す図である。
【図３】オペレーティング・システムで作成され、使用されるドライバ・オブジェクト、デバイス・オブジェクトおよびファイル・オブジェクト間の関係を示す垂直関係モデルを示す図である。
【図４】ドライバ・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図５】デバイス・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図６】ファイル・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図７】ルーチングとバリデーション・コンポーネントリの初期セットアップとカーネル・モード・ドライバによる入出力メッセージの処理を示すフローチャートである。
【図８】制御エージェントの処理、ルーチングとバリデーション・メカニズム、および新しいファイル・オブジェクトを作成する具体的な作成ハンドラ・ルーチンを示す詳細フローチャートである。
【図９】オペレーティング・システムでファイル・オブジェクト構造を利用して、接続を標準化された方法で行う接続フィルタ間の水平関係を示すロジック図である。
【図１０】図９のカーネル・モード・フィルタまたはドライバを作成し、接続するためにユーザ・モードの制御エージェントによってとられる処理ステップを示すフローチャートであり、制御エージェントから受け取った入出力要求を処理するために接続を行い、その処理が異なるドライバ（フィルタ）間で続けられる様子を示している。
【図１１】ユーザ・モードの制御エージェントの指示を受けてカーネル・モード・フィルタのチェインを作成するために使用され、サウンド・データをハード・ドライブから読み取り、カーネル・モード・フィルタでそのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにするシステムを実装するためのカーネル・モード・ドライバと接続を示す概要ロジック図である。
【図１２】ユーザ・モードの制御エージェントの指示を受けてカーネル・モード・フィルタのチェインを作成するために使用され、サウンド・データをハード・ドライブから読み取り、カーネル・モード・フィルタでそのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにするシステムを実装するためのカーネル・モード・ドライバと接続を示す概要ロジック図である。
【図１３】図１１と図１２に示すシステム用に相互接続カーネル・モード・ドライバを作成するための処理ステップを示すフローチャートである。
【符号の説明】
４４ 制御エージェント
４６ ディスク・ドライブ
４８ ディスク・ドライバ
５０ リーダ・ドライバ
５２ デコンプレッサ・ドライバ
５４ 効果フィルタ
５６ 効果プロセッサ
５８ レンダリング・ドライバ
６２ スピーカ
６４，７６，８０ ドライバ・オブジェクト
６６ デバイス・オブジェクト
７０，７２，７４，９０ ファイル・オブジェクト
７８ 汎用マルチプレクシング・ディスパッチ機能
８２ デバイス・エクステンション・エリア
８４，１００ ファイル・タイプ・バリデーション・テーブル
８６，１０２ ファイル・オブジェクト・タイプ
８８ 作成ハンドラ
９２ ファイル・コンテキスト・エリア
９４ ＩＲＰ要求ハンドラ・テーブル
９６ ＩＲＰ要求
９８ ハンドラ
１０４ 参照
１４６ フィルタＡ
１４８ フィルタＢ
１５４ 入力フィルタ・ピン・インスタンス
１５８ 出力ピン・インスタンス
【発明の属する技術分野】
本発明の分野はコンピュータ・ソフトウェア・ドライバの開発に属するものでである。本発明はドライバのコード生成を単純化すると共に、標準化されたアクセス・ポイントを提供するツール、ソフトウェア・フレームワーク、規則などに関する。より具体的には、本発明は異なる開発者によって書かれたソフトウェア・ドライバをカーネル・モードで相互接続し、カーネル・モードからユーザ・モードへまたはユーザ・モードからカーネル・モードへの非効率な遷移を行うことなく、異なるドライバ間で連続処理を可能にする標準化されたメソッド、コンピュータ・プログラム・プロダクト、およびデータ構造に関する。
【０００２】
【従来の技術】
ソフトウェア・ドライバはハードウェアを制御するように、またはソフトウェア機能を提供するように作られているのが通常であり、システム・オーバヘッドを軽減し、制約を相対的に少なくしてオペレーティング・システムの下で実行されている。そのようにすると、正常な動作(behavior)を保証し、無効なアクセスまたはオペレーティング・システムの下で実行中の別のプロセスとの干渉を「トラップ(trap)」するために実行されるシステム・コードが少なくなるので、ドライバがハードウェアをアクセスし、タイム・クリティカル処理要求(time critical processing request)をサービスすることが高速化している。
【０００３】
オペレーティング・システムは、アクセスの量と実装（実装）されているセキュリティ機能に応じていくつかの異なる動作レベルまたは「モード(mode)」をもっているのが通常である。例えば、通常のアプリケーション・プログラムは最低優先度で実行され、他のアプリケーションとの干渉を防止するためのセキュリティ・デバイスを適所に完備している。ハードウェアは制御下に置かれたインタフェースを通してのみアクセスされる。説明の便宜上、これを「ユーザ・モード(user mode) 」と総称することにするが、下述する本発明の実装例の一部として使用されているWindows NTオペレーティング・システムはユーザ・モードをサポートしている。同様に、他の大部分のオペレーティング・システムは、その複雑度に関係なく、「ユーザ・モード」と同等の動作モードを持っている。
【０００４】
他方、ドライバは実行優先度がはるかに高く、セキュリティ保護が低いオペレーティング・システムのモードで実行されるので、ドライバは、多くの場合、ドライバが直接に取り扱う実際のハードウェアへアクセスすることが可能になっている。多くのアプリケーションは、このよりゆるやかで、よりパフォーマンス指向のモードで実行させると利点が得られるが、これはWindows NT用語では、一般に「カーネル・モード(kernel mode) 」と呼ばれており、本明細書でもそのように呼ぶことにする。この場合も、他の堅牢な(robust)オペレーティング・システムは機能的に同等のモードをもっている。
【０００５】
ソフトウェア・ドライバの一般的概念は特定のハードウェアを制御することを意図しているので、ドライバは相互から切り離されて開発され、ハードウェア・メーカによって提供されるのが通常である。例えは、アドイン・ハードウェア・カード(add-in hardware card)に関連する、ある種の入出力サービスをデバイスの定義を通して提供するソフトウェア・ドライバは他のどのドライバとも通信する必要もなければ、その存在を知っている必要もない。
【０００６】
事情によっては、ドライバの開発のこのような専用的アプローチと、ドライバ間で通信できる機能の関連する欠如は、カーネル・モードで動作させることが好ましい処理をユーザ・モードで動作させざるを得なくさせるので、パフォーマンス面で不利になることが起こる。
【０００７】
本明細書の中で用いられている、カーネル・モード・ドライバを容易に使用することができない現行プログラムの代表的な例の１つとして、ユーザがフィルタと呼ばれる異なる処理ブロックを選択し、これらを１つに結合して、マルチメディア・データのストリームを連続的に操作できるようにするグラフ作成機能がある。データはサウンドまたはビデオを表す一連のサンプルであるのが代表的であり、処理ブロックは、圧縮データの伸張(decompression) 処理、特殊効果(special effects) 処理、CODEC 機能、データをアナログ信号に変換するレンダリング・ブロック(rendering block) などがある。
【０００８】
上記のようなフィルタは、プログラムのグラフ作成機能部分が相互接続され、そのオペレーションを制御し、ユーザの入力と処理ブロックの再配置(rearrangement) に応じられるようにユーザ・モードに置かれているのが代表的である。マルチメディア・データのストリームには一貫性があり、大量のデータが生成されるために、パフォーマンスは重要な問題になっている。汎用オペレーティング・システムでは、ユーザ・モードとカーネル・モードとの間で受渡しや切替えを繰り返し行い、このような遷移(transition)がセキュリティ上有効であるかどうかの検査を暗黙的に行う結果、システム・パフォーマンスが低下するので、ある種のマルチメディア・アプリケーションが使用できないことになる。
【０００９】
さらに、処理ブロックは多くの時間、ハードウェアと結びつけられているため、ユーザ・モードとカーネル・モードのコンポーネント間の遷移がなん度も行われることになる。このような遷移が行われると、マルチメディア処理システムの総パフォーマンスを低下させる、別の形態のオーバヘッドを含むことになる。ユーザ・モードとカーネル・モードとの間で遷移を行うと、異なるバッファ間でデータをコピーするときに関連するオーバヘッドが生じ、これは処理をカーネル・モードのままにしておけば生じるはずがないものである。
【００１０】
カーネル・モードからユーザ・モードへの遷移を行うときに起こる、もう１つの欠点は、オペレーティング・システムで作業タスクをスケジューリングする方法が制限されることである。作業をカーネル・モードのままにしておくことが可能であれば、ソフトウェア割込みや据置きプロシージャ・コール(deferred procedure call‐ＤＰＣ）といった、よりパフォーマンス指向のスケジューリング方法を利用できるので、システム・パフォーマンスはさらに最適化される。
【００１１】
さらに、異なるドライバ開発者が相互に接続可能なドライバを、共通の相互接続方式と定義に従って作成できるようにすると好都合な場合がある。このようにすると、共通インタフェースに対して書かれたどのドライバ機能も、機能処理ブロックのシステム中に相互接続できるので、すべてのデータ遷移はカーネル・モードで行われることになる。さらに、公知の規格を使用すると、多くの異なるドライバ開発者は相互操作可能で、相互接続可能なドライバ・ソフトウェアを開発することが可能になる。
【００１２】
【発明が解決しようとする課題】
本発明の目的は、ソフトウェア・ドライバを標準化された方式で相互接続し、データ処理期間にオペレーティング・システムのモード遷移を防止することによって、システム・パフォーマンスを向上することである。
【００１３】
さらに、本発明の目的は、サード・パーティ開発者によって拡張可能である、相互接続可能なソフトウェア・ドライバ用のベース・メカニズムを提供することである。
【００１４】
本発明の別の目的は、より多くのパフォーマンス・クリティカル処理をカーネル・モードで発生させるようにすることである。
【００１５】
さらに、本発明の別の目的は、ユーザ・モードのエージェントがソフトウェア・ドライバを相互接続できるようにすることである。
【００１６】
本発明のその他の目的および利点は以下の説明に記載されているが、その一部はその説明から理解されるものと、本発明を実施することにより知得し得るものとがある。本発明の目的と利点は、請求の範囲に個々に記載されているインストリューメント(instrument)の手段および組合せにより実現し、得られるものである。
【００１７】
【課題を解決するための手段】
上記目的を達成するために、また以下に具現化され、広義に説明されている本発明によれば、ソフトウェア・ドライバをカーネル・モードで相互接続するための方法およびコンピュータ・プログラム・プロダクトが提供されている。ある与えられたドライバまたはフィルタは、他のドライバに置かれた他のピン・インスタンス(pin instance)と相互接続できる、ある種のタイプのピン・インスタンスを作成する接続「ピン・ファクトリ(pin factory) 」をサポートし、定義することにより、ユーザ・モードのエージェントに頼らなくても、処理メッセージがドライバによってカーネル・モードで連続処理されるようにしている。このようにすると、データは完全にカーネル・モードでフローし、データはユーザ・モードにクロスするというオーバヘッドが不要になるので効率的に処理される。
【００１８】
コンプライアント・ドライバ(compliant driver)を接続することを希望するユーザ・モードのエージェントはドライバにその機能があるかどうかを照会する。そのような機能としては、接続ピン・インスタンスをインスタンシェイト(instantiate) するのにどのような種類の接続ピン・ファクトリが使用できるかということがあり、この中には、処理されるデータのタイプ、データ・フォーマット、転送レート、転送媒体またはモード、接続ピン・インスタンスの入力または出力の性質といった関連特性が含まれている。
【００１９】
ユーザ・モードで実行されるのが代表的であるエージェントが１つまたは２つ以上のコンプライアント・ドライバの機能について照会したあと、そのエージェントは、複数のドライバを１つに「チェイニング」してデータがドライバ間で最適に処理されるようにする最良の接続特性を決定する。この決定ステップは、すべてのドライバ機能の照会を終えて、最適な接続基準が選択できるようになったあとで行われる。
【００２０】
次に、ユーザ・モードのエージェントは、各ドライバ上の必要な接続ピンのインスタンスをピン・ファクトリを使用して作成することによってドライバを相互接続する。エージェントは、データ・フォーマットと接続フォーマットを接続ピン・インスタンス作成の一部として指定する。さらに、以前に作成された接続ピン・インスタンスへの参照は、他の接続ピン・インスタンスを作成する要求の中で指定され、接続ピン・インスタンス間の接続が行えるようにする。
【００２１】
ＮＴオペレーティング・システムの下で実装されている例示的実施の形態では、実際の接続ピン・インスタンスは「ファイル」へのハンドル(handle)を返す作成入出力オペレーションによって作成される。この作成入出力要求は、接続ピン・インスタンスのデータ・フォーマットと接続フォーマットを示しているデータ構造へのドライバ・インスタンス・ハンドルと参照を含めている。
【００２２】
コンプライアント・ドライバを作成するためには、ドライバ開発者は、ユーザ・モードのエージェントが機能について照会し、ドライバ間の相互接続を行えるようにする、ある種の標準機能をサポートしている。Windows NTオペレーティング・システム上で構築されている、ある実施の形態では、これは、必要とする機能を実装している「集合(set) 」（つまり、プロパティ、メソッド、およびイベントの集合）の使用によって達成されている。
【００２３】
集合は、集合全体を特定するＧＵＩＤ(globally unique identifier)（グローバルにユニークな識別子）と、集合内の各機能エレメントのＲＵＩＤ(relatively unique identifier)（相対的にユニークな識別子、例えば、集合自体内で相対的な識別子）をもつものとして論理的に定義されている。各集合は１つまたは２つのＩＯＣＴＬｓ(IO Controls)(入出力コントロール）だけと関連づけられ、ＩＯＣＴＬは、集合の仕様と組み合わされて、ドライバとのすべてのインタラクションを制御する。
【００２４】
本実施の形態では、３タイプの集合が使用されている。つまり、プロパティ集合、メソッド集合、およびイベント集合である。プロパティ集合はサウンド・ボリューム、転送レートなどの、値または設定値をドライバ内で管理するために使用され、コールがプロパティ値を得ようとしているのか、および／またはプロパティ値を設定しようしているのかを示すフラグと一緒に単一のＩＯＣＴＬを使用する。メソッド集合は、メモリの割当て、バッファのフラッシング(flushing)などのように、ドライバが実行できるオペレーションを管理するために使用され、単一のＩＯＣＴＬを使用して特定のメソッドをコールする。イベント集合は、デバイス変更通知、データ・スターベーション(data starvation) 通知などのように、ドライバの処理に関連するイベントを管理するために使用され、２つのＩＯＣＴＬを使用する。１つは特定のイベントをイネーブル(enable)にするためのもので、もう１つは特定のイベントをディスエイブル(disable) にするためのものである。
【００２５】
集合を使用するには、入出力制御オペレーションは特定のＩＯＣＴＬと、集合のＧＵＩＤ、ＲＵＩＤをもつデータ構造への参照およびその他の必要なデータを使用して開始される。例えば、サウンド・カード・ドライバでボリューム・プロパティを設定する場合は、集合プロパティのＩＯＣＴＬを使用し、ボリューム設定値をもつプロパティ集合の適切なＧＵＩＤを指定し、その集合内の特定ＲＵＩＤがボリューム・プロパティを示していることを指示し、新しいボリューム設定値を含んでいる入出力制御オペレーションが行われることになる。
【００２６】
サポートされる集合について照会するには、ヌルＧＵＩＤが特定集合タイプの特定ＩＯＣＴＬ（例えば、プロパティ集合ＩＯＣＴＬ、メソッド集合ＩＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）で照会フラグと一緒に使用され、サポートされる集合ＧＵＩＤのリストが返される。ある集合内のサポートされたプロパティ、メソッド、またはイベントについて照会するには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、および照会フラグが、サポートされたＲＵＩＤのリストを返すオペレーションと一緒に使用される。
【００２７】
汎用集合メカニズムを使用すると、コンプライアント・ドライバをサポートするために最小限の機能を実装することができるが、それでも拡張性は無制限である。集合は、特定の集合が実装されている限り、相互動作可能で、相互接続可能なドライバのシステムを作成するために、多数の異なるドライバ開発者によって独立してコーディングすることができる仕様書に定義することができる。さらに、この仕様書には、サポートする必要のある必須のプロパティ、メソッドおよびイベントを定義できるだけでなく、ドライバの機能と拡張機能に依存して実装できるオプションのプロパティ、メソッド、およびイベントも定義することができる。要求される基本的最小限の共通性のほかに、ドライバ開発者は独自の集合を定義し、その集合にＧＵＩＤを割当てることによって追加の機能を組み込むことも可能である。サポートされる機能（つまり、サポートされるＧＵＩＤとＲＵＩＤの照会を行うこと）を列挙できるようにすると、ユーザ・モードのエージェントなどの、呼出し側(caller)は期待を調整することも、基礎となるフィルタの機能に依存して適切な補償を行うこともできる。
【００２８】
本発明の上記およびその他の目的と特徴は以下の説明および請求の範囲に詳しく記載されている通りであるが、以下に説明する本発明を実施することによって知得することも可能である。
【００２９】
本発明の上記およびその他の利点と目的がどのようにして得られるかという方法を示すために、以下では、添付図面に図示されている具体的実施の形態を参照して、以上で簡単に説明してきた本発明を詳しく説明することにする。添付図面は本発明の代表的な実施の形態を示したにずぎず、従って、本発明の範囲を限定するものではないとの了解の下で、以下、添付図面を使用しながら本発明をもっと具体的にかつ詳しく記述し説明することにする。
【００３０】
【発明の実施の形態】
本明細書で用いられている「ユーザ・モード(user mode) 」という用語は、ユーザが書いたプログラムの大部分が実行されるときの、オペレーティング・システムにおける動作レベルのことである。ユーザ・モードの動作レベルはセキュリティ・レベルが最も高く、あるアプリケーション・プログラムまたはプロセスが別のアプリケーション・プログラムまたはプロセスに干渉するのを防止するために大量のオーバヘッドが消費されるのが代表的である。さらに、システム・リソースへのアクセスは特定のインタフェースを通して厳格に制御され、実行優先度は最低ではないとしても、最低優先度の１つであるのが一般である。
【００３１】
本明細書で用いられている「カーネル・モード(kernel mode) 」という用語はユーザ・モードの動作モードよりも制約が非常に少ない、オペレーティング・システムにおける動作レベルのことである。カーネル・モードのプログラムまたはプロセスの例としては、ハードウェア・コンポーネントを制御するソフトウェア・ドライバ(software driver) を含む。代表例として、カーネル・モードのプログラムはパフォーマンスに影響されやすく、従って、動作上のオーバヘッドはユーザ・モードのプログラムよりも少なくなっている。さらに、ハードウェアや多くのシステム・リソースへのアクセスは無制約であるか、あるいはユーザ・モードのプログラムの場合よりも制約がはるかに少なくなっている。多くの場合、カーネル・モードで実行されるプログラム・コードは、規則(convention)に対するプログラマの規律正しさと準拠とを信頼して、システムが良好に動作するようにする（例えば、別のプログラムのアドレス空間を破壊しないようにする）。カーネル・モードを表わす別の用語として、「トラステッド(trusted) 」コードがある。
【００３２】
本明細書で用いられている「ドライバ(driver)」という用語はカーネル・モードで実行されるのが代表的である、ソフトウェア・ドライバ・プログラムのことである。ドライバという用語は、オペレーティング・システム上にロードされる実際の実行可能プログラムまたはある種の機能を分け与えるプログラム部分を意味する場合もある。ドライバは、多くの場合、ある形態のハードウェアと関連づけられているが、必ずしもそうである必要はない。
【００３３】
本明細書で用いられている「フィルタ(filter)」という用語はソフトウェア・ドライバ内に置かれている機能部分のことであり、この中には、ドライバ自体も含まれ、そこでは、接続ポイントがフィルタを通してデータを送信するために公開されている。例えば、ソフトウェア・ドライバはいくつかの異なるフィルタをサポートする場合もあれば、１つの単一機能をもっている場合もある。さらに、内部的には１つに接続され、外部的には入出力用に接続ポイントを公開している異なるドライバからの複数のフィルタは単一フィルタとして集合的に参照される場合もある。また、もっと総称的な意味では、フィルタという用語は、伸張(decompression) などのように、それがカーネル・モードで実行されるソフトウェア・ドライバ・フィルタで起こるか、ユーザ・モードで実行される別のプログラム・コードで起こるかに関係なく、実行されるオペレーションを意味する場合もある。
【００３４】
本明細書で用いられている「ドライバ・オブジェクト(driver object) 」という用語は、ソフトウェア・ドライバを管理し、これをシステム・リソースとして知らせるオペレーティング・システムによって定義されているオペレーティング・システムのエンティティのことである。
【００３５】
本明細書で用いられている「デバイス・オブジェクト(device object) 」という用語はシステムによって定義されたシステム・レベルのエンティティのことであり、これは利用が可能であるドライバの機能の一部をシステム・リソースとして知らせ、ドライバの機能と他のシステム・コンポーネントが利用できるかどうかを定義している。ドライバ・オブジェクトとデバイス・オブジェクトはどちらも、代表的にドライバ・ソフトウェアのロード時と初期化時に作成される。
【００３６】
本明細書で用いられている「ファイル・オブジェクト(file object) 」という用語は、デバイス・オブジェクトによって指定されたリソースの呼出しを管理するオペレーティング・システムのエンティティのことであり、これはオペレーティング・システムによって定義されている。ファイル・オブジェクトはドライバ・オブジェクトの使用状況に関するコンテキストを提供する。さらに、ファイル・オブジェクトは、以前のファイル・オブジェクトが新しいファイル・オブジェクトの作成時に「親」と指定されていれば、別のファイル・オブジェクトと階層的に関係づけることが可能である。ファイル・オブジェクトは、代表的にデータ・ストリーム上に操作するすべての入出力オペレーションの管理に使用される。
【００３７】
本明細書で用いられている「データ(data)」という用語は、相互接続されたカーネル・モードのフィルタを通して処理される一切の情報のことである。そのようなデータは、ビデオ、オーディオ、テキスト、ＭＩＤＩなどを表すメディア・データを含むが、他のアプリケーションの場合には制御情報やパラメータも含んでいる場合がある。例えば、カーネル・モード・フィルタ・グラフはプロセス制御オペレーションで使用されることがあるが、そこでは、異なるフィルタ間で受け渡しされる制御情報はマシン類をアクチュエートする制御信号を創り出すために使用されている。メディア処理システムの例が示されているが、他のアプリケーションも、本明細書に説明されている相互接続カーネル・モード・フィルタのシステムから、同じような方法で利点を得ることが可能である。
【００３８】
本明細書では、本発明の説明は、Microsoft(登録商標）社から提供されているWindows NT（商標）オペレーティング・システムのコンテキスト内で記載されている。さらに、本明細書に説明されている好適実施の形態を理解するためには、Windows NTの入出力アーキテクチャの知識が前提になっている。入出力システムおよび NT オペレーティング・システム全般について解説した好適書としては、Helen Custer著「Windows NTの内部(Inside Windows NT)」(Microsoft Press発行）がある。
【００３９】
ドライバおよびファイル・オブジェクト、デバイス・オブジェクト、ドライバ・オブジェクトなどのシステム・エンティティの以下の説明では、Windows NTオペレーティング・システム上でこれらがどのような働き方をするかが解説されているが、この分野の精通者ならば理解されるように、本発明は、類似のコンポーネントを持つ他のオペレーティング・システム上で実装することが可能であり、これらのオペレーティング・システムが同じ用語を使用しているかどうかとは無関係である。例えば、別のオペレーティング・システムがファイル・オブジェクトとして動作するエンティティを持っていれば、そのエンティティはその実際の名称に関係なく、ファイル・オブジェクトと解釈することができる。
【００４０】
まず、図１を参照して説明すると、図示のシステム例は、サウンド・データのストリームをディスク・ドライブから読み取り、そのサウンド・データをレンダリング(rendering) して、従来のモデルに従ってスピーカから聞こえるようにするものである。あるデータ量はハード・ドライブ２０にストアされるが、これはディジタル化されたサウンド・サンプルの形態でサウンドを表している。ほかにも、サウンド・データ・ストリームのソースとしては、電話回線を利用して送られてくるディジタル化情報、ネットワークや他の通信パケットからのディジタル化情報、この分野で公知の他のソースが考えられる。データ・ストリームはディジタル化サンプルから構成され、これらのサンプルはデータ・フォーマットと規則によって、または各サンプルに付加される明示的タイムスタンプ情報によってタイム・インターバル情報が関連づけられている。カーネル・モードのディスク・ドライバ２２はディスク・ドライブ・ハードウェア２０と相互作用し、ユーザ・モードのリーダ(reader)プログラム・コンポーネント２４の制御下に置かれている。制御エージェント(controlling agent) ２６はサウンド・データのレンダリングを行うために異なるコンポーネントを管理するが、動的グラフ作成機能(dynamic graph building capability) を備えている場合は、異なるソフトウェア・コンポーネントが動的に割当てられて、エンド・ユーザの指定に従ってカスタム・フィルタリングまたは他の処理経路を提供できるようにする。
【００４１】
リーダ・コンポーネント２４はオペレーティング・システムの標準入出力制御インタフェースを使用してディスク・ドライバ２２と相互作用し、圧縮サウンド・データをディスク・ドライブ２０から読み取って、ユーザ・モード・プロセスのアドレス空間(address space) の一部としてユーザ・モードで割当てたバッファに入れる働きをする。次に、デコンプレッサ(decompressor)・コンポーネント２８は圧縮データを処理に適した伸張(decompressed)フォーマットに伸張する。図示のように、このステップ全体は、付随の低優先度の、プロセス動作(process behavior)安全メカニズムを使用してユーザ・モードで実行される。
【００４２】
効果フィルタ(effects filter)３０はデータに操作を加えて、ある種の特殊効果が得られるようにし、カーネル・モードで動作する附属の効果フィルタ３２をもっている。さらに、効果プロセッサ３４が存在する場合もあれば、効果フィルタ全体が実際のハードウェア・プロセッサをエミュレートするソフトウェアで動作する場合もある。効果フィルタ３２をアクセスするためには、効果コンポーネント３０はシステム入出力制御メカニズムを使用して、データと制御を効果フィルタに転送する。この場合も、カーネル・モード／ユーザ・モード境界を交差して、この遷移が行われる。
【００４３】
効果フィルタ３２は効果プロセッサ３４を制御し、必要または望ましいとされる特殊効果がそのデータ上に作られるようにする。これは、効果コンポーネント３０から全データをコピーし、そのコピーを効果フィルタ３２に、実際のシステム構成によっては、再度効果プロセッサ３４にも移すことにより行われる。多くのソフトウェア効果コンポーネントはハードウェア・プロセッサが関連づけられているが、他のコンポーネントは、ホスト・プロセッサ上で実行されるシステム・ソフトウェア内で完全に機能している。
【００４４】
効果コンポーネント３０の処理の完了時にコントロールとデータがユーザ・モードに戻されると、これは、次に、サウンド・レンダリング・コンポーネント３６に転送される。サウンド・レンダリング・コンポーネント３６はコントロールとデータをサウンド・レンダリング・ドライバ３８に転送し、これを受けてサウンド・レンダリング・ドライバは、処理され、フィルタリングされたデータをスピーカ４２からのサウンドとしてレンダリングするようにサウンド・カード４０を制御する。以上から容易に理解されるように、ユーザ・モードとカーネル・モード間の転送は多種類存在するために、サウンド・データのレンダリングを非効率化している。連続するサウンドまたはビデオ・ストリームのように、マルチメディア・データはタイミングに影響されやすい性質のため、これらの非効率性とコントロールの遷移を少なくすると共に、異なるバッファ間でなん度もデータをコピーすることを少なくすると、好都合である。
【００４５】
本明細書で用いられている本発明の一実施の形態は、Windows NTオペレーティング・システム・アーキテクチャ上で提供されるサービスから構成されている。このサービスはシステムのユーザがアクセスする、いくつかの異なるソフトウェア・コンポーネントに分割されている。第１は、ユーザ・モードのＡＰＩであり、これは、接続ピン・インスタンスと、クロック・メカニズムやバッファ割当てメカニズムなどの特定の機能を表している他のファイル・オブジェクトとを作成するためのルーチンを含んでいる。ほかにも、もっと重要なものとして、ドライバ開発者が標準化アーキテクチャに従うドライバを作成するのを支援するルーチンとデータ構造が完備されている。システムに用意されているこれらの機能を利用すると、異なるドライバ開発者は特定のアーキテクチャに準拠して相互に相互作用するコンプライアント・ドライバを作成することができる。ユーザ・モードのエージェントはＮＴエグゼクティブおよび入出力マネージャのシステム・サービスと通信する、ユーザ・モードで実行中の環境サブシステムを通してコンプライアント・ドライバと通信する。これは、他のすべての入出力に対する同じ標準入出力メカニズムであり、好適実施の形態の本実装では、既存のシステム・サービスを可能な限り利用するようになっている。
【００４６】
本発明を利用する図１のシステムのアーキテクチャは図２に示すようになっている。制御エージェント４４は知らされているドライバに照会し、データ・フォーマットと接続フォーマットに従って相互接続を行い、レンダリングを完全にカーネル・モードで行うようにする。さらに、制御エージェントは重要なイベントの通知を受けるので、必要に応じて制御を行うことができる。このようなイベントの例としては、処理の終了、データ・スターベーション事態などを含む。
【００４７】
この構成では、サウンド・データは前述したように、ディスク・ドライバ４８によってディスク・ドライブ４６から読み取られる。リーダ・ドライバ５０はディスク・ドライバ４８を制御し、従来の使い方と同じようにＮＴ層(NT layered)入出力アーキテクチャに従ってディスク・ドライバ４８と「垂直方向」に関連づけられている。「垂直方向」と「水平方向」の用語は、ＮＴ層入出力アーキテクチャの一部として現在行われているドライバ接続（垂直方向）と、ユーザ・モードのエージェントによって動的に行われる相互接続カーネル・モード・ドライバに従う接続（水平方向）とを区別するために用いられている。
【００４８】
リーダ・ドライバ５０は以下で説明する接続メソッドに従ってデコンプレッサ・ドライバ５２とも「水平方向」に相互接続され、制御エージェント４４によって管理されている。デコンプレッサ５２は伸張をカーネル・モードで行ってから、データとコントロールを効果フィルタ５４に引き渡す。効果フィルタは必要に応じて効果プロセッサ５６を利用して特殊効果を適用してからデータとコントロールをサウンド・レンダリング・ドライバ５８に引き渡し、このドライバはサウンド・カードを制御し、データをスピーカ６２からのサウンドとしてレンダリングする。図２から理解されるように、処理をカーネル・モードのままにしておくと、ユーザ・モードとカーネル・モードとの間の複数の遷移がなくなり、処理をユーザ・モードで行うと通常起こるオーバヘッド量が減少するので、効率面の利点が得られる。
【００４９】
次に、図３を参照して説明する。図３は、本発明の一実施の形態に従う相互接続ソフトウェア・ドライバに関係するシステム・オブジェクトの階層的性質を示すロジック図である。ドライバ・オブジェクト６４は、メモリにロードされるときの、実行可能ソフトウェア・コード・イメージを表すために作成される。ドライバ・コード・イメージはドライバの機能全体を含んでおり、ドライバ・オブジェクト６４はシステムに置かれている場所、サポートされるドライバの種類などのイメージに関する情報を含んでいる。
【００５０】
制御エージェントによって独立にアクセスできる機能の各タイプ別に、デバイス・オブジェクト６６a 〜６６N が入出力ディレクトリ構造に作成され、これらのオブジェクトは利用可能で、ユーザ・モードのクライアントによってアクセスされる異なる機能を表している。これらは、フィルタまたは独立に利用できる他の機能部分を表しているのが代表的である。ドライバ・オブジェクト６４とデバイス・オブジェクト６６a 〜６６N は囲みボックス６８で示すように、ドライバ・コードのインストール時に作成される。
【００５１】
歴史的には、デバイス・オブジェクトは物理ハードウェアの各エレメントごとに存在する。しかるに、最新の入出力システムの柔軟性は、デバイス・オブジェクトが完全にソフトウェアで実装されたフィルタを表すことを可能にさせている。そのため、デバイス・オブジェクトは専らソフトウェアで実装されたフィルタの各インスタンスごとに作成することが容易になっている。従って、ソフトウェア・フィルタは、デバイス・オブジェクトで表された各インスタンスがデバイス・オブジェクトと１対１の対応関係をもつように実装することも、単一のデバイス・オブジェクトがより伝統的な手法に従い、各々がフィルタのクライアント・インスタンスを表している複数のファイル・オブジェクトを管理するように実装することも可能になっている。
【００５２】
デバイス・オブジェクト、図示の例では、デバイス・オブジェクト６６a 上には、ファイル・オブジェクトが作成され、これはデバイス・オブジェクトで表された機能の独立インスタンスを表している。デバイス・オブジェクトはフィルタを表し、そのフィルタの複数のインスタンスを管理するのに対し、ファイル・オブジェクトは特定のエンティティによって使用される、そのフィルタの実際のインスタンスを表している。従って、ファイル・オブジェクト７０はデバイス・オブジェクト６６a によって定義されたフィルタのインスタンスである。
【００５３】
フィルタを使用するには、制御エージェントまたは他のユーザ・モード・クライアントは入出力ディレクトリ構造内で利用可能なデバイス上でファイルをオープンする。適切なコンテキスト情報を収めているファイル・オブジェクトが作成され、そのファイルへのハンドルがユーザ・モード・クライアントに返される。ファイル・オブジェクトは、作成時に「親」ファイル・オブジェクトを指定することによって階層的に関係づけることが可能であるが、ファイル・オブジェクトはすべてが同一デバイス・オブジェクトの子であるような、兄弟(sibling) 関係も持っている。
【００５４】
ファイル・オブジェクト内のコンテキスト情報は、ユーザ・モード・クライアントとの入出力インタフェースを管理する情報、ファイル・オブジェクトが表わしているエンティティの「状態(state) 」などからなっている。コンテキスト情報には、システムが必要とする情報があり、さらに、特殊な意味をもたせることができる、ユーザ定義可能エリアも含まれている。ユーザ定義可能エリアの使い方の例は、下述するバリデーション(validation)とＩＲＰルーチング(routing) ・メソッドのインプリメーテンションの説明個所に示されている。
【００５５】
接続ピン・インスタンスを提供するためには、フィルタ・インスタンスを表すファイル・オブジェクト７０が親として使用され、特定フィルタの接続ピン・インスタンスを表す子ファイル・オブジェクトが作成される。ファイル・オブジェクト７０は接続ピン・ファクトリの定義と可用性に関して照会されるのに対し、実際のファイル・オブジェクトは特定のファイル・オブジェクトを適切な情報コンテキストとして使用して、ピン・ファクトリの各インスタンスごとに作成され、接続ピン・インスタンスが有効に、かつ正しく作成されるようにする。例えば、ファイル・オブジェクト７２と７４はファイル・オブジェクト７０で表されたフィルタの接続ピン・インスタンスを表し、ファイル・オブジェクト７０と階層的に関係づけられている。それぞれファイル・オブジェクト７２と７４で表された接続ピン・インスタンスはフィルタ・インスタンス（ファイル・オブジェクト７０で表されている）に入ったあとで、そこから出るデータ・パスにすることができ、これは一連のチェイン・フィルタまたは他のドライバ機能を形成するときに他の接続ピン・インスタンスと接続するために使用できる。
【００５６】
ピン・インスタンスがフィルタ・インスタンスを表す別のファイル・オブジェクトと階層関係をもつファイル・オブジェクトで表されて、ピン・インスタンスのコンテキスト情報を提供するようにするのとまったく同じように、他のファイル・オブジェクトをピン・インスタンスと階層的に関係づけて他の機能を表すようにすると、正しいコンテキスト情報が得られるようになる。コンテキスト情報は、ピン・データ・フォーマット、通信タイプなどのように、作成時に使用される個々のパラメータに従って、あるピン・インスタンスを他のピン・インスタンスと区別するために必要である。
【００５７】
バッファ割当てメカニズム、タイミング・メカニズムなどのように、個別コンテキストかユーザ・モードのコントロールのどちらかをハンドルを通して要求する他の操作エンティティも、ファイル・オブジェクトで表すことができる。さらに、ファイル・オブジェクト（例えば、特定の接続ピン・インスタンスと関連づけられたバッファ割当てメカニズム）間の階層関係は、必要ならば、子ファイル・オブジェクトの作成時に親ファイル・オブジェクトを指定することにより確立することができる。これらの親子関係は、操作エンティティを表すファイル・オブジェクト間の関係と構造を決定するために存在する。さらに、特定タイプの「親」ファイル・オブジェクトはある種のタイプの「子」ファイル・オブジェクトだけを作ることができるので、以下で説明するように作成バリデーション・メカニズムが必要になる。この場合も、このようなファイル・オブジェクトは対応するハンドルがユーザ・モードで利用可能になっており、これらのハンドルはNtCreateFileなどのシステムＡＰＩコールを通してクライアントに返される。
【００５８】
ファイル・オブジェクトへのハンドルはカーネル・モード・ドライバと通信するために、制御エージェントなどのユーザ・モード・クライアントによって使用される。ファイル・オブジェクト、デバイス・オブジェクト、およびドライバ・オブジェクトの階層的チェインは、入出力サブシステムが階層関係をもつファイル・オブジェクトとデバイス・オブジェクトを通ってドライバ・オブジェクトまで戻り、実際のドライバ・コードに入るエントリ・ポイント(entry point) に到達することができるようにする。このようなエントリ・ポイントはソフトウェア・ドライバ・コードの中の機能を指す参照（例えば、ポインタ）になっている。さらに、特定のファイル・オブジェクトと、ソフトウェア・ドライバ・コードへのエントリ・ポイントをもつドライバ・オブジェクトとの間のオブジェクト通路(pathway) 上にあるオブジェクトの各々は、入出力サブシステムがＩＲＰを作成するときに重要なコンテキスト情報のほかに、下述するルーチングおよびバリデーション・メカニズムに従ってＩＲＰを正しくルーチングするときに使用されるデータ構造への参照も提供する。
【００５９】
ファイル・オブジェクトと他のシステム・オブジェクトに対するハンドルはプロセス専用であり、ユーザ・モード・プロセスが基礎となるオブジェクトと通信するときの手段となる。注目すべきことは、ファイル・オブジェクトなどの、基礎となる単一システム・オブジェクトを参照するために複数のハンドルが作成できることである。このことは、複数のアプリケーションがファイル・オブジェクトで表されたピン・インスタンスに情報を供給できることを意味する。
【００６０】
異なるドライバを相互接続するとき重要となる情報エレメントの１つとして、デバイス・オブジェクト・スタックの深さ(depth) パラメータがある。これは特定のドライバ・オブジェクトのＩＲＰスタック・ロケーションを示している。このようにすると、入出力マネージャを使用して、相互接続されたドライバ間で単一のＩＲＰを使用し受け渡しできるので、ＩＲＰを別々に作成し、それを種々の相互接続ドライバ間で送信するよりもパフォーマンス向上を提供できることになる。別の方法として、各ドライバは適切な入出力マネージャのコールを通して、各連続通信ごとに新しいＩＲＰを作成し、各々の新ＩＲＰを相互接続されたドライバのチェイン上の次のドライバへ送信させることも可能である。
【００６１】
次に、図４〜図６を参照して説明する。図は、異なるタイプのファイル・オブジェクト作成のバリデーションと適切なハンドラへの入出力要求パケット（I/O Request Packet：ＩＲＰ）のルーチングを可能にするシステム・ドライバ・オブジェクト、デバイス・オブジェクト、およびファイル・オブジェクトのエクステンションを示している。図４は、１つまたは２つ以上のフィルタまたは他のドライバ機能を実装している実行可能コードを表すドライバ・オブジェクト７６を示している。ドライバ・オブジェクト内では、Windows NTアーキテクチャはソフトウェア・ドライバ開発者が用意した作成ハンドラへの参照を要求している。この実施の形態によれば、マルチプレクシング・ディスパッチ機能(multiplexing dispatch function)７８は作成ハンドラとしてドライバ・オブジェクト７６から参照され、メッセージを作成されるファイル・オブジェクトのタイプに応じて特定の作成ハンドラへルーチングするために使用される。マルチプレクシング・ディスパッチ機能７８のオペレーションは図８に示すフローチャートを参照して以下で説明する。
【００６２】
同じように、ドライバ・オブジェクトからの他のハンドラはマルチプレクシング・ディスパッチ機能を示し、どのように実装するかに応じて、これらは同じ機能にすることが可能である。言い換えれば、以下で詳しく説明するように、各タイプの入出力ハンドラ参照（例えば、読取り、書込み、デバイス制御など）はデバイス・オブジェクト内のエクステンション・データとファイル・オブジェクト内のコンテキスト情報を使用して、メッセージを適切なハンドラへルーチングするマルチプレクシング・ディスパッチ機能を指している。バリデーション・テーブルを参照するデバイス・オブジェクト内のエクステンション・データは、作成オペレーションで親ファイル・オブジェクトの指定がないとき使用される。指定があれば、親ファイル・オブジェクトのコンテキスト情報は正しいバリデーション・テーブルを示している。
【００６３】
図５は、ドライバ開発者によって所望により利用でき、ドライバ専用情報を含んでいる特定のデバイス・エクステンション・エリア８２をもつドライバ・オブジェクト８０を示している。ドライバ・オブジェクト８０のデバイス・エクステンション・エリア８２内の定義されたロケーションには、ファイル・タイプ・バリデーション・テーブル８４と呼ばれ、ファイル・オブジェクト・タイプ８６のストリング表現を含んでいるデータ構造への参照と、表現される各ファイル・タイプ別の関連する作成ハンドラ８８への参照が置かれている。作成マルチプレクシング・ディスパッチ機能はファイル・タイプ・バリデーション・テーブル８４を使用して、作成されるファイル・オブジェクト・タイプを検査し、そのあと、コントロールを適切な作成ハンドラへ引き渡す。これについては、以下の図８の説明個所で詳しく説明する。検査されるストリングはＩＲＰ作成要求に見出され、ユーザ・モードのNtCreateFile関数コールと共に使用されるファイル名ストリングから創られる。NtCreateFile関数コールは、ピン・インスタンスまたは他のメカニズムを作成するためにユーザ・モード関数セルの中で行われる。
【００６４】
図６は、ソフトウェア・ドライバ開発者が使用するために解放されているファイル・コンテキスト・エリア９２をもつファイル・オブジェクト９０を示している。参照はファイル・コンテキスト・エリア９２からＩＲＰ要求ハンドラ・テーブル９４へ行われる。ＩＲＰ要求９６の異なるタイプは特定のハンドラ９８と関連づけられ、適切なマルチプレクシング・ディスパッチ機能はこの情報を使用して正しいハンドラにアクセスする。正しい作成ハンドラを決定する場合には、ファイル・タイプ・バリデーション・テーブル１００と呼ばれるデータ構造が参照され、そこには、ファイル・オブジェクト・タイプ１０２のストリング表現と、表現される各ファイル・タイプ別の関連する作成ハンドラへの参照１０４が入っている。子ファイル・オブジェクト（つまり、デバイス・オブジェクトではなく別のファイル・オブジェクトを親としてもつファイル・オブジェクト）の場合は、タイプはファイル・オブジェクト・タイプ１０２内のストリングと比較されるストリングで表されている。一致するものが見つかると、関連する作成ハンドラは、参照１０４のうち、一致したファイル・オブジェクト・タイプ・ストリングと関連づけられている参照を使用してアクセスされる。一致するものが見つからなければ、要求は無効であるので、エラー表示が出されることになる。
【００６５】
次に、図７を参照して説明すると、図は作成バリデーションとメカニズムをセットアップするためのインストレーション・プロシージャを示している。ステップ１０６で、インストール・プログラムは適切なマルチプレクシング・ディスパッチ機能への参照をドライバ・オブジェクトの中に作成する。図４に示すように、作成ハンドラは汎用マルチプレクシング・ディスパッチ機能を指している。同様に、ドライバ・オブジェクト７６の中の他のすべてのハンドラ参照は、特定ハンドラと密接な関係をもつ他の汎用(generic) マルチプレクシング・ディスパッチ機能を必要に応じて指している。別の方法として、各ハンドラ参照は同一マルチプレクシング・ディスパッチ機能を指すことも可能であり、その場合は、このディスパッチ機能はＩＲＰ要求を処理したあと、それを適切なハンドラへルーチングすることができる。この方法によるマルチプレクシング機能は異なる種類の要求（例えば、作成、書込みなど）を受け付ける必要があるため、複雑化することが避けられない。
【００６６】
次に、ステップ１０８で、ソフトウェア・ドライバ実行可能コードのインストールの一部として作成された各デバイス・オブジェクトは、図５に示すようにファイル・タイプ・バリデーション・テーブル８４を参照するように調整される。最後に、ステップ１１０で、ＩＲＰ要求の処理は、適切なデバイス・オブジェクト８０から参照されたファイル・タイプ・バリデーション・テーブル８４を使用してマルチプレクシング・ディスパッチ機能から開始される。
【００６７】
ファイル・オブジェクトが作成されると、適切なＩＲＰディスパッチ・テーブル９４が作成され、必要ならば、インデックスされたファイル・オブジェクト・タイプ・バリデーション・テーブル１００と一緒に参照される。ファイル・オブジェクト・タイプ・バリデーション・テーブルの作成は、ファイル・オブジェクト・タイプに従って用意された作成ハンドラ内で行われる。データ構造が作成され、これはＩＲＰディスパッチ・テーブル９４とファイル・オブジェクト・タイプ・バリデーション・テーブル１００を表しており、それを指す参照は作成される特定ファイル・オブジェクト９０のファイル・コンテキスト情報９２と一緒に特定ロケーションにストアされる。
【００６８】
次に、図８を参照して説明すると、図は作成マルチプレクシング・ディスパッチ機能のオペレーションとそのバリデーション・メカニズムを示すフローチャートであり、そこには、システム・ドライバ・オブジェクト、デバイス・オブジェクト、およびファイル・オブジェクトから参照されるデータ構造との相互作用も示されている。ステップ１１２で、ユーザ・モード・プロセスはファイル・オブジェクトを作成する入出力要求を送信する。この入出力作成要求はNtCreateFileのシステムＡＰＩを呼び出すことによって行われる。ステップ１１４で、入出力マネージャはドライバ・オブジェクト７６内の参照に基づいてＩＲＰをマルチプレクシング・ディスパッチ機能７８に送信する（図４参照）。
【００６９】
マルチプレクシング・ディスパッチ機能７８が作成要求のＩＲＰを受け取ると、ステップ１１６でテストが行われ、親ファイル・オブジェクトがあるかどうかが判断される。この判断を行うために必要な情報はＩＲＰ自体の中にあるが、これはユーザ・モード・プロセスによって元来用意されたものである。ユーザ・モード・プロセスは「親」ファイル・オブジェクトを参照するハンドルを作成要求の一部として用意し、ＮＴシステムは「親」ファイル・オブジェクトへの正しい参照をもつＩＲＰを作成する。
【００７０】
親ファイル・オブジェクトがなければ、右へのブランチがとられ、マルチプレクシング・ディスパッチ機能７８は適切なデバイス・オブジェクト８０からのデバイス・エクステンション８２を使用して、ファイル・タイプ・バリデーション・テーブル８４をステップ１１８で参照する（図５参照）。バリデーション・テーブル８４を使用して、マルチプレクシング・ディスパッチ機能７８は要求の中のストリングをファイル・オブジェクト・タイプ８６のストリングと比較することによって、ステップ１２０でファイル・オブジェクト・タイプを検査する。
【００７１】
ステップ１２２でストリングが一致していると判断されると、適切な作成ハンドラがステップ１２４でアクセスされる。一致していなければ、作成要求はステップ１２６で拒否される。ステップ１２４でアクセスされた作成ハンドラはステップ１２６でファイル・オブジェクトを作成するか、あるいは作成させる。作成されたファイル・オブジェクトを使用して、適切な作成ハンドラは、以前に作成していたＩＲＰディスパッチ・テーブル９４を指すファイル・オブジェクト参照をファイル・コンテキスト９２の中に作成する。
【００７２】
再びステップ１１６に戻って、親ファイル・オブジェクトが存在するかどうかが判断される。親ファイル・オブジェクトが存在するとステップ１１６で判断され、それが作成要求に関連するＩＲＰに入っていれば、マルチプレクシング・ディスパッチ機能７８は親ファイル・オブジェクト９０からのファイル・コンテキスト９２を使用して、ステップ１３０でＩＲＰディスパッチ・テーブル９２を参照する（図６）。作成要求の場合は、マルチプレクシング・ディスパッチ機能７８はステップ１３２でファイル・タイプ・バリデーション・テーブル１００を参照する。ファイル・タイプ・バリデーション・テーブル１００を使用して、マルチプレクシング・ディスパッチ機能７８は、上記と同じように、要求の中のストリングをファイル・オブジェクト・タイプ１０２のストリングと比較することによってステップ１３３でファイル・オブジェクト・タイプを検査する。
【００７３】
ストリングが一致しているとステップ１３４で判断されると、適切な作成ハンドラがステップ１３８でアクセスされる。一致していなければ、作成要求はステップ１３６で拒否される。適切な作成ハンドラを使用して、ファイル・オブジェクトは１４０で作成され、作成ハンドラは新しく作成されたファイル・オブジェクトの新しいＩＲＰディスパッチ・テーブル９４を作成し、新しく作成されたＩＲＰディスパッチ・テーブル９４を指す参照を新しく作成されたファイル・オブジェクト９０のファイル・コンテキスト・エリア９２の中にステップ１４２で作成する。注意すべきことは、親ファイル・オブジェクトおよび有効に作成された子ファイル・オブジェクトとの相互作用を説明するために、どちらの場合も、図６に示す同じファイル・オブジェクト構造が使用されていることである。どちらの場合も同じ構造が存在するが（新しいファイル・オブジェクトが作成されたあと）、これらはその使い方が異なり、含んでいる情報も異なっている。
【００７４】
接続ピン・インスタンスが作成されるといつでも、接続ピンＩＤが引き渡され、これはピン・インスタンスの作成を「サポート」するファイル内のピン・ファクトリを示している。この分野の精通者ならば理解されるように、接続ピンＩＤは、ファイル・オブジェクトが検査されるのとまったく同じように、バリデーションテーブルでストリングとして検査することも可能であり、また、その実装方法もさまざまである。
【００７５】
異なるドライバ間の接続を行うためには、あるドライバがそのような相互接続をサポートしていることを確かめるための共通メカニズムが必要である。この共通メカニズムは、接続ピン・ファクトリ機能を含むフィルタ機能を明らかにすることを可能にするものでなければならない。さらに、この種のメカニズムは、ドライバ開発者の柔軟性を向上するように拡張可能であることも必要である。
【００７６】
コンプライアント・ドライバを定義し、機能を明らかにすることを可能にするために本実施の形態で選択されている１つのメカニズムは関連アイテムの「集合」と名づけられている。これは既存の入出力通信メカニズムと一緒に使用すると便利なメカニズムである。集合は集合全体を特定するＧＵＩＤ（グローバルにユニークな識別子）と集合内の各機能エレメントのＲＵＩＤ（相対的にユニークな識別子、例えば、集合自体内の相対的な識別子）を持つものとして論理的に定義されている。集合識別子および選択されたＲＵＩＤアイテムと一緒にオペレーションするために必要な他のデータ構造は、フィルタ・ハンドルをパラメータとして使用して入出力制御コールの一部として引き渡される。機能の完全なシステムを実装するためには、少数のＩＯＣＴＬを割当てるだけで十分である。実装されるとき、３つの異なる種類の集合がその機能に応じて確立されるので、必要になるＩＯＣＴＬは総計４個である。他の実装では、集合の使い方が異なる場合がある。特定のＩＯＣＴＬは、選択されたエレメント（ＲＵＩＤを使用する）をなんらかの方法で解釈または使用するように入出力制御のハンドラに通知する。さらに、制御フラグをＧＵＩＤおよびＲＵＩＤと一緒に渡して、制御情報をもっと詳しく指定することができる。
【００７７】
最初の集合タイプはプロパティ集合であり、これはドライバ内または関連ハードウェア上に置かれている値または設定値と一緒に使用される。そのような設定値の例としては、転送レート、ボリューム・レベル（音量）などがある。１つのＩＯＣＴＬがプロパティ集合と関連づけられ、制御フラグは"get" プロパティ・コマンドと"set" プロパティ・コマンドとを区別している。このようにすると、同じデータ構造が特定のプロパティを設定または取得するように使用でき、ドライバは必要なアクションを使用されたＩＯＣＴＬに基づいて決定することができる。正しいプロパティは、ユニークなＧＵＩＤとＲＵＩＤの組合せからなる集合識別子(set identifier)によって特定される。
【００７８】
メソッド集合は使用されるもう１つの集合タイプであり、これはドライバによって実行できるアクションの集合である。メソッド集合を特定するために必要なＩＯＣＴＬは１つだけであり、アクチュエートされる正しいメソッドは集合識別子のユニークなＧＵＩＤとＲＵＩＤの組合せによって特定される。メソッドはドライバを制御するために使用され、ドライバを使用するための初期化、バッファのクリアといった機能を含んでいる。
【００７９】
イベント集合は、デバイス変更通知、データ・スターベーション通知などのドライバ処理や、ユーザ・モード・アプリケーションで使用すると便利である集合によって定義された他の通知に関連するイベントを管理するために使用される。２つのＩＯＣＴＬが使用され、１つは特定のイベントをイネーブルにするためのものであり、もう１つは特定のイベントをディスエーブルにするためのものである。ＲＵＩＤで識別された、与えられたイベントに必要なデータ構造は、イベントをイネーブルにするか、ディスエーブルにするかに関係なく共用することができる。
【００８０】
集合を使用するには、入出力制御オペレーションは特定のＩＯＣＴＬおよび集合ＧＩＤ、 ＲＵＩＤをもつデータ構造と他の必要なデータ（例えば、制御フラグ、データ構造など）を指す参照を使用して開始される。例えば、サウンド・カード・ドライバでボリューム・プロパティを設定することは、入出力制御オペレーションをプロパティ集合ＩＯＣＴＬ、集合プロパティ・オペレーションを示す制御フラグ、ボリューム設定値をもつプロパティ集合の適切なＧＵＩＤ、ボリューム・プロパティを示しているその集合内の特定ＲＵＩＤ、および新しいボリューム設定値を使用することを必然的に伴なう。
【００８１】
サポートされる集合についてタイプ別に照会するには、ヌルＧＵＩＤとサポートされる集合の列挙を示す制御フラグとをもつ、特定の集合タイプのＩＯＣＴＬ（例えば、プロパティＩＯＣＴＬ、メソッドＩＯＣＴＬ、またはイベント・イネーブルＩＯＣＴＬ）が入出力コマンドの一部として出され、サポートされる集合ＧＵＩＤのリストが返される。ある集合内のサポートされるプロパティ、メソッドまたはイベントについて照会するには、集合ＧＵＩＤ、集合タイプＩＯＣＴＬ、ヌルＲＵＩＤ、およびサポートされるエレメントの列挙を示す制御フラグが入出力オペレーションと共に使用される。サポートされるＲＵＩＤのリストは入出力オペレーションの結果として返される。このリストから、ユーザ・モードのエージェントは、実装されている集合のどのオプション・エレメント（もしある場合）がサポートされるかを判断することができる。
【００８２】
ＧＵＩＤでユニークに識別された集合の仕様書は、ドライバ開発者とユーザ・モードのエージェントのどちらもが実装ガイドとして利用できるメカニズムをドキュメント化している。サード・パーティ開発者は、あるドライバの機能を照会に対する応答に基づいて知り、事前プログラムされた知識を抽象的集合定義に基づいて知ることになる。同様に、ドライバ開発者は、知った機能をどのようなユーザ・モードのエージェントに対して提供する集合または集合グループを実装するときのガイドとして抽象的集合定義を使用することができる。
【００８３】
ここで説明している接続機能を提供するためには、コンプライアント・ドライバはある種の集合をサポートしていなければならない。以下の表は、プロパティ集合フォーマットでサポートされ、本発明を実装するときに使用できるいくつかの重要な情報を示している。最初の表は、フィルタによって実装される接続ピン・ファクトリに関するプロパティに関し、２番目の表は、特定の接続ピン・ファクトリをテンプレートとして使用して作成される実際の接続ピン・インスタンスに関するプロパティを示している。
【００８４】
【表１】
【表２】
【表１】
【表２】
【表５】
【表３】
上記の表は単なる例示であり、これに限定されるものではない、この分野の精通者ならば理解されるように、異なるドライバ間の接続を作成するためには多数の異なるプロパティとスキーマを実装することが可能である。１つの重要な要素は標準化係数(standardization factor)であり、異なるドライバ製造者または開発グループは同一のプロパティ集合を実装する能力をもっているので、相互接続できるドライバを作成できるようにすることである。
【００９１】
もう１つの有用なプロパティ集合は、あるフィルタ上の入力と出力の接続ピン・ファクトリの内部関係に関するトポロジ情報を与える。この情報はあるフィルタ上の入力ピン・ファクトリおよび対応する出力ピン・ファクトリの関係だけでなく、入力と出力のピン・ファクトリの間でどのようなタイプの処理が行われるかも記載している。行われる処理の例としては、異なるデータ変換、データ伸張、エコー打消し(cancellation)などがある。このような情報は複数のフィルタを使用して仮定上の接続パスをトレースしてから実際の接続ピン・インスタンスおよび接続を作成する自動化フィルタ・グラフ作成機能で使用すると、便利である。基本的には、トポロジ情報はフィルタの内部構造を説明し、これをプロパティ集合メカニズムを通してユーザ・モードのエージェントからの照会に公開する。
【００９２】
従って、コンプライアント・ドライバは指定されたプロパティ集合を実装しているものにすぎない。そのため、ユーザ・モードのエージェントは、あるプロパティ集合がサポートされていることが分かったとき、コンプライアント・フィルタに対し照会と設定を行うことができる。全体目標は、異なるフィルタを１つに接続してフィルタ・グラフを作る方法に関する十分な情報を得ることである。
【００９３】
汎用集合メカニズムを使用すると、最小限の機能を実装してコンプライアント・ドライバのシステムをサポートできるが、その場合でも、拡張性は無制限である。集合は、特定の集合が実装されている限り、相互操作可能で相互接続可能なドライバのシステムを作成するために多数の異なるドライバ開発者によって独立にコーディングできる仕様書の中で定義することができる。さらに、この仕様書には、サポートしなければならない必須のプロパティ、メソッド、およびイベントを定義できるだけでなく、ドライバ機能と拡張機能に応じて実装できるオプションのプロパティ、メソッド、およびイベントも定義できる。最小限に要求される基本的共通性のほかに、ドライバ開発者は独自の集合を定義し、これらにＧＵＩＤを割当てることにより追加の機能を組み入れることも可能である。
【００９４】
次に、図９および図１０を参照して説明する。図は２つのカーネル・モード・フィルタを接続するプロセスを図形化して示している。図９はロジック・ブロック説明図であり、そこでは各フィルタ・インスタンスと接続ピン・インスタンスはファイル・オブジェクトで表されている。図１０はファイル・オブジェクトおよび適切な接続を作成するときのステップを示すフローチャートである。
【００９５】
ステップ１４４からスタートして、フィルタＡ１４６のインスタンスおよびフィルタＢ１４８のインスタンスはユーザ・モードのエージェントによって作成される。これらは特定のデバイスでファイルを作成する標準ファイル・システムＡＰＩを使用して作成される。フィルタＡ１４６とフィルタＢ１４８がコンプライアント・フィルタまたはドライバとなっているのは、これらが適切なプロパティ、メソッド、およびイベント集合を実装して接続ピン・インスタンスの作成をサポートし、サポートされる集合とそのフィルタ用に定義された接続ピン・ファクトリに関してそれぞれのフィルタの機能に照会するようになっているからである。
【００９６】
ユーザ・モードのエージェントは、ステップ１５０でフィルタＡ１４６とフィルタＢ１４８にそれぞれ照会し、利用可能な接続ピン・ファクトリおよびそれから作成できる接続ピン・インスタンスの属性を判断する。これらの属性には、前述したように、各フィルタ１４６と１４８のそれぞれのピン・ファクトリのタイプ別の接続フォーマットとデータ・フォーマットがある。照会は、以下で詳しく説明する集合ベース照会メカニズムを使用して行われる。
【００９７】
上記情報の照会を終えると、ユーザ・モードのエージェントは、以前に照会したデータ・フォーマットと接続フォーマットの範囲に基づいて最適接続フォーマットを決定する。この決定はステップ１５２で行われ、選択した接続パスの要求事項に応じて同じフィルタをユーザ・モードのエージェントが異なった使い方をできるようにする。ユーザ・モードのエージェントはデータ交差プロパティ(data intersection property)、トポロジ情報、および接続ピン・ファクトリを両方のフィルタで使用して、作成される実際のフィルタ・グラフに応じてデータ・フォーマットと接続配置の最良の選択方法を決定する。
【００９８】
入力フィルタ・ピン・インスタンス１５４はステップ１５２で判断された最適検出情報を使用して、ステップ１５６でユーザ・モードのエージェントによって作成される。入力ピン・インスタンス１５４はファイル・オブジェクトであるので、ハンドルが作成プロセスから返されるが、これは入出力要求を入力インスタンス１５４へ送るために使用できる。さらに、入力ピン・インスタンス１５４の作成が有効性の検査をされているが、この作成には、図４〜図６、図７および図８を参照して前述したルーチングおよびバリデーション・メカニズムが使用される。
【００９９】
接続を完成するために、出力ピン・インスタンス１５８は、以前に作成された入力ピン・インスタンス１５４のハンドルをNtCreateFileコールの中でパラメータとして使用してステップ１６０で作成される。出力ピン・インスタンス１５８がこのようにして作成される効果として、システム・ファイル管理機能と入出力管理機能を使用して内部ＩＲＰスタック構造が作成される。このスタック構造により、オリジナルの書込みコマンドは、さまざまな方法で接続された接続ピン・インスタンスとフィルタによって適当な順序で連続処理することが可能になるので、異なるフィルタ間の直接データ・フローが容易化される。これを行うためには、入力ピン・インスタンスを供給する関連出力ピン・インスタンスの前に入力ピン・インスタンスが作成されていることが必要である。
【０１００】
デバイス・オブジェクトのスタック深さパラメータは、このドライバに送られるＩＲＰ用にスタック・ロケーションをいくつ作成するかを制御する。スタック深さパラメータは、デバイス・オブジェクトが初めて作られるときは１つであると想定されているが、複数のドライバが１つにチェイニングされているかどうかに応じて、あとで変更することも可能である。現システムでは、この変更は、必要ならば、出力ピン・インスタンスが初期「停止」状態から「取得」または他の状態に遷移するとき行われる。接続ピン・インスタンスの状態遷移はＩＲＰを正しく作成し、処理するための正しいスタック深さパラメータ情報を決定するメカニズムである。
【０１０１】
チェイニングされた接続ピン・インスタンス集合を正しく割当てるためには、接続ピン・インスタンスを特定の順序で停止状態から出るように遷移させる必要がある。つまり、最後の入力ピン・インスタンス（この例では、入力ピン・インスタンス１５４）から始まって、関連の（例えば、接続された）出力ピン・インスタンス（この例では、出力ピン・インスタンス１５８) まで連続的に逆方向に戻っていく必要がある。多数のフィルタが１つにチェイニングされていれば、最も深いフィルタまたはブリッジの入力ピン・インスタンスが遷移の開始ポイントであって、ブリッジまたはフィルタ上の初期出力ピン・インスタンスが設定されるまで逆方向に連続的に構築していかなければならない。言い換えれば、停止状態から出る遷移はチェインを逆昇るように行われ、各接続ピン・インスタンスが前の接続ピン・インスタンスの後で必要になるスタック・サイズを得るようにしなければならない。代表例として、必ずしもそうする必要はないが、接続ピン・インスタンスは停止状態から取得状態へ遷移するが、以下での説明の便宜上、取得状態への遷移はスタック深さパラメータの調整に関しては、停止状態から出る遷移と同じ目的を果たすようになっている。
【０１０２】
すべてのピン・インスタンスが取得状態になったあとは、ストリーム読取りと書込みをフィルタ・グラフに対して出すことができる。なお、注目すべきことは、ここで説明しているシステムが、関連入力と出力ピン・インスタンスの接続をどの順序でも行うことができ、停止状態からの遷移だけはボトムアップ方式、つまり、最も深いものから先に行わなければならないことである。さらに、フィルタ・グラフは初期作成後に変更が行えるように再構成可能になっている。変更が行われるときは、状態遷移は停止状態にある接続ピン・インスタンスだけで行い、正しいスタック深さパラメータ情報が得られるようにする必要がある。
【０１０３】
フィルタ上に見出される接続ピン・ファクトリは、フィルタが特定フォーマットでデータを消費および／または作成できる場所を表している。例えば、特定の接続ピン・ファクトリは、１６ビットの４４キロヘルツＰＣＭオーディオや８ビットの２２キロヘルツＰＣＭオーディオなどの、いくつかの異なるデータ・フォーマットをサポートすることができる。前述したように、接続ピン・ファクトリやそのデータ・フォーマットなどの異なる機能については、適切なプロパティ集合メカニズムとシステム入出力機能を使用してフィルタから照会することができる。実際の接続ピン・インスタンスはピン・ファクトリから受信した情報に基づいて作成される。
【０１０４】
単一のストリーム書込みまたはストリーム読取りオペレーションがユーザ・モード・エージェントから出されると、接続されたフィルタを通してデータの連続処理が行われるストリーミング環境では、ＩＲＰ制御用の２つのメイン・メソッドがＮＴオペレーティング・システムのネーティブ機能の一部として使用することができる。第１のメソッドでは、個別ＩＲＰは各フィルタによって作成され、次のフィルタへ送られて処理され、このフィルタは新しいＩＲＰを作成し、チェインを下って次々と処理されていく。他のメソッドでは、単一のＩＲＰが使用され、入出力マネージャと相互作用するために用意された標準プロシージャを使用して連続フィルタ間で受け渡しされていく。チェイン上の各連続フィルタごとに新しいＩＲＰを作成していく第１のメソッドが使用される場合は、フィルタ間の相互接続順序が重要でないのは、フィルタはＩＲＰのデスティネーション(destination) だけを知っていればよく、入出力マネージャをコールしてＩＲＰを指定のフィルタへ送ることができるからである。ＩＲＰが再使用される場合に重要なことは、停止状態からの接続ピン・インスタンスの遷移が再使用ＩＲＰを受け取る最後のフィルタから始まるように行われ、再使用ＩＲＰを受け取る最初のフィルタまで、または処理のためにＩＲＰを作成したフィルタまで逆方向に処理していくことである。
【０１０５】
相互接続カーネル・モード・フィルタの本実施の形態と実装例は、ＩＲＰ共用を利用してドライバ開発の複雑さを軽減し、より堅牢なドライバが作成されることを可能にし、処理を効率化するという利点がある。「ボトム・アップ」のピン・インスタンス状態遷移パスは、正しいスタック順序が連続ドライバによって処理されるＩＲＰに作成され、各ドライバ・オブジェクトが適切なスタック深さパラメータ集合をもつことを保証する。さらに、受信側入力ピン・ファクトリの現状態は、状態遷移シーケンスを正しくたどっていたかどうかを確かめるためにチェックされる。そのような理由から、特定の接続ピン・ファクトリの通信プロパティは起こり得るフロー方向を判断し、接続ピン・インスタンスの状態遷移を正しく分配する上で支援する。
【０１０６】
出力ピン・インスタンス（またはＩＲＰソース）を作成するとき、別のフィルタ上の入力ピン・インスタンス（またはＩＲＰシンク(sink)）を表すファイル・オブジェクトへの参照はNtCreateFileコールの一部として引き渡される。適切な作成ハンドラはマルチプレクシング・ディスパッチ機能とデバイス・オブジェクト／ファイル・オブジェクト階層を使用して、前述したように実行される。この作成ハンドラは入力ピン・インスタンスをもつフィルタ（例えば、図９のフィルタＢ１４８）のデバイス・オブジェクトを、入力接続ピン・インスタンス・ファイル・オブジェクト（例えば、入力ピン・インスタンス１５４）を通してアクセスすることができる。デバイス・オブジェクトから、前のスタック深さパラメータを読み取ることができ、出力ピン・インスタンスをもつフィルタのデバイス・オブジェクトのスタック深さパラメータが増加される。例えば、フィルタＡ１４６に関連するデバイス・オブジェクトは、図９に示す接続ではフィルタＢ１４８に関連するデバイス・オブジェクトのそれから増加されるスタック深さパラメータをもっている。これは停止状態から出る遷移のとき行われるのが通常であり、ＩＲＰは接続ピン・インスタンスが停止状態にある間はルーチングされない。
【０１０７】
フィルタがＩＲＰを処理するとき、その特定フィルタ用に指定された情報を含んでいる、ＩＲＰスタック内のどのスタック・フレームまたはロケーションをアクセスすべきかを、関連デバイス・オブジェクトのスタック深さパラメータを参照するか、あるいはそれを使用することによって知る。さらに、現フィルタは、デバイス・オブジェクトのスタック深さパラメータを減らして次のフィルタのＩＲＰスタック・ロケーションに位置づけることによって、処理チェイン上の次のフィルタ用のＩＲＰを準備する。
【０１０８】
フィルタ・コードはＩＲＰスタック内の次のロケーションを準備し、入出力マネージャをコールしてＩＲＰを、指定された通りに次のフィルタに渡すことを受け持っている。このようにすると、フィルタは、特定の接続ピン・インスタンスを表す、どのファイル・オブジェクトがＩＲＰと関連データを受け取って処理するかを指定することができる。従って、ＩＲＰの順次処理のためにそれぞれのデバイス・オブジェクトをスタックするためのIoAttachDeviceのような標準入出力マネージャ・コールは使用されない。
【０１０９】
注目すべきことは、接続ピン・インスタンス間の接続を作成することは、その接続を表すために新しいデバイス・オブジェクトを作成することを意味しないことである。基礎となる単一のデバイス・オブジェクトはフィルタのインスタンスとそのフィルタ上のすべての接続ピン・インスタンスをサポートするために使用される。正しいデータ処理のために必要な具体的情報はファイル・オブジェクトのコンテキスト・エリアに保存されていて、コンテキスト情報はそのまま残されているが、非ページ・メモリ使用量は最小限に保たれている。さらに注目すべきことは、ＩＲＰベースの媒体について説明してきたが、相互接続フィルタ間の通信のための他の媒体も使用できることである。そのようなものとして、非ホスト・ハードウェアとハードウェア間通信での直接関数コールがある。
【０１１０】
次に、図１１と図１２および図１３を参照して、図１（従来技術）と図２（相互接続カーネル・モード・ドライバのハイレベル・ロジック図）に示すソフトウェア・ドライバの正しい作成、接続、および状態遷移順序について説明する。図１１はボックス１６２で囲んだロジック構造とそこに含まれる処理ステップを示している。図１２は接続ピン・インスタンスを作成して、カーネル・モード・フィルタの相互接続を完成する様子を示し、図１３に示すフローチャートにボックス１６４で囲んだ処理ステップを含んでいる。
【０１１１】
すべての相互接続が行われている図１２の状態にあるとき、カーネル・モード・フィルタ・システムは処理を行うために読み書きの準備状態にある。入出力システムは正しい状態遷移プロセスによって正しく設定されたＩＲＰスタック情報を使用して、ストリーム読取りと書込みをそれぞれの接続ピン・インスタンスを通して異なるフィルタ・エレメントに引き渡す。なお、グラフを作成するために使用されたエージェント以外の、ある種の外部ソフトウェアは、ブリッジまたはフィルタ自体とハードウェアも含めて、ストリーム読取りのデータを提供する。
【０１１２】
ステップ１６８からスタートしたあと、制御エージェント１７０はステップ１８０で、リーダ・フィルタ１７２、デコンプレッサ・フィルタ１７４、効果フィルタ１７６、およびサウンド・レンダリング・フィルタ１７８のインスタンスを作成する。さらに、リーダ・フィルタ１７２とディスク・ドライバ１８２との間の接続が行われて、データがディスク・ドライブから持ち込まれるようにする。各フィルタ・インスタンスの作成は標準入出力コールを使用してデバイス入出力ディレクトリ階層に見出される適切なデバイス上のファイルをオープンすることにより、ユーザ・モード制御エージェント１７０によって行われる。このコールからは、各フィルタのインスタンスを表すファイル・オブジェクトへのハンドルが返される。
【０１１３】
ステップ１８４で、ユーザ・モードのエージェントは効果フィルタ１７２、デコンプレッサ・フィルタ１７４、効果フィルタ１７６、およびサウンド・レンダリング・フィルタ１７８に照会し、接続ピン・ファクトリの機能を判断する。これらの機能は、どのような種類の入出力ピン・インスタンスが作成できるか、特定のフィルタは各接続ピン・ファクトリにいくつのインスタンスをサポートするか、各接続ピン・ファクトリでサポートされるデータ・フォーマット、通信パスの媒体またはタイプなどがある。これらの機能は以前に詳しく説明したプロパティ集合メカニズムを使用して照会され、カーネル・モード・フィルタは、適切な「集合」（例えば、プロパティ、メソッド、およびイベントの集合）をサポートしているのでアーキテクチャに従っていることが前提になっている。
【０１１４】
ステップ１８４でのこのようなすべての照会情報は、チェインニングされた接続パスが、適切な接続ピン・インスタンスを作成し、接続することによりそれぞれのフィルタ間で可能であるかどうかを判断するために使用される。ユーザ・モードのエージェントは、相互接続のために必要なピン・インスタンスのタイプを判断し、与えられた目的を達成するフィルタ・グラフを作成する。
【０１１５】
サポートされるデータ・フォーマットに基づく接続フォーマットの決定はステップ１８６で行われる。フィルタ上のトポロジ情報、データ・フォーマット、およびデータ交差プロパティを使用すると、仮定上の(hypothetical)フィルタ・グラフを作成することができる。接続順序は重要でないので、そのようにする必要はないが、フィルタ・グラフを作成しようとするとき時間を節約することができる。この仮定上のフィルタ・グラフがエラーなしで作成されるのであれば、ユーザ・モードのエージェントは、相互接続する接続ピン・インスタンスの作成を信頼して行うことができるという安心が得られる。実際のピン・インスタンスが作成されていなければ、ある種の照会からはエラーが返されるので、かかる接続ピン・インスタンスを作成してから仮定上のフィルタ・グラフを作成するようにすると、実行可能であるとの信頼できる指示が返されることになる。この場合も、仮定上のフィルタ・グラフは相互接続を行う前にテストすることが可能である。
【０１１６】
正しい接続情報が分かっているとステップ１８６で決定されると、入力ピン・インスタンスを作成し、相互接続して、図１３のボックス１６４で囲まれた処理ステップのループで表すことができる。このループはデータ・ストリームのソースから最も遠くに離れた入力ピン・インスタンスから始まる処理ステップを含んでいる。この最後の入力ピン・インスタンスは「最も深い」ピン・インスタンスと呼ばれ、これは最初に作成され、そのあとに関連する出力ピン・インスタンスを続けることができる。従って、接続は、以前に作成された入力ピン・インスタンスのハンドルを使用して出力ピン・インスタンスを作成したものである。
【０１１７】
このパターンは、すべての入力ピン・インスタンスが関連出力ピン・インスタンスとの接続の前に、それ以後連続して作成されるように続けられる。このような接続シナリオは単なる例示であり、それぞれの出力と入力ピン・インスタンスを接続して、本発明によるカーネル・モード・フィルタ間の接続を形成する他の可能な方法を限定するものではない。フィルタは、入力ピン・インスタンスからのハンドルが別のフィルタ上の接続された出力ピン・インスタンスの作成期間に使用される限り、実装に従ってどの順序でも接続することが可能である。さらに、前述したように、初期作成後（および使用後も）フィルタ・グラフに変更を行うことが可能である。
【０１１８】
ループの最初の繰り返しでは、入力ピン・インスタンス１８８はステップ１９０でユーザ・モードのエージェント１７０により作成される。作成機能からハンドルを受け取ると、ユーザ・モードのエージェント１７０はそのハンドルをNtCreateFileコールでパラメータとして使用してステップ１９４で出力ピン・インスタンス１９２を作成する。最初の繰り返しでこれを行うと、サウンド・レンダリング・フィルタ１７８は、それぞれ対応する接続ピン・インスタンス１８８と１９２を通して効果フィルタ１７６に実効的に接続される。現実装では、NtCreateFileコールはユーザ・モードのエージェントが利用できるＡＰＩの関数コールの一部として「ラップ(wrapped) 」される。これにより、ユーザ・モードのエージェントの開発者は詳細を知る必要から解放されるので、すべての関係機能を単一ユーザ・モードＡＰＩに集中させることができる。
【０１１９】
ステップ１９６で、ユーザ・モードのエージェントは作成すべき入力ピン・インスタンスが他にも残っているかどうかを判断する。残っていれば、入力ピン・インスタンスを作成し、そのあとに別のフィルタ上の対応する出力ピン・インスタンスを続けなければならない。最終的には、すべての接続が行われ、ユーザ・モードのエージェント１７０はストリーム化データ処理に対してフィルタ・グラフを準備する。
【０１２０】
以上のようにして、入力ピン・インスタンス２０２はステップ１９０でボックス１６４で囲まれたループの２回目の繰り返しで作成され、他方、出力ピン・インスタンス２０４は入力ピン・インスタンス２０２のハンドルをステップ１９４でその作成の一部として使用する。最後に、この特定の例では、３回目と最後の繰り返しで、入力ピン・インスタンス２０６が作成され、そのあとに出力ピン・インスタンス２０８が続いて接続が完結する。
【０１２１】
ステップ１９７で、ユーザ・モードのエージェント１７０は、フィルタ・グラフによるストリーム化データ処理に備えて各接続ピン・インスタンスを停止状態から取得状態へ遷移させる。それぞれのフィルタのデバイス・オブジェクトの各々でスタック深さパラメータを正しく設定するためには、状態遷移は「最も深い」または最後の接続ピン・インスタンス（例えば、処理のためのデータを受け取る最後の入力ピン・インスタンス）から始めて、最初の接続ピン・インスタンス（例えば、データをグラフに送り込む最初の出力ピン・インスタンス）に到達するまで相互接続カーネル・モード・フィルタのチェインを順次に「さかのぼる」ように行う必要がある。最初のフィルタまたはブリッジはＩＲＰを作成し、スタック・ロケーションはＩＲＰがグラフ内の各カーネル・モード・フィルタに効率よく連続して受け渡されるように十分に割当てられる。
【０１２２】
最後に、ユーザ・モードのエージェント１７０はストリーム読取りと書込みを出し、ステップ１９８でデータを処理してからステップ２００で終了する。
【０１２３】
前述したように、出力ピン・インスタンスの各作成には、そこに接続された入力ピン・インスタンスを表すファイル・オブジェクトのハンドルが必要である。このファイル・オブジェクト参照は、出力ピン・インスタンスの作成ハンドラが入力ピン・インスタンスに対応するデバイス・オブジェクトへの参照を、現在または将来のアクセスのためにセーブしておくことができるようにする。
【０１２４】
もっと具体的に説明すると、これにより、入力ピン・インスタンスを管理するデバイス・オブジェクトのスタック深さパラメータは、停止状態から取得または他の状態へ状態遷移するとき出力ピン・インスタンスのドライバによってアクセスすることが可能になる。入力ピン・インスタンスに関連するスタック深さパラメータの値はアクセスされ、増加され、出力ピン・インスタンスに対応するデバイス・オブジェクトのスタック深さパラメータの中にセーブされる。
【０１２５】
スタック深さパラメータは、共用ＩＲＰスタック構造のどこに特定フィルタ用のスタック・フレーム情報が置かれているかを判断するために使用されるが、これは各フィルタごとに異なっている。フィルタをこのように相互接続し、状態遷移を正しいシーケンスで行うと、通信をユーザ・モードにしなくても、カーネル・モードの相互接続フィルタのチェインを下るように単一ＩＲＰを受け渡してくことができる。
【０１２６】
以上の説明から理解されるように、同一の接続ピン・ファクトリを基礎にした複数のインスタンスをもつことが可能である。例えば、オーディオ・ミキシング・フィルタは複数のピン・インスタンスをミックスして単一の出力ピン・インスタンスにしてから処理することができる。各入力インスタンスは同一タイプであり、フィルタは１つのタイプの入力ピンだけをサポートすることができる。このような構成の別の例として、複数の入力を１つの出力にする例がある。
【０１２７】
逆のことを行うことも可能である。つまり、スプリッタ・フィルタは単一入力接続ピン・インスタンスをもち、複数の出力ピン・インスタンスを提供することによりデータ・ストリームを倍にすることが可能である。この分野の精通者ならば理解されるように、上述してきた接続メカニズムから実際の実装とその要求条件に応じて種々態様に変形し、種々態様に組み合わせることが可能である。
【０１２８】
ドライバ開発者が独立に実装できる共通メカニズム（例えば、プロパティ集合、メソッド集合、およびイベント集合）を、すべてのコンプライアント・フィルタにサポートさせることによって均一性と標準化が達成されているので、制御エージェントは異種ソフトウェア・プロバイダから提供されるコンプライアント・フィルタを都合よく接続することができる。さらに、接続ピン・ファクトリの観点から見た機能の多くはある状況では必要であっても、別の状況では必要でない場合がある。必要とされる接続ピン・インスタンスの決定は異なるフィルタ間の相互接続を実際に行うサード・パーティ制御エージェントによって最初に行われる。
【０１２９】
この分野の精通者ならば理解されるように、本発明の種々方法はコンピュータ・プログラム・コード手段として、磁気ディスク、CD-ROM、およびこの分野で共通している他の媒体やまだ未開発の他の共通媒体などの、コンピュータ読取り可能媒体上にストアされるコンピュータ命令として組み込んでおくことが可能である。さらに、コンピュータ・ハードウェア・メモリに置かれる重要なデータ構造は、上記のようなコンピュータ・プログラム・コード手段のオペレーションにより作成することができる。
【０１３０】
本発明は本発明の基本的特徴の精神から逸脱しない限り、他の実施形態で実現することも可能である。上述してきた各種実施の形態はすべての点で説明した通りであるが、これらの実施の形態に限定されるものではない。従って、本発明の範囲は上述してきた説明によってではなく、特許請求の範囲に記載されている事項によってのみ限定されるものである。特許請求の範囲の均等の意味と範囲に属する一切の変更は本発明の範囲に属するものである。
【図面の簡単な説明】
【図１】制御エージェントの指示を受けてサウンド・データをディスク・ファイルから持ち込み、サウンド・データをなんらかの形態で処理し、サウンド・データをレンダリングしてスピーカから再生させる相互接続フィルタとドライバのシステムを示す従来技術のデータ・フロー図である。
【図２】図１に示すシステムと目的が同じであり、サウンド・データをディスク・ドライバから読み取り、そのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにし、処理フィルタとレンダリングは、この場合も制御エージェントの指示を受けて相互接続カーネル・モード・ドライバによって処理されるようした本発明によるシステムを示す図である。
【図３】オペレーティング・システムで作成され、使用されるドライバ・オブジェクト、デバイス・オブジェクトおよびファイル・オブジェクト間の関係を示す垂直関係モデルを示す図である。
【図４】ドライバ・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図５】デバイス・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図６】ファイル・オブジェクトのロジック・ブロック図であり、本発明のシステムに従ってメッセージを適切なプロセス・ハンドリング・コードへ転送し、新しいファイル・オブジェクトの作成をバリデーションするためのデータ構造およびプログラム・コードとの論理的関係を示す図である。
【図７】ルーチングとバリデーション・コンポーネントリの初期セットアップとカーネル・モード・ドライバによる入出力メッセージの処理を示すフローチャートである。
【図８】制御エージェントの処理、ルーチングとバリデーション・メカニズム、および新しいファイル・オブジェクトを作成する具体的な作成ハンドラ・ルーチンを示す詳細フローチャートである。
【図９】オペレーティング・システムでファイル・オブジェクト構造を利用して、接続を標準化された方法で行う接続フィルタ間の水平関係を示すロジック図である。
【図１０】図９のカーネル・モード・フィルタまたはドライバを作成し、接続するためにユーザ・モードの制御エージェントによってとられる処理ステップを示すフローチャートであり、制御エージェントから受け取った入出力要求を処理するために接続を行い、その処理が異なるドライバ（フィルタ）間で続けられる様子を示している。
【図１１】ユーザ・モードの制御エージェントの指示を受けてカーネル・モード・フィルタのチェインを作成するために使用され、サウンド・データをハード・ドライブから読み取り、カーネル・モード・フィルタでそのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにするシステムを実装するためのカーネル・モード・ドライバと接続を示す概要ロジック図である。
【図１２】ユーザ・モードの制御エージェントの指示を受けてカーネル・モード・フィルタのチェインを作成するために使用され、サウンド・データをハード・ドライブから読み取り、カーネル・モード・フィルタでそのデータを処理し、そのデータをレンダリングしてスピーカから聞こえるようにするシステムを実装するためのカーネル・モード・ドライバと接続を示す概要ロジック図である。
【図１３】図１１と図１２に示すシステム用に相互接続カーネル・モード・ドライバを作成するための処理ステップを示すフローチャートである。
【符号の説明】
４４ 制御エージェント
４６ ディスク・ドライブ
４８ ディスク・ドライバ
５０ リーダ・ドライバ
５２ デコンプレッサ・ドライバ
５４ 効果フィルタ
５６ 効果プロセッサ
５８ レンダリング・ドライバ
６２ スピーカ
６４，７６，８０ ドライバ・オブジェクト
６６ デバイス・オブジェクト
７０，７２，７４，９０ ファイル・オブジェクト
７８ 汎用マルチプレクシング・ディスパッチ機能
８２ デバイス・エクステンション・エリア
８４，１００ ファイル・タイプ・バリデーション・テーブル
８６，１０２ ファイル・オブジェクト・タイプ
８８ 作成ハンドラ
９２ ファイル・コンテキスト・エリア
９４ ＩＲＰ要求ハンドラ・テーブル
９６ ＩＲＰ要求
９８ ハンドラ
１０４ 参照
１４６ フィルタＡ
１４８ フィルタＢ
１５４ 入力フィルタ・ピン・インスタンス
１５８ 出力ピン・インスタンス
Claims (6)
- カーネル・モードに存在する２つ以上のソフトウェア・ドライバを相互接続してデータをカーネル・モードで処理するための方法において、前記ソフトウェア・ドライバはカーネル・モードのデバイス・オブジェクトに対応するフィルタの情報を有し、前記方法は、
ユーザ・モードのエージェントが、前記フィルタの情報に基づいて、前記フィルタを接続するための接続ピン・インスタンスを作成するステップと、
前記ユーザ・モードのエージェントが、前記作成された接続ピン・インスタンスを用いて前記フィルタを接続したフィルタ・グラフを作成するステップであって、前記フィルタ・グラフの最後のフィルタから前記フィルタ・グラフの最初のフィルタに向かう順に、前記フィルタの情報のスタック構造を作成するステップを含む、フィルタ・グラフを作成するステップと、
前記フィルタが前記フィルタ・グラフに沿ってデータを処理する際に、前記スタック構造に含まれたフィルタの情報に基づいて処理を行うステップと
を備え、前記データは、カーネル・モードにおいて前記フィルタにより連続的に処理されることを特徴とする方法。 - 請求項１に記載の方法において、前記２つ以上のソフトウェア・ドライバはあらかじめ定義された少なくとも１つの接続ピン・インスタンスのタイプをサポートし、前記接続ピン・インスタンスを作成するステップは、前記２つ以上のソフトウェア・ドライバの各々に照会し、サポートされる接続ピン・インスタンスのタイプを判断してから前記接続ピン・インスタンスを作成するステップを含むことを特徴とする方法。
- 請求項１に記載の方法において、前記２つ以上のソフトウェア・ドライバはあらかじめ定義された少なくとも１つの接続ピン・インスタンスのタイプとデータ・フォーマットをサポートし、どのタイプの接続ピン・インスタンスとデータ・フォーマットがソフトウェア・ドライバによってサポートされるかを前記ユーザ・モードのエージェントに示すことを特徴とする方法。
- 請求項１に記載の方法において、前記接続ピン・インスタンスは関連ソフトウェア・ドライバで処理するためのデータを受信する入力ピン・インスタンス、および関連ソフトウェア・ドライバから接続されたソフトウェア・ドライバへデータを送信する出力ピン・インスタンスを含むことを特徴とする方法。
- 請求項１に記載されたステップをコンピュータに実行させるためのコンピュータ実行可能命令を有するコンピュータ読取り可能な記録媒体。
- メディア・ソースと、
前記メディア・ソースから受信したメディア・サンプルを処理するための複数のカーネル・モード・ドライバであって、各カーネル・モード・ドライバは実行可能な各機能に関連づけられた個別のデバイス・オブジェクトに対応するフィルタの情報を有する複数のカーネル・モード・ドライバと、
前記メディア・ソースからメディア・ストリームのメディア・サンプルを読み取る第１のコンポーネントと、
前記メディア・ストリームをレンダリングする第２のコンポーネントと、
前記メディア・サンプルを前記第１のコンポーネントおよび前記第２のコンポーネント間で受け渡すために、前記フィルタの情報に基づいて前記フィルタを接続するための接続ピン・インスタンスを作成し、前記作成された接続ピン・インスタンスを用いて前記フィルタを接続したフィルタ・グラフを作成するユーザ・モードのエージェントであって、前記フィルタ・グラフの最後のフィルタから前記フィルタ・グラフの最初のフィルタに向かう順に、前記フィルタの情報のスタック構造を作成する、ユーザ・モードのエージェントとを有し、
前記フィルタは前記フィルタ・グラフに沿って前記メディア・サンプルを処理する際に、前記スタック構造に含まれたフィルタの情報に基づいて処理を行い、
前記メディア・サンプルは、カーネル・モードにおいて前記フィルタにより連続的に処理されることを特徴とするカーネル・モード・メディア・レンダリング・システム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/825,856 | 1997-04-04 | ||
| US08/825,856 US6205492B1 (en) | 1997-04-04 | 1997-04-04 | Method and computer program product for interconnecting software drivers in kernel mode |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007150927A Division JP2007305141A (ja) | 1997-04-04 | 2007-06-06 | カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10283195A JPH10283195A (ja) | 1998-10-23 |
| JP4684376B2 true JP4684376B2 (ja) | 2011-05-18 |
Family
ID=25245074
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP16477097A Expired - Fee Related JP4684376B2 (ja) | 1997-04-04 | 1997-06-20 | カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法，コンピュータ・プログラム・プロダクト、システムおよび記録媒体 |
| JP2007150927A Pending JP2007305141A (ja) | 1997-04-04 | 2007-06-06 | カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007150927A Pending JP2007305141A (ja) | 1997-04-04 | 2007-06-06 | カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US6205492B1 (ja) |
| EP (1) | EP0871114A3 (ja) |
| JP (2) | JP4684376B2 (ja) |
| CA (1) | CA2208289C (ja) |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7007096B1 (en) | 1999-05-12 | 2006-02-28 | Microsoft Corporation | Efficient splitting and mixing of streaming-data frames for processing through multiple processing modules |
| US6658477B1 (en) * | 1999-05-12 | 2003-12-02 | Microsoft Corporation | Improving the control of streaming data through multiple processing modules |
| US6832379B1 (en) * | 1999-08-17 | 2004-12-14 | Emc Corporation | Computer architecture utilizing layered device drivers |
| CA2397740C (en) | 2000-01-14 | 2015-06-30 | Catavault | Method and system for secure registration, storage, management and linkage of personal authentication credentials data over a network |
| US7043697B1 (en) * | 2000-05-15 | 2006-05-09 | Intel Corporation | Virtual display driver |
| US6868450B1 (en) * | 2000-05-17 | 2005-03-15 | Hewlett-Packard Development Company, L.P. | System and method for a process attribute based computer network filter |
| US6609155B1 (en) * | 2000-05-25 | 2003-08-19 | International Business Machines Corporation | Method and apparatus for providing relationships in simple network management protocol management information base |
| CN1393095A (zh) | 2000-10-17 | 2003-01-22 | 皇家菲利浦电子有限公司 | 控制硬件组件配置的方法 |
| US7818443B2 (en) | 2000-12-01 | 2010-10-19 | O2Micro International Ltd. | Low power digital audio decoding/playing system for computing devices |
| US6959438B2 (en) | 2000-12-06 | 2005-10-25 | Microsoft Corporation | Interface and related methods for dynamically generating a filter graph in a development system |
| US7447754B2 (en) * | 2000-12-06 | 2008-11-04 | Microsoft Corporation | Methods and systems for processing multi-media editing projects |
| US7103677B2 (en) | 2000-12-06 | 2006-09-05 | Microsoft Corporation | Methods and systems for efficiently processing compressed and uncompressed media content |
| US6983466B2 (en) * | 2000-12-06 | 2006-01-03 | Microsoft Corporation | Multimedia project processing systems and multimedia project processing matrix systems |
| US6912717B2 (en) | 2000-12-06 | 2005-06-28 | Microsoft Corporation | Methods and systems for implementing dynamic properties on objects that support only static properties |
| US6961943B2 (en) * | 2000-12-06 | 2005-11-01 | Microsoft Corporation | Multimedia processing system parsing multimedia content from a single source to minimize instances of source files |
| US6882891B2 (en) | 2000-12-06 | 2005-04-19 | Microsoft Corporation | Methods and systems for mixing digital audio signals |
| US7114161B2 (en) | 2000-12-06 | 2006-09-26 | Microsoft Corporation | System and related methods for reducing memory requirements of a media processing system |
| US6954581B2 (en) * | 2000-12-06 | 2005-10-11 | Microsoft Corporation | Methods and systems for managing multiple inputs and methods and systems for processing media content |
| US6768499B2 (en) * | 2000-12-06 | 2004-07-27 | Microsoft Corporation | Methods and systems for processing media content |
| US7287226B2 (en) * | 2000-12-06 | 2007-10-23 | Microsoft Corporation | Methods and systems for effecting video transitions represented by bitmaps |
| US7114162B2 (en) | 2000-12-06 | 2006-09-26 | Microsoft Corporation | System and methods for generating and managing filter strings in a filter graph |
| US6834390B2 (en) * | 2000-12-06 | 2004-12-21 | Microsoft Corporation | System and related interfaces supporting the processing of media content |
| US6774919B2 (en) * | 2000-12-06 | 2004-08-10 | Microsoft Corporation | Interface and related methods for reducing source accesses in a development system |
| US6892377B1 (en) * | 2000-12-21 | 2005-05-10 | Vignette Corporation | Method and system for platform-independent file system interaction |
| US7194506B1 (en) | 2000-12-21 | 2007-03-20 | Vignette Corporation | Method and system for cache management of locale-sensitive content |
| JP5055492B2 (ja) * | 2001-05-07 | 2012-10-24 | サイエンスパーク株式会社 | 電子計算機のインターフェースドライバプログラム及びその記録媒体 |
| US7571445B2 (en) * | 2001-11-29 | 2009-08-04 | Dell Products L.P. | System and method for dynamic device driver support in an open source operating system |
| US7209971B1 (en) * | 2001-12-11 | 2007-04-24 | Microsoft Corporation | Architecture and run-time environment for network filter drivers |
| CN1332331C (zh) * | 2002-02-15 | 2007-08-15 | 科学园株式会社 | 利用计算机输入装置的输入特征的个人认证方法及其电子计算机系统 |
| US7451457B2 (en) * | 2002-04-15 | 2008-11-11 | Microsoft Corporation | Facilitating interaction between video renderers and graphics device drivers |
| US7219352B2 (en) * | 2002-04-15 | 2007-05-15 | Microsoft Corporation | Methods and apparatuses for facilitating processing of interlaced video images for progressive video displays |
| US7024672B2 (en) * | 2002-06-26 | 2006-04-04 | Microsoft Corporation | Process-mode independent driver model |
| CN1288548C (zh) * | 2002-12-31 | 2006-12-06 | 上海科泰世纪科技有限公司 | 基于类别创建驱动构件对象实现设备驱动程序多态的方法 |
| CN1245685C (zh) * | 2002-12-31 | 2006-03-15 | 上海科泰世纪科技有限公司 | 基于构件的操作系统动态设备驱动的方法 |
| US20040243783A1 (en) * | 2003-05-30 | 2004-12-02 | Zhimin Ding | Method and apparatus for multi-mode operation in a semiconductor circuit |
| US7643675B2 (en) | 2003-08-01 | 2010-01-05 | Microsoft Corporation | Strategies for processing image information using a color information data structure |
| JP2005275643A (ja) | 2004-03-24 | 2005-10-06 | Hitachi Ltd | コンテンツデータ処理装置及び方法 |
| JP4285307B2 (ja) | 2004-04-02 | 2009-06-24 | 株式会社日立製作所 | データ処理装置およびその方法 |
| US7765558B2 (en) * | 2004-07-06 | 2010-07-27 | Authentium, Inc. | System and method for handling an event in a computer system |
| US8341649B2 (en) * | 2004-07-06 | 2012-12-25 | Wontok, Inc. | System and method for handling an event in a computer system |
| JP2006031261A (ja) * | 2004-07-14 | 2006-02-02 | Matsushita Electric Ind Co Ltd | マルチメディア処理システム |
| US7711952B2 (en) * | 2004-09-13 | 2010-05-04 | Coretrace Corporation | Method and system for license management |
| US7640552B2 (en) * | 2004-10-29 | 2009-12-29 | Microsoft Corporation | Multimedia filter resilience |
| US7400271B2 (en) * | 2005-06-21 | 2008-07-15 | International Characters, Inc. | Method and apparatus for processing character streams |
| JP4828927B2 (ja) * | 2005-12-16 | 2011-11-30 | パナソニック株式会社 | ストリーム制御装置 |
| US8479283B2 (en) * | 2006-11-28 | 2013-07-02 | Microsoft Corporation | Generating security validation code automatically |
| US20080235246A1 (en) * | 2007-03-20 | 2008-09-25 | Arun Hampapur | Filter sequencing based on a publish-subscribe architecture for digital signal processing |
| US8020150B1 (en) * | 2007-05-11 | 2011-09-13 | Nvidia Corporation | System, method, and computer program product for controlling a driver utilizing scripts |
| WO2009151888A2 (en) * | 2008-05-19 | 2009-12-17 | Authentium, Inc. | Secure virtualization system software |
| US10534637B1 (en) * | 2018-02-21 | 2020-01-14 | Parallels International Gmbh | Systems and methods for managing chain of software applications |
| CN115048157B (zh) * | 2022-08-12 | 2022-11-11 | 南方电网数字电网研究院有限公司 | 一种基于专用芯片的自主可控配电控制模组 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2521016B2 (ja) | 1991-12-31 | 1996-07-31 | インターナショナル・ビジネス・マシーンズ・コーポレイション | マルチメディア・デ―タ処理システム |
| US5386568A (en) * | 1992-12-01 | 1995-01-31 | Yamaha Corporation | Apparatus and method for linking software modules |
| US5485617A (en) * | 1993-12-13 | 1996-01-16 | Microsoft Corporation | Method and system for dynamically generating object connections |
| US5793961A (en) * | 1994-11-18 | 1998-08-11 | Intel Corporation | Computer system with data conference capability |
| US5768126A (en) * | 1995-05-19 | 1998-06-16 | Xerox Corporation | Kernel-based digital audio mixer |
-
1997
- 1997-04-04 US US08/825,856 patent/US6205492B1/en not_active Expired - Lifetime
- 1997-06-19 EP EP97304296A patent/EP0871114A3/en not_active Withdrawn
- 1997-06-19 CA CA002208289A patent/CA2208289C/en not_active Expired - Fee Related
- 1997-06-20 JP JP16477097A patent/JP4684376B2/ja not_active Expired - Fee Related
-
2007
- 2007-06-06 JP JP2007150927A patent/JP2007305141A/ja active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| EP0871114A3 (en) | 1998-12-16 |
| JP2007305141A (ja) | 2007-11-22 |
| CA2208289C (en) | 2009-12-29 |
| JPH10283195A (ja) | 1998-10-23 |
| EP0871114A2 (en) | 1998-10-14 |
| CA2208289A1 (en) | 1998-10-04 |
| US6205492B1 (en) | 2001-03-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4684376B2 (ja) | カーネル・モードにおけるソフトウェア・ドライバを相互接続する方法，コンピュータ・プログラム・プロダクト、システムおよび記録媒体 | |
| JP3929554B2 (ja) | ファイル・オブジェクトの生成をバリデーションし、ファイル・オブジェクトへのメッセージをルーチングする方法 | |
| JP3929551B2 (ja) | セパレート・プロセッシング・コンポーネント間のバッファ間データ転送を減らす方法およびコンピュータ読取り可能媒体 | |
| JP4575528B2 (ja) | 標準クロック・メカニズムを用いて、多重データ・ストリームの処理の同期と異なる処理速度のマッチングを行う方法 | |
| JP4972082B2 (ja) | 開発者がシステム上の周知のロケーションを容易に発見し、または拡張するための能力 | |
| JP3072709B2 (ja) | 要求伝達方法 | |
| US6226692B1 (en) | Method and system for constructing software components and systems as assemblies of independent parts | |
| US6266716B1 (en) | Method and system for controlling data acquisition over an information bus | |
| US20030163598A1 (en) | Method and system for distributing data events over an information bus | |
| JPH10283198A (ja) | コンピュータ・オペレーティング・システムにおけるカーネル・モード動作のユーザ・モード・プロキシ | |
| JPH08263292A (ja) | オブジェクト指向プログラミング・インターフェース及びマップする方法 | |
| JP2005301993A (ja) | コマンドバインディングを実行するためのデータバインディング機構のアプリケーション | |
| JPH0675846A (ja) | アプリケーションのオブジェクト指向呼出しをデータベースで行うための方法及び装置 | |
| US6643712B1 (en) | Validating the creation of and routing of messages to file objects | |
| US20040049765A1 (en) | Method and system for implementing virtual functions of an interface | |
| US20050034099A1 (en) | Method of developing software programs for resource constrained mobile computing devices | |
| CA2396104A1 (en) | Method and system for implementing virtual functions of an interface | |
| WO2011071543A2 (en) | Transparent network substrate system | |
| JP2002132502A (ja) | 言語機能解釈による分散オブジェクト自動生成システム及び方法 | |
| Cui | Correctness of distributed systems with middleware. | |
| CN117908971A (zh) | 基于微内核系统的设备资源管理方法、装置、设备和介质 | |
| Greenbaum | Writing Flexible Device Drivers for DSP/BIOS II | |
| Lin et al. | A Design Framework for Embedded Linux Drivers | |
| US20090240720A1 (en) | Method and system for dynamically controlling functionality of an application program and storage medium for storing instructions which effectuate the method | |
| Popovich et al. | Integrating a Rule-Based Process Server with an Existing Environment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040514 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060512 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060814 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060818 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061113 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070206 |
|
| RD13 | Notification of appointment of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7433 Effective date: 20070508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20070508 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070606 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070612 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20071012 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100512 |
|
| RD13 | Notification of appointment of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7433 Effective date: 20100526 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20100526 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110107 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110209 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140218 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees | ||
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |