(57)【要約】【課題】アプリケーションプログラムとデバイスドライバが異なるメモリ空間に置かれるOS上で、IDL（インターフェース定義言語）によりアプリケーションプログラムからダイナミックリンクライブラリの機能呼び出しを行う方法によりデバイス制御を可能とする手段を提供することを第一の課題とし、デバイスドライバから逆に機能呼び出しを可能とする手段を提供することを第二の課題とする。【解決手段】本発明は、IDLによりデバイス制御のインターフェースを定義し、アプリケーションプログラムとデバイスドライバの間に機能呼び出しを中継するためのプログラムを置き、アプリケーションプログラムからデバイスドライバに対する機能呼び出しと、逆方向の機能呼び出しを可能とし、前記中継プログラムは特殊なIDLコンパイラにより自動生成可能とすることにより達成される。【選択図】図２
2005108082.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムとカーネルのメモリ空間が異なり、入出力装置を制御するデバイスドライバプログラムがカーネルのメモリ空間に取り込まれて実装されるオペレーティングシステムを有し、
インターフェース定義言語によって定義されたインターフェース情報に基づいて生成される部分プログラムにより、アプリケーションプログラムからダイナミックリンクライブラリまたは、他のアプリケーションプログラムの機能呼び出しを可能とする機構を備えたコンピュータシステムにおけるデバイスドライバのインターフェース方法において、
インターフェース定義言語に基づき入出力装置を制御するデバイスドライバのインターフェース情報を定義する定義工程と、
定義工程で定義されたインターフェース情報をインターフェース定義言語コンパイラによりコンパイルするインターフェース定義言語コンパイル工程と、
を有し、
インターフェース定義言語コンパイル工程は、
入出力装置を制御するシステムコールに基づいて機能呼び出しを中継するためのアプリケーション側プログラム、およびカーネル側プログラムを生成し、アプリケーション側プログラムを生成するにあたっては、アプリケーションプログラムからダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出しを可能とする機構に組み入れて使用可能とし、
アプリケーション側プログラム生成工程と、
カーネル側プログラム生成工程と、
を含み、
アプリケーション側プログラムは、定義工程により定義されたインターフェース情報に基づき入出力装置のデバイスドライバの機能呼び出しを可能とすることを特徴とするインターフェース定義言語に基づくデバイスドライバのインターフェース方法。
【請求項２】
請求項１に記載のデバイスドライバのインターフェース方法において、
入出力装置制御システムコールに基づいて機能呼び出しを中継するカーネル側プログラムは、入出力装置を制御するデバイスドライバプログラムとは異なるデバイスドライバとして実装することを特徴とするインターフェース定義言語に基づくデバイスドライバのインターフェース方法。
【請求項３】
アプリケーションプログラムとカーネルのメモリ空間が異なり、入出力装置を制御するデバイスドライバプログラムがカーネルのメモリ空間に取り込まれて実装されるオペレーティングシステムを有し、
インターフェース定義言語によって定義されたインターフェース情報に基づいて生成される部分プログラムにより、アプリケーションプログラムからダイナミックリンクライブラリまたは、他のアプリケーションプログラムの機能呼び出しを可能とする機構を備えたコンピュータシステムにおけるデバイスドライバのインターフェース方法において、
インターフェース定義言語に基づき定義されたダイナミックリンクライブラリまたはアプリケーションプログラムのインターフェース情報をコンパイルするコンパイル工程を有し、
インターフェース定義言語コンパイル工程は、
入出力装置を制御するシステムコールに基づいて機能呼び出しを中継するためのアプリケーション側プログラム、およびカーネル側プログラムを生成し、アプリケーション側プログラムを生成するにあたっては、アプリケーションプログラムからダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出しを可能とする機構を組み入れて使用可能とし、
アプリケーション側プログラム生成工程と、
カーネル側プログラム生成工程と、
を含み、
デバイスドライバから前記ダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能を呼び出し可能とすることを特徴とするインターフェース定義言語に基づくデバイスドライバのインターフェース方法。
【請求項４】
請求項３に記載のデバイスドライバのインターフェース方法において、
インターフェース定義言語コンパイラが生成する入出力装置制御システムコールに基づいて機能呼び出しを中継するカーネル側プログラムは、入出力装置を制御するデバイスドライバプログラムとは異なるデバイスドライバとして実装することを特徴とするインターフェース定義言語に基づくデバイスドライバのインターフェース方法。
【請求項５】
請求項３に記載のデバイスドライバのインターフェース方法において、
呼び出され側プログラムを独立実行するプログラムを用意し、独立実行されるプログラムは、カーネル側プログラムの状態を監視し、デバイスドライバからカーネル側プログラムを介してダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出し要求を受け付けることを特徴とするインターフェース定義言語に基づくデバイスドライバのインターフェース方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アプリケーションプログラムとカーネルのメモリ空間が異なるようになされ、入出力装置を制御するデバイスドライバプログラムが前記カーネルのメモリ空間に取りこまれて実装されるオペレーティングシステムを有し、インターフェース定義言語（以下IDLと記す）によって定義されたインターフェースに基づき、前記アプリケーションプログラムからダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出しを可能とする機構を備えたコンピュータシステムにおいて、前記機構をアプリケーションプログラムとデバイスドライバプログラム間に拡張するものであり、アプリケーションプログラムからデバイスドライバの提供する機能を呼び出したり、反対にデバイスドライバプログラムからアプリケーションプログラムまたはダイナミックリンクライブラリの提供する機能を呼び出すことを可能とする。
【背景技術】
【０００２】
従来、アプリケーションプログラムとカーネルのメモリ空間が異なるようになされたOS（Operating System：オペレーティングシステム）で、デバイスをアプリケーションプログラムから制御するには、UNIX（登録商標）系のシステムであればioctlシステムコールを使用し、またWindowsNT（登録商標）系のOSであればDeviceIoControlシステムコールを使用して操作する必要がある。
【０００３】
例えばDeviceIoControlシステムコールでは、第１引数にファイルハンドル、第２引数にIO制御コード、第３引数に入力バッファへのポインタ、第４引数に入力バッファのサイズ、第５引数に出力バッファへのポインタ、第６引数に出力バッファのサイズ、第７引数に出力されたバイト数を返す整数へのポインタ、第８引数にオーバーラップI/O用の構造体ポインタを指定する。
【０００４】
ここで第３引数、第５引数に与えるべきデータはLPVOID型とプロトタイプ宣言されているが、実際には第２引数のIO制御コードにあわせて適切な型のポインタを与える必要がある。しかし、このような引数の型が適切であるかどうかの静的検査は行うことができないことから、誤ったデータ型が指定されていてもコンパイル時に誤りが検出されることはない。また、実行時においても、データ型を検査する手段はないので、必ずしも誤りが検出されるとは限らずソフトウェア信頼性の向上の妨げとなる。
【０００５】
図１５は、従来例における制御プログラムを説明するためのプログラム例を示している。DeviceIoControlシステムコールを使用して、入出力装置を制御するプログラムの例を図１５を用いて説明する。図１５の例ではサーボ制御デバイスに対してSetSpeed（速度設定）するための引数を整えてからDeviceIoControlシステムコールを呼び出す。
【０００６】
図１６は、従来例におけるデバイスドライバプログラムを説明するためのプログラム例を示している。図1６に示すプログラムは、サーボ制御デバイスに対してDeviceIoControlシステムコールが呼び出された時に呼び出されるデバイスドライバプログラムである。このプログラムではIOCTLコードの種類によって場合わけを行い、IOCTL_SVC_SET_SPEEDの時には対応する引数を取り出して、SetSpeed関数を呼び出している。
【０００７】
以上のようにサーボ制御デバイスに対してSetSpeedを行うために、呼び出し側では、呼び出しのためにDeviceIoControlシステムコールの引数を整える手順が煩雑であるにもかかわらず引数の静的検査がなく、一方呼び出されるデバイスドライバプログラムでは、IOCTLコードにあわせて処理を選択すること、処理にあわせて引数を取り出したり、出力値を設定したりする必要がありプログラムが煩雑である。このようなプログラムは、機能および各機能ごとの入力、出力が決まれば一意に作成できるものであるにもかかわらず、必要都度プログラミングを行う必要があった。
【０００８】
一方、このようなOSにおいてデバイスドライバからアプリケーションプログラムの機能を呼び出すための機構は整えられていない。例えばデバイスドライバプログラム処理において、履歴情報の収集のためにデータベースシステムに情報を記憶したいとしても、デバイスドライバ側から呼び出すことのできる汎用的なインターフェースは備えられておらず、その実現は容易ではなかった。つまり、アプリケーション側で実現されるデータベースやグラフィカルユーザインターフェースなどの機能をデバイスドライバ側から直接的に利用するための機能は従来提供されてこなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は上述のような問題に鑑みなされたもので、アプリケーションプログラムとデバイスドライバが異なるメモリ空間に置かれるOSを使用するにおいて、IDLによりデバイス制御のインターフェースを定義し、アプリケーションプログラムからダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出しを可能とする機構と同じ方法によりデバイス制御を可能とする手段を提供することを第一の課題とする。
【００１０】
反対に、デバイスドライバからアプリケーションプログラムまたはダイナミックリンクライブラリに対する機能呼び出し可能とする手段を提供することを第二の課題とする。
【課題を解決するための手段】
【００１１】
既存のアプリケーションプログラムからダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出しを可能とする機構には、例えばマイクロソフト社のCOM(Component Object Model)がある。元来COMはコンポーネントオブジェクトを扱うものであるが、コンポーネントオブジェクトを操作するために機能呼び出しを行うための機構を備えている。COMではインターフェース定義言語（IDL）によりインターフェースを定義し、アプリケーションプログラムから定義されたインターフェースに基づいて機能の呼び出しが可能となっており、実装とインターフェースを分離することができ、組合わせの自由度やソフトウェアの保守性などが大幅に向上する。
【００１２】
これまでもデバイスを制御するプログラムでは、アプリケーションプログラムとデバイスドライバプログラムのメモリ空間が異なるがゆえに実装とインターフェースの分離は行われてきたが、上述の問題点を有している。
【００１３】
本発明では、IDLによりデバイス制御のインターフェースを定義し、アプリケーションプログラムとデバイスドライバの間に機能呼び出しを中継するためのプログラムを置き、アプリケーションプログラムからデバイスドライバに対する機能呼び出し、反対にデバイスドライバからアプリケーションプログラムまたはダイナミックリンクライブラリに対する機能呼び出し可能とし、前記中継プログラムの一部を前記インターフェース定義に基づき特殊なIDLコンパイラにより自動生成可能とすることにより達成される。
【００１４】
ここで特殊なIDLコンパイラとはCRADコンパイラ（Component object invoking Repeater between Application and Device-driver）の略で、アプリケーションプログラムとデバイスドライバプログラム間のコンポーネントオブジェクトに対する呼び出しの中継器を意味する。
【発明の効果】
【００１５】
本発明のデバイスドライバのインターフェース方法によれば、デバイスドライバプログラムの機能呼び出しをインターフェース定義に基づいて行うことができるので、実装とインターフェースを分離することができ、組合せの自由度が向上する。
【００１６】
またアプリケーション側からデバイスドライバ側、またはデバイスドライバ側からアプリケーション側への機能呼び出しを中継する、呼び出し中継プロキシーおよび呼び出し中継スタブはインターフェース定義に基づきCRADコンパイラにより自動生成することができるから、ソフトウェアの保守性などが大幅に向上する。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態（以下実施形態という）を、図面に従って説明する。
【００１８】
図１は、本発明を実施することのできる装置の例を示すブロック図である。中央処理装置１は、システムバス８を介してメモリ２、ディスクコントローラ３、ＤＡコンバータ５と接続されており、さらにＤＡコンバーター５はサーボユニット６を介してサーボモータ７に接続されている。ここで図示しないが中央処理装置１はメモリ管理ユニットを内蔵し複数のメモリ空間をサポートしており、ハードディスク４に格納されメモリ２にロードされて中央処理装置１により実行されるオペレーティングシステムは、やはりハードディスク４に格納されメモリ２にロードされ実行されるアプリケーションプログラムと、オペレーティングシステムのカーネルメモリ空間に取り込まれて実装されるデバイスドライバプログラムとを異なるメモリ空間に配置して管理を行う。
【００１９】
ＤＡコンバータ５は、アプリケーションプログラムとは異なるメモリ空間に配置されているため、アプリケーションプログラムの中から直接ＤＡコンバーター５をアクセスして操作することはできず、デバイスドライバプログラムを介して操作せねばならない。なお本実施例では、オペレーティングシステムとしてWindows（登録商標）を使用するものとして、また既存のアプリケーションプログラムからダイナミックリンクライブラリまたは他のアプリケーションプログラムの機能呼び出しを可能とする機構としてCOMを使用するものとして説明する。
【００２０】
図２は、本発明に基づく呼び出し機構のプログラム構造をあらわすブロック図である。
プログラムの構造は、アプリケーション側のプログラム群とデバイスドライバを含むカーネル側のプログラム群で構成されている。
【００２１】
COMクライアント１１は、Windows（登録商標）オペレーティングシステムに備え付けられたソフトウェアコンポーネント機構であるCOMのクライアントとなるソフトウェアで、COMインプロセスサーバー１２は呼び出し中継プロキシー（Proxy）１３を内包する。COMインプロセスサーバー１２は、COMクライアントからの要求に基づいて動作するもので、ダイナミックリンクライブラリとして実装される。
【００２２】
図５は、サーボコントローラのインターフェースの定義例を示すプログラムリストの１例である。ここで、COMインプロセスサーバー１２は図５に示すようなIDLに基づいてインターフェースが定義され、COMクライアント１１はこのインターフェース定義に基づいてCOMインプロセスサーバー１２に対し、機能呼び出しをすることができる。
【００２３】
なお、図５はCOMのIDLに基づく完全なインターフェース定義ではなく、インターフェース定義の本質部分を抜き出したものであるが、uuid(Universally Unique Identifiers)としてインターフェースの種類を識別するための１６進数が記述され、サーボを制御するための関数setSpeedをはじめとして６個の関数が定義されている。
【００２４】
図６は、setSpeed関数の中継プロキシーの動作を説明するためのフローチャートであり、呼び出し中継プロキシー１３の動作を図６のフローチャートを用いて説明する。図６は図５に示したインターフェース定義のうちsetSpeedの呼び出しの中継を行う処理を示しており、COMクライアント１１によりsetSpeed関数が呼び出されると、COMインプロセスサーバー１２内の呼び出し中継プロキシー１３に配置されたsetSpeed関数が呼び出される（ステップＳ１０）。以下に、処理の流れを説明する。
【００２５】
はじめに呼び出しパケットの準備を行う（ステップＳ１１）。これは、パケットのメモリ領域を確保し必要な初期化を行う。次に、呼び出し番号を設定する（ステップＳ１２）。この場合、インターフェース定義における先頭の関数であり呼び出し番号として１を呼び出しパケットに設定する。
【００２６】
次にsetSpeed関数のSpeed引数の実引数値をパケットに設定する（ステップＳ１３）。以上で、呼び出しパケットが整い、呼び出しパケットを送出する（ステップＳ１４）。呼び出しパケットの送出は、DeviceIOControlシステムコール１４によりアプリケーション側のメモリ空間からデバイスドライバ側のメモリ空間へ伝えられる。
【００２７】
呼び出しパケットの送出が終わると、あとの動作は呼び出し中継ドライバー１５以下に委ねられ、呼び出し中継プロキシー１３は、呼び出し中継ドライバー１５から出力パケットが届くまで待ち状態に入る（ステップＳ１５）。出力パケットが届くと、出力や戻り値を適切に設定した後、setSpeed関数を終了する。以上の動作についてはsetSpeed関数について説明したが、図５のインターフェースの定義例を示す他の関数についても同様の動作を行う。
【００２８】
図８は、呼び出し中継ドライバーの動作を説明するためのフローチャートであり、呼び出し中継ドライバー１５の動作について図２、図７のフローチャートを用いて説明する。図２で示している呼び出し中継プロキシー１３の動作ステップＳ１４（図６）にてパケットが送り出されて、出力パケット待ち状態（ステップＳ１５）に入ると、図８で示される呼び出し中継ドライバーが呼び出される（ステップＳ３０）。はじめに送り出されたパケットを取り出し（ステップＳ３１）、続いて呼び出しパケットから呼び出し番号を取り出す（ステップＳ３２）。呼び出し番号に従ってスタブ関数を呼び出す（ステップＳ３３）。この際引数として呼び出しパケットを渡す。呼び出し中継スタブ１６の動作が終わると呼び出し中継スタブの返した出力パケットを呼び出し中継プロキシーに対し送出する（ステップＳ３４）。
【００２９】
図２で示される呼び出し中継スタブ１６は、呼び出し中継ドライバー１５の動作ステップＳ３３（図８）により呼び出される（ステップＳ２０）。はじめに呼び出し中継ドライバー１５から引数として渡された呼び出しパケットからCOMクライアント１１が渡したもともとの引数speedを取り出す（ステップＳ２１）。そして呼び出されプログラム１７に位置する本来のsetSpeedプログラムを呼び出す（ステップＳ２２）。これによりsetSpeedの動作が行われる。setSpeedの動作が終わると、setSpeedの戻り値を返すための器である出力パケットの準備を行う(ステップＳ２３)。戻り値を出力パケットに設定する（ステップＳ２４）。以上のように中継スタブ１６の動作が行われる。
【００３０】
setSpeed関数について説明したが、図５のインターフェースの定義例を示すプログラムリストの１例で定義した他の関数についても同じ動作を行う。setSpeedには出力がなかったが、関数に出力がある場合には図７に示されるステップＳ２４にて関数の出力も出力パケットに設定する。
【００３１】
ここで第１の実施形態における呼び出しパケットの構造を図１０に示し、第１の実施形態における出力パケットの構造を図１１に示す。呼び出しパケットには図６に示されるステップＳ１２にて設定される呼び出し番号、ステップＳ１３にて設定される引数がある。なお、図１０では引数は１〜３まで存在するように書かれているが、実際の個数に合わせて変化する。図１１の出力パケットにはステップＳ２４にて設定される戻り値および出力が存在するが、やはり戻り値や出力の個数にあわせて変化するのは言うまでもない。
【００３２】
以上により、COMクライアント１１（Windows（登録商標）アプリケーション）から発せられた呼び出しsetSpeedが、COMインプロセスサーバー１２の内包する呼び出し中継プロキシー１３、呼び出し中継ドライバー１５および呼び出し中継スタブ１６を経由して呼び出されプログラム１７に存在するsetSpeedが呼び出され、戻り値が返されることを示した。なお、呼び出されプログラム１７と呼び出し中継ドライバー１５とは異なるデバイスドライバとして実装することができる。そうすることで、インターフェースの変更と実装の変更とを区別してソフトウェアを保守することができる。
【００３３】
一般的に、COMインプロセスサーバー１２および内包する呼び出し中継プロキシー１３、および呼び出し中継スタブ１６は、図５のインターフェースの定義例を示すプログラムリストの１例で示したインターフェース定義の内容が変化するごとに、新しく作成しなくてはならない。しかし、この作業は機械的に行うことができ、本実施形態のCRADコンパイラにより自動生成できる。
【００３４】
図４はCRADコンパイラの動作を説明するフローチャートである。CRADコンパイラは、起動されるとはじめに指定されたIDLファイルを読込む（ステップＳ１）、これに基づきプロキシープログラムを生成する（ステップＳ２）。プロキシープログラムをコンパイルおよびリンクする（ステップＳ３）。以上のステップによりCOMインプロセスサーバーおよび内包する呼び出し中継プロキシーが生成される。なお、CRADコンパイラがインターフェース定義からプロキシープログラムを生成する手続きは、関数が何番目に定義されたものであるのか（呼び出し番号）と、引数の個数および型が分かれば図６のフローチャートに示す処理を生成することができ、機械的に行うことができる。引き続いてインターフェース定義に基づいてスタブプログラムを生成し（ステップＳ４）、スタブプログラムをコンパイルおよびリンクして（ステップＳ５）、呼び出し中継スタブ１６を生成することができる。
【００３５】
以上のステップＳ２およびステップＳ４により、機能呼出しを中継するためのアプリケーション側プログラムおよびカーネル側プログラムが生成される。なおステップＳ３およびＳ５は必ずしもCRADコンパイラにより行われる必要はなく、アプリケーションプログラムやデバイスドライバプログラムと同時にコンパイルリンクを行ってもよい。
【００３６】
図７は、setSpeed関数の中継スタブの動作を説明するためのフローチャートであり、インターフェース定義から呼び出しスタブプログラムを生成する手続きは、戻り値の型や出力の個数および型が分かれば図７のフローチャートに示す処理を生成することができ、機械的に行うことができる。
【００３７】
なお、以上のCRADコンパイラの説明では、呼び出し中継スタブのプログラムとして図７のフローチャートの処理を出力するように説明したが、データとして引数の個数や型、戻り値などの情報のみを出力するようにし、呼び出し中継ドライバーにおいてこれらのデータに基づき呼び出されプログラムを呼び出すようにしてもよい。
【００３８】
以下に、第２の実施形態について説明する。図３は、デバイスドライバ側からWindows（登録商標）アプリケーション側の機能呼び出しを行うためのプログラム構造を示している。ここまでの説明では図２においてWindows（登録商標）アプリケーションであるCOMクライアント１１からデバイスドライバ側の機能を呼び出すものであったが、反対にデバイスドライバ側からWindows（登録商標）アプリケーション側に存在するプログラムの機能を呼び出す場合について、図３に示すブロック図をもとに説明する。
【００３９】
図１２は、メッセージボックスのインターフェースの定義例を示すプログラムリストの１例であり、図３に示すCOMサーバー２６は図１２のIDLにより定義されたインターフェースの機能を提供するものとする。
【００４０】
以下、図１２にあるSendMessage関数が呼び出された場合を例に、呼び出し中継プロキシー２２の動作を図１３のフローチャートを用いて説明する。また、呼び出し中継デーモン２４の動作について図９のフローチャートを用いて説明する。
【００４１】
図１３に示す呼び出し中継プロキシーＳ５０は呼び出しプログラム２１から関数SendMessageが呼び出されたときに開始される。始めに呼び出しパケットを準備する（ステップＳ５１）。これは、パケットのメモリ領域を確保し必要な初期化を行う。次に呼び出し番号を設定する（ステップＳ５２）。この場合、インターフェース定義における先頭の関数であり、呼び出し番号として１を呼び出しパケットに設定する。
【００４２】
次にSendMessage関数のmessage引数の実引数値を呼び出しパケットに設定する（ステップＳ５３）。以上で、呼び出しパケットが整い、呼び出しパケットを送出する（ステップＳ５４）。ここで呼び出しパケットの送出は、実際には、呼び出し中継プロキシー２２内のメモリ領域へのコピーが行われるだけで、呼び出し中継デーモン２４に伝えられるものではない。なぜならDeviceIoControlシステムコール２３はアプリケーション側からカーネル側に対する呼び出しであり、呼び出し中継プロキシー２２が呼び出し中継デーモン２４の機能を直接的に呼び出すことはできないためである。呼び出し中継デーモン２４の受信動作については後で説明する。
【００４３】
呼び出しパケットの送出が終わるとあとは呼び出し中継ドライバー２４以下に委ねられ、呼び出し中継プロキシー２２は、呼び出し中継ドライバー２４から出力パケットが届くまで待ち状態に入る（ステップＳ５５）。出力パケットが、出力や戻り値を適切に設定した後、SendMessage関数を終了する。以上、呼び出し中継プロキシー２２および呼び出し中継デーモン２４の動作についてSendMessage関数を例に説明したが、図１２にあるRecieveMessage関数についても同様の動作を行う。
【００４４】
図９に示す呼び出し中継デーモンＳ４０は、呼び出し中継ドライバーＳ３０とは異なり、独立実行するプログラムとして予め起動されパケットの到着まで待機する（ステップＳ４１）。実際の待機時の動作としてはDeviceIoControlシステムコール２３により呼び出し中継プロキシー２２が呼び出しパケットの送出Ｓ５４（図１３）を行うのを監視する。これはデバイスドライバ側のコンテキストを引き継ぐ形でアプリケーション側のプログラムを動作させることができないためで、アプリケーション側とデバイスドライバ側のメモリ空間が分けて管理されるオペレーティングシステムにおいては一般的な制約である。
【００４５】
図９に示す呼び出しパケットの到着を検出すると、呼び出しパケットを取り出し（ステップＳ４２）、呼び出しパケットの中から呼び出し番号を取り出す（ステップＳ４３）。呼び出し番号に従ってスタブ関数を呼び出す（ステップＳ４４）。この例の場合、スタブ関数が呼び出されると図１４に示すステップＳ６０から動作が開始され、呼び出しパケットから引数を取り出し（ステップＳ６１）、SendMessageの実処理を呼び出す（ステップＳ６２）。SendMessageの実処理が完了すると、出力パケットを準備し（ステップＳ６３）、出力パケットに出力および戻り値を設定する（ステップＳ６４）。以上で、SendMessageのスタブ関数の動作は完了し、図９に示す呼び出し中継デーモンの動作をステップＳ４５から再開して、出力パケットを送出する（ステップＳ４５）。以上の動作が終了すると再びステップＳ４１へ戻り呼び出しパケットを待つ。
【００４６】
なお、第２の実施形態における呼び出しパケットおよび出力パケットは、第１の実施形態におけるそれら（図１０，図１１）と同様である。以上により、呼び出しプログラム２１から発せられた呼び出しSendMessageが、呼び出し中継プロキシー２２、呼び出し中継デーモン２４の内包する呼び出し中継スタブ２５を経由してＣＯＭサーバー２６に存在するSendMessageが呼び出され、戻り値が返されることを示した。なお、呼び出しプログラム２１と呼び出し中継プロキシー２２とは異なるデバイスドライバとして実装することができる。そうすることで、インターフェースの変更と実装の変更とを区別してソフトウェアを保守することができる。
【００４７】
図１２は、メッセージボックスのインターフェースの定義例を示すプログラムリストの１例である。このように、図３に示す呼び出し中継プロキシー２２および呼び出し中継スタブ２５は図１２に示したインターフェース定義の内容が変化するごとに、新しく作成しなくてはならない。この作業は機械的に行うことができ、CRADコンパイラにより自動生成可能であり、この手順は、図４を用いて説明したCRADコンパイラの動作と同じである。
【００４８】
ただし、この場合はプロキシープログラムがカーネル側で動作し、スタブプログラムがアプリケーション側で動作するので、使用できるシステムコールの相違などから、出力を変更する必要がある。
【００４９】
以上により、ＤＡコンバーター５を介して接続されるサーボユニット６により制御されるサーボモータ７を制御するデバイスドライバを例に取り、そのインターフェースを図５に示して説明したが、本発明はサーボモータに限らず種々のデバイスドライバに適用することが可能で、図５や図１２に示したインターフェース定義のほかにも種々のインターフェース定義に適用することができる。また、本実施例ではマイクロソフト社のWindows（登録商標）およびCOMに基づいて説明したが、UNIX（登録商標）などのオペレーティングシステムや、XPCOMなど他のIDLをベースにするコンポーネントオブジェクトを扱うためのフレームワークを利用してもよく、これらに限定されるものではない。
【００５０】
また、入出力装置を制御するシステムコールとしてDeviceIOControlやioctlを例にしたが、必ずしもこれらに限定されるものではなく、例えば、read、writeシステムコールにより呼び出しパケット、出力パケットを転送するようにしてもよい。
【００５１】
なお、本発明においては、デバイスドライバプログラムによってカーネル側メモリ空間に取り込まれるプログラムもデバイスドライバプログラムとみなされる。
【図面の簡単な説明】
【００５２】
【図１】本発明を実施することのできる装置のブロック図である。
【図２】Windows（登録商標）アプリケーション側からデバイスドライバ側の機能呼び出しを行うためのプログラム構造を示す図である。
【図３】デバイスドライバ側からWindows（登録商標）アプリケーション側の機能呼び出しを行うためのプログラム構造を示す図である。
【図４】CRADコンパイラの動作を説明するためのフローチャートである。
【図５】サーボコントローラのインターフェースの定義例を示すプログラムリストの１例を示す図である。
【図６】setSpeed関数の中継プロキシーの動作を説明するためのフローチャートである。
【図７】setSpeed関数の中継スタブの動作を説明するためのフローチャートである。
【図８】呼び出し中継ドライバの動作を説明するためのフローチャートである。
【図９】呼び出し中継デーモンの動作を説明するためのフローチャートである。
【図１０】第１の実施形態における呼び出しパケットの構造を説明するための図である。
【図１１】第１の実施形態における出力パケットの構造を説明するための図である。
【図１２】メッセージボックスのインターフェースの定義例を示すプログラムリストの１例を示す図である。
【図１３】SendMessage関数の中継プロキシーの動作を説明するためのフローチャートである。
【図１４】SendMessage関数の中継スタブの動作を説明するためのフローチャートである。
【図１５】従来例における制御プログラムを説明するためのプログラム例を示す図である。
【図１６】従来例におけるデバイスドライバプログラムを説明するためのプログラム例を示す図である。
【符号の説明】
【００５３】
１  中央処理装置、２  メモリ、３  ディスクコントローラ、４  ハードディスク、５  ＤＡコンバータ、６  サーボユニット、７  サーボモータ、８  システムバス、１１  COMクライアント、１２  COMインプロセスサーバー、１３  呼び出し中継プロキシー、１４  DeviceIOControlシステムコール、１５  呼び出し中継ドライバー、１６  呼び出し中継スタブ、１７  呼び出されプログラム、２１  呼び出しプログラム、２２  呼び出し中継プロキシー、２３  DeviceIOControlシステムコール、２４  呼び出し中継デーモン、２５  呼び出し中継スタブ、２６  COMサーバー。
【図１】
2005108082.tif 000003
【図２】
2005108082.tif 000004
【図３】
2005108082.tif 000005
【図４】
2005108082.tif 000006
【図５】
2005108082.tif 000007
【図６】
2005108082.tif 000008
【図７】
2005108082.tif 000009
【図８】
2005108082.tif 000010
【図９】
2005108082.tif 000011
【図１０】
2005108082.tif 000012
【図１１】
2005108082.tif 000013
【図１２】
2005108082.tif 000014
【図１３】
2005108082.tif 000015
【図１４】
2005108082.tif 000016
【図１５】
2005108082.tif 000017
【図１６】
2005108082.tif 000018