JP2004318524A - デバイスドライバ制御モジュール、デバイスドライバ制御方法、デバイスドライバ制御プログラムおよびデバイスドライバ - Google Patents

Abstract

【課題】ＤＤＩ関数の引数に設定された引数領域がメモリ領域上の確保可能であるか否かを判別することができなかった。
【解決手段】実行モジュール１０４ａがＤＤＩ関数１０３を入力した場合、ラッパーモジュール１０４ｂにてそのＤＤＩ関数１０３に設定してある引数領域が必要とされるメモリ領域を確保しているか否かを判別し、確保していない場合に、エラー処理を行い、ＤＤＩ関数１０３の処理を停止させることによって、この確保不可能なメモリ領域に対してアクセスするプリンタドライバ１０４の動作によってホストコンピュータ１０がハングアップしてしまうことを防止する。また、かかる状況をメモリオーバーラン情報４６に格納することによって、アプリケーション１００側に引数設定におけるバグがあることを判別することが可能になる。
【選択図】 図３

Description

【０００１】
【発明の属する技術分野】
本発明は、デバイスドライバ制御モジュール、デバイスドライバ制御方法、デバイスドライバ制御プログラムおよびデバイスドライバに関し、特に、ＤＤＩ関数に基づいた処理を実行するデバイスドライバの実行状態を制御するデバイスドライバ制御モジュール、デバイスドライバ制御方法、デバイスドライバ制御プログラムおよびデバイスドライバに関する。
【０００２】
従来、この種の装置としては、コンピュータのハードウェアやソフトウェアをデバッグするものが多数知られている（例えば、特許文献１〜４を参照。）。
【０００３】
【特許文献１】
特開平２−１０５２３４号公報
【特許文献２】
特開平５−１５１０２１号公報
【特許文献３】
特開昭６４−４４５５２号公報
【特許文献４】
特開平３−２４８２７５号公報
【０００４】
【発明が解決しようとする課題】
上述した従来の装置においては、ＤＤＩ関数の引数に設定された引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かを判別することができなかった。この引数領域はアプリケーションにて設定されるものであり、アプリケーションが誤ってメモリ領域上に確保できない引数領域を設定してしまった場合、デバイスドライバはこの引数領域に基づいてＤＤＩ関数に基づいた処理を実行するため、処理機能が異常停止してしまうという課題があった。
【０００５】
本発明は、上記課題にかんがみてなされたもので、アプリケーションが設定した引数領域が必要とされるメモリ領域を確保している場合にＤＤＩ関数に基づいた処理を実行させることが可能なデバイスドライバ制御モジュール、デバイスドライバ制御方法、デバイスドライバ制御プログラムおよびデバイスドライバの提供を目的とする。
【０００６】
【課題を解決するための手段】
上記目的を達成するため、所定のデバイスを駆動する際に起動されるデバイスドライバを制御するデバイスドライバ制御モジュールであって、アプリケーションが出力する制御アプリケーションインターフェース（ＡＰＩ）に基づいて呼び出されたデバイスドライバインターフェース（ＤＤＩ）関数を検知するＤＤＩ関数検知手段と、上記検知されたＤＤＩ関数の引数に設定された引数領域を取得する引数領域取得手段と、上記取得した引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かを判別するメモリ領域判別手段と、上記メモリ領域を確保していると判別された場合に上記引数を取得し上記ＤＤＩ関数に基づいた処理を実行する上記デバイスドライバに同引数を出力して同ＤＤＩ関数に基づいた処理を実行させるＤＤＩ関数処理実行制御手段とを具備することを要旨とする。 かかる構成のもと、ＤＤＩ関数検知手段では、アプリケーションが出力しデバイスドライバに対して入力させられる制御アプリケーションインターフェース（ＡＰＩ）に基づいて呼び出されたデバイスドライバインターフェース（ＤＤＩ）関数を検知する。ここで、引数領域取得手段は、検知されたＤＤＩ関数の引数に設定された引数領域を取得し、メモリ領域判別手段は、取得された引数領域が必要とされるデータサイズ分のメモリ領域を確しているか否かを判別する。そして、ＤＤＩ関数処理実行制御手段は、メモリ領域を確保していると判別された場合に上記引数を取得し上記ＤＤＩ関数に基づいた処理を実行する上記デバイスドライバに同引数を出力して同ＤＤＩ関数に基づいた処理を実行させる。これにより、アプリケーションが引数の設定を誤った場合にその状況を把握することが可能となり、不具合についてアプリケーションとデバイスドライバとの切り分けを行うことが可能になる。
【０００７】
メモリ領域に引数領域を確保できない場合、この確保できない引数領域に基づいてＤＤＩ関数に基づいた処理を実行すると、デバイスドライバの組み込まれたコンピュータがハングアップしてしまう可能性がある。そこで、ＤＤＩ関数処理実行制御手段は、メモリ領域判別手段にて引数領域をメモリ領域上にて確保していないと判別された場合にデバイスドライバにおけるＤＤＩ関数に基づいた処理の実行を停止させる。これにより、上述したハングアップによる不具合を防止することが可能になる。ＤＤＩ関数に基づいた処理を停止させた場合、どのような理由で停止されたか否かを認識できると好適である。そこで、ＤＤＩ関数処理実行制御手段は、停止状態通知手段にてＤＤＩ関数に基づいた処理の実行を停止させた場合にその旨を通知する。確保していない場合にこの状況をリアルタイムに認識することができると好適である。メモリ領域判別手段は、取得した引数領域をメモリ領域上にて確保していないと判別した場合に、その旨を認識可能な情報を所定の外部モジュールに出力する。これにより、外部モジュールを利用して引数領域をメモリ領域にて確保することが可能か否かを認識することが可能になる。
【０００８】
上述した判別処理はオーバーヘッドとなり、デバイスドライバにおける処理速度のスループットが落ちる。ここで、判別する処理を行うか否かの選択を可能とし、状況に応じて適宜切り換えることができると好適である。そこで、第１モードをメモリ領域判別手段にて引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かの判別を行わせるモードとし、第２モードを同判別を行わせないモードとした場合、モード設定手段にて何れか一方のモードを設定する。そして、ＤＤＩ関数処理実行制御手段は、同モード設定手段にて第２モードが設定された場合に、ＤＤＩ関数検知手段にて検知されたＤＤＩ関数に基づいた処理を直にデバイスドライバに実行させる。これにより第２モード時の処理のスループットを向上させることが可能になる。ここで、モード設定の具体的な手法の一例として、モード設定手段は、第１モードもしくは第２モードの何れか一方の設定を異なる処理系統にて動作する外部モジュールの起動状態に基づいて行う。すなわち、外部モジュールの起動を制御して間接的にモードの設定を行う。このとき、外部モジュールに第１モードもしくは第２モードに対応する所定の機能を備えさせておけば、外部モジュールの起動にリンクしてデバイスドライバにて所定のモードにおける処理を実行させることが可能になる。
【０００９】
ここで、上述してきたデバイスドライバ制御モジュールは、デバイスドライバを制御する方法としても成立することは言うまでもないし、当該デバイスドライバの制御と同等の機能をコンピュータにて実現可能にするデバイスドライバプログラムとしても発明が成立することは言うまでもない。このとき、このデバイスドライバ制御プログラムの記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置などコンピュータが読み取り可能な種々の媒体を利用できる。また、デバイスドライバ制御モジュールを内部モジュールとして組み込んだデバイスドライバとしても発明にかかる技術思想を実現できることは言うまでもない。
【００１０】
【発明の実施の形態】
ここでは、下記の順序に従って本発明の実施形態について説明する。
（１）印刷システムの構成：
（２）コンピュータの構成：
（３）プリンタドライバ実行状態監視システムの構成：
（４）プリンタドライバ遠隔監視システムの形態：
（５）本発明との対応：
（６）まとめ：
【００１１】
（１）印刷システムの構成：
図１は、本発明のドライバ実行状態監視システムを実現可能な印刷システムの構成を説明するブロック図である。なお、本発明の機能が実行されるのであれば、単体の機器であっても、複数の機器からなるシステムであっても、ＬＡＮ，ＷＡＮ等のネットワークを介して接続がなされ処理が行われるシステムであっても本発明を適用できる。
同図において、ホストコンピュータ１０は、ＲＯＭ１３のプログラム用ＲＯＭあるいは外部メモリ１６ａに記憶された文書処理プログラム等に基づいて図形、イメージ、文字、表（表計算等を含む）等が混在した文書処理を実行するＣＰＵ１１を備え、システムバス１８に接続される各デバイスをＣＰＵ１１が総括的に制御可能になっている。
【００１２】
また、このＲＯＭ１３のプログラム用ＲＯＭあるいは外部メモリ１６ａには、ＣＰＵ１１の制御プログラムであるオペレーティングシステムプログラム等を記憶し、ＲＯＭ１３のデータ用ＲＯＭあるいは外部メモリ１６ａには文書処理の際に使用するフォントデータ等を記憶し、ＲＯＭ１３のフォント用ＲＯＭあるいは外部メモリ１６ａには上記文書処理等を行う際に使用する各種データを記憶する。ＲＡＭ１２は、ＣＰＵ１１の主メモリ、ワークエリア等として機能する。キーボードコントローラ（ＫＢＣ）１４は、接続されたキーボード１４ａや、図示しないマウス等のポインティングデバイスからのキー入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）１５は、接続されたＣＲＴディスプレイ１５ａの表示を制御する。ディスクコントローラ（ＤＫＣ）１６では、ブートプログラム、各種のアプリケーションプログラム、フォントデータ、ユーザファイル、編集ファイル、プリンタ制御コマンド生成プログラム（以下、プリンタドライバ）等を記憶するハードディスク、フレキシブルディスク等の外部メモリ１６ａとのアクセスを制御する。
【００１３】
プリンタコントローラ（ＰＲＴＣ）１７は、双方向性インターフェース３０を介してプリンタ２０に接続されて、プリンタ２０との通信制御処理を実行可能になっている。なお、ＣＰＵ１１は、例えばＲＡＭ１２上に設定された表示情報ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴディスプレイ１５ａでのＷＹＳＩＷＹＧを可能としている。また、ＣＰＵ１１は、ＣＲＴディスプレイ１５ａ上の図示しないマウスカーソル等で指示されたコマンドに基づいて登録された種々のウィンドウを開き、種々のデータ処理を実行する。ユーザは印刷を実行する際、印刷の設定に関するウィンドウを開き、プリンタの設定や、印刷モードの設定を含むプリンタドライバに対する印刷処理方法の設定を行えるようになっている。
【００１４】
プリンタ２０は、プリンタＣＰＵ２１により制御される。プリンタＣＰＵ２１は、ＲＯＭ２３のプログラム用ＲＯＭに記録された制御プログラム等あるいは外部メモリ２６ａに記憶された制御プログラム等に基づいて、システムバス２８に接続される印刷部インターフェース２５を介して印刷部（プリンタエンジン）２５ａに出力情報としての画像信号を出力する。また、ＲＯＭ２３のプログラムＲＯＭには、ＣＰＵ２１の制御プログラム等を記憶する。ＲＯＭ２３のフォント用ＲＯＭには、上記出力情報を生成する際に使用するフォントデータ等が記憶され、ＲＯＭ２３のデータ用ＲＯＭには、ハードディスク等の外部メモリ２６ａがないプリンタの場合に、ホストコンピュータ１０上で利用される情報等が記憶されている。ＣＰＵ２１は、入力部２４を介してホストコンピュータ１０との通信処理が可能となっており、プリンタ２０内の情報等をホストコンピュータ１０に通知できる。ここで、ＲＡＭ２２は、ＣＰＵ２１の主メモリや、ワークエリア等として機能するＲＡＭで、図示しない増設ポートに接続されるオプションＲＡＭによりメモリ容量を拡張することができるように構成されている。
【００１５】
なお、ＲＡＭ２２は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。上述したハードディスク、ＩＣカード等の外部メモリ２６ａは、メモリコントローラ（ＭＣ）２６によりアクセスを制御される。外部メモリ２６ａは、オプションとして接続され、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶する。また、操作パネル２７は、図示しない操作のためのスイッチやＬＥＤ表示器等が配設されている。また、上述した外部メモリ２６ａは、１個に限らず、複数個備えられ、内蔵フォントに加えてオプションカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていても良い。さらに、図示しないＮＶＲＡＭを有し、操作パネル２７からのプリンタモード設定情報を記憶するようにしても良い。
【００１６】
（２）コンピュータの構成：
図２は、プリンタ等の印刷装置が直接接続されているか、あるいはネットワーク経由で接続されているホストコンピュータ１０における典型的な印刷処理の処理内容を示したフローチャートである。
同図において、アプリケーション１００、ＷｉｎｄｏｗｓＡＰＩ１０１（Ｗｉｎｄｏｗｓは米マイクロソフト社の登録商標、以下、ＡＰＩ１０１とする。）、グラフィックエンジン１０２、プリンタドライバ１０４およびシステムスプーラ１０５は、外部メモリ１６ａに保存されたファイルとして存在し、実行される場合にオペレーティングシステムやそのモジュールを利用するモジュールによってＲＡＭ１２にロードされ実行されるプログラムモジュールである。また、アプリケーション１００およびプリンタドライバ１０４は、外部メモリ１６ａのフレキシブルディスクや図示しないＣＤ−ＲＯＭあるいは図示しないネットワークを経由して当該外部メモリ１６ａのハードディスクに追加することが可能になっている。外部メモリ１６ａに保存されているアプリケーション１００は、ＲＡＭ１２にロードされ実行可能になっているグラフィックエンジン１０２を利用して出力（描画）を行う。
【００１７】
グラフィックエンジン１０２は、印刷装置ごとに用意されたプリンタドライバ１０４を同様に外部メモリ１６ａからＲＡＭ１２にロードし、アプリケーション１００の出力をプリンタドライバ１０４に設定する。そして、アプリケーション１００からＡＰＩ１０１を受け取り、対応するＧＤＩ（グラフィックデバイスインターフェース）関数に変換するとともに、ＤＤＩ（デバイスドライバインターフェース）関数１０３に変換して、プリンタドライバ１０４へＤＤＩ関数１０３を出力する。プリンタドライバ１０４は、グラフィックエンジン１０２から受け取ったＤＤＩ関数１０３に基づいて、プリンタ２０が認識可能なプリンタ制御コマンド、例えばＰＤＬ（ページ記述言語）に変換する。変換されたプリンタ制御コマンドは、オペレーティングシステムによってＲＡＭ１２にロードされたシステムスプーラ１０５にて呼び出されるＡＰＩ１０１を経てシリアルもしくはパラレルもしくはネットワークドライバにて構成されるインターフェース２０を経由してプリンタ２０へ印刷データとして出力される仕組みになっている。このシステムスプーラ１０５は内部にプリントプロセッサ１０５ａとプリントモニタ１０５ｂとを有し、これらの構成を動作させて所定の機能を実現する。
【００１８】
ここで、上述したようにアプリケーション１００にて印刷を行う際に、当該アプリケーション１００からプリンタドライバ１０４に対して設定が行われる。この設定はＡＰＩ１０１もしくはＤＤＩ関数１０３を通じて行われたり、アプリケーション１００から直接プリンタドライバ１０４に入力されるＤＥＶＭＯＤＥ情報に基づいて行われる。プリンタドライバ１０４もプログラムであり、コーディングミスやソフトウェア設計不具合により内部にバグを含む場合がある。むろん、アプリケーション１００もプログラムであり、内部にバグを含む場合がある。すなわち、アプリケーション１００がプリンタドライバ１０４に対して諸設定等を行う処理にバグが存在すると、これが原因となり、プリンタドライバ１０４の動作が不安定になることがある。
【００１９】
また、アプリケーション１００の処理は正常であるが、プリンタドライバ１０４のバグが原因となり、当該プリンタドライバ１０４の動作が不安定になることがある。このとき、プリンタドライバ１０４の実行状態をトレースすることにより、アプリケーション１００にバグがあるのか、プリンタドライバ１０４にバグがあるのかを切り分ける作業を行う。このとき、ホストコンピュータ１０にツールプログラムを組み込んだプリンタドライバをインストールしたりする。しかし、このツールプログラムの仕様等に起因してホストコンピュータ１０を再立ち上げしなければならない。従って、ホストコンピュータ１０は一時的にシャットアウトされ停止する。このため、業務用のアプリケーション１００の動作も停止してしまうのため、業務が滞ってしまうという問題があった。
【００２０】
そこで、本実施形態では、プリンタドライバ１０４とは別の処理系統で実行される後述するイベント管理プログラムを起動させるとともに、プリンタドライバ１０４にてこのイベント管理プログラムの起動を検知可能とするとともに、イベント管理プログラムが起動された場合にプリンタドライバ１０４から当該プリンタドライバ１０４の実行状態を示す諸情報をイベント管理プログラムに対して出力し、当該イベント管理プログラムにてプリンタドライバ１０４の実行状態を監視することを可能にする。これによって、プリンタドライバ１０４が不安定になる不具合が発生した場合に、イベント管理プログラムを起動するのみで同プリンタドライバ１０４の実行状態をトレース可能なデバッグモードに移行することができるため、ホストコンピュータ１０をシャットダウンする必要がない。従って、ホストコンピュータ１０にて実施されている各種業務が停止してしまうことを防止することが可能になる。
【００２１】
（３）プリンタドライバ実行状態監視システムの構成：
図３は、プリンタドライバ１０４の実行状態を監視するプリンタドライバ実行状態監視システムの概略構成をを示した概略構成図である。また、図４は、プリンタドライバ１０４の概略内部構成を示した構成図であり、図５は、イベント管理プログラム５０の概略内部構成を示した構成図である。図において、プリンタドライバ１０４は共有メモリ４０を介してイベント管理プログラム５０との各種情報のやり取りを行う。本実施形態において、この各種情報は、起動／停止情報４１と、ＡＰＩ呼出情報４２と、ＤＥＶＭＯＤＥ情報４３と、ＤＤＩ情報４４と、メモリオーバーラン情報４６とから構成されている。各種情報の内容については後述する。プリンタドライバ１０４は、ＤＤＩ関数１０３を入力すると、複数の実行モジュール１０４ａの中からこの入力したＤＤＩ関数１０３に対応する処理を実行可能な実行モジュール１０４ａにてＤＤＩ関数１０３に基づいて処理を実行し、所定の機能を実現する。
【００２２】
このとき、実行モジュール１０４ａではこの処理に伴い、ＡＰＩ１０１を呼び出し、このＡＰＩ１０１にて実行された処理結果に基づいてＤＤＩ関数１０３に対応する処理を適宜実行する。本実施形態ではこの呼び出されたＡＰＩ１０１を一旦ラッパーモジュール１０４ｂにて受け付ける。このラッパーモジュール１０４ｂは、実行モジュール１０４ａがＡＰＩ１０１の呼び出しを行うに際して、起動される。すなわち、実行モジュール１０４ａにて呼び出されて起動される。呼び出されたラッパーモジュール１０４ｂは、実行モジュール１０４ａが呼び出したＡＰＩ１０１を横取りする。そして、イベント管理プログラム５０が起動しているか否かを判別し、起動している場合には各種情報を共有メモリ４０に転送し、イベント管理プログラム５０にて取得可能にするとともに、実行モジュール１０４ａが呼び出し一旦横取りしたＡＰＩ１０１を呼び出し、実行モジュール１０４ａにてこのＡＰＩ１０１の処理結果に基づいたＤＤＩ関数１０３の処理を実行可能にする。これを本実施形態ではデバッグモードと言う。このイベント管理プログラム５０にて取得可能にする手法を、各種情報のイベント管理プログラム５０への転送と呼ぶ。ここで、本実施形態においては、共有メモリ４０を介してプリンタドライバ１０４とイベント管理プログラム５０との間における各種情報のやり取りを実現する態様を採用したが、むろん、プロセス間通信等の通信手法に基づいて各種情報をプリンタドライバ４０からイベント管理プログラム５０に対して出力し、取得可能にする態様を採用しても良い。
【００２３】
一方、イベント管理プログラム５０が起動していない場合には各種情報の共有メモリ４０への転送は行わない。そして、実行モジュール１０４ａが呼び出し一旦横取りしたＡＰＩ１０１を呼び出し、実行モジュール１０４ａにてこのＡＰＩ１０１の処理結果に基づいたＤＤＩ関数１０３の処理を実行可能にする。これを本実施形態では通常モードと言う。
一方、図５に示すようにイベント管理プログラム５０は、初期設定モジュール５０ａと、データ収集モジュール５０ｂと、表示モジュール５０ｃとを有する構成となっている。初期設定モジュール５０ａはイベント管理プログラム５０が起動された際に起動状態を認識可能な情報を共有メモリ４０に転送し、停止された際に停止状態を認識可能な情報を共有メモリ４０に転送する。データ収集モジュール５０ｂは、共有メモリ４０に転送された各種情報を読み出して収集してＲＡＭ１２もしくは外部メモリ１６ａに格納する機能を実現し、表示モジュール５０ｃは収集した各種情報を所定の形式に基づいてユーザが視認可能な画面を表示する。
【００２４】
ここで、上述した各種情報について説明する。起動／停止情報４１は、イベント管理プログラム５０の起動状態および停止状態を認識可能な情報が格納されており、プリンタドライバ１０４は、この起動／停止情報に基づいてイベント管理プログラム５０が起動されているか否かを判別可能になっている。ＡＰＩ呼出情報４２は、実行モジュール１０４ａから呼び出されたＡＰＩ１０１のＡＰＩ名称や、当該ＡＰＩ１０１を呼び出した実行モジュール１０４ａを特定可能なモジュール名称や、このＡＰＩ１０１の呼び出しが行われた実行モジュール１０４ａのソースプログラムの実行行や、呼び出し日時や、エラー情報（例えば、ＮＵＬＬポイントが渡ってきた等）等の情報を有している。これらの情報は、ＡＰＩ１０１に基づいて検出可能になっている。また、ＡＰＩ呼出情報４２は、実行モジュール１０４ａが所定の共有資源を排他的に使用する場合に呼び出すＡＰＩ１０１に関する情報も有している。例えば、“Ｏｐｅｎ”“Ｃｌｏｓｅ”や、“Ａｌｌｏｃ”“Ｆｒｅｅ”等の対となる処理を行い、共有資源を排他的にロックして占有するとともに、排他的な処理が終了したらこのロックを解放することを示す情報である。イベント管理プログラム５０は、このＡＰＩ呼出情報４２に基づいて、上述した占有／解放状態を認識可能な情報を作成し、この情報をＡＰＩ呼出情報４２の一要素として格納し、当該ＡＰＩ呼出情報４２によって排他的処理の不完全な完了状態を認識することを可能にする。
【００２５】
ＤＥＶＭＯＤＥ情報４３は、印刷時にアプリケーション１００からプリンタドライバ１０４に渡されるＤＥＶＭＯＤＥ構造体に基づいた情報であり、プリンタ２０のデバイス名や、バージョン番号や、プリンタドライバ１０４のバージョン番号や、印刷用紙の方向や、印刷用紙サイズや、印刷用紙の高さおよび幅や、拡大縮小率や、印刷部数および印刷品質（簡易印刷、低品質、高品質等）や、白黒もしくはカラー設定等の情報を有している。ＤＤＩ情報４４は、実行モジュール１０４ａが入力したＤＤＩ関数１０３の関数名称や、この関数に設定された引数もしくはパラメータ等の情報を有している。この情報は実行モジュール１０４ａに問い合わせて取得可能になっている。
【００２６】
メモリオーバーラン情報４６は、ＤＤＩ関数１０３の引数に設定された引数領域がメモリ領域上に確保不可能な場合にその旨を通知する情報である。このＤＤＩ関数１０３の引数領域は、アプリケーション１００がグラフィックエンジン１０２に引き渡すＡＰＩ１０１に設定されている。すなわち、アプリケーション１００が出力するＡＰＩ１０１に基づいてＤＤＩ関数１０３の引数領域が構成される。ここで、アプリケーション１００のバグによって設定された引数領域をメモリ領域上に確保できない場合、この確保できないメモリ領域に実行モジュール１０４ａがアクセスすると不具合が発生する。従って、このメモリオーバーラン情報４６に基づいてアプリケーション１００のバグ（引数設定のバグ）を発見することが可能になる。
【００２７】
ここで、上述してきた機能を実現する際にプリンタドライバ１０４にて実行される概略処理内容を図６のフローチャートに示す。
同図において、プリンタドライバ１０４はグラフィックドライバ１０２からＤＤＩ関数１０３を入力すると、複数ある実行モジュール１０４ａのうち、当該入力したＤＤＩ関数１０３の処理を実行可能な実行モジュール１０４ａにてＤＤＩ関数１０３の処理を実行する（ステップＳ１００）。そして、このＤＤＩ関数１０３の処理においてＡＰＩ１０１の呼び出しが発生した場合、ラッパーモジュール１０４ｂを呼び出す。このラッパーモジュール１０４ｂは、イベント管理プログラム５０が起動している場合、デバッグモードに移行し上述した各種情報を作成して共有メモリ４０に転送するとともに、ＡＰＩ１０１の呼び出しを行う。一方、ラッパーモジュール１０４ｂは、イベント管理プログラム５０が起動していない場合、通常モードに移行して実行モジュール１０４ａが呼び出したＡＰＩ１０１の呼び出しを行う（ステップＳ１０５）。
【００２８】
図７は、ラッパーモジュール１０４ｂを呼び出す際に実行モジュール１０４ａにて実行される処理内容を示したフローチャートである。
同図において、実行モジュール１０４ａはグラフィックエンジン１０２からＤＤＩ関数１０３を入力すると（ステップＳ１５０）、実行モジュール１０４ａに予め規定されている対応するＤＤＩ関数を引き出して、ＤＤＩ関数１０３に基づいた処理を実行する（ステップＳ１５５）。この処理においてＡＰＩ１０１を呼び出す処理が発生した場合（ステップＳ１６０）、ラッパーモジュール１０４ｂを呼び出して同ラッパーモジュール１０４ｂを動作可能状態にする（ステップＳ１６５）。このラッパーモジュール１０４ｂの呼び出し方法は特に限定されず、ＤＤＩ関数１０３に対応するＤＤＩ関数の中に起動コマンドを埋め込んでおいても良いし、ラッパーモジュール１０４ｂの呼び出し専用のＡＰＩ１０１を規定しておき、同ＡＰＩ１０１を呼び出すことによってラッパーモジュール１０４ｂを呼び出すようにしても良い。
【００２９】
図８は、ＡＰＩ呼出情報４２をイベント管理プログラム５０に転送する際にラッパーモジュール１０４ｂにて実行される処理内容を示したフローチャートである。
同図において、先ず最初に実行モジュール１０４ａからの呼び出しがあったか否かを判別する（ステップＳ２００）。実行モジュール１０４ａからの呼び出しがあった場合は、共有メモリ４０の起動／停止情報４１にアクセスする（ステップＳ２０５）。そして、この起動／停止情報４１にイベント管理プログラム５０が起動時に初期設定モジュール５０ａによって格納する起動情報が存在するか否かを判別する（ステップＳ２１０）。起動情報が存在すると判別された場合は、実行モジュール１０４ａが呼び出したＡＰＩ１０１の呼び出しを行うとともに（ステップＳ２１１）、デバッグモードに移行し、実行モジュール１０４ａが呼び出したＡＰＩ１０１の戻り値などに基づくＡＰＩ呼出情報を取得して（ステップＳ２１５）、ＡＰＩ呼出情報４２として共有メモリ４０に転送してセットすることによって、イベント管理プログラム５０に転送する（ステップＳ２２０）。一方、ステップＳ２１０にて起動情報が存在しないと判別された場合は、通常モードに移行し、実行モジュール１０４ａが呼び出したＡＰＩ１０１の呼び出しを行う（ステップＳ２２５）。
【００３０】
ここで、イベント管理プログラム５０の初期設定モジュール５０ａによって起動／停止情報４１を更新する際に実行される処理内容を図９のフローチャートに示す。
同図において、先ず最初にイベント管理プログラム５０に対する起動操作が行われたか否かを判別する（ステップＳ２５０）。起動操作が行われたと判別した場合は、共有メモリ４０にアクセスするとともに、起動／停止情報４１に起動情報を格納する（ステップＳ２５５）。一方、イベント管理プログラム５０に対する停止操作が行われた場合は（ステップＳ２６０）、共有メモリ４０にアクセスするとともに、起動／停止情報４１に停止情報を格納する（ステップＳ２６５）。このように、イベント管理プログラム５０に対する起動操作もしくは停止操作に基づいて起動／停止情報４１を更新することによって、プリンタドライバ１０４のラッパーモジュール１０４ｂはこの起動／停止情報４１に格納された情報に基づいてイベント管理プログラム５０の状態を判別することが可能になる。むろん、イベント管理プログラム５０の状態を判別する手法は上述の手法に限定されるものではなく、イベント管理プログラム５０が起動された際に、当該イベント管理プログラム５０から起動通知をプリンタドライバ１０４に対して直接入力させるようにしても良いことは言うまでもない。
【００３１】
図１０は、ＤＥＶＭＯＤＥ情報４３をイベント管理プログラム５０に転送する際にラッパーモジュール１０４ｂにて実行される処理内容を示したフローチャートである。
同図において、先ず最初に実行モジュール１０４ａからの呼び出しがあったか否かを判別する（ステップＳ３００）。実行モジュール１０４ａからの呼び出しがあった場合は、共有メモリ４０の起動／停止情報４１にアクセスする（ステップＳ３０５）。そして、この起動／停止情報４１にイベント管理プログラム５０が起動時に初期設定モジュール５０ａによって格納する起動情報が存在するか否かを判別する（ステップＳ３１０）。起動情報が存在すると判別された場合は、デバッグモードに移行し、実行モジュール１０４ａに入力されたＤＤＩ関数１０３が特定のＤＤＩ関数１０３（ＤＥＶＭＯＤＥ情報が付随するＤＤＩ関数）であるか否かを判別する（ステップＳ３１５）。特定のＤＤＩ関数１０３であると判別された場合は、ＡＰＩ１０１を呼び出したアプリケーション１００からＤＥＶＭＯＤＥ情報を取得し（ステップＳ３２０）、所定のデータ構造体にコピーしてこのデータ構造体を共有メモリ４０に転送する。これにより、同共有メモリ４０に転送したＤＥＶＭＯＤＥ情報４３をイベント管理プログラム５０に転送する（ステップＳ３２５）。一方、ステップＳ３１０にて起動情報が存在しないと判別された場合は、通常モードに移行する。
【００３２】
図１１は、ＤＤＩ情報４４をイベント管理プログラム５０に転送する際に実行モジュール１０４ａにて実行されるる処理内容を示したフローチャートである。
同図において、実行モジュール１０４ａはグラフィックエンジン１０２からＤＤＩ関数１０３を入力すると（ステップＳ４００）、ＤＤＩ関数１０３に基づいた処理を開始し（ステップＳ４０５）、ラッパーモジュール１０４ｂを呼び出して起動させる（ステップＳ４１０）。ここで、後述するラッパーモジュール１０４ｂの処理にて実行されるＤＤＩ情報４４のイベント管理プログラム５０への転送が完了したか否かを判別し、転送が完了するまで待機する（ステップＳ４１５）。そして、ＤＤＩ関数１０３に基づいた処理を実行する（ステップＳ４２０）。上述したようにＤＤＩ関数情報４４をイベント管理プログラム５０に転送する際には、ラッパーモジュール１０４ｂの呼び出しを実行モジュール１０４ａにＤＤＩ関数１０３が入力されたタイミングとする。
【００３３】
図１２は、ＤＤＩ情報４４をイベント管理プログラム５０に転送する際にラッパーモジュール１０４ｂにて実行される処理内容を示したフローチャートである。
同図において、先ず最初に実行モジュール１０４ａからの呼び出しがあったか否かを判別する（ステップＳ４５０）。実行モジュール１０４ａからの呼び出しがあった場合は、共有メモリ４０の起動／停止情報４１にアクセスする（ステップＳ４５５）。そして、この起動／停止情報４１にイベント管理プログラム５０が起動時に初期設定モジュール５０ａによって格納する起動情報が存在するか否かを判別する（ステップＳ４６０）。起動情報が存在すると判別された場合は、デバッグモードに移行し、実行モジュール１０４ａに入力されたＤＤＩ関数１０３のＤＤＩ関数名称や引数のパラメータを取得し（ステップＳ４６５）、所定のデータ構造体にコピーしてこのデータ構造体を共有メモリ４０にＤＤＩ情報４４として格納する。これにより、同共有メモリ４０に転送したＤＤＩ情報４４をイベント管理プログラム５０に転送する（ステップＳ４７０）。そして、上述した実行モジュール１０４ａのステップＳ４１５に対する転送完了通知を同実行モジュール１０４ａに対して出力する（ステップＳ４７５）。一方、ステップＳ３１０にて起動情報が存在しないと判別された場合は、通常モードに移行する。
【００３４】
図１３は、メモリオーバーラン情報４６をイベント管理プログラム５０に転送する際に実行モジュール１０４ａにて実行される処理内容を示したフローチャートである。
同図において、実行モジュール１０４ａはグラフィックエンジン１０２からＤＤＩ関数１０３を入力すると（ステップＳ５５０）、ラッパーモジュール１０４ｂを呼び出して起動させる（ステップＳ５５５）。ここで、後述するラッパーモジュール１０４ｂの処理にて実行されるメモリ領域のチェック結果の応答を入力したか否かを判別し、応答の入力まで待機する（ステップＳ５６０）。そして、応答があった場合は、後述するラッパーモジュール１０４ｂから入力する情報が引数を設定したパラメータ構造体であるか否かを判別する（ステップＳ５６５）。入力した情報が引数を設定したパラメータ構造体であると判別された場合は、この設定された引数に基づいてＤＤＩ関数１０３の処理を実行する（ステップＳ５７０）。一方、入力した情報がパラメータ構造体ではないと判別された場合は、メモリ領域のチェックでエラーが発生していることを示すエラー通知であるため、所定のエラー処理を実行する（ステップＳ５７５）。このエラー処理は、例えば、ＤＤＩ関数１０３に基づく処理を中止して、その旨をユーザに通知する表示を行う等の処理が勘案できる。
【００３５】
図１４は、メモリオーバーラン情報４６をイベント管理プログラム５０に転送する際にラッパーモジュール１０４ｂにて実行される処理内容を示したフローチャートである。
同図において、先ず最初に実行モジュール１０４ａからの呼び出しがあったか否かを判別する（ステップＳ６００）。実行モジュール１０４ａからの呼び出しがあった場合は、共有メモリ４０の起動／停止情報４１にアクセスする（ステップＳ６０５）。そして、この起動／停止情報４１にイベント管理プログラム５０が起動時に初期設定モジュール５０ａによって格納する起動情報が存在するか否かを判別する（ステップＳ６１０）。起動情報が存在すると判別された場合は、デバッグモードに移行し、実行モジュール１０４ａが入力したＤＤＩ関数１０３に設定された引数領域を取得する（ステップＳ６１５）。
【００３６】
この引数領域は、例えば、ＤＤＩ関数１０３が“ＤｒｖＳｔａｒｔＤｏｃ”（印刷ドキュメントの転送準備ができたときに、グラフィックエンジン１０２から呼ばれるＤＤＩ関数）である場合、印刷情報に関する構造体へのポイントである“ＳＵＲＦＯＢＪ＊ｐｓｏ”であったり、印刷ドキュメント名の文字列へのポインタ“ＬＰＷＳＴＲ ｐｗｓｚＤｏｃＮａｍｅ”であったり、ジョブＩＤを示す“ＤＷＯＲＤ ｄｗＪｏｂＩｄ”であったりする。引数領域を取得すると、所定のＷｉｎｄｏｗｓの関数を利用してこの引数領域がメモリ領域上に存在しているか否か、すなわち引数領域をメモリ領域上に確保可能であるか否かをチェックする（ステップＳ６２０）。このＷｉｎｄｏｗｓの関数はチェック後に戻り値をラッパーモジュール１０４ｂに返答するので、次にこの戻り値が失敗を示す値、すなわち引数領域がメモリ領域上に確保不可能の場合には、共有メモリ４０にメモリオーバーラン情報４６を格納することによってイベント管理プログラム５０に転送するとともに（ステップＳ６３０）、実行モジュール１０４ａに対してエラー通知の応答を行う（ステップＳ６３５）。
【００３７】
従って、共有メモリ４０にメモリオーバーラン情報４６が格納されていれば、メモリオーバーランの不具合があったことを認識することが可能になる。一方、Ｗｉｎｄｏｗｓの関数が返答した戻り値が有効を示す値、すなわち引数領域がメモリ領域上に確保可能の場合には、引数領域をパラメータ構造体にコピーするとともに（ステップＳ６４０）、実行モジュール１０４ａに転送する（ステップＳ６４５）。そして、実行モジュール１０４ａはこの転送されたパラメータ構造体に基づいて上述したステップＳ５７０にてＤＤＩ関数１０３に基づいた処理を実行することになる。
【００３８】
図１５は、各種情報を入力した際にイベント管理プログラム５０のデータ収集モジュール５０ｂにて実行される処理内容を示したフローチャートである。
同図において、所定間隔もしくはある規則に基づいて規定された間隔等に基づいて共有メモリ４０にアクセスし、ラッパーモジュール１０４ｂによって当該共有メモリ４０に転送された各種情報４２〜４６を入力する（ステップＳ６５０）。この入力した各種情報４２〜４６にＡＰＩ呼出情報４２が含まれるか否かを判別し（ステップＳ６５５）、ＡＰＩ呼出情報４２が含まれていない場合は各種情報４３〜４６をＲＡＭ１２もしくは外部メモリ１６ａに個別に格納する（ステップＳ６９０）。ＡＰＩ呼出情報４２が含まれている場合は、ＡＰＩ呼出情報４２が有しているＡＰＩ１０１が共有資源を占有、すなわちロックするためのＡＰＩ１０１（例えば、“ＧｌｏｂａｌＡｌｌｏｃ”，“ＨｅａｐＡｌｌｏｃ”，“ｍａｌｌｏｃ”等）であるか否かを判別する（ステップＳ６６０）。
【００３９】
占有ＡＰＩであれば、ステップＳ６９０にてこの情報をＡＰＩ呼出情報４２としてＲＡＭ１２もしくは外部メモリ１６ａに個別に格納する。一方、占有ＡＰＩでない場合は、判別したＡＰＩ１０１が占有した共有資源を解放するためのＡＰＩ１０１（例えば、“ＧｌｏｂａｌＦｒｅｅ”，“ＨｅａｐＦｒｅｅ”，“ｆｒｅｅ”等）を示す解放ＡＰＩ１０１であるか否かを判別し（ステップＳ６６５）、解放ＡＰＩでないときは、入力したＡＰＩ呼出情報４２をステップＳ６９０にてＲＡＭ１２もしくは外部メモリ１６ａに個別に格納する。解放ＡＰＩであれば、以前確保された占有メモリ領域を検索し（ステップＳ６７０）、マッチするメモリ領域が有るか否かを判別する（ステップＳ６７５）。この検索は、後述する図１７に示した画面構成にて「ＤａｔａＡｄｄｒｅｓｓ」というカラムがあり、ここに占有したメモリ領域の先頭アドレスが表示されている。従って、解放ＡＰＩである場合は、その先頭アドレスを検索し、マッチするか否かを判断することになる。マッチするメモリ領域が有る場合は、排他的処理が正常に終了したと判断し、ＲＡＭ１２もしくは外部メモリ１６ａに格納されている占有時のＡＰＩ呼出情報４２を削除する（ステップＳ６８０）。一方、マッチするメモリ領域が無い場合は、占有していないメモリ領域を解放しようとしているため、エラーと判断し（ステップＳ６８５）、その旨をステップＳ６９０にてＡＰＩ呼出情報４２に格納する。
【００４０】
図１６は、各種情報を表示する際にイベント管理プログラム５０の表示モジュール５０ｃにて実行される処理内容を示したフローチャートである。また、図１７および図１８は、表示モジュール５０ｃによってＣＲＴディスプレイ１５ａに表示される画面構成の一例を示した画面構成図である。
同図において、ＣＲＴディスプレイ１５ａにイベント管理プログラム５０の所定のユーザインターフェース画面が表示されると、表示モジュール１５ｃは、ＲＡＭ１２もしくは外部メモリ１６ａに格納した各種情報４２〜４６を視認可能にする画面表示を行う処理の待機状態となる。ここで、このユーザインターフェース画面から所定操作に基づいてＡＰＩ呼出情報４２の表示要求が行われると（ステップＳ７００）、ＲＡＭ１２もしくは外部メモリ１６ａからＡＰＩ呼出情報４２を読み出して（ステップＳ７０５）、ＣＲＴディスプレイ１５ａに表示する（ステップＳ７１０）。
【００４１】
ユーザインターフェース画面から所定操作に基づいてＤＥＶＭＯＤＥ情報４３の表示要求が行われると（ステップＳ７１５）、ＲＡＭ１２もしくは外部メモリ１６ａからＤＥＶＭＯＤＥ情報４３を読み出して（ステップＳ７２０）、ＣＲＴディスプレイ１５ａに表示する（ステップＳ７２５）。ユーザインターフェース画面から所定操作に基づいてＤＤＩ情報４４の表示要求が行われると（ステップＳ７３０）、ＲＡＭ１２もしくは外部メモリ１６ａからＤＤＩ情報４４を読み出して（ステップＳ７３５）、ＣＲＴディスプレイ１５ａに表示する（ステップＳ７４０）。ユーザインターフェース画面から所定操作に基づいてメモリオーバーラン情報４６の表示要求が行われると（ステップＳ７６０）、ＲＡＭ１２もしくは外部メモリ１６ａからメモリオーバーラン情報４６を読み出して（ステップＳ７６５）、ＣＲＴディスプレイ１５ａに表示する（ステップＳ７７０）。そして、各画面表示において、例えば、引数の表示等に基づいて不具合の解析を行うことが可能になる。
【００４２】
（４）プリンタドライバ遠隔監視システムの形態：
上述してきた実施形態においては、プリンタドライバ１０４が動作するホストコンピュータ１０にてプリンタドライバ１０４とは異なる処理系統にて起動可能なイベント管理プログラム５０を起動させて、プリンタドライバ１０４にてこのイベント管理プログラム５０の起動を検知した場合にデバッグモードに移行し、同プリンタドライバ１０４から各種情報をイベント管理プログラム５０に共有メモリ４０を介して転送した。一方、イベント管理プログラム５０の起動が検知されない場合に通常モードに移行し、実行モジュール１０４ａが呼び出したＡＰＩ１０１に基づいてＤＤＩ関数１０３の処理を実行可能にした。
【００４３】
このようにプリンタドライバ１０４とは別の処理系統にて起動可能なイベント管理プログラム５０の起動させることによりデバッグモードに移行できるようにしたため、プリンタドライバ１０４の実行状態をトレースする際にホストコンピュータ１０を再立ち上げする必要がなくなった。そして、イベント管理プログラム５０にて収集された各種情報は、メンテナンス部門に引き渡されて解析される。この解析によってバグがプリンタドライバ１０４側にあるのかアプリケーション１００側にあるかを判別する。
【００４４】
この場合、メンテナンス要員は、ホストコンピュータ１０が設置されている現場に赴き、当該ホストコンピュータ１０にイベント管理プログラム５０をインストールし、もしくは既にインストールされているイベント管理プログラム５０を起動するとともに、収集した各種情報をリムーバブルな記録媒体に記憶して持ち帰る必要があった。この場合、人件費や交通費などの工数がかかり好ましくない。そこで、メンテナンス部門のホストコンピュータと顧客のクライアントとをネットワークにて接続し、適宜イベント管理プログラム５０をクライアントに転送して実行させるとともに、同イベント管理プログラム５０にて収集した各種情報をネットワークを介してホストコンピュータ１０に転送させるようにすれば、メンテナンス要員は現地に赴く必要がなくなり、工数を削減することができるとともに、各種情報に基づいた不具合の解析に直ぐに着手することが可能となり、プリンタドライバ１０４の実行状態を監視し解析すると言う作業の効率を向上させることが可能となり好適である。
【００４５】
図１９は、プリンタドライバ遠隔監視システムの概略構成を示したシステム構成図である。
同図において、ホストコンピュータＡ１はプリンタドライバ１０４のプリンタドライバ製造会社Ａに設置され、インターネットに接続されている。むろん、ホストコンピュータＡ１はメンテナンス会社に設置しても良く、サービス提供態様に応じて適宜設置場所は変更可能である。プリンタドライバ１０４を購入した顧客Ｂは自己のクライアントコンピュータＢ１〜Ｂｎにプリンタドライバ１０４をインストールして印刷を行う。このクライアントコンピュータＢ１〜Ｂｎも同様にインターネットに接続されており、ホストコンピュータＡ１と相互に通信可能になっている。従って、ホストコンピュータＡ１からクライアントコンピュータＢ１〜Ｂｎにデータを送信するとともにクライアントコンピュータＢ１〜Ｂｎが備えるハードディスク等の外部メモリにこのデータを記憶することもでき、クライアントコンピュータＢ１〜ＢｎからホストコンピュータＡ１にデータを送信するとともにホストコンピュータＡ１が備えるハードディスク等の外部メモリにこのデータを記憶することもできる。
【００４６】
図２０は、プリンタドライバ遠隔監視システムの業務内容を示した業務フローチャートである。
同図において、プリンタドライバ製造会社Ａは顧客Ｂからプリンタドライバ１０４の実行環境における不具合の通知を受けると（ステップＳ８００）、不具合が発生したクライアンコンピュータＢ１〜Ｂｎを特定する相手先データをホストコンピュータＡ１に入力し（ステップＳ８０５）、この相手先データに基づいてホストコンピュータＡ１から特定したクライアントコンピュータＢ１〜Ｂｎにイベント管理プログラム５０を転送し、当該クライアントコンピュータＢ１〜Ｂｎの外部メモリに格納する（ステップＳ８１０）。次に、イベント管理プログラム５０をホストコンピュータＡ１側もしくはクライアントコンピュータＢ１〜Ｂｎにて起動させイベント管理プログラム５０の処理を実行させる（ステップＳ８１５）。そして、このイベント管理プログラム５０の処理に基づいてクライアントコンピュータＢ１〜ＢｎからホストコンピュータＡ１に転送されてきた各種情報に基づいて不具合の解析作業を行う（ステップＳ８２０）。これにより、プリンタドライバ製造会社Ａはメンテナンス要員を顧客Ｂに派遣することなく、不具合の解析作業を行うことが可能となり、メンテナンスに費やされる時間を飛躍的に向上させることが可能となる。
【００４７】
図２１は、クライアントコンピュータＢ１〜Ｂｎに転送されたイベント管理プログラム５０にて実行される処理内容を示したフローチャートである。
同図において、外部メモリに格納されたイベント管理プログラム５０に対して起動操作が行われた否かを判別し（ステップＳ８５０）、起動操作が行われた場合はイベント管理プログラム５０の機能を起動する（ステップＳ８５５）。このとき、初期設定モジュール５０ａにてクライアントコンピュータＢ１〜Ｂｎの共有メモリ４０の起動／停止情報４１に起動情報を格納する（ステップＳ８６０）。そして、ラッパーモジュール１０４ｂから共有メモリ４０を介して各種情報４２〜４６を入力すると（ステップＳ８６５）、外部メモリにログデータとして収集し格納する（ステップＳ８７０）。
【００４８】
所定データ量のログデータが収集されると、クライアントコンピュータＢ１〜ＢｎからホストコンピュータＡ１に対してデータが転送可能な否かを判別する（ステップＳ８８０）。むろん、ホストコンピュータＡ１に転送する際のタイミングは所定データ量が収集されたタイミングに限定されるものではなく、所定周期毎に転送するようにしても良い。転送可能の場合は、各種情報４２〜４６のログデータをインターネットを介してホストコンピュータＡ１に転送し同ホストコンピュータＡ１の外部メモリに格納させる（ステップＳ８８５）。ホストコンピュータＡ１への転送が完了した場合、クライアントコンピュータＢ１〜Ｂｎの外部メモリに格納されたログデータを削除する（ステップＳ８９０）。
【００４９】
一方、転送不可能の場合は、未転送データとして外部メモリに保存しておく（ステップＳ８９５）。この保存した未転送データは適宜所定周期毎に転送の可否を判断して転送可能であれば順次ホストコンピュータＡ１に転送するようにすれば良い。以上の操作をイベント管理プログラム５０が停止操作されるまで実行する（ステップＳ８９６）。なお、イベント管理プログラム５０の初期設定モジュール５０ａは停止操作が行われた際に共有メモリ４０の起動／停止情報４１に停止情報を格納し、この起動／停止情報４１を介してイベント管理プログラム５０の停止状態を認識可能にする（ステップＳ８９７）。
【００５０】
ホストコンピュータＡ１からクライアントコンピュータＢ１〜Ｂｎに転送され、同クライアントコンピュータＢ１〜Ｂｎの外部メモリに格納されたイベント管理プログラム５０は、作業終了後に顧客Ｂの作業員に削除させるようにしても良いし、予めプリンタドライバ１０４のラッパーモジュール１０４ｂに所定条件を検出した際にイベント管理プログラム５０を削除する機能を持たせるようにしても良い。
【００５１】
図２２は、転送されたイベント管理プログラム５０を削除する際におけるクライアントコンピュータＢ１〜Ｂ３のプリンタドライバ１０４が備えるラッパーモジュール１０４ｂの処理内容を示したフローチャートである。
同図において、実行モジュール１０４ａによる呼び出しがあった場合、共有メモリ４０の起動／停止情報４１にアクセスすることによってイベント管理プログラム５０の起動状態を取得する（ステップＳ９０５）。そして、イベント管理プログラム５０が停止状態が停止状態であるか否かを判別し（ステップＳ９１０）、停止状態であると判別した場合は、イベント管理プログラム５０が格納されているハードディスク等の外部メモリにアクセスし（ステップＳ９１５）、イベント管理プログラム５０が格納されているか否かを判別する（ステップＳ９２０）。ここで、イベント管理プログラム５０が格納されていると判別した場合はイベント管理プログラム５０のファイルを削除する（ステップＳ９２５）。
【００５２】
図２３は、ホストコンピュータＡ１の動作内容を示したフローチャートである。同図において、クライアントコンピュータＢ１〜Ｂｎから各種情報４２〜４６が転送されて同各種情報４２〜４６を入力すると（ステップＳ９５０）、当該ホストコンピュータＡ１の外部メモリに格納する（ステップＳ９５５）。そして、各種情報４２〜４６の表示を要求する操作があった場合（ステップＳ９６０）、操作に応じて適宜各種情報４２〜４６の内容を視認可能にホストコンピュータＡ１のＣＲＴディスプレイに表示する（ステップＳ９６５）。これによって、プリンタドライバ製造会社Ａでは顧客Ｂに赴くことなく、顧客ＢのクライアントコンピュータＢ１〜Ｂｎに組み込まれたプリンタドライバ１０４の実行状態を把握し解析することが可能になる。
【００５３】
（５）本発明との対応：
ここで、本発明と上述してきた実施形態との対応関係について説明する。本発明にかかるデバイスドライバはプリンタドライバ１０４に対応する。また、本発明にかかる監視モジュールがイベント管理プログラム５０に対応する。そして、ドライバモジュールが有する実行モジュールは実行モジュール１０４ａに対応し、ＡＰＩ制御モジュールはラッパーモジュール１０４ｂに対応する。
【００５４】
（６）まとめ：
このように、プリンタドライバ１０４において、実行モジュール１０４ａとＡＰＩ１０１との間にラッパーモジュール１０４ｂを介在させることによって、イベント管理モジュール５０がこのラッパーモジュール１０４ｂにて実行モジュール１０４ａが共有資源に対して占有するための占有ＡＰＩ１０１や、この占有を解放するための解放ＡＰＩ１０１の呼び出しを検出し、この検出に基づいてＡＰＩ情報４５を作成する。従って、このＡＰＩ情報４５に基づいてプリンタドライバ１０４の処理にて共有資源に対するデッドロックやリークの不具合が発生した場合に、その不具合の発生状況を把握することが可能になる。
【図面の簡単な説明】
【図１】プリンタ制御システムの構成を説明するブロック図。
【図２】ホストコンピュータの内部構成図。
【図３】監視システムの概略構成図。
【図４】プリンタドライバの概略構成図。
【図５】イベント管理プログラムの概略構成図。
【図６】プリンタドライバの概略フローチャート。
【図７】実行モジュールの動作内容を示したフローチャート。
【図８】ラッパーモジュールの動作内容を示したフローチャート。
【図９】イベント管理プログラムの動作内容を示したフローチャート。
【図１０】ラッパーモジュールの動作内容を示したフローチャート。
【図１１】実行モジュールの動作内容を示したフローチャート。
【図１２】ラッパーモジュールの動作内容を示したフローチャート。
【図１３】実行モジュールの動作内容を示したフローチャート。
【図１４】ラッパーモジュールの動作内容を示したフローチャート。
【図１５】イベント管理プログラムの動作内容を示したフローチャート。
【図１６】表示モジュールの動作内容を示したフローチャート。
【図１７】表示画面の画面構成を示した画面構成図。
【図１８】表示画面の画面構成を示した画面構成図。
【図１９】デバイスドライバ遠隔監視システムの概略構成を示したシステム構成図。
【図２０】デバイスドライバ遠隔監視システムの業務内容を示した業務フローチャート。
【図２１】イベント管理プログラムにて実行される処理内容を示したフローチャート。
【図２２】ラッパーモジュールの処理内容を示したフローチャート。
【図２３】ホストコンピュータＡの動作内容を示したフローチャート。
【符号の説明】
１０…ホストコンピュータ
１１…ＣＰＵ
１２…ＲＡＭ
１３…ＲＯＭ
１４…ＫＢＣ
１５…ＣＲＴＣ
１６…ＤＫＣ
１７…ＰＲＴＣ
１８…システムバス
２０…プリンタ
２１…ＣＰＵ
２２…ＲＡＭ
２３…ＲＯＭ
２４…入力部
２５…印刷部Ｉ／Ｆ
２６…ＭＣ
３０…双方向性インターフェース
４０…共有メモリ
５０…イベント管理プログラム
５０ａ…初期設定モジュール
５０ｂ…データ収集モジュール
５０ｃ…表示モジュール
１００…アプリケーション
１０１…ＡＰＩ
１０２…グラフィックエンジン
１０３…ＤＤＩ関数
１０４…プリンタドライバ
１０４ａ…実行モジュール
１０４ｂ…ラッパーモジュール
１０５…システムスプーラ

