(57)【特許請求の範囲】
【請求項１】
ともに同じデータ処理システムの一部であるオブジェクト指向コンポーネントと手続き型プログラム式デバイス・ドライバの間で通信をブリッジする装置であって、
前記オブジェクト指向コンポーネントを前記デバイス・ドライバに結合するオブジェクト指向インターフェース・デバイスと、
前記オブジェクト指向インターフェース・デバイスに含まれ、前記オブジェクト指向コンポーネントを前記デバイス・ドライバから分離する手段であって、前記分離手段は、前記手続き型デバイス・ドライバと通信されるデータ・オブジェクトからデータ型、属性およびバッファリング・アドレス情報を取得させ、前記デバイス・ドライバをオープンし、初期化し、制御し、或いはクローズするための手続型コードの関数呼び出しを実行させるための前記分離手段と、
トランスポート手段であって、前記オブジェクト指向インターフェース・デバイスにより制御され、前記分離手段からのデータ型、属性およびバッファリング・アドレス情報を受け取って前記データ型、属性により指定される手続き型デバイス固有の情報と前記データ・オブジェクトとをカプセル化するためのトランスポート手段と、
前記トランスポート手段に含まれ、前記オブジェクト指向コンポーネントから前記デバイス・ドライバへデータをトランスポートするための手段と、
前記トランスポート手段に含まれ、前記オブジェクト指向コンポーネントと前記デバイス・ドライバの間のデータフローを制御するための手段と、
を備える装置。
【請求項２】
前記オブジェクト指向インターフェース・デバイスがさらに、
前記デバイス・ドライバを介して前記オブジェクト指向コンポーネントから前記デバイスにマイクロコードをロードする手段を備えることを特徴とする請求項１に記載の装置。
【請求項３】
１つのオブジェクト指向コンポーネントと複数個の手続き型デバイス・ドライバとを有するデータ処理システムにおいて、前記オブジェクト指向コンポーネントと前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つとの間で通信をブリッジするコンピュータにより実行可能な方法であって、
前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つから前記オブジェクト指向コンポーネントを分離するステップであって、前記手続き型デバイス・ドライバと通信されるデータ・オブジェクトからデータ型、属性およびバッファリング・アドレス情報を取得させ、前記デバイス・ドライバをオープンし、初期化し、制御し、或いはクローズするための手続型コードの関数呼び出しを実行する、前記分離を行うステップと、
前記分離手段からのデータ型、属性およびバッファリング・アドレス情報を受け取って前記データ型、属性により指定される前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つに関連する固有のデバイス・ドライバ情報を、前記データ・オブジェクトとカプセル化するステップと、
前記データ型、属性、およびバッファリング・アドレス情報による指定に対応して、要求またはコマンドあるいはその両方を前記オブジェクト指向コンポーネントから前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つに、他の複数のデバイス・ドライバに対するデータフローとは独立して移送するステップとを含む方法。
【請求項４】
前記デバイス・ドライバを介して前記オブジェクト指向コンポーネントから前記デバイスにマイクロコードをロードするステップをさらに含む請求項３に記載の方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、一般にオブジェクト指向アプリケーションと手続き型プログラム式アプリケーションの両方を備えるデータ処理システムに関し、より詳細には、手続き型デバイス・ドライバとインターフェースするオブジェクト指向オペレーティング・システムを使用したデータ処理システムに関する。さらに具体的には、本発明は、オブジェクト指向ソリューションを使用して手続き型デバイス・ドライバとインターフェースするオブジェクト指向コンポーネントを使用したデータ処理システムに関する。
【０００２】
【従来の技術】
オブジェクト指向プログラミングは、重要な新しいプログラミング技術になってきた。オブジェクト指向プログラミングでは、ソフトウェアの再使用可能性と拡張性が得られるため、ソフトウェアのプログラミングが大幅に簡単になっており、従来のソフトウェア・プログラミングに較べてプログラマの生産性の改善をもたらす。とはいえ、オブジェクト指向技術は、主要な商用ソフトウェア製品群にまだ普及していない。特に、オペレーティング・システムは、この新しい技術の採用にまだ躊躇している。
【０００３】
とはいえ、オブジェクト指向プログラミング（ＯＯＰ：Ｏｂｊｅｃｔ  Ｏｒｉｅｎｔｅｄ  Ｐｒｏｇｒａｍｍｉｎｇ）は、業界で受け入れられ始めている。残念なことに、手続き型プログラミングに関してオブジェクト指向プログラミングが直面している１つの問題は、今日の既存のソフトウェアのほとんどが手続き型コードから構成されている点である。この手続き型コードは、その性質上、きわめて一体的に設計されており、オブジェクト指向ソフトウェアの柔軟な要件に追随できない。さらに、今日のソフトウェアでは厳密な手続き型アプローチが（アプリケーションからオペレーティング・システムを経てデバイス・ドライバに至る）トップ・ダウン方式で適用されており、このこともＯＯＰへの移行をきわめて困難なものにしている。
【０００４】
多くの場合、オブジェクト指向ソフトウェア・コンポーネントを実施するには、オペレーティング・システムとそのデバイス・ドライバを、ＯＯＰの規格に合わせて書き直さなければならない。オブジェクト指向コンポーネントを実施するためのもう１つの方法は、ハイブリッドＯＯ（Ｏｂｊｅｃｔ  Ｏｒｉｅｎｔｅｄ）コンポーネントを設計することである。このハイブリッドＯＯコンポーネントでは、オペレーティング・システムまたはデバイス・ドライバあるいはその両方など、その他の既存の手続き型ソフトウェア・コンポーネントとインターフェースする必要がある場合に、手続き型モードに戻る。ＯＯと手続き型ソフトウェアを組み合わせたこのハイブリッド・モデルは、ＯＯＰで提供される利点を打ち消してしまう。また、そのようなソフトウェアの全体的整合性が危険にさらされる。
【０００５】
したがって、既存の手続き型デバイス・ドライバを再度作成したり、ＯＯソフトウェア・コンポーネントをハイブリッド・モードにしたりする必要のない設計および実施形態が必要である。また、データ処理システムを実行する基本ソフトウェアとは無関係に、ＯＯＰコンポーネントと手続き型プログラム式コンポーネントをブリッジするための汎用ＯＯＰデバイス・ドライバ・インターフェースも必要とされている。
【０００６】
【発明が解決しようとする課題】
そのため、本発明の一目的は、オブジェクト指向アプリケーションと手続き型プログラム式アプリケーションの両方を備えたデータ処理システムを提供することである。
【０００７】
本発明の他の目的は、手続き型デバイス・ドライバとインターフェースするオブジェクト指向オペレーティング・システムを使用したデータ処理システムを提供することである。
【０００８】
本発明の他の目的は、オブジェクト指向ソリューションを使用して手続き型デバイス・ドライバとインターフェースするオブジェクト指向コンポーネントを使用したデータ処理システムを提供することである。
【０００９】
【課題を解決するための手段】
前記の目的は以下に記述するようにして達成される。本発明によれば、オブジェクト指向コンポーネントと手続き型プログラム式デバイス・ドライバの間の通信をブリッジするための方法および装置を開示する。オブジェクト指向コンポーネントも、手続き型プログラム式デバイス・ドライバも、ともにデータ処理システムの一部である。デバイス・ドライバとインターフェースする際は、方法と装置の両方を使用し、特定のデバイス・ドライバに関連する固有のデバイス・ドライバ情報をカプセル化し、次いでデバイス・ドライブとインターフェースするときオブジェクト指向コンポーネントからその固有のデバイス・ドライバに要求またはコマンドを移送することによって、オブジェクト指向コンポーネントをデバイス・ドライバ、具体的には活動デバイス・ドライバから分離する。オブジェクト指向コンポーネントは、デバイス・ドライバとの通信をオープンまたはクローズするだけでなく、デバイス・ドライバ内の情報を使用してデバイスを初期設定し、デバイス・ドライバを介してデバイスを制御することも可能とするインターフェース・オブジェクトを生成する。また、選択されたオブジェクト指向デバイス・ドライバからオブジェクト指向コンポーネントにデータを移送できるようにするトランスポート・オブジェクトも生成される。このトランスポート・オブジェクトはまた、コンポーネントと選択されたデバイス・ドライバの間のデータ・フローを制御することもできる。
【００１０】
代替実施例では、オブジェクト指向コンポーネントとプログラム式デバイス・ドライバの間の通信をブリッジする方法は、オブジェクト指向サブシステム内にオブジェクト指向コンポーネントを作成する。次に、システムは、インターフェース・オブジェクトを構築し、次いでオブジェクト指向サブシステム内でトランスポート・オブジェクトを構築する。その後、インターフェース・オブジェクトとトランスポート・オブジェクトを介して、デバイス・ドライバとオブジェクト指向コンポーネントの間で通信を確立する。このインターフェース・オブジェクトを使用すると、データ型を、オブジェクト指向サブシステムから設定することができ、デバイス・ドライバのコンポーネント属性を設定することもできる。トランスポート・オブジェクトとインターフェース・オブジェクトを使用すると、オブジェクト指向サブシステムからデバイス・ドライバによってコマンドを実行できるだけでなく、オブジェクト指向サブシステムとデバイス・ドライバの間でデータを伝送することもできる。
【００１１】
本発明の上記その他の目的、機能、および利点は、以下の詳しい説明から明らかになるであろう。
【００１２】
本発明の特徴であると考えられる新規な特徴は、添付の特許請求の範囲に記述する。ただし、本発明自体ならびに本発明の好ましい使用態様、その他目的および利点は、例示的実施形態に関する下記の詳細な説明を添付の図面と併せて読めば最もよく理解されよう。
【００１３】
【発明の実施の形態】
本発明では、発明対象のクラス内にデータとコードの両者をカプセル化するなど、オブジェクト指向設計およびプログラミング（ＯＯＤ＆Ｐ）に固有の技法を利用する。これらのクラスは、他のソフトウェア・コンポーネントがそれと通信するためのＯＯインターフェースを備え、それがデバイス・ドライバなど他の手続き型コンポーネントと通信するのに必要な手続き型インターフェースを含む。これは、ハイブリッドなソリューションに見えるが、手続き型コンポーネントと通信する必要のある他のＯＯコンポーネントとは独立している。本発明は、ＯＯＤ＆Ｐおよび手続き型プログラミングという２つのプログラミング・モデル間の、汎用の自己完結型インターフェースを提供する。さらに、本発明では、本特許と同じ譲受人に譲渡された「Ｏｂｊｅｃｔ  Ｏｒｉｅｎｔｅｄ  Ｍｅｔｈｏｄ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ  ａｎｄ  Ｓｏｆｔｗａｒｅ  ｆｏｒ  Ｍａｎａｇｉｎｇ  Ｃｌａｓｓ  Ｍｅｔｈｏｄ  Ｎａｍｅｓ  ｉｎ  ａ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ」という名称の米国特許第５３６１３５０号に教示されているオブジェクト指向設計およびプログラミングの概念の多くを利用している。上記特許をあらゆる目的でこの参照により本明細書の一部とする。
【００１４】
本発明は、パーソナル・コンピュータやワークステーションなどのマイクロコンピュータ上に常駐するオペレーティング・システムの環境で実施することが望ましい。代表的なハードウェア環境を、図１に示す。図１には、従来型のマイクロプロセッサなどの中央演算処理装置１０、およびシステム・バス１２を介して相互接続されたその他の多数の装置を備える、本発明によるワークステーションの典型的なハードウェア構成を示す。図１に示したワークステーションは、ランダム・アクセス・メモリ（ＲＡＭ）１４、読取り専用メモリ（ＲＯＭ）１６、ディスク装置２０などの周辺装置を前記バスに接続するための入出力（Ｉ／Ｏ）アダプタ１８、キーボード２４、マウス２６、スピーカー２８、マイクロフォン３２や、タッチ・スクリーン装置（図示せず）などのユーザ・インターフェース装置を前記バスに接続するためのユーザ・インターフェース・アダプタ２２、ワークステーションをデータ処理ネットワークに接続するための通信アダプタ３４、および前記バスを表示装置３８に接続するための表示装置アダプタ３６を備える。このワークステーション上には、ＯＳ／２ベースのオペレーティング・システムと、本発明を構成するツールキットとしてのコンピュータ・ソフトウェアが常駐する。
【００１５】
ＲＯＭ１６はさらに、オンボード・チップＲＯＭやコンパクト・ディスクＲＯＭなど、他のＲＯＭ装置を備えることができる。また、オペレーティング・システムは、ＯＳ／２の代わりに、インターナショナル・ビジネス・マシーンズ・コーポレイションから市販のＡＩＸ、Ｍｉｃｒｏｓｏｆｔ  Ｉｎｃ．から市販されている製品Ｗｉｎｄｏｗｓ、ＤＯＳ、ＮＴ、Ｔａｌｉｇｅｎｔ  Ｃｏｒｐｏｒａｔｉｏｎから市販のＴａｌｉｇｅｎｔＯ／Ｓ、ならびに様々なソフトウェア会社から提供されているＵＮＩＸオペレーティング・システムなどの中から選択することもできる。さらに、本発明は、やはりインターナショナル・ビジネス・マシーンズ・コーポレイション製のＡＳ／４００ワークステーション・システムなどもう少し大型のミニコンピュータや、さらに大型のメインフレーム・コンピュータ・システム上で稼働させることもできる。
【００１６】
図２に、手続き型デバイス・ドライバ５２と通信しなければならないオブジェクト指向ソフトウェア・コンポーネント５０との間のブリッジを提供するシステムのブロック図を示す。オブジェクト指向汎用デバイス・インターフェース５４が、このブリッジとして提供される。インターフェース５４を使用すると、ＯＯソフトウェアがその利点をすべて保持しながら、ＯＯソフトウェア・コンポーネントとデバイス・ドライバの間の通信が可能になる。これにより、ＯＯＰは、既存の手続き型のコード・ベースのデバイス・ドライバと互換性をもつことができる。また、本発明は、その中でＯＯＰを使用することにより、ＯＯＰでないデバイス・ドライバがＯＯＰに移行する道を開く。
【００１７】
オブジェクト指向コンポーネント５０中では、ＯＯコードは手続き型デバイス・ドライバ５２内の手続き型コードから分離されたままとなる。手続き型デバイス・ドライバ５２中では、手続き型コードは、そのままコンポーネント５０内のＯＯコードから分離されたままである。ＯＯコンポーネント５０は、ＯＯ方法の呼出しを手続き型デバイス・ドライバに発行するが、デバイス・ドライバ５２は手続き型呼出しを受け取るとコール・バックを発行しようと試みるのでこれらの呼出しは互換性がなく、ブリッジが必要となる。このブリッジは、ＯＯ総称デバイス・インターフェース５４によって実現または提供される。デバイス・インターフェース５４は、ＯＯＰ方法を使用してデバイス・ドライバから手続き型コードをラップアラウンドし、それによってＯＯコンポーネント５０と手続き型デバイス・ドライバ５２の間の通信が可能になる。デバイス・インターフェース５４は、さらにＤＤＩｎｔｅｒｆａｃｅとＤＤＴｒａｎｓｐｏｒｔという名前のＯＯクラスも備える。各クラスはデータのカプセル化、包含、独立した役割などのＯＯ特性を有し、それらがあいまってＯＯＰと手続き型ソフトウェア・モデルの間のブリッジが構築される。また、これらのクラスをサブクラスに分割して、特定のデバイスやプラットフォームに必要な特別の特性を実現することもできる。これらのクラスは、１）他のＯＯコンポーネントに対するＯＯインターフェースを提供する、２）手続き型デバイス・ドライバから他のＯＯコンポーネントを分離する、３）デバイス固有の情報をカプセル化し、それによってデバイスの独立性を提供する、４）オブジェクト・データの型と属性を操作する、５）手続き型デバイス・ドライバとの間でのデータ・フローを制御する、６）データ・フローの「状態」を維持するという役割を実行する。
【００１８】
ＤＤＩｎｔｅｒｆａｃｅクラスは、手続き型デバイス・ドライバに対する通信を実現するために他のＯＯコンポーネントがインターフェースする基底クラスである。また、ＤＤＩｎｔｅｒｆａｃｅは、デバイス・ドライバにアクセスするための手続き型コードを含むＯＯメソッドも備える。このクラスが提供する関数の概要を、図３のブロック図に示す。ブロック３０２に示した関数ＤｅｖｉｃｅＯｐｅｎ（）は、オブジェクト指向コンポーネントからデバイス・ドライバへの通信をオープンする。ブロック３０４に示した関数ＤｅｖｉｃｅＣｌｏｓｅ（）は、デバイス・ドライバへの通信をクローズする。ブロック３０６に示したＤｅｖｉｃｅＩｎｉｔ関数は、デバイス・ドライバを介してデバイスを初期設定する。一方、ブロック３０８に示したＤｅｖｉｃｅＣｏｎｔｒｏｌ（）関数は、デバイス・ドライバを介してデバイスを制御する。ブロック３１０に示したＤｅｖｉｃｅＬｏａｄ（）関数は、デバイス・ドライバを介してマイクロコードをデバイスにロードする。ブロック３０２〜３１０は、コンピュータ・システムの設計インターフェース、たとえばＤＯＳ  ＩＯＣＴＬ、入力／出力制御、ＭａｃｈのＩＰＣ、プロセス間通信を介して、手続き型デバイス・ドライバのエントリ・ポイントと通信する。ブロック３１２には、オブジェクト・データに対するコンストラクタ操作およびデストラクタ操作を提供するための内部方法を示してある。ブロック３１４には、ＳｅｔＤａｔａＴｙｐｅ（）関数やＳｅｔＣｏｎｔｒｏｌＡｔｔｒｉｂｕｔｅｓ（）関数などのデータ操作メソッドも示してある。ブロック３１６では、ＳｅｎｄＢｕｆｆｅｒｔｏＤｅｖｉｃｅ（）関数やＧｅｔＢｕｆｆｅｒｆｒｏｍＤｅｖｉｃｅ（）関数など、のデータ・フローメソッドを示してある。ブロック３１８に示したトランスポートメソッドはＤｅｖｉｃｅＳｔａｒｔ、ＤｅｖｉｃｅＳｔｏｐ、ＤｅｖｉｃｅＰａｕｓｅなどの関数を含み、本発明のＤＤＴｒａｎｓｐｏｒｔを介して、オブジェクト・データをデバイス・ドライバに移送するように機能する。ＤＤＩｎｔｅｒｆａｃｅクラスの動作は、図４のブロック図にさらに詳しく示す。これは、付録に示すＣ＋＋コードをベースにしたものである。
【００１９】
ＤＤＴｒａｎｓｐｏｒｔクラスは、特定の要求またはコマンドあるいはその両方を手続き型デバイス・ドライバに送信するためにＤＤＩｎｔｅｒｆａｃｅクラスがインターフェースする基底クラスである。また、ＤＤＴｒａｎｓｐｏｒｔクラスは、ＤＤＩｎｔｅｒｆａｃｅが現在通信しているデバイス・ドライバ以外のデバイス・ドライバと通信する能力、あるいはそれに必要な方法を備えている。ＤＤＴｒａｎｓｐｏｒｔクラスが提供する関数の概要を、図４のブロック図に示す。ＤＤＴｒａｎｓｐｏｒｔクラスは、内部メソッド４０２、トランスポート・メソッド４０４、データ制御操作４０６など、様々な関数およびメソッドを実行する。内部メソッド４０２には、ＤｅｖｉｃｅＯｐｅｎ、ＤｅｖｉｃｅＣｌｏｓｅ、およびＳｔａｔｅＣｏｎｔｒｏｌがオブジェクト・データおよび到着した要求パケットへのポインタと共に含まれる。データ・トランスポート・メソッド４０４には、図３のＤＤＩｎｔｅｒｆａｃｅの関数に類似した関数ＧｅｔＢｕｆｆｅｒｆｒｏｍＤｅｖｉｃｅ（）と関数ＳｅｎｄＢｕｆｆｅｒｔｏＤｅｖｉｃｅ（）が含まれる。データ制御メソッド４０６には、オブジェクトからデバイス・ドライバへのデータの移送を制御するための重要な関数であるＴｒａｎｓｐｏｒｔＳｔａｒｔ（）とＴｒａｎｓｐｏｒｔＳｔｏｐ（）が含まれる。これら３つのメソッドはすべて、ＩＯＣＴＬまたはＩＰＣ設計の通信手段を使用して、手続き型デバイス・ドライバのエントリ・ポイントに接続する。ＤＤＴｒａｎｓｐｏｒｔクラスおよびＤＤＩｎｔｅｒｆａｃｅクラスの実施および動作は、図５の流れ図にさらに詳しく示す。
【００２０】
図５のブロック図は、手続き型デバイス・ドライバにアクセスする際のステップを示す。ブロック５０２で、オブジェクト指向（ＯＯ）サブシステムが、操作対象となるオブジェクト、この場合は、オーディオ・オブジェクトを作成する。ブロック５０４で、オブジェクト指向サブシステム内からＤＤＩｎｔｅｒｆａｃｅオブジェクトが構築される。次にブロック５０６で、ＤＤＩｎｔｅｒｆａｃｅオーディオ・オブジェクトとして、オブジェクト指向サブシステムからデータの型と属性が設定される。ブロック５０８で、ＤＤＩｎｔｅｒｆａｃｅがＤＤＴｒａｎｓｐｏｒｔオブジェクトを構築し、デバイス・ドライバとの通信を確立する。この段階で、オブジェクトのデータと状態が設定される。ブロック５１０で、オブジェクト指向サブシステムが、たとえぱオーディオ・オブジェクトの再生を要求する。これは実際には、オーディオ・オブジェクトやビデオ・オブジェクトの再生など、そのオブジェクトに関して動作を実行することを求める要求である。
【００２１】
ブロック５１２で、ＤＤＩｎｔｅｒｆａｃｅが、ＯＯサブシステムからデータ・バッファを受信し、ＤＤＴｒａｎｓｐｏｒｔを呼び出してデバイスを起動する。具体的に言えば、ＤＤＩｎｔｅｒｆａｃｅは、開始コマンドとデータ送信コマンドを発行する。次にブロック５１４で、ＤＤＴｒａｎｓｐｏｒｔがデータ・バッファをデバイス・ドライバに送信する。次いでブロック５１８でＯＯサブシステムが停止を要求するまで、ブロック５１６で、さらにデータを送信するかどうかを判断する。「停止」が発行されておらず、かつ送信すべきデータがまだある場合、システムはブロック５１４に戻る。送信すべきデータがもうない場合、またはオーディオ・オブジェクトが「停止」要求を送信した場合、システムはブロック５２０に進む。ブロック５２０で、ＤＤＩｎｔｅｒｆａｃｅもＤＤＴｒａｎｓｐｏｒｔも、それぞれの状態制御メソッド内でそれぞれの状態を更新する。次に、ブロック５２２で、システムは次のコマンドを待ち、次のコマンドを受信するとブロック５１０に戻る。コマンドは、別の「再生」、データ・タイプ変更要求、破棄要求、あるいはその他の形でのデータの変更など、どのようなタイプのものでもかまわない。ブロック５２４で、ＯＯサブシステムがオーディオ・オブジェクトの処理を完了し、そのオブジェクトは破棄される。ブロック５２６で、ＤＤＩｎｔｅｒｆａｃｅデストラクタが活動化される。このデストラクタは、保留中の転送をすべて終了し、デバイス・ドライバをクローズして、自分自身を終了させる。次いでブロック５２８で、ＤＤＴｒａｎｓｐｏｒｔがＤＤＴｒａｎｓｐｏｒｔのデストラクタ関数を活動化して、デバイス・ドライバをクローズし、次いで自分自身を終了させる。ＤＤＴｒａｎｓｐｏｒｔクラスの動作は、付録のＤＤＴｒａｎｓｐｏｒｔと題するＣ＋＋のプログラム・コードに基づいている。
【００２２】
ＤＤＩｎｔｅｒｆａｃｅクラスもＤＤＴｒａｎｓｐｏｒｔクラスも、各デバイスやプラットフォームの具体条件に合わせて導出できるように設計されているクラスである。具体的に言うと、これらのクラスは利用できるように導出されなければならない。それが、抽象クラスであることの本質だからである。本発明が従来技術に勝る柔軟性を提供するのは、この導出、つまりサブクラス分割のプロセスである。ＯＯＰコンポーネントと手続き型デバイス・ドライバの間のブリッジを提供するために、これらの抽象クラスをどのようにして特定の実施形態に変換するかを図６〜図８に示す。
【００２３】
図６は、抽象クラスと、手続き型デバイス・ドライバに対するその役割を示すブロック図である。ＤＤＩｎｔｅｒｆａｃｅオブジェクトは、ＯＯサブシステムがＤＤＩｎｔｅｒｆａｃｅオブジェクトと通信するのを許すが、ＯＯサブシステムが、要求の受取り方法や要求を受け取ることのできるドライバを知る必要も、ましてや意識する必要さえもない。具体的に言うと、ＯＯサブシステムは、デバイスの独立性を完全に維持しながら、ＤＤＩｎｔｅｒｆａｃｅオブジェクトが通信できるどんなデバイスをも使用できる。このシステムは、デバイスの独立性を提供するだけでなく、プラットフォームの独立性も提供する。
【００２４】
基底クラスＤＤＩｎｔｅｒｆａｃｅおよびＤＤＴｒａｎｓｐｏｒｔをサブクラスに分割してプラットフォームの独立性を実現するための方法を、図７のブロック図に示す。この方法を使用すると、ＯＯサブシステム全体を他のオペレーティング・システムのプラットフォームに移植することができる。図７の例では、ＯＳ／２  ＤＤＩｎｔｅｒｆａｃｅとＯＳ／２  ＤＤＴｒａｎｓｐｏｒｔを使用するＯＳプラットフォームは、ＯＳサブシステム上で所与の要求を処理するために２つのデバイス・ドライバを必要とする。ＯＳ／２  ＤＤＩｎｔｅｒｆａｃｅが、ＯＯサブシステムとデバイス・ドライバの間のブリッジとして使用されるが、この場合はデータ転送を処理するための第２のデバイス・ドライバが存在する。ＯＳ／２  ＤＤＴｒａｎｓｐｏｒｔは、この第２のデバイス・ドライバとの通信を提供する働きをする。この２つのデバイス・ドライバのＯＳ／２プラットフォームで動作するために、ＯＯサブシステムの変更は不要であった。ＤＤＩｎｔｅｒｆａｃｅクラスとＤＤＴｒａｎｓｐｏｒｔクラスをこのプラットフォーム上で動作するようにサブクラスに分割しただけである。リング３のレベルでは、ＯＳ／２  ＤＤＩｎｔｅｒｆａｃｅおよびＯＳ／２  ＤＤＴｒａｎｓｐｏｒｔ用のＤｏｓＤｅｖＩＯＣＴＬが、デバイス・ドライバのオープンとクローズを行う関数を提供する。図７で点線によってリング３から分離されているリング０のレベルでは、ＯＳ／２  ＤＤＩｎｔｅｒｆａｃｅによってデバイス・ドライバの初期設定、制御、およびロードを行う関数が提供され、ＯＳ／２  ＤＤＴｒａｎｓｐｏｒｔサブクラスによって第２のデバイス・ドライバの読取り／書込み、および開始／停止／休止を行う関数が処理される。第１のデバイス・ドライバは、オーディオ／ビデオ・デバイス・ドライバであり、ＯＳ／２ストリーム・ハンドラ・デバイス・ドライバである第２のデバイス・ドライバと通信する。
【００２５】
図８には、基底クラスＤＤＩｎｔｅｒｆａｃｅおよびＤＤＴｒａｎｓｐｏｒｔをサブクラスに分割して他のプラットフォーム、すなわちマイクロカーネル（μＫ）ベースのＯＳへの移植性を実現するためのブロック図を示す。導出されるクラスは、μＫ  ＤＤＩｎｔｅｒｆａｃｅとμＫ  ＤＤＴｒａｎｓｐｏｒｔであり、マイクロカーネルＯＳのプロトコル具体条件に合わせて構築する。このプラットフォームに移植する際も、ＯＯサブシステムの変更は不要である。この例には、オーディオ／ビデオ・デバイス・ドライバであるデバイス・ドライバしか含まれていない。ユーザ・レベルでは、デバイス・ドライバのオープンとクローズを行う関数がμＫ  ＤＤＩｎｔｅｒｆａｃｅによってＭａｃｈインターフェース・ジェネレータ（ＭＩＧ）の呼出しとして提供され、デバイス・ドライバに対する読取り／書込み呼出しを実行する関数がμＫ  ＤＤＴｒａｎｓｐｏｒｔサブクラスによって提供される。カーネル・レベルでは、デバイス・ドライバを介してデバイスの初期設定と制御を行う関数と、デバイス・ドライバを介してデバイスにマイクロコードをロードする関数が、μＫ  ＤＤＩｎｔｅｒｆａｃｅによって提供される。データ転送メソッド呼出しは、μＫ  ＤＤＩｎｔｅｒｆａｃｅサブクラスからμＫ  ＤＤＴｒａｎｓｐｏｒｔサブクラスに送られる。
【００２６】
本発明を、好ましい実施形態に関して具体的に示し説明したが、当業者なら、本発明の意図および範囲から逸脱することなく、本発明の形態および細部に様々な変更を加えられることを理解されよう。
【００２７】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００２８】
（１）ともに同じデータ処理システムの一部であるオブジェクト指向コンポーネントと手続き型プログラム式デバイス・ドライバの間で通信をブリッジする装置であって、
前記オブジェクト指向コンポーネントを前記デバイス・ドライバに結合するオブジェクト指向インターフェース・デバイスと、
前記オブジェクト指向インターフェース・デバイスに結合され、前記オブジェクト指向コンポーネントを前記デバイス・ドライバから分離する手段と、
前記分離する手段に結合され、デバイス固有の情報をカプセル化する手段とを備える装置。
（２）前記オブジェクト指向コンポーネントから前記デバイス・ドライバに要求またはコマンドを移送する手段をさらに備える上記（１）に記載の装置。
（３）前記オブジェクト指向インターフェース・デバイスがさらに、
前記デバイス・ドライバに対する通信をオープンする手段と、
前記デバイス・ドライバに対する通信をクローズする手段とを備えることを特徴とする上記（１）に記載の装置。
（４）前記オブジェクト指向インターフェース・デバイスがさらに、
前記デバイス・ドライバを介して前記デバイスを初期設定する手段と、
前記デバイス・ドライバを介して前記デバイスを制御する手段とを備えることを特徴とする上記（１）に記載の装置。
（５）前記オブジェクト指向インターフェース・デバイスがさらに、
前記デバイス・ドライバを介して前記オブジェクト指向コンポーネントから前記デバイスにマイクロコードをロードする手段を備えることを特徴とする上記（１）に記載の装置。
（６）前記移送手段がさらに、他のデバイス・ドライバとの通信をオープンする手段を備えることを特徴とする上記（２）に記載の装置。
（７）前記移送手段がさらに、選択された前記オブジェクト指向デバイス・ドライバからデータを移送する手段を備えることを特徴とする上記（２）に記載の装置。
（８）前記移送手段がさらに、前記オブジェクト指向コンポーネントと選択された前記デバイス・ドライバの間のデータ・フローを制御する手段を備えることを特徴とする上記（２）に記載の装置。
（９）１つのオブジェクト指向コンポーネントと複数個の手続き型デバイス・ドライバとを有するデータ処理システムにおいて、前記オブジェクト指向コンポーネントと前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つとの間で通信をブリッジする方法であって、
前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つから前記オブジェクト指向コンポーネントを分離するステップと、
前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つに関連する固有のデバイス・ドライバ情報をカプセル化するステップと、
要求またはコマンドあるいはその両方を前記オブジェクト指向コンポーネントから前記複数個の手続き型デバイス・ドライバのうちの少なくとも１つに移送するステップとを含む方法。
（１０）要求またはコマンドを移送する前記ステップが、
前記デバイス・ドライバのうちの少なくとも１つとの通信をオープンするステップと、
前記デバイス・ドライバを介してデバイスを初期設定するステップとをさらに含むことを特徴とする上記（９）に記載の方法。
（１１）前記デバイス・ドライバを介して前記オブジェクト指向コンポーネントから前記デバイスにマイクロコードをロードするステップをさらに含む上記（１０）に記載の方法。
（１２）前記移送するステップがさらに、他のデバイス・ドライバに対する通信をオープンするステップを含むことを特徴とする上記（１０）に記載の方法。
（１３）前記移送するステップがさらに、選択された前記オブジェクト指向デバイス・ドライバからデータを移送するステップを含むことを特徴とする上記（１０）に記載の方法。
（１４）前記移送するステップがさらに、前記オブジェクト指向コンポーネントと前記複数個のデバイス・ドライバのうちの少なくとも１つとの間の前記データ・フローを制御するステップを含むことを特徴とする上記（１０）に記載の方法。
（１５）ともに同じデータ処理システムの一部であるオブジェクト指向コンポーネントと手続き型デバイス・ドライバの間で通信をブリッジする方法であって、
前記データ処理システムによって操作される前記オブジェクト指向コンポーネントをオブジェクト指向サブシステム内で作成するステップと、
前記オブジェクト指向サブシステム内でインターフェース・オブジェクトを構築するステップと、
前記オブジェクト指向サブシステム内でトランスポート・オブジェクトを構築するステップと、
前記デバイス・ドライバおよび前記オブジェクト指向コンポーネント間の通信を確立するステップとを含む方法。
（１６）前記インターフェース・オブジェクトを構築するステップの後に、
前記オブジェクト指向サブシステムからデータ・タイプを設定するステップと、
前記オブジェクト指向サブシステムからコンポーネントの属性を設定するステップとを含むことを特徴とする上記（１５）に記載の方法。
（１７）前記オブジェクト指向サブシステムにコマンドの実行を要求するステップをさらに含むことを特徴とする上記（１５）に記載の方法。
（１８）前記サブシステムからのデータを前記インターフェース・オブジェクトで受信するステップと、
前記トランスポート・オブジェクトを呼び出して前記デバイスを起動させるステップとをさらに含むことを特徴とする上記（１５）に記載の方法。
（１９）前記トランスポート・オブジェクトから前記デバイス・ドライバにデータ・バッファを送信するステップをさらに含むことを特徴とする上記（１５）に記載の方法。
（２０）前記インターフェース・オブジェクトと前記トランスポート・オブジェクトの両方の状態を更新する上記（１９）に記載の方法。
（２１）前記インターフェース・オブジェクトのデストラクタ関数を呼び込み、前記トランスポート・オブジェクトのデストラクタ関数を呼び込むことによって、
要求された前記オブジェクトの使用を終了するステップをさらに含むことを特徴とする上記（２０）に記載の方法。
【図面の簡単な説明】
【図１】本発明の好ましい実施形態による、本発明を実施するためのハードウェア環境を示す図である。
【図２】オブジェクト指向ソフトウェア・コンポーネントと手続き型デバイス・ドライバの間のブリッジを提供するシステムのブロック図である。
【図３】手続き型デバイス・ドライバとの通信を得るために他のＯＯコンポーネントがインターフェースする、基底クラスとしてのＤＤＩｎｔｅｒｆａｃｅクラスを示す図である。
【図４】本発明によるＤＤＩｎｔｅｒｆａｃｅクラスの動作を示す図である。
【図５】手続き型デバイス・ドライバにアクセスする際の諸ステップを示すブロック図である。
【図６】抽象クラスと、手続き型デバイス・ドライバに対するその役割を示すブロック図である。
【図７】プラットフォームからの独立性を実現するためにＤＤＩｎｔｅｒｆａｃｅとＤＤＴｒａｎｓｐｏｒｔという基底クラスがどのようにサブクラス分けされるかを示すブロック図である。
【図８】他のプラットフォームに対する移植性を実現するためにＤＤＩｎｔｅｒｆａｃｅとＤＤＴｒａｎｓｐｏｒｔという基底クラスがどのようにサブクラス分けされるかを示すブロック図である。
【符号の説明】
５０  オブジェクト指向ソフトウェア・コンポーネント
５１  ＯＯ本来のデバイス・インターフェース
５２  手続き型デバイス・ドライバ
0003618892.tif 000002
0003618892.tif 000003
0003618892.tif 000004
0003618892.tif 000005
0003618892.tif 000006
0003618892.tif 000007
0003618892.tif 000008
0003618892.tif 000009
【図１】
0003618892.tif 000010
【図２】
0003618892.tif 000011
【図３】
0003618892.tif 000012
【図４】
0003618892.tif 000013
【図５】
0003618892.tif 000014
【図６】
0003618892.tif 000015
【図７】
0003618892.tif 000016
【図８】
0003618892.tif 000017