Claims (12)

1. 所定のデバイスを駆動する際に起動されるデバイスドライバを制御するデバイスドライバ制御モジュールであって、
   アプリケーションが出力する制御アプリケーションインターフェース（ＡＰＩ）に基づいて呼び出されたデバイスドライバインターフェース（ＤＤＩ）関数を検知するＤＤＩ関数検知手段と、
   上記検知されたＤＤＩ関数の引数に設定された引数領域を取得する引数領域取得手段と、
   上記取得した引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かを判別するメモリ領域判別手段と、
   上記メモリ領域を確保している判別された場合に上記引数を取得し上記ＤＤＩ関数に基づいた処理を実行する上記デバイスドライバに同引数を出力して同ＤＤＩ関数に基づいた処理を実行させるＤＤＩ関数処理実行制御手段とを具備することを特徴とするデバイスドライバ制御モジュール。
2. 上記ＤＤＩ関数処理実行制御手段は、上記メモリ領域判別手段にて上記引数領域をメモリ領域上にて確保していないと判別された場合に上記デバイスドライバにおける上記ＤＤＩ関数に基づいた処理の実行を停止させることを特徴とする上記請求項１に記載のデバイスドライバ制御モジュール。
3. 上記ＤＤＩ関数処理実行制御手段は、上記ＤＤＩ関数に基づいた処理の実行を停止させた場合にその旨を通知する停止状態通知手段を有することを特徴とする上記請求項２に記載のデバイスドライバ制御モジュール。
4. 上記メモリ領域判別手段は、上記取得した引数領域をメモリ領域上にて確保していないと判別した場合にその旨を認識可能な情報を所定の外部モジュールに出力することを特徴とする上記請求項１〜請求項３のいずれかに記載のデバイスドライバ制御モジュール。
5. 上記メモリ領域判別手段にて上記引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かの判別を行わせる第１モードと、同判別を行わせない第２モードとの何れか一方を設定するモード設定手段を有し、上記ＤＤＩ関数処理実行制御手段は、同モード設定手段にて上記第２モードが設定された場合に上記ＤＤＩ関数検知手段にて検知されたＤＤＩ関数に基づいた処理を直に上記デバイスドライバに実行させることを特徴とする上記請求項１〜請求項４のいずれかに記載のデバイスドライバ制御モジュール。
6. 上記モード設定手段は、上記第１モードもしくは第２モードの何れか一方の設定を異なる処理系統にて動作する外部モジュールの起動状態に基づいて設定することを特徴とする上記請求項５に記載のデバイスドライバ制御モジュール。
7. 所定のデバイスを駆動する際に起動されるデバイスドライバを制御するデバイスドライバ制御方法であって、
   アプリケーションが出力する制御アプリケーションインターフェース（ＡＰＩ）に基づいて呼び出されたデバイスドライバインターフェース（ＤＤＩ）関数を検知するＤＤＩ関数検知工程と、
   上記検知されたＤＤＩ関数の引数に設定された引数領域を取得する引数領域取得工程と、
   上記取得した引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かを判別するメモリ領域判別工程と、
   上記メモリ領域を確保している判別された場合に上記引数を取得し上記ＤＤＩ関数に基づいた処理を実行する上記デバイスドライバに同引数を出力して同ＤＤＩ関数に基づいた処理を実行させるＤＤＩ関数処理実行制御工程とを具備することを特徴とするデバイスドライバ制御方法。
8. 所定のデバイスを駆動する際に起動されるデバイスドライバを制御する機能をコンピュータにて実現可能にするデバイスドライバ制御プログラムであって、
   アプリケーションが出力する制御アプリケーションインターフェース（ＡＰＩ）に基づいて呼び出されたデバイスドライバインターフェース（ＤＤＩ）関数を検知するＤＤＩ関数検知機能と、
   上記検知されたＤＤＩ関数の引数に設定された引数領域を取得する引数領域取得機能と、
   上記取得した引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かを判別するメモリ領域判別機能と、
   上記メモリ領域を確保していると判別された場合に上記引数を取得し上記ＤＤＩ関数に基づいた処理を実行する上記デバイスドライバに同引数を出力して同ＤＤＩ関数に基づいた処理を実行させるＤＤＩ関数処理実行制御機能とを具備することを特徴とするデバイスドライバ制御プログラム。
9. 所定のデバイスを駆動する際に起動されるデバイスドライバであって、
   ＤＤＩ関数に基づいて所定の機能を実行可能な実行モジュールと、
   アプリケーションが出力する制御アプリケーションインターフェース（ＡＰＩ）に基づいて呼び出されたデバイスドライバインターフェース（ＤＤＩ）関数を検知するＤＤＩ関数検知手段と、上記検知されたＤＤＩ関数の引数に設定された引数領域を取得する引数領域取得手段と、上記取得した引数領域が必要とされるデータサイズ分のメモリ領域を確保しているか否かを判別するメモリ領域判別手段と、上記メモリ領域を確保していると判別された場合に上記引数を取得し上記実行モジュールに引き渡し同ＤＤＩ関数に基づいた処理を実行させるＤＤＩ関数処理実行制御手段とを有するラッパーモジュールとを具備することを特徴とするデバイスドライバ。
10. 上記ラッパーモジュールは、異なる処理系統にて動作する監視モジュールに対して上記メモリ領域判別手段にて上記引数領域をメモリ領域上に確保していないと判別された場合にその旨を認識可能な所定の監視情報を出力することを特徴とする上記請求項９に記載のデバイスドライバ。
11. 上記ラッパーモジュールは、上記監視モジュールが起動されているか否かを判別する起動状態判別手段を有し、同起動状態判別手段にて監視モジュールが起動していると判別された場合に上記監視情報を出力することを特徴とする上記請求項１０のいずれかに記載のデバイスドライバ。
12. 上記ＤＤＩ関数処理実行手段は、上記メモリ領域判別手段にて上記引数領域をメモリ領域上にて確保していないと判別された場合に上記実行モジュールにて実行される上記ＤＤＩ関数に基づいた処理を停止させることを特徴とする上記請求項９〜請求項１１のいずれかに記載のデバイスドライバ。

Images