情報処理装置及びその制御方法、コンピュータプログラム、記憶媒体
【課題】 特にカラー・データを扱うソフトウェアの処理ログを容易に解析可能とする技術を提供する。
【解決手段】 本発明によれば、第１のモジュールにより呼び出し要求がなされた関数が、第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶する記憶制御手段と、前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御手段によって記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段とを備えることを特徴とする情報処理装置が提供される。
【解決手段】 本発明によれば、第１のモジュールにより呼び出し要求がなされた関数が、第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶する記憶制御手段と、前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御手段によって記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段とを備えることを特徴とする情報処理装置が提供される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアのデバッグを行う技術に関する。
【背景技術】
【０００２】
従来より、再現率の低いソフトウェアの問題を解決するために、開発中のソフトウェアのソースコードに処理ログを出力するルーチンを追加し、ソフトウェアの実行時に出力される処理ログを解析して、ソフトウェアのデバッグを行う方法が知られている。
【０００３】
このような方法によるデバッグは、プリンタ装置等の画像形成装置の動作を制御するソフトウェアの開発工程に対しても適用されている。例えば、特定のカラーを意図して出力したデータに基づいて印刷処理を行ったところ、開発したソフトウェアのバグが原因で、その出力結果が想定したものと異なっているという障害が発生した状況を考える。この場合、従来のデバッグは、カラー・データに関して処理や通信等を行う全てのソースコードに対して処理ログを出力するルーチンを追加し、カラー・データに関するログをモジュール毎に取得して、それらを解析するという形でなされていた。
【０００４】
しかしながら、上記従来の技術は以下の問題がある。
【０００５】
（１）開発中のソフトウェアを構成する各モジュールが個別にログを出力するため、ソフトウェア全体の処理について検証するためには、それぞれのログを統合して解析する必要がある。このため、ログの解析から問題の箇所を発見するまでに多大な工数を要する。
【０００６】
（２）ログを解析して意味のある情報を迅速に得ることができるようにするためには、適切なログ取得用ルーチンをソースコードの適切な箇所に配置する必要があるが、このようなルーチンを構成することは一般に困難である。
【０００７】
そこで、複数にモジュール分けされているソフトウェアにおいて、アプリケーションソフトウェアに相当するモジュールから別のモジュール内に存在する関数への呼び出しを仲介し、当該呼び出しに応じた別モジュールにおける処理のログを取得するログ取得用モジュールを提供することにより、各モジュールに処理ログを出力するルーチンを追加せずとも、処理ログを取得可能とする方法が提案されている（例えば特許文献１参照）。
【０００８】
（３）しかしながら、この場合も、ソフトウェアが大量のデータを扱う場合や、ログ取得用ルーチンの構成により、取得できるログが膨大になり、その解析作業が困難になる。特に、画像形成装置のソフトウェアのデバッグ作業においては、カラー・データのすべてをログに保存すると、ログ取得に多大な時間がかかる上にログ・ファイルのサイズが膨大になる。このため、ログ・ファイルを解析して有用な情報を得ることが困難になり、解析作業に多大な工数を要してしまう。
【特許文献１】特開２００４−３８３１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
以上のように、従来の構成においてはカラー・データを扱うソフトウェアの処理ログを解析することに多大な工数を要していた。
【００１０】
本発明は上記問題に鑑みなされたものであり、特にカラー・データを扱うソフトウェアの処理ログを容易に解析可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、例えば本発明による情報処理装置は以下の構成を備える。即ち、
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶する記憶制御手段と、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御手段によって記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段と
を備える。
【発明の効果】
【００１２】
本発明によれば、特にカラー・データを扱うソフトウェアの処理ログを容易に解析可能とする技術を提供することができる。
【発明を実施するための最良の形態】
【００１３】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００１４】
［第１実施形態］
＜システム構成＞
図１は、本実施形態に対応する情報処理装置の構成を例示的に示す図である。説明を簡略化するために、本実施形態では、情報処理システムが１台のＰＣ内部に構築されるものとする。ただし、本発明の特徴は、複数の情報処理装置を用いた分散環境としても有効である。
【００１５】
図１のように、本情報処理装置（ＰＣ）は、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ（以下、ＨＤＤと呼ぶ）６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵ１とチップセット２を繋ぐ信号線１１、チップセット２とＲＡＭ３を繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とＨＤＤ６を繋ぐ信号線１４、ハードディスク４とＣＤ−ＲＯＭドライブ７を繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８を繋ぐ信号線１６が搭載されている。
【００１６】
図１において、ＣＰＵ１は、ＨＤＤ６に格納されているアプリケーションプログラム、オペレーティングシステム（ＯＳ）や制御プログラム等を実行し、ＲＡＭ３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。
【００１７】
チップセット２は、情報処理装置内部のＣＰＵ１の周辺回路を搭載したＬＳＩ等のチップの集まりであり、メモリインタフェース等の制御回路が搭載されている。ＲＡＭ３は、各種データを一時記憶するためのメモリであり、ＣＰＵ１の主メモリ、ワークエリア等として機能する。
【００１８】
ＨＤＤ６は、所定の情報を記憶する大容量メモリである。ＨＤＤ６には、アプリケーションプログラム、ＯＳ、制御プログラム、関連プログラム等が格納される。ＣＤ−ＲＯＭドライブ７は、記録媒体へのアクセスを実現する装置であり、ＣＤ−ＲＯＭメディア（記録媒体）に記憶されたプログラム等を本情報処理装置にロードすることができる。ハードディスクコントローラ４は、ＨＤＤ６とＣＤ−ＲＯＭドライブ７の動作を制御する装置である。
【００１９】
ディスプレイ８は表示出力装置であり、入力されたコマンドや、それに対する情報処理装置の応答出力等を表示したりするものである。ディスプレイコントローラ５は周辺機器バス１３とディスプレイ８とを仲介してディスプレイ８の動作を制御する。周辺機器バス８は、情報処理装置内のデータの流れを司るものである。
【００２０】
尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。また、図１の構成は本発明を実施するための最低限の構成であり、他の装置が構成要素として付加されている構成でも構わない。
【００２１】
本実施形態では、メディアから本実施形態に係るプログラム及び関連データを直接ＲＡＭ３にロードして実行させる例を示すが、これ以外にも、本実施形態に係るプログラムを動作させる度に、既にプログラムがインストールされているＨＤＤ６からＲＡＭ３にロードするようにしてもよい。また、本実施形態に係るプログラムをＲＯＭ（不図示）に記録しておき、これをメモリマップの一部をなすように構成し、直接ＣＰＵ１で実行することも可能である。
【００２２】
＜ＩＡＴ Ｐａｔｃｈ＞
次に、本実施形態に係る情報処理装置を説明するために、図２を参照して、複数のモジュールから構成される評価対象のソフトウェアが、通常の状態でどのようにメモリ（ＲＡＭ３）にロードされるかを説明する。図２は、関数ロード時の通常のメモリ構成を模式的に示した図である。
【００２３】
通常、複数のモジュールから構成されるソフトウェアは、実行ファイル（以下、ＥＸＥと呼ぶ）２３とダイナミックリンクライブラリ（以下、ＤＬＬと呼ぶ）２７とに分かれてＲＡＭ３にロードされる。ここで、ＥＸＥ２３はソフトウェア全体の実行制御を行なうファイルであり、ＤＬＬ２７はモジュールとして存在しＥＸＥ２３の補完的な役割を担うファイルである。
【００２４】
この図では、１つのＥＸＥ２３がＡ．ＤＬＬ２５及びＢ．ＤＬＬ２６の２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ ＡＡ，Ｆｕｎｃ ＡＢ，Ｆｕｎｃ ＡＣ，Ｆｕｎｃ ＢＡ，Ｆｕｎｃ ＢＢ，Ｆｕｎｃ ＢＣの６個である。ＤＬＬ２７の関数の実体は、ＤＬＬ２７毎（２５，２６）にロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。
【００２５】
ＲＡＭ３において、ＥＸＥ３はコードセグメント２８とデータセグメント２９、そしてインポート関数アドレステーブル２２の各セグメントから構成される。コードセグメント２８は、ソフトウェアの演算命令のコード等が格納されている。データセグメント２９は、演算対象の変数や定数等のデータが格納されている。
【００２６】
インポート関数アドレステーブル２２は、ＤＬＬ２７として定義されている関数のアドレスを格納したものであり、ＥＸＥ２３はインポート関数アドレステーブル２２を参照して関数のアドレスを取得し、関数をロードする。インポート関数アドレステーブル２２は、関数の所属するＤＬＬ毎に関数のアドレス値を格納している。図２の例では、Ａ．ＤＬＬ２５に含まれる関数のアドレスを格納した領域２１と、Ｂ．ＤＬＬ２６に含まれる関数のアドレスを格納した領域２４とから構成され、それぞれの領域に関数がロードされたアドレスが格納されている（３０〜３５）。
【００２７】
例えば、ＥＸＥ２３のコードセグメント内にあるコードが関数Ｆｕｎｃ ＡＡ３６を呼び出す場合には、まずインポート関数アドレステーブル２２内に格納されたＦｕｎｃ ＡＡのアドレス３０を参照する。即ち、Ａ．ＤＬＬの一部として読み込まれたＦｕｎｃ ＡＡコード３６のアドレスを参照し、そのアドレスをコールすることによって、ＥＸＥ２３のコードはＡ．ＤＬＬ２５のＦｕｎｃ ＡＡ３６を呼び出すことができる。
【００２８】
次に、ログを取得するための方法であるＩＡＴ Ｐａｔｃｈ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて関数呼び出しを仲介した場合の、情報処理装置のメモリ構成の一例について、図３を参照して説明する。
【００２９】
ＩＡＴ Ｐａｔｃｈを用いたログの出力は、関数呼び出しを中継し必要な情報をログとして出力するモジュール（以下、ＡＰＩトレーサーと呼ぶ）をＲＡＭ３に格納し、ＥＸＥ５３のインポート関数アドレステーブル５２を書き換えることにより実現される。即ち、ＥＸＥ５３はＤＬＬ５７を直接コールするのではなく、ログを出力するＡＰＩトレーサーをコールして間接的にＤＬＬ５７をコールすることで、ログの出力が実現される。以下、その詳細を説明する。
【００３０】
ログを取得する前処理として、本実施形態に対応する情報処理装置は、後述する関数定義ファイルとトレースシナリオファイルを読み込み、ＡＰＩトレーサーをＣ．ＤＬＬとして生成する。そして、情報処理装置は、図３のように、ＲＡＭ３にＩＡＴ Ｐａｔｃｈ用のＤＬＬであるＣ．ＤＬＬ５８をロードするように制御する。ここで、Ｃ．ＤＬＬ５８内のＦｕｎｃ ＣＡＡ７３，Ｆｕｎｃ ＣＡＢ７４，Ｆｕｎｃ ＣＡＣ７５，Ｆｕｎｃ ＣＢＡ７６，Ｆｕｎｃ ＣＢＢ７７，Ｆｕｎｃ ＣＢＣ７８の各コードは、ログを記録すると共に、元々関数呼び出しを受けるべくメモリ（ＲＡＭ３）にロードされている、該当する関数であるＦｕｎｃ ＡＡ６７，Ｆｕｎｃ ＡＢ６８，Ｆｕｎｃ ＡＣ６９，Ｆｕｎｃ ＢＡ７０，Ｆｕｎｃ ＢＢ７１，Ｆｕｎｃ ＢＣ７２を呼び出すものである。
【００３１】
そして、本実施形態に対応する情報処理装置は、後述するトレースシナリオファイルに基づいて、ＥＸＥ５３のインポート関数アドレステーブル５２内に書かれた関数のアドレスを、Ｃ．ＤＬＬ５８内のログ取得コードである、Ｆｕｎｃ ＣＡＡ７３，Ｆｕｎｃ ＣＡＢ７４，Ｆｕｎｃ ＣＡＣ７５，Ｆｕｎｃ ＣＢＡ７６，Ｆｕｎｃ ＣＢＢ７７，Ｆｕｎｃ ＣＢＣ７８の各アドレスに書き換える（６１〜６６）。
【００３２】
次に、図３のように構成されたモジュールの構成において、ＩＡＴ Ｐａｔｃｈがどのように実現されるかについて、図４を参照して説明する。図４は、図３におけるＩＡＴ Ｐａｔｃｈの処理をあらわすタイミングチャートである。ここでは、ＥＸＥ２３がＡ．ＤＬＬ２１内のＦｕｎｃ ＡＡ３６を呼び出す際に、ＩＡＴ Ｐａｔｃｈによるログ取得コード（Ｃ．ＤＬＬ５８）がどのように動作するかの例をあらわしている。他の関数の場合についても同様の処理が行われることは言うまでもない。
【００３３】
ＥＸＥ９１がＦｕｎｃ ＡＡをコールすると（９４）、Ｃ．ＤＬＬ９２内にあるログ取得コードは、ＤＬＬ名／関数名、呼び出し時刻、呼び出し時のパラメータ、呼び出し時のポインタ・パラメータの指すメモリ内容、及びその他の情報を、それぞれ所定の記憶装置（ＲＡＭ３，ＨＤＤ６等）に保存する（９５）。その後、Ｃ．ＤＬＬ９２は、本来呼び出されるはずであった、Ａ．ＤＬＬ９３内のＦｕｎｃ ＡＡをコールする（９６）。
【００３４】
Ａ．ＤＬＬのＦｕｎｃ ＡＡ処理（９７）が終了し、Ｃ．ＤＬＬ９２に制御がリターンすると（９８）、Ｃ．ＤＬＬ９２はリターン時の時刻、戻り値、リターン時にポインタ・パラメータが指すメモリ内容、及びその他の情報を、それぞれ所定の記憶装置に保存する（９９）。その後、Ｃ．ＤＬＬ９２は保存したログ情報をファイルに書き込み（１００）、あたかもＡ．ＤＬＬ９３のＦｕｎｃ ＡＡが通常通りに終了したかのように、ＥＸＥ９１にリターンする（１０１）。
【００３５】
図５は、本実施形態に対応する情報処理装置において実行ファイルＥＸＥが実行される場合の動作を例示的に示した図である。通常は実行形式のＥＸＥ１１３が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサ１１４は、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）の関数定義を記述した関数定義ファイル１１１と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかを記述した設定シナリオファイル１１２に基づいて動作する。
【００３６】
＜ＶＴａｂｌｅ Ｐａｔｃｈ＞
図６は、本実施形態に対応する情報処理装置において、実行ファイルＥＸＥ１１８がＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂjｅｃｔ Ｍｏｄｅｌ：コンポーネント・オブジェクト・モデル）サーバでエクスポートされているインターフェースのインスタンスを作成する場合の、メモリ構成の一例を示す図である。
【００３７】
通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１，１２２）と、そのメソッド（１３０〜１３５）が作成され、それらは共にメモリ（ＲＡＭ３）上にロードされる。ここで、ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅは作成された各インターフェース毎に作られ（１１８，１２０）、作成要求を行ったＥＸＥ１１９に渡される。このｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅには各メソッドについて作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥ１１９はこれら情報を利用し、各インターフェースに対して呼び出しを行う。図６では、１つのＥＸＥ１１９がＩｎｔｅｒｆａｃｅ Ａ１２１及びＩｎｔｅｒｆａｃｅ Ｂ２２の２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ ＡＡ１３０， Ｍｅｔｈｏｄ ＡＢ１３１， Ｍｅｔｈｏｄ ＡＣ１３２， Ｍｅｔｈｏｄ ＢＡ１３３， Ｍｅｔｈｏｄ ＢＢ１３４， Ｍｅｔｈｏｄ ＢＣ１３５となっている。
【００３８】
ＥＸＥ１１９のコードが関数Ｍｅｔｈｏｄ ＡＡ１３０を呼び出す場合には、まずｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ ＡＡ１３０のアドレス１２４が読み込まれる。このアドレス１２４にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ Ａ１２１の一部として作成されたＭｅｔｈｏｄ ＡＡコード１３０のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥ１１９のコードはＩｎｔｅｒｆａｃｅ Ａ１２１のＭｅｔｈｏｄ ＡＡ１３０を呼び出すことができる。
【００３９】
図７は、本実施形態に対応する情報処理装置のメモリ構成をあらわす図であり、図６とは、ログ取得用のコードとしてＶＴａｂｌｅ Ｐａｔｃｈ（ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しを仲介しているという点で異なっている。
【００４０】
ログ取得が開始されると、ＲＡＭ３内にはＶＴａｂｌｅ Ｐａｔｃｈ用のＤＬＬ１４３がロードされる。このＤＬＬはｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（１３６，１３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ Ａ’Ａ１４５，Ｍｅｔｈｏｄ Ａ’Ｂ１４６，Ｍｅｔｈｏｄ Ａ’Ｃ１４７，Ｍｅｔｈｏｄ Ｂ’Ａ１４８，Ｍｅｔｈｏｄ Ｂ’Ｂ１４９，Ｍｅｔｈｏｄ Ｂ’Ｃ１５０のアドレスに書き換える。ＤＬＬ内のＭｅｔｈｏｄ Ａ’Ａ１５７，Ｍｅｔｈｏｄ Ａ’Ｂ１５８，Ｍｅｔｈｏｄ Ａ’Ｃ１５９，Ｍｅｔｈｏｄ Ｂ’Ａ１６０，Ｍｅｔｈｏｄ Ｂ’Ｂ１６１，Ｍｅｔｈｏｄ Ｂ’Ｃ１６２のコードは、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリ（ＲＡＭ３）にロードされていたＭｅｔｈｏｄ ＡＡ１５７，Ｍｅｔｈｏｄ ＡＢ１５８，Ｍｅｔｈｏｄ ＡＣ１５９，Ｍｅｔｈｏｄ ＢＡ１６０，Ｍｅｔｈｏｄ ＢＢ１６１，Ｍｅｔｈｏｄ ＢＣ１６２を呼び出す。
【００４１】
図８は、図７におけるＶＴａｂｌｅ Ｐａｔｃｈの処理をあらわすタイミングチャートである。説明を簡略化するために、この図ではＥＸＥ１６３がＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄ ＡＡを呼び出す際に、ＶＴａｂｌｅ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。他のメソッドの場合についても同様の処理が行われることはいうまでもない。
【００４２】
ＥＸＥ１６３がＭｅｔｈｏｄ ＡＡをコールすると（１６６）、ＤＬＬ１６４内にあるログ取得コードは、モジュール名／インターフェース名／メソッド名、呼び出し時刻、呼び出し時のパラメータ、呼び出し時のポインタパラメータの指すメモリ内容、及びその他の情報をメモリ（ＲＡＭ３）に保存する（１６７）。その後ＤＬＬ１６４は本来呼び出されるはずであった、ＣＯＭサーバ１６５内のＭｅｔｈｏｄ ＡＡをコールする（１６８）。ＣＯＭサーバのＭｅｔｈｏｄ ＡＡ処理（１６９）が終了し、ＤＬＬ１６４に制御がリターンすると（１７０）、ＤＬＬ１６４はリターン時の時刻をメモリに保存し、戻り値をメモリ（ＲＡＭ３）に保存し、リターン時にポインタパラメータが指すメモリ内容を、メモリ（ＲＡＭ３）に保存する（１７１）。その後、ＤＬＬ１６４は保存したログ情報をファイルに書き込み（１７２）、あたかもＣＯＭサーバのＭｅｔｈｏｄ ＡＡが通常通りに終了したかのように、ＥＸＥ１６３にリターンする（１７３）。
【００４３】
図９は、本実施形態に対応する情報処理装置において実行形式ファイルＥＸＥが実行される場合の動作の一例を示す図である。通常は実行形式のＥＸＥ１７６が、ＣＯＭサーバ−１（１７９）やＣＯＭサーバ−２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ−１（１７９）やＣＯＭサーバ−２の関数定義を記述したファイル（関数定義ファイル）１７４と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅを書き換えてログを取得するかを記述した設定シナリオファイル１７５に基づいて動作する。
【００４４】
図１０は、本実施形態に対応する情報処理装置において使用する、関数定義ファイルの一例を示したものである。この例では、一般的に広く用いられているＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ：インタフェース定義言語）により、関数の定義が記述されている。本実施形態に対応する情報処理装置においては、このＩＤＬをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、関数定義ファイルは付加バイナリ情報（各ログ情報）を取得するための定義を提供することを特徴とするものであり、関数定義は必ずしもＩＤＬによって記述されている必要はない。例えば、通常のテキストファイルを用いることも可能であり、ＸＭＬなどのマークアップ言語を用いることも可能である。
【００４５】
＜出力データのカラー判別＞
次に、本実施形態に対応する情報処理装置において、プリンタ出力データのカラー判別を行う構成について説明する。ここでは、説明の簡略化のため、画像形成装置に対してテキスト描画コマンドを送出する場合について例示的に説明するが、以下の構成はいかなるグラフィック・オブジェクトについても適用可能である。また、以下ではプリンタ装置に対して出力される描画コマンドについてログを取得する構成について例示的に説明を行うが、出力対象はどのような装置でもよい。
【００４６】
図１１は、本実施形態に対応する情報処理装置において、プリンタ出力データのカラー判別を行なうための、関数定義ファイルの例である。本実施形態では、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）にＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌというダイナミックリンクライブラリファイルが用意されており、そのライブラリ内に、テキストの描画を行なう関数ＴｅｘｔＯｕｔ２０２、テキストの色を設定する関数ＳｅｔＴｅｘｔＣｏｌｏｒ２０４、設定されているテキストの色を取得する関数ＧｅｔＴｅｘｔＣｏｌｏｒ２０３が用意されているものとする。尚、関数名はこれらに限定されるものではない。また、テキスト以外のグラフィック・オブジェクトを出力する場合は、関数名は当然に異なったものになる。
【００４７】
関数ＴｅｘｔＯｕｔ２０２は、デバイスコンテキストのハンドル、描画開始位置のｘ，ｙ座標、描画する文字列、描画する文字列の数をパラメータ（引数）として入力し、入力値に基づいて所定の対象にテキストの描画コマンドを発行するように動作する。そして、動作が正しく終了したか否かを示す２値情報を戻り値として返す。
【００４８】
ただし、デバイスコンテキストは、オペレーティングシステムによって仮想化された「面」に対するハンドルであり、描画対象装置を指定するものである。本実施形態において、デバイスコンテキストはディスプレイ８向けのものとプリンタ（不図示）向けのものが用意されている。例えば、プリンタ向けを示すデバイスコンテキスト（ＴｅｘｔＯｕｔ関数の第一パラメータ）のハンドルを選択して、その他の必要なパラメータを入力することにより、プリンタ装置に対してテキストの描画コマンドを発行することができる。なお、デバイスコンテキストは、ｔｙｐｅｄｅｆによって定義している（２００）。
【００４９】
関数ＳｅｔＴｅｘｔＣｏｌｏｒ２０４は、ＴｅｘｔＯｕｔ２０２をコールすることによってテキストを描画する際に、テキストの色を設定する関数であり、後述するようにＳｅｔＴｅｘｔＣｏｌｏｒ２０４をコールする前にコールして用いる。ＳｅｔＴｅｘｔＣｏｌｏｒ２０４は、デバイスコンテキストのハンドルと、設定するテキストの色をパラメータとして入力し、パラメータに指定された色情報を設定し、ＳｅｔＴｅｘｔＣｏｌｏｒ２０４をコールする前に設定されていた色情報を戻り値として返す。
【００５０】
関数ＧｅｔＴｅｘｔＣｏｌｏｒ２０３は、設定されているテキストの色情報を取得する関数である。ＧｅｔＴｅｘｔＣｏｌｏｒ２０３は、デバイスコンテキストのハンドルをパラメータとして入力し、入力されたハンドルに対応するデバイスコンテキストに設定されている色情報を取得し、その値を戻り値として返す。
【００５１】
上記の関数をコールして特定の色の文字をプリンタに出力する際には、以下の処理を行う。即ち、
（１）ＳｅｔＴｅｘｔＣｏｌｏｒ関数２０４でテキスト色の設定を行ない、
（２）ＴｅｘｔＯｕｔ関数２０２でテキストの描画指示を行なう。
【００５２】
このような処理手順に鑑み、プリンタ装置に対応するデバイスコンテキストに対してアプリケーション・ソフトウェアがテキスト描画コマンドを発行する際に、そのテキストの色に関するログを、ＩＡＴ Ｐａｔｃｈを用いて取得する処理について、図１２を参照して説明する。図１２は、このような処理の流れを示すフローチャートである。尚、以下の処理は上述したＶＴａｂｌｅ Ｐａｔｃｈを用いて構成してもよい。
【００５３】
アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。そして、ステップＳ２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。尚、先に述べたように、パラメータには文字列の内容等の画像の形状に関する情報や、描画位置等の画像の位置に関する情報が含まれている。このことは画像がテキストに関するものに限られず、他のグラフィック・オブジェクトに適用する場合も同様である。
【００５４】
次に、呼び出された関数の種類に応じて別個の処理を行う。即ち、ステップＳ３において、呼び出された関数がテキストカラー設定関数（ＳｅｔＴｅｘｔＣｏｌｏｒ）であるか否かを判定し、テキストカラー設定関数であれば（ステップＳ３においてＹＥＳ）ステップＳ４へ進む。ステップＳ４においては、関数呼び出しのパラメータ（引数）を解析し、設定する色のパラメータを取得する。そして、取得した色のパラメータをＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値に変換する。ステップＳ５において、変換した各値をＲＡＭ３に一時的に記憶制御し、ステップＳ８へ進む。
【００５５】
ステップＳ８においては、ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌにアクセスし、アプリケーション・ソフトウェアが呼び出し要求を行った関数を実際に呼び出す。この時、関数のパラメータをアプリケーション・ソフトウェアが送出した値に設定する。関数からリターンが発生すると、ステップＳ９において、リターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をログとしてログ書き込みファイルに追加する。そして、ステップＳ１０へ進む。
【００５６】
ステップＳ１０においては、アプリケーション・ソフトウェア、或いは、ユーザから終了の命令がなされたか否かを判定する。終了の命令がなされた場合（ステップＳ１０においてＹＥＳ）は処理を終了し、なされていない場合（ステップＳ１０でＮＯ）はステップＳ１へ戻り処理を継続する。
【００５７】
アプリケーション・ソフトウェアから呼び出された関数がテキストカラー設定関数でない場合は（ステップＳ３においてＮＯ）ステップＳ６へ進み、呼び出された関数がテキスト出力関数（ＴｅｘｔＯｕｔ）であるか否かを判定する。テキスト出力関数であれば（ステップＳ６においてＹＥＳ）ステップＳ７へ進み、テキスト出力関数でなければ（ステップＳ６においてＮＯ）ステップＳ８へ進む。ステップ８以降の処理は先に述べたものと同様である。
【００５８】
ステップＳ７においては、ステップＳ５で一時的に記憶制御した、Ｒｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値から構成される色情報をＲＡＭ３から読み出し、ログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。ＲＡＭ３に色情報が格納されていない場合は、エラー情報をログとしてログ書き込みファイルに追加する。そしてステップＳ８へ進む。ステップＳ８以降の処理は先に述べたものと同様である。
【００５９】
次に、上記の処理とＩＡＴ−Ｐａｔｃｈ法の各構成要素との対応について、図２２を参照して説明する。図２２は対応するタイミングチャートである。
【００６０】
図２２において、３０１はアプリケーション・ソフトウェアの実行ファイルＥＸＥ、３０２はＩＡＴ Ｐａｔｃｈによるログ取得コード（ＩＡＴ Ｐａｔｃｈコードと呼ぶ）、３０３はＯＳＧｒａｐｈｉｃＫｅｒｎｅｌをそれぞれ示している。
【００６１】
ＥＸＥ３０１が関数呼び出しを行う場合は、先に述べたように、ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３に対して行うのではなく、ＩＡＴ Ｐａｔｃｈコード３０２に対して行う（３０４）。ＩＡＴ Ｐａｔｃｈコード３０２は、関数呼び出しを受け取ると、関数名や呼び出し時刻等の情報を、ログとしてＨＤＤ６のログ書き込みファイルに追加する（３０５）。この処理は、図１２のステップＳ１及びＳ２の処理に対応する。
【００６２】
そして、ＩＡＴ Ｐａｔｃｈコード３０２は、呼び出し要求がなされた関数の種類を判定し、関数がＳｅｔＴｅｘｔＣｏｌｏｒの場合と、ＴｅｘｔＯｕｔの場合は、それぞれ所定の処理を行う。関数がＳｅｔＴｅｘｔＣｏｌｏｒの場合は図１２のステップＳ４及びＳ５の処理を行い（３０６）、ＴｅｘｔＯｕｔの場合は図１２のステップＳ７の処理を行う（３０７）。
【００６３】
次に、呼び出し要求がなされたＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３の関数にアクセスし（３０８）、関数に所定の処理を実行させる（３０９）。これらの処理は図１２のステップＳ８に対応する。
【００６４】
ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３の関数からリターンが発生すると（３１０）、戻り値や時刻等の情報をログとしてログ書き込みファイルに追加する（３１１、３１２）。これらの処理は図１２のステップＳ９に対応する。そして、ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３の関数からリターンをＥＸＥ３０１へ返す。
【００６５】
次に、以上のような処理の結果得られるログについて図１３を参照して説明する。図１３は、本実施形態に対応する情報処理装置において、図１１の定義及び図１２、２２の処理により取得されるログデータを例示的に示す図である。図１３において、２０５、２０６は、関数ＴｅｘｔＯｕｔが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、実際にどのような色情報に基づいて出力要求がなされたかを、時系列順に容易に把握することができる。また、色情報は他の画像情報と関連づけた形で表示されるため、例えば、プリンタの出力結果とログとの比較が容易である。
【００６６】
以上のように、ＩＡＴ Ｐａｔｃｈを用いてカラー出力を検出することにより、プリンタ装置等へのカラー出力において発生した障害に対して、アプリケーション・ソフトウェアがオペレーティングシステムに対してどのような指示を行なった結果その障害が発生したのかを、明示的に知ることができる。
【００６７】
また、ＩＡＴ Ｐａｔｃｈを用いたログ取得において、テキストカラー設定関数及びテキスト出力関数への呼び出しを判定しログを生成することで、カラー関連の処理に関するログの解析を容易にしている。更に、色情報のログを画像情報と対応づけて生成することで、例えば、プリンタの出力結果と、ログの中のグラフィック・オブジェクトの位置や色情報等とを比較してバグを検知することを可能にしており、ログを解析する際にバグの原因を容易に特定することができる。これにより、カラー関連の障害の原因を特定する作業を迅速に行うこと可能である。
【００６８】
［第２実施形態］
第１実施形態においては、ＩＡＴ Ｐａｔｃｈの手法に加えて、色情報の設定関数とグラフィック・オブジェクトの出力を指示する関数の呼び出しについて選択的にログを生成する構成について述べた。本実施形態においては、設定されている色情報を取得するテキストカラー取得関数（ＧｅｔＴｅｘｔＣｏｌｏｒ）を用いて色情報を取得する構成について説明する。尚、システム構成やＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ等は第１実施形態と同様である。
【００６９】
図１４は、本実施形態に対応する情報処理装置に於いて、プリンタ出力データのカラー判別を行なう処理の流れを示すフローチャートである。アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ２１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。次に、ステップＳ２２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。そして、ステップＳ２３へ進む。
【００７０】
本実施形態においては、ステップＳ２３〜ステップＳ２６の処理が第１実施形態と異なっている。即ち、ステップＳ２３において呼び出された関数がテキスト出力関数（ＴｅｘｔＯｕｔ）であるか否かを判定し、テキスト出力関数であれば（ステップＳ２３においてＹＥＳ）ステップＳ２４へ進み、テキスト出力関数でなければ（ステップＳ２３においてＮＯ）ステップＳ２７へ進む。ステップＳ２４においては、ＩＡＴ Ｐａｔｃｈコードから直接ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌのテキストカラー取得関数（ＧｅｔＴｅｘｔＣｏｌｏｒ）を呼び出し、設定されている色情報を取得する。次に、ステップＳ２５において、取得した色情報をＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値に変換する。そして、ステップＳ２６において、ステップＳ２５で得られたＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値をログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。ステップＳ２７以降の処理は図１２のステップＳ８以降の処理と同様であるため、説明を省略する。
【００７１】
次に、以上のような処理の結果得られるログについて図１５を参照して説明する。図１５は、本実施形態に対応する情報処理装置において、図１４の処理により取得されるログデータを例示的に示す図である。図１５において、２０７、２０８、２０９は、関数ＴｅｘｔＯｕｔが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、第１実施形態と同様に、実際にどのような色情報に基づいて出力要求がなされたかを、時系列順に容易に把握することができる。
【００７２】
以上のように、本実施形態においては、ＩＡＴ Ｐａｔｃｈコードからテキストカラー取得関数を呼び出す構成を採っていることにより、テキストカラー設定関数のログを取得せずに、テキスト出力関数時にテキストの出力に用いられた色データをログとして出力することができる。これにより、ログを生成する際にかかる時間やログを取得する際に必要なメモリを節約しつつ、第１実施形態と同様の効果を得ることができる。
【００７３】
［第３実施形態］
第１、第２実施形態においては、カラー出力能力を持つ関数の全ての呼び出しについてログを出力する構成について述べたが、目的・用途によっては、そのような関数呼び出しについての全てのログは必要ない場合も考えられる。例えば、グレイスケール（無彩色）の画像出力とカラー（有彩色）の画像出力とを実行可能なシステムにおいて、有彩色の画像出力のみについてログを取得し、障害原因を特定したいという場合が考えられる。そこで、本実施形態においては、有彩色の画像出力のみについてログを取得する構成について例示的に説明する。尚、以下の構成は、例えば、無彩色の画像出力のみについてログを取得する場合にも適用可能である。尚、システム構成やＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ等は第１実施形態と同様である。
【００７４】
図１６は、本実施形態に対応する情報処理装置に於いて、プリンタ出力データのカラー判別を行なう処理の流れを示すフローチャートである。アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ４１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。次に、ステップＳ４２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。そして、ステップＳ４３へ進む。
【００７５】
本実施形態においては、ステップＳ４３〜ステップＳ４７の処理が第１実施形態と異なる。即ち、ステップＳ４３において呼び出された関数がテキスト出力関数（ＴｅｘｔＯｕｔ）であるか否かを判定し、テキスト出力関数であれば（ステップＳ４３においてＹＥＳ）ステップＳ４４へ進み、テキスト出力関数でなければ（ステップＳ４３においてＮＯ）ステップＳ４８へ進む。ステップＳ４４においては、ＩＡＴ Ｐａｔｃｈコードから直接ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌのテキストカラー取得関数（ＧｅｔＴｅｘｔＣｏｌｏｒ）を呼び出し、設定されている色情報を取得する。次に、ステップＳ４５において、取得した色情報をＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値に変換し、ステップＳ４６へ進む。
【００７６】
本実施形態においては、ステップＳ４６、Ｓ４７の処理が第２実施形態と異なる。即ち、ステップＳ４６において、ステップＳ４４で取得した色情報が有彩色であるか否かを判定し、有彩色の場合（ステップＳ４６でＮＯ）ステップＳ４７へ進み、ステップＳ４５で得られたＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値をログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。有彩色でない場合（ステップＳ４６でＹＥＳ）は、ステップＳ４８へ進む。尚、ステップＳ４６における有彩色か否かの判定は、ステップＳ４５で取得したＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値について、Ｒｅｄ値＝Ｇｒｅｅｎ値＝Ｂｌｕｅ値が成立するか否か（成立する場合は無彩色、成立しない場合は有彩色）により行う。ステップＳ４８以降の処理は図１２のステップＳ８以降の処理と同様であるため、説明を省略する。
【００７７】
次に、以上のような処理の結果得られるログについて図１７を参照して説明する。図１７は、本実施形態に対応する情報処理装置において、図１６の処理により取得されるログデータを例示的に示す図である。図１７において、２１０、２１１は、関数ＴｅｘｔＯｕｔが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、有彩色の場合のログのみが記録されている。実際にどのような色情報に基づいて出力要求がなされたかを時系列順に容易に把握することができる点は、第１、第２実施形態と同様である。
【００７８】
以上のように、本実施形態においては、ＩＡＴ Ｐａｔｃｈコードで有彩色か無彩色かの判定を実装する構成を採っていることにより、無彩色データのログを取得せずに、有彩色データのみをログとして出力することができる。これにより、ログを生成する際にかかる時間を削減しつつ、必要な情報のみが記載されたログを得ることができ、障害発見の作業能率を高めることができる。
【００７９】
［第４実施形態］
第１〜３実施形態においては、説明を簡略するために、テキスト出力に関するログを取得する構成について例示的に説明したが、上記の構成はどのようなグラフィック・オブジェクトについても適用可能である。本実施形態では、テキストとは異なるグラフィック・オブジェクトの一例として、「ペン」オブジェクトの出力についてログを取得する構成について述べる。ペンオブジェクトとは、オペレーティングシステムに仮想的に備えられたグラフィック・オブジェクトであり、デバイスコンテキストに対して線の描画を指示する際に用いられる。
【００８０】
図１８は、本実施形態に対応する情報処理装置に於いて、プリンタ出力データのカラー判別を行なうための、関数定義ファイルの例である。本実施形態では、オペレーティングシステムにＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌというダイナミックリンクライブラリファイルが用意されており、そのライブラリ内には、ＣｒｅａｔｅＰｅｎ２２３、ＳｅｌｅｃｔＰｅｎ２２４、ＳｅｔＳｔａｒｔＰｏｉｎｔ２２５、ＬｉｎｅＴｏ２２６、ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ２２７、ＤｅｌｅｔｅＰｅｎ２２８を含む関数が用意されているものとする。
【００８１】
関数ＣｒｅａｔｅＰｅｎ２２３はペンオブジェクトを生成する関数である。ＣｒｅａｔｅＰｅｎ２２３は、パラメータ（引数）としてペンオブジェクトの色情報を受け取り、指定された色のペンオブジェクトを生成してそのオブジェクトをハンドルを戻り値として返す。関数ＳｅｌｅｃｔＰｅｎ２２４はデバイスコンテキストにペンオブジェクトを関連づける関数である。ＳｅｌｅｃｔＰｅｎ２２４は、パラメータとしてデバイスコンテキストのハンドルとペンオブジェクトのハンドルを受け取り、指定されたデバイスコンテキストにペンオブジェクトを関連づけ、戻り値として関連づけが成功したか否かを示すブール値を返す。
【００８２】
関数ＳｅｔＳｔａｒｔＰｏｉｎｔ２２５及びＬｉｎｅＴｏ２２６はペンオブジェクトを用いた描画を行なうための関数である。ＳｅｔＳｔａｒｔＰｏｉｎｔ２２５は、パラメータとしてデバイスコンテキストのハンドル、描画開始位置の座標（ｘ，ｙ座標）を受け取り、線の始点の座標を設定する。ＬｉｎｅＴｏ２２６は、パラメータとしてデバイスコンテキストのハンドル、描画終了位置の座標（ｘ，ｙ座標）を受け取り、線の終点の座標を設定し、座標が設定された始点と終点を結ぶ線を出力するように指示する。なお、この時出力される線の色はＣｒｅａｔｅＰｅｎ２２３のパラメータで設定された値である。
【００８３】
関数ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ２２７はペンオブジェクトに設定されている色情報を取得する関数である。ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ２２７は、パラメータとしてデバイスコンテキストのハンドルとペンオブジェクトの色情報へのポインタを入力し、ペンオブジェクトの色を取得する。そして、取得した色情報にアクセスできるように色情報へのポインタを設定して、戻り値として色情報の取得が成功したか否かを示すブール値を返す。
【００８４】
関数ＤｅｌｅｔｅＰｅｎ２２８は、ペンオブジェクトを削除する関数である。ＤｅｌｅｔｅＰｅｎ２２８は、パラメータとしてペンオブジェクトへのハンドルを入力し、ハンドルで指定されたペンオブジェクトをメモリから削除する。
【００８５】
ある色の線をプリンタに出力する際には、以下の処理を行う。即ち、
（１）ＣｒｅａｔｅＰｅｎ関数で、特定の色を持つペン・オブジェクトを生成する
（２）プリンタ装置を仮想化したデバイスコンテキストに対して、ＳｅｌｅｃｔＰｅｎ関数で、そのペン・オブジェクトを関連付ける
（３）ＳｅｔＳｔａｒｔＰｏｉｎｔ関数で、描画の開始座標を設定する
（４）ＬｉｎｅＴｏ関数で、描画の終了座標、すなわちデバイスコンテキストに関連付けられたペン・オブジェクトでどの座標まで線を書けばよいかを指示し、描画指令を行う
（５）ＤｅｌｅｔｅＰｅｎ関数でペン・オブジェクトを削除する
このような処理手順に鑑み、プリンタ装置に対応するデバイスコンテキストに対してアプリケーション・ソフトウェアがペンオブジェクトの描画指令を発行する際に、そのペンオブジェクトの色に関するログを、ＩＡＴ Ｐａｔｃｈを用いて取得する処理について、図１９を参照して説明する。図１９は、このような処理の流れを示すフローチャートである。尚、以下の処理は上述したＶＴａｂｌｅ Ｐａｔｃｈを用いて構成してもよい。また、この例では第３実施形態と同様に有彩色の出力指令のログを取得する場合について述べるものとする。
【００８６】
アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ６１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。そして、ステップＳ６２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。尚、先に述べたように、パラメータには文字列の内容等の画像の形状に関する情報や、描画位置等の画像の位置に関する情報が含まれている。このことは画像がペン・オブジェクトに関するものに限られず、他のグラフィック・オブジェクトに適用する場合も同様である。
【００８７】
ステップＳ６３においては、呼び出された関数がペン描画関数（ＬｉｎｅＴｏ）であるか否かを判定し、ペン描画関数の場合（ステップＳ６３でＹＥＳ）ステップＳ６４へ進み、ペン描画関数ではない場合（ステップＳ６３でＮＯ）ステップＳ６８へ進む。
【００８８】
ステップＳ６４においては、ペン状態取得関数（ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ）をＩＡＴ Ｐａｔｃｈコードから内部的に呼び出し、ペンオブジェクトに設定された色情報を取得する。次に、ステップＳ６５において、取得した色情報をＲｅｄ値，Ｇｒｅｅｎ値，Ｂｌｕｅ値に変換する。
【００８９】
次に、ステップＳ６６において、取得した色情報が有彩色であるか否かを判定し、有彩色の場合（ステップＳ６６でＮＯ）ステップＳ６７へ進み、ステップＳ６５で得られたＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値をログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。有彩色でない場合（ステップＳ６６でＹＥＳ）は、ステップＳ６８へ進む。尚、ステップＳ６６における有彩色か否かの判定は、ステップＳ６５で取得したＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値について、Ｒｅｄ値＝Ｇｒｅｅｎ値＝Ｂｌｕｅ値が成立するか否か（成立する場合は無彩色、成立しない場合は有彩色）により行う。ステップＳ６８以降の処理は図１２のステップＳ８以降の処理と同様であるため、説明を省略する。
【００９０】
次に、以上のような処理の結果得られるログについて図２０を参照して説明する。図２０は、本実施形態に対応する情報処理装置において、図１９の処理により取得されるログデータを例示的に示す図である。図２０において、２３０、２３１は、関数ＬｉｎｅＴｏが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、有彩色の場合のログのみが記録されている。実際にどのような色情報に基づいて出力要求がなされたかを時系列順に容易に把握することができる点は、第１〜３実施形態と同様である。
【００９１】
以上のように、本実施形態においては、グラフィック・オブジェクトの出力指示のタイミングで色情報を取得してログに記録することにより、グラフィック・オブジェクトの一つであるペンオブジェクトについてもログを得ることができる。
【００９２】
尚、本実施形態はペン・オブジェクトを例に説明したが、どのようなグラフィック・オブジェクトに対しても有効である。例えば、オペレーティングシステムが提供するグラフィック・オブジェクトとしてブラシ・オブジェクト、ビットマップ・オブジェクトが用意されている場合、すべてのグラフィック・オブジェクトに対して同様の処理を行なうことにより、アプリケーション・ソフトウェアがオペレーティングシステムに対して、プリンタ装置にどのような色の描画を行なうよう指示したかを、ＩＡＴ Ｐａｔｃｈ／ＶＴａｂｌｅ Ｐａｔｃｈの技術を用いて、すべてログ・ファイルに取得することができる。これによって、カラーに関係する障害に関して迅速な原因の特定が可能となる。
【００９３】
［第５実施形態］
第１〜４実施形態においては、ＩＡＴ Ｐａｔｃｈ／ＶＴａｂｌｅ Ｐａｔｃｈを用いてログを出力する構成について述べたが、本実施形態では出力されたログを解析しやすいように、カラーフィールドを持つレコードを明示的に他のレコードと分けて表示するユーザインタフェース（ＵＩ）について述べる。
【００９４】
図２１は、本実施形態に対応する情報処理装置における、ログ表示ユーザ・インタフェースの一例である。このユーザインタフェースにおいては、カラー情報フィールドを持つレコードに関して強調表示する。図２１の例では、２３０のように印を付して表示する。但し、レコードとは１回の関数呼び出しに伴って出力されるログ情報である。これにより、カラー情報フィールドを持つレコードを迅速に特定することが可能である。尚、印ではなく、例えば、カラー情報フィールドを持つレコードに対して、テキストやテキスト・バックグラウンドの色を、カラー情報フィールドを持たないレコードとは別の色に設定するようにしてもよい。また、カラー情報フィールドの有無だけではなく、例えば、ある特定の関数や、モジュール、或いは、ある条件を満たす時刻におけるレコードについて強調表示するようにしてもよい。
【００９５】
また、表題欄２３０をボタンとして提供し、ボタンを押下した際に、印を有するフィールドと有しないフィールドとをソートする機能を提供する。更に、２３１，２３２，２３３，２３４のように、モジュール名や、関数／メソッド名、呼び出された時刻、Ｒｅｔｕｒｎした時刻等を表示し、更に、２３１，２３２，２３３，２３４をボタンとして提供して、ボタンが押下されたときに項目の値に応じてソートする機能を提供する。
【００９６】
また、不図示の検索メニューや検索ショートカットキーを提供し、所望のキーワードに合致するログ項目を検索する機能を提供する。
【００９７】
以上のようなログを表示する構成を採ることで、障害発見の作業能率を高めることができる。
【００９８】
尚、ログ書き込みファイルからレコードを生成する処理について図２３のフローチャートを参照して説明する。
【００９９】
まず、ステップＳ８１において、ログ書き込みファイルを読み込みメモリ（ＲＡＭ３等）に一時的に記憶制御する。次に、ステップＳ８２において、メモリに記憶されたログ書き込みファイルの先頭から参照して、まだ参照していない関数呼び出しに対応するログが存在するか否かを判定する。存在する場合（ステップＳ８２でＹＥＳ）はステップＳ８３へ進み、存在しない場合（ステップＳ８２でＮＯ）は処理を終了する。
【０１００】
ステップＳ８３においては、まだ参照していない関数呼び出しに対応するログで、先頭に近いものを参照する。そしてステップＳ８４において参照したログ情報を取得し、ステップＳ８５において取得したログ情報をレコードとして出力する。ステップＳ８２からステップＳ８５までの処理を繰り返し実行することで、ログ書き込みファイルから全てのレコードを生成することができる。
【０１０１】
尚、各レコードはそれぞれ別個のファイルとして出力されるようにしてもよいし、或いは、一つのファイルにまとめて出力されるようにしてもよい。本実施形態に対応する情報処理装置は、このようにして生成されるレコードに基づいて上述したようなユーザインタフェースを提供する。
【０１０２】
［他の実施形態］
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１０３】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１０４】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【０１０５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１０６】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０１０７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１０８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。 また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１０９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１１０】
【図１】本実施形態に対応する情報処理装置の構成の一例を示す図である。
【図２】本実施形態に対応する情報処理装置のメモリに、複数のモジュールに分割されたソフトウェアがロードされた様子を例示的に示す図である。
【図３】本実施形態に対応する情報処理装置において、ＩＡＴ Ｐａｔｃｈを使用したときのメモリ構成を模式的に示した図である。
【図４】本実施形態に対応する情報処理装置において、ＩＡＴ Ｐａｔｃｈを実行した場合のタイミングチャートである。
【図５】本実施形態に対応する情報処理装置において実行形式ファイルＥＸＥが実行される場合の動作の一例を示す図である。
【図６】本実施形態に対応する情報処理装置において、実行ファイルＥＸＥがＣＯＭサーバでエクスポートされているインターフェースのインスタンスを作成する場合の、メモリ構成の一例を示す図である。
【図７】本実施形態に対応する情報処理装置のメモリ構成を例示的に示す図である。
【図８】本実施形態に対応する情報処理装置において、ＶＴａｂｌｅ Ｐａｔｃｈの処理を実行した場合のタイミングチャートの一例を示す図である。
【図９】本実施形態に対応する情報処理装置において実行形式ファイルＥＸＥが実行される場合の動作の一例を示す図である。
【図１０】本実施形態で用いる関数定義ファイルの内容を例示的に示した図である。
【図１１】本実施形態で用いるテキスト描画コマンドを発行する関数の、関数定義ファイルの内容を例示的に示した図である。
【図１２】第１実施形態において、テキストの色に関するログを取得する処理の流れを示すフローチャートである。
【図１３】第１実施形態におけるログデータを例示的に示した図である。
【図１４】第２実施形態において、テキストの色に関するログを取得する処理の流れを示すフローチャートである。
【図１５】第２実施形態におけるログデータを例示的に示した図である。
【図１６】第３実施形態において、テキストの色に関するログを取得する処理の流れを示すフローチャートである。
【図１７】第３実施形態におけるログデータを例示的に示した図である。
【図１８】第４実施形態において用いる関数定義ファイルの例をあらわす図である。
【図１９】第４実施形態において、ペンオブジェクトの色に関するログを取得する処理の流れを示すフローチャートである。
【図２０】第４実施形態におけるログデータを例示的に示した図である。
【図２１】第５実施形態におけるログデータを表示するユーザインタフェースを例示的に示した図である。
【図２２】本実施形態に対応する情報処理装置において、テキスト描画コマンドを発行する際にテキストの色に関するログを取得する場合のタイミングチャートである。
【図２３】第５実施形態におけるログ書き込みファイルからレコードを生成する処理を示すフローチャートである。
【技術分野】
【０００１】
本発明は、ソフトウェアのデバッグを行う技術に関する。
【背景技術】
【０００２】
従来より、再現率の低いソフトウェアの問題を解決するために、開発中のソフトウェアのソースコードに処理ログを出力するルーチンを追加し、ソフトウェアの実行時に出力される処理ログを解析して、ソフトウェアのデバッグを行う方法が知られている。
【０００３】
このような方法によるデバッグは、プリンタ装置等の画像形成装置の動作を制御するソフトウェアの開発工程に対しても適用されている。例えば、特定のカラーを意図して出力したデータに基づいて印刷処理を行ったところ、開発したソフトウェアのバグが原因で、その出力結果が想定したものと異なっているという障害が発生した状況を考える。この場合、従来のデバッグは、カラー・データに関して処理や通信等を行う全てのソースコードに対して処理ログを出力するルーチンを追加し、カラー・データに関するログをモジュール毎に取得して、それらを解析するという形でなされていた。
【０００４】
しかしながら、上記従来の技術は以下の問題がある。
【０００５】
（１）開発中のソフトウェアを構成する各モジュールが個別にログを出力するため、ソフトウェア全体の処理について検証するためには、それぞれのログを統合して解析する必要がある。このため、ログの解析から問題の箇所を発見するまでに多大な工数を要する。
【０００６】
（２）ログを解析して意味のある情報を迅速に得ることができるようにするためには、適切なログ取得用ルーチンをソースコードの適切な箇所に配置する必要があるが、このようなルーチンを構成することは一般に困難である。
【０００７】
そこで、複数にモジュール分けされているソフトウェアにおいて、アプリケーションソフトウェアに相当するモジュールから別のモジュール内に存在する関数への呼び出しを仲介し、当該呼び出しに応じた別モジュールにおける処理のログを取得するログ取得用モジュールを提供することにより、各モジュールに処理ログを出力するルーチンを追加せずとも、処理ログを取得可能とする方法が提案されている（例えば特許文献１参照）。
【０００８】
（３）しかしながら、この場合も、ソフトウェアが大量のデータを扱う場合や、ログ取得用ルーチンの構成により、取得できるログが膨大になり、その解析作業が困難になる。特に、画像形成装置のソフトウェアのデバッグ作業においては、カラー・データのすべてをログに保存すると、ログ取得に多大な時間がかかる上にログ・ファイルのサイズが膨大になる。このため、ログ・ファイルを解析して有用な情報を得ることが困難になり、解析作業に多大な工数を要してしまう。
【特許文献１】特開２００４−３８３１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
以上のように、従来の構成においてはカラー・データを扱うソフトウェアの処理ログを解析することに多大な工数を要していた。
【００１０】
本発明は上記問題に鑑みなされたものであり、特にカラー・データを扱うソフトウェアの処理ログを容易に解析可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１１】
上記目的を達成するため、例えば本発明による情報処理装置は以下の構成を備える。即ち、
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶する記憶制御手段と、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御手段によって記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段と
を備える。
【発明の効果】
【００１２】
本発明によれば、特にカラー・データを扱うソフトウェアの処理ログを容易に解析可能とする技術を提供することができる。
【発明を実施するための最良の形態】
【００１３】
以下、添付図面を参照して本発明に係る実施の形態を詳細に説明する。ただし、この実施の形態に記載されている構成要素はあくまでも例示であり、この発明の範囲をそれらのみに限定する趣旨のものではない。
【００１４】
［第１実施形態］
＜システム構成＞
図１は、本実施形態に対応する情報処理装置の構成を例示的に示す図である。説明を簡略化するために、本実施形態では、情報処理システムが１台のＰＣ内部に構築されるものとする。ただし、本発明の特徴は、複数の情報処理装置を用いた分散環境としても有効である。
【００１５】
図１のように、本情報処理装置（ＰＣ）は、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ（以下、ＨＤＤと呼ぶ）６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵ１とチップセット２を繋ぐ信号線１１、チップセット２とＲＡＭ３を繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とＨＤＤ６を繋ぐ信号線１４、ハードディスク４とＣＤ−ＲＯＭドライブ７を繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８を繋ぐ信号線１６が搭載されている。
【００１６】
図１において、ＣＰＵ１は、ＨＤＤ６に格納されているアプリケーションプログラム、オペレーティングシステム（ＯＳ）や制御プログラム等を実行し、ＲＡＭ３にプログラムの実行に必要な情報、ファイル等を一時的に格納する制御を行う。
【００１７】
チップセット２は、情報処理装置内部のＣＰＵ１の周辺回路を搭載したＬＳＩ等のチップの集まりであり、メモリインタフェース等の制御回路が搭載されている。ＲＡＭ３は、各種データを一時記憶するためのメモリであり、ＣＰＵ１の主メモリ、ワークエリア等として機能する。
【００１８】
ＨＤＤ６は、所定の情報を記憶する大容量メモリである。ＨＤＤ６には、アプリケーションプログラム、ＯＳ、制御プログラム、関連プログラム等が格納される。ＣＤ−ＲＯＭドライブ７は、記録媒体へのアクセスを実現する装置であり、ＣＤ−ＲＯＭメディア（記録媒体）に記憶されたプログラム等を本情報処理装置にロードすることができる。ハードディスクコントローラ４は、ＨＤＤ６とＣＤ−ＲＯＭドライブ７の動作を制御する装置である。
【００１９】
ディスプレイ８は表示出力装置であり、入力されたコマンドや、それに対する情報処理装置の応答出力等を表示したりするものである。ディスプレイコントローラ５は周辺機器バス１３とディスプレイ８とを仲介してディスプレイ８の動作を制御する。周辺機器バス８は、情報処理装置内のデータの流れを司るものである。
【００２０】
尚、以上の各装置と同等の機能を実現するソフトウェアにより、ハードウェア装置の代替として構成することもできる。また、図１の構成は本発明を実施するための最低限の構成であり、他の装置が構成要素として付加されている構成でも構わない。
【００２１】
本実施形態では、メディアから本実施形態に係るプログラム及び関連データを直接ＲＡＭ３にロードして実行させる例を示すが、これ以外にも、本実施形態に係るプログラムを動作させる度に、既にプログラムがインストールされているＨＤＤ６からＲＡＭ３にロードするようにしてもよい。また、本実施形態に係るプログラムをＲＯＭ（不図示）に記録しておき、これをメモリマップの一部をなすように構成し、直接ＣＰＵ１で実行することも可能である。
【００２２】
＜ＩＡＴ Ｐａｔｃｈ＞
次に、本実施形態に係る情報処理装置を説明するために、図２を参照して、複数のモジュールから構成される評価対象のソフトウェアが、通常の状態でどのようにメモリ（ＲＡＭ３）にロードされるかを説明する。図２は、関数ロード時の通常のメモリ構成を模式的に示した図である。
【００２３】
通常、複数のモジュールから構成されるソフトウェアは、実行ファイル（以下、ＥＸＥと呼ぶ）２３とダイナミックリンクライブラリ（以下、ＤＬＬと呼ぶ）２７とに分かれてＲＡＭ３にロードされる。ここで、ＥＸＥ２３はソフトウェア全体の実行制御を行なうファイルであり、ＤＬＬ２７はモジュールとして存在しＥＸＥ２３の補完的な役割を担うファイルである。
【００２４】
この図では、１つのＥＸＥ２３がＡ．ＤＬＬ２５及びＢ．ＤＬＬ２６の２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ ＡＡ，Ｆｕｎｃ ＡＢ，Ｆｕｎｃ ＡＣ，Ｆｕｎｃ ＢＡ，Ｆｕｎｃ ＢＢ，Ｆｕｎｃ ＢＣの６個である。ＤＬＬ２７の関数の実体は、ＤＬＬ２７毎（２５，２６）にロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。
【００２５】
ＲＡＭ３において、ＥＸＥ３はコードセグメント２８とデータセグメント２９、そしてインポート関数アドレステーブル２２の各セグメントから構成される。コードセグメント２８は、ソフトウェアの演算命令のコード等が格納されている。データセグメント２９は、演算対象の変数や定数等のデータが格納されている。
【００２６】
インポート関数アドレステーブル２２は、ＤＬＬ２７として定義されている関数のアドレスを格納したものであり、ＥＸＥ２３はインポート関数アドレステーブル２２を参照して関数のアドレスを取得し、関数をロードする。インポート関数アドレステーブル２２は、関数の所属するＤＬＬ毎に関数のアドレス値を格納している。図２の例では、Ａ．ＤＬＬ２５に含まれる関数のアドレスを格納した領域２１と、Ｂ．ＤＬＬ２６に含まれる関数のアドレスを格納した領域２４とから構成され、それぞれの領域に関数がロードされたアドレスが格納されている（３０〜３５）。
【００２７】
例えば、ＥＸＥ２３のコードセグメント内にあるコードが関数Ｆｕｎｃ ＡＡ３６を呼び出す場合には、まずインポート関数アドレステーブル２２内に格納されたＦｕｎｃ ＡＡのアドレス３０を参照する。即ち、Ａ．ＤＬＬの一部として読み込まれたＦｕｎｃ ＡＡコード３６のアドレスを参照し、そのアドレスをコールすることによって、ＥＸＥ２３のコードはＡ．ＤＬＬ２５のＦｕｎｃ ＡＡ３６を呼び出すことができる。
【００２８】
次に、ログを取得するための方法であるＩＡＴ Ｐａｔｃｈ（Ｉｍｐｏｒｔ Ａｄｄｒｅｓｓ Ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて関数呼び出しを仲介した場合の、情報処理装置のメモリ構成の一例について、図３を参照して説明する。
【００２９】
ＩＡＴ Ｐａｔｃｈを用いたログの出力は、関数呼び出しを中継し必要な情報をログとして出力するモジュール（以下、ＡＰＩトレーサーと呼ぶ）をＲＡＭ３に格納し、ＥＸＥ５３のインポート関数アドレステーブル５２を書き換えることにより実現される。即ち、ＥＸＥ５３はＤＬＬ５７を直接コールするのではなく、ログを出力するＡＰＩトレーサーをコールして間接的にＤＬＬ５７をコールすることで、ログの出力が実現される。以下、その詳細を説明する。
【００３０】
ログを取得する前処理として、本実施形態に対応する情報処理装置は、後述する関数定義ファイルとトレースシナリオファイルを読み込み、ＡＰＩトレーサーをＣ．ＤＬＬとして生成する。そして、情報処理装置は、図３のように、ＲＡＭ３にＩＡＴ Ｐａｔｃｈ用のＤＬＬであるＣ．ＤＬＬ５８をロードするように制御する。ここで、Ｃ．ＤＬＬ５８内のＦｕｎｃ ＣＡＡ７３，Ｆｕｎｃ ＣＡＢ７４，Ｆｕｎｃ ＣＡＣ７５，Ｆｕｎｃ ＣＢＡ７６，Ｆｕｎｃ ＣＢＢ７７，Ｆｕｎｃ ＣＢＣ７８の各コードは、ログを記録すると共に、元々関数呼び出しを受けるべくメモリ（ＲＡＭ３）にロードされている、該当する関数であるＦｕｎｃ ＡＡ６７，Ｆｕｎｃ ＡＢ６８，Ｆｕｎｃ ＡＣ６９，Ｆｕｎｃ ＢＡ７０，Ｆｕｎｃ ＢＢ７１，Ｆｕｎｃ ＢＣ７２を呼び出すものである。
【００３１】
そして、本実施形態に対応する情報処理装置は、後述するトレースシナリオファイルに基づいて、ＥＸＥ５３のインポート関数アドレステーブル５２内に書かれた関数のアドレスを、Ｃ．ＤＬＬ５８内のログ取得コードである、Ｆｕｎｃ ＣＡＡ７３，Ｆｕｎｃ ＣＡＢ７４，Ｆｕｎｃ ＣＡＣ７５，Ｆｕｎｃ ＣＢＡ７６，Ｆｕｎｃ ＣＢＢ７７，Ｆｕｎｃ ＣＢＣ７８の各アドレスに書き換える（６１〜６６）。
【００３２】
次に、図３のように構成されたモジュールの構成において、ＩＡＴ Ｐａｔｃｈがどのように実現されるかについて、図４を参照して説明する。図４は、図３におけるＩＡＴ Ｐａｔｃｈの処理をあらわすタイミングチャートである。ここでは、ＥＸＥ２３がＡ．ＤＬＬ２１内のＦｕｎｃ ＡＡ３６を呼び出す際に、ＩＡＴ Ｐａｔｃｈによるログ取得コード（Ｃ．ＤＬＬ５８）がどのように動作するかの例をあらわしている。他の関数の場合についても同様の処理が行われることは言うまでもない。
【００３３】
ＥＸＥ９１がＦｕｎｃ ＡＡをコールすると（９４）、Ｃ．ＤＬＬ９２内にあるログ取得コードは、ＤＬＬ名／関数名、呼び出し時刻、呼び出し時のパラメータ、呼び出し時のポインタ・パラメータの指すメモリ内容、及びその他の情報を、それぞれ所定の記憶装置（ＲＡＭ３，ＨＤＤ６等）に保存する（９５）。その後、Ｃ．ＤＬＬ９２は、本来呼び出されるはずであった、Ａ．ＤＬＬ９３内のＦｕｎｃ ＡＡをコールする（９６）。
【００３４】
Ａ．ＤＬＬのＦｕｎｃ ＡＡ処理（９７）が終了し、Ｃ．ＤＬＬ９２に制御がリターンすると（９８）、Ｃ．ＤＬＬ９２はリターン時の時刻、戻り値、リターン時にポインタ・パラメータが指すメモリ内容、及びその他の情報を、それぞれ所定の記憶装置に保存する（９９）。その後、Ｃ．ＤＬＬ９２は保存したログ情報をファイルに書き込み（１００）、あたかもＡ．ＤＬＬ９３のＦｕｎｃ ＡＡが通常通りに終了したかのように、ＥＸＥ９１にリターンする（１０１）。
【００３５】
図５は、本実施形態に対応する情報処理装置において実行ファイルＥＸＥが実行される場合の動作を例示的に示した図である。通常は実行形式のＥＸＥ１１３が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサ１１４は、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）の関数定義を記述した関数定義ファイル１１１と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかを記述した設定シナリオファイル１１２に基づいて動作する。
【００３６】
＜ＶＴａｂｌｅ Ｐａｔｃｈ＞
図６は、本実施形態に対応する情報処理装置において、実行ファイルＥＸＥ１１８がＣＯＭ（Ｃｏｍｐｏｎｅｎｔ Ｏｂjｅｃｔ Ｍｏｄｅｌ：コンポーネント・オブジェクト・モデル）サーバでエクスポートされているインターフェースのインスタンスを作成する場合の、メモリ構成の一例を示す図である。
【００３７】
通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１，１２２）と、そのメソッド（１３０〜１３５）が作成され、それらは共にメモリ（ＲＡＭ３）上にロードされる。ここで、ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅは作成された各インターフェース毎に作られ（１１８，１２０）、作成要求を行ったＥＸＥ１１９に渡される。このｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅには各メソッドについて作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥ１１９はこれら情報を利用し、各インターフェースに対して呼び出しを行う。図６では、１つのＥＸＥ１１９がＩｎｔｅｒｆａｃｅ Ａ１２１及びＩｎｔｅｒｆａｃｅ Ｂ２２の２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ ＡＡ１３０， Ｍｅｔｈｏｄ ＡＢ１３１， Ｍｅｔｈｏｄ ＡＣ１３２， Ｍｅｔｈｏｄ ＢＡ１３３， Ｍｅｔｈｏｄ ＢＢ１３４， Ｍｅｔｈｏｄ ＢＣ１３５となっている。
【００３８】
ＥＸＥ１１９のコードが関数Ｍｅｔｈｏｄ ＡＡ１３０を呼び出す場合には、まずｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ ＡＡ１３０のアドレス１２４が読み込まれる。このアドレス１２４にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ Ａ１２１の一部として作成されたＭｅｔｈｏｄ ＡＡコード１３０のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥ１１９のコードはＩｎｔｅｒｆａｃｅ Ａ１２１のＭｅｔｈｏｄ ＡＡ１３０を呼び出すことができる。
【００３９】
図７は、本実施形態に対応する情報処理装置のメモリ構成をあらわす図であり、図６とは、ログ取得用のコードとしてＶＴａｂｌｅ Ｐａｔｃｈ（ｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しを仲介しているという点で異なっている。
【００４０】
ログ取得が開始されると、ＲＡＭ３内にはＶＴａｂｌｅ Ｐａｔｃｈ用のＤＬＬ１４３がロードされる。このＤＬＬはｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅ（１３６，１３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ Ａ’Ａ１４５，Ｍｅｔｈｏｄ Ａ’Ｂ１４６，Ｍｅｔｈｏｄ Ａ’Ｃ１４７，Ｍｅｔｈｏｄ Ｂ’Ａ１４８，Ｍｅｔｈｏｄ Ｂ’Ｂ１４９，Ｍｅｔｈｏｄ Ｂ’Ｃ１５０のアドレスに書き換える。ＤＬＬ内のＭｅｔｈｏｄ Ａ’Ａ１５７，Ｍｅｔｈｏｄ Ａ’Ｂ１５８，Ｍｅｔｈｏｄ Ａ’Ｃ１５９，Ｍｅｔｈｏｄ Ｂ’Ａ１６０，Ｍｅｔｈｏｄ Ｂ’Ｂ１６１，Ｍｅｔｈｏｄ Ｂ’Ｃ１６２のコードは、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリ（ＲＡＭ３）にロードされていたＭｅｔｈｏｄ ＡＡ１５７，Ｍｅｔｈｏｄ ＡＢ１５８，Ｍｅｔｈｏｄ ＡＣ１５９，Ｍｅｔｈｏｄ ＢＡ１６０，Ｍｅｔｈｏｄ ＢＢ１６１，Ｍｅｔｈｏｄ ＢＣ１６２を呼び出す。
【００４１】
図８は、図７におけるＶＴａｂｌｅ Ｐａｔｃｈの処理をあらわすタイミングチャートである。説明を簡略化するために、この図ではＥＸＥ１６３がＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ ＡのＭｅｔｈｏｄ ＡＡを呼び出す際に、ＶＴａｂｌｅ Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。他のメソッドの場合についても同様の処理が行われることはいうまでもない。
【００４２】
ＥＸＥ１６３がＭｅｔｈｏｄ ＡＡをコールすると（１６６）、ＤＬＬ１６４内にあるログ取得コードは、モジュール名／インターフェース名／メソッド名、呼び出し時刻、呼び出し時のパラメータ、呼び出し時のポインタパラメータの指すメモリ内容、及びその他の情報をメモリ（ＲＡＭ３）に保存する（１６７）。その後ＤＬＬ１６４は本来呼び出されるはずであった、ＣＯＭサーバ１６５内のＭｅｔｈｏｄ ＡＡをコールする（１６８）。ＣＯＭサーバのＭｅｔｈｏｄ ＡＡ処理（１６９）が終了し、ＤＬＬ１６４に制御がリターンすると（１７０）、ＤＬＬ１６４はリターン時の時刻をメモリに保存し、戻り値をメモリ（ＲＡＭ３）に保存し、リターン時にポインタパラメータが指すメモリ内容を、メモリ（ＲＡＭ３）に保存する（１７１）。その後、ＤＬＬ１６４は保存したログ情報をファイルに書き込み（１７２）、あたかもＣＯＭサーバのＭｅｔｈｏｄ ＡＡが通常通りに終了したかのように、ＥＸＥ１６３にリターンする（１７３）。
【００４３】
図９は、本実施形態に対応する情報処理装置において実行形式ファイルＥＸＥが実行される場合の動作の一例を示す図である。通常は実行形式のＥＸＥ１７６が、ＣＯＭサーバ−１（１７９）やＣＯＭサーバ−２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ−１（１７９）やＣＯＭサーバ−２の関数定義を記述したファイル（関数定義ファイル）１７４と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ ａｄｄｒｅｓｓ ｔａｂｌｅを書き換えてログを取得するかを記述した設定シナリオファイル１７５に基づいて動作する。
【００４４】
図１０は、本実施形態に対応する情報処理装置において使用する、関数定義ファイルの一例を示したものである。この例では、一般的に広く用いられているＩＤＬ（Ｉｎｔｅｒｆａｃｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ：インタフェース定義言語）により、関数の定義が記述されている。本実施形態に対応する情報処理装置においては、このＩＤＬをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、関数定義ファイルは付加バイナリ情報（各ログ情報）を取得するための定義を提供することを特徴とするものであり、関数定義は必ずしもＩＤＬによって記述されている必要はない。例えば、通常のテキストファイルを用いることも可能であり、ＸＭＬなどのマークアップ言語を用いることも可能である。
【００４５】
＜出力データのカラー判別＞
次に、本実施形態に対応する情報処理装置において、プリンタ出力データのカラー判別を行う構成について説明する。ここでは、説明の簡略化のため、画像形成装置に対してテキスト描画コマンドを送出する場合について例示的に説明するが、以下の構成はいかなるグラフィック・オブジェクトについても適用可能である。また、以下ではプリンタ装置に対して出力される描画コマンドについてログを取得する構成について例示的に説明を行うが、出力対象はどのような装置でもよい。
【００４６】
図１１は、本実施形態に対応する情報処理装置において、プリンタ出力データのカラー判別を行なうための、関数定義ファイルの例である。本実施形態では、オペレーティングシステム（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）にＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌというダイナミックリンクライブラリファイルが用意されており、そのライブラリ内に、テキストの描画を行なう関数ＴｅｘｔＯｕｔ２０２、テキストの色を設定する関数ＳｅｔＴｅｘｔＣｏｌｏｒ２０４、設定されているテキストの色を取得する関数ＧｅｔＴｅｘｔＣｏｌｏｒ２０３が用意されているものとする。尚、関数名はこれらに限定されるものではない。また、テキスト以外のグラフィック・オブジェクトを出力する場合は、関数名は当然に異なったものになる。
【００４７】
関数ＴｅｘｔＯｕｔ２０２は、デバイスコンテキストのハンドル、描画開始位置のｘ，ｙ座標、描画する文字列、描画する文字列の数をパラメータ（引数）として入力し、入力値に基づいて所定の対象にテキストの描画コマンドを発行するように動作する。そして、動作が正しく終了したか否かを示す２値情報を戻り値として返す。
【００４８】
ただし、デバイスコンテキストは、オペレーティングシステムによって仮想化された「面」に対するハンドルであり、描画対象装置を指定するものである。本実施形態において、デバイスコンテキストはディスプレイ８向けのものとプリンタ（不図示）向けのものが用意されている。例えば、プリンタ向けを示すデバイスコンテキスト（ＴｅｘｔＯｕｔ関数の第一パラメータ）のハンドルを選択して、その他の必要なパラメータを入力することにより、プリンタ装置に対してテキストの描画コマンドを発行することができる。なお、デバイスコンテキストは、ｔｙｐｅｄｅｆによって定義している（２００）。
【００４９】
関数ＳｅｔＴｅｘｔＣｏｌｏｒ２０４は、ＴｅｘｔＯｕｔ２０２をコールすることによってテキストを描画する際に、テキストの色を設定する関数であり、後述するようにＳｅｔＴｅｘｔＣｏｌｏｒ２０４をコールする前にコールして用いる。ＳｅｔＴｅｘｔＣｏｌｏｒ２０４は、デバイスコンテキストのハンドルと、設定するテキストの色をパラメータとして入力し、パラメータに指定された色情報を設定し、ＳｅｔＴｅｘｔＣｏｌｏｒ２０４をコールする前に設定されていた色情報を戻り値として返す。
【００５０】
関数ＧｅｔＴｅｘｔＣｏｌｏｒ２０３は、設定されているテキストの色情報を取得する関数である。ＧｅｔＴｅｘｔＣｏｌｏｒ２０３は、デバイスコンテキストのハンドルをパラメータとして入力し、入力されたハンドルに対応するデバイスコンテキストに設定されている色情報を取得し、その値を戻り値として返す。
【００５１】
上記の関数をコールして特定の色の文字をプリンタに出力する際には、以下の処理を行う。即ち、
（１）ＳｅｔＴｅｘｔＣｏｌｏｒ関数２０４でテキスト色の設定を行ない、
（２）ＴｅｘｔＯｕｔ関数２０２でテキストの描画指示を行なう。
【００５２】
このような処理手順に鑑み、プリンタ装置に対応するデバイスコンテキストに対してアプリケーション・ソフトウェアがテキスト描画コマンドを発行する際に、そのテキストの色に関するログを、ＩＡＴ Ｐａｔｃｈを用いて取得する処理について、図１２を参照して説明する。図１２は、このような処理の流れを示すフローチャートである。尚、以下の処理は上述したＶＴａｂｌｅ Ｐａｔｃｈを用いて構成してもよい。
【００５３】
アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。そして、ステップＳ２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。尚、先に述べたように、パラメータには文字列の内容等の画像の形状に関する情報や、描画位置等の画像の位置に関する情報が含まれている。このことは画像がテキストに関するものに限られず、他のグラフィック・オブジェクトに適用する場合も同様である。
【００５４】
次に、呼び出された関数の種類に応じて別個の処理を行う。即ち、ステップＳ３において、呼び出された関数がテキストカラー設定関数（ＳｅｔＴｅｘｔＣｏｌｏｒ）であるか否かを判定し、テキストカラー設定関数であれば（ステップＳ３においてＹＥＳ）ステップＳ４へ進む。ステップＳ４においては、関数呼び出しのパラメータ（引数）を解析し、設定する色のパラメータを取得する。そして、取得した色のパラメータをＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値に変換する。ステップＳ５において、変換した各値をＲＡＭ３に一時的に記憶制御し、ステップＳ８へ進む。
【００５５】
ステップＳ８においては、ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌにアクセスし、アプリケーション・ソフトウェアが呼び出し要求を行った関数を実際に呼び出す。この時、関数のパラメータをアプリケーション・ソフトウェアが送出した値に設定する。関数からリターンが発生すると、ステップＳ９において、リターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をログとしてログ書き込みファイルに追加する。そして、ステップＳ１０へ進む。
【００５６】
ステップＳ１０においては、アプリケーション・ソフトウェア、或いは、ユーザから終了の命令がなされたか否かを判定する。終了の命令がなされた場合（ステップＳ１０においてＹＥＳ）は処理を終了し、なされていない場合（ステップＳ１０でＮＯ）はステップＳ１へ戻り処理を継続する。
【００５７】
アプリケーション・ソフトウェアから呼び出された関数がテキストカラー設定関数でない場合は（ステップＳ３においてＮＯ）ステップＳ６へ進み、呼び出された関数がテキスト出力関数（ＴｅｘｔＯｕｔ）であるか否かを判定する。テキスト出力関数であれば（ステップＳ６においてＹＥＳ）ステップＳ７へ進み、テキスト出力関数でなければ（ステップＳ６においてＮＯ）ステップＳ８へ進む。ステップ８以降の処理は先に述べたものと同様である。
【００５８】
ステップＳ７においては、ステップＳ５で一時的に記憶制御した、Ｒｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値から構成される色情報をＲＡＭ３から読み出し、ログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。ＲＡＭ３に色情報が格納されていない場合は、エラー情報をログとしてログ書き込みファイルに追加する。そしてステップＳ８へ進む。ステップＳ８以降の処理は先に述べたものと同様である。
【００５９】
次に、上記の処理とＩＡＴ−Ｐａｔｃｈ法の各構成要素との対応について、図２２を参照して説明する。図２２は対応するタイミングチャートである。
【００６０】
図２２において、３０１はアプリケーション・ソフトウェアの実行ファイルＥＸＥ、３０２はＩＡＴ Ｐａｔｃｈによるログ取得コード（ＩＡＴ Ｐａｔｃｈコードと呼ぶ）、３０３はＯＳＧｒａｐｈｉｃＫｅｒｎｅｌをそれぞれ示している。
【００６１】
ＥＸＥ３０１が関数呼び出しを行う場合は、先に述べたように、ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３に対して行うのではなく、ＩＡＴ Ｐａｔｃｈコード３０２に対して行う（３０４）。ＩＡＴ Ｐａｔｃｈコード３０２は、関数呼び出しを受け取ると、関数名や呼び出し時刻等の情報を、ログとしてＨＤＤ６のログ書き込みファイルに追加する（３０５）。この処理は、図１２のステップＳ１及びＳ２の処理に対応する。
【００６２】
そして、ＩＡＴ Ｐａｔｃｈコード３０２は、呼び出し要求がなされた関数の種類を判定し、関数がＳｅｔＴｅｘｔＣｏｌｏｒの場合と、ＴｅｘｔＯｕｔの場合は、それぞれ所定の処理を行う。関数がＳｅｔＴｅｘｔＣｏｌｏｒの場合は図１２のステップＳ４及びＳ５の処理を行い（３０６）、ＴｅｘｔＯｕｔの場合は図１２のステップＳ７の処理を行う（３０７）。
【００６３】
次に、呼び出し要求がなされたＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３の関数にアクセスし（３０８）、関数に所定の処理を実行させる（３０９）。これらの処理は図１２のステップＳ８に対応する。
【００６４】
ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３の関数からリターンが発生すると（３１０）、戻り値や時刻等の情報をログとしてログ書き込みファイルに追加する（３１１、３１２）。これらの処理は図１２のステップＳ９に対応する。そして、ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ３０３の関数からリターンをＥＸＥ３０１へ返す。
【００６５】
次に、以上のような処理の結果得られるログについて図１３を参照して説明する。図１３は、本実施形態に対応する情報処理装置において、図１１の定義及び図１２、２２の処理により取得されるログデータを例示的に示す図である。図１３において、２０５、２０６は、関数ＴｅｘｔＯｕｔが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、実際にどのような色情報に基づいて出力要求がなされたかを、時系列順に容易に把握することができる。また、色情報は他の画像情報と関連づけた形で表示されるため、例えば、プリンタの出力結果とログとの比較が容易である。
【００６６】
以上のように、ＩＡＴ Ｐａｔｃｈを用いてカラー出力を検出することにより、プリンタ装置等へのカラー出力において発生した障害に対して、アプリケーション・ソフトウェアがオペレーティングシステムに対してどのような指示を行なった結果その障害が発生したのかを、明示的に知ることができる。
【００６７】
また、ＩＡＴ Ｐａｔｃｈを用いたログ取得において、テキストカラー設定関数及びテキスト出力関数への呼び出しを判定しログを生成することで、カラー関連の処理に関するログの解析を容易にしている。更に、色情報のログを画像情報と対応づけて生成することで、例えば、プリンタの出力結果と、ログの中のグラフィック・オブジェクトの位置や色情報等とを比較してバグを検知することを可能にしており、ログを解析する際にバグの原因を容易に特定することができる。これにより、カラー関連の障害の原因を特定する作業を迅速に行うこと可能である。
【００６８】
［第２実施形態］
第１実施形態においては、ＩＡＴ Ｐａｔｃｈの手法に加えて、色情報の設定関数とグラフィック・オブジェクトの出力を指示する関数の呼び出しについて選択的にログを生成する構成について述べた。本実施形態においては、設定されている色情報を取得するテキストカラー取得関数（ＧｅｔＴｅｘｔＣｏｌｏｒ）を用いて色情報を取得する構成について説明する。尚、システム構成やＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ等は第１実施形態と同様である。
【００６９】
図１４は、本実施形態に対応する情報処理装置に於いて、プリンタ出力データのカラー判別を行なう処理の流れを示すフローチャートである。アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ２１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。次に、ステップＳ２２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。そして、ステップＳ２３へ進む。
【００７０】
本実施形態においては、ステップＳ２３〜ステップＳ２６の処理が第１実施形態と異なっている。即ち、ステップＳ２３において呼び出された関数がテキスト出力関数（ＴｅｘｔＯｕｔ）であるか否かを判定し、テキスト出力関数であれば（ステップＳ２３においてＹＥＳ）ステップＳ２４へ進み、テキスト出力関数でなければ（ステップＳ２３においてＮＯ）ステップＳ２７へ進む。ステップＳ２４においては、ＩＡＴ Ｐａｔｃｈコードから直接ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌのテキストカラー取得関数（ＧｅｔＴｅｘｔＣｏｌｏｒ）を呼び出し、設定されている色情報を取得する。次に、ステップＳ２５において、取得した色情報をＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値に変換する。そして、ステップＳ２６において、ステップＳ２５で得られたＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値をログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。ステップＳ２７以降の処理は図１２のステップＳ８以降の処理と同様であるため、説明を省略する。
【００７１】
次に、以上のような処理の結果得られるログについて図１５を参照して説明する。図１５は、本実施形態に対応する情報処理装置において、図１４の処理により取得されるログデータを例示的に示す図である。図１５において、２０７、２０８、２０９は、関数ＴｅｘｔＯｕｔが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、第１実施形態と同様に、実際にどのような色情報に基づいて出力要求がなされたかを、時系列順に容易に把握することができる。
【００７２】
以上のように、本実施形態においては、ＩＡＴ Ｐａｔｃｈコードからテキストカラー取得関数を呼び出す構成を採っていることにより、テキストカラー設定関数のログを取得せずに、テキスト出力関数時にテキストの出力に用いられた色データをログとして出力することができる。これにより、ログを生成する際にかかる時間やログを取得する際に必要なメモリを節約しつつ、第１実施形態と同様の効果を得ることができる。
【００７３】
［第３実施形態］
第１、第２実施形態においては、カラー出力能力を持つ関数の全ての呼び出しについてログを出力する構成について述べたが、目的・用途によっては、そのような関数呼び出しについての全てのログは必要ない場合も考えられる。例えば、グレイスケール（無彩色）の画像出力とカラー（有彩色）の画像出力とを実行可能なシステムにおいて、有彩色の画像出力のみについてログを取得し、障害原因を特定したいという場合が考えられる。そこで、本実施形態においては、有彩色の画像出力のみについてログを取得する構成について例示的に説明する。尚、以下の構成は、例えば、無彩色の画像出力のみについてログを取得する場合にも適用可能である。尚、システム構成やＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌ等は第１実施形態と同様である。
【００７４】
図１６は、本実施形態に対応する情報処理装置に於いて、プリンタ出力データのカラー判別を行なう処理の流れを示すフローチャートである。アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ４１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。次に、ステップＳ４２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。そして、ステップＳ４３へ進む。
【００７５】
本実施形態においては、ステップＳ４３〜ステップＳ４７の処理が第１実施形態と異なる。即ち、ステップＳ４３において呼び出された関数がテキスト出力関数（ＴｅｘｔＯｕｔ）であるか否かを判定し、テキスト出力関数であれば（ステップＳ４３においてＹＥＳ）ステップＳ４４へ進み、テキスト出力関数でなければ（ステップＳ４３においてＮＯ）ステップＳ４８へ進む。ステップＳ４４においては、ＩＡＴ Ｐａｔｃｈコードから直接ＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌのテキストカラー取得関数（ＧｅｔＴｅｘｔＣｏｌｏｒ）を呼び出し、設定されている色情報を取得する。次に、ステップＳ４５において、取得した色情報をＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値に変換し、ステップＳ４６へ進む。
【００７６】
本実施形態においては、ステップＳ４６、Ｓ４７の処理が第２実施形態と異なる。即ち、ステップＳ４６において、ステップＳ４４で取得した色情報が有彩色であるか否かを判定し、有彩色の場合（ステップＳ４６でＮＯ）ステップＳ４７へ進み、ステップＳ４５で得られたＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値をログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。有彩色でない場合（ステップＳ４６でＹＥＳ）は、ステップＳ４８へ進む。尚、ステップＳ４６における有彩色か否かの判定は、ステップＳ４５で取得したＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値について、Ｒｅｄ値＝Ｇｒｅｅｎ値＝Ｂｌｕｅ値が成立するか否か（成立する場合は無彩色、成立しない場合は有彩色）により行う。ステップＳ４８以降の処理は図１２のステップＳ８以降の処理と同様であるため、説明を省略する。
【００７７】
次に、以上のような処理の結果得られるログについて図１７を参照して説明する。図１７は、本実施形態に対応する情報処理装置において、図１６の処理により取得されるログデータを例示的に示す図である。図１７において、２１０、２１１は、関数ＴｅｘｔＯｕｔが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、有彩色の場合のログのみが記録されている。実際にどのような色情報に基づいて出力要求がなされたかを時系列順に容易に把握することができる点は、第１、第２実施形態と同様である。
【００７８】
以上のように、本実施形態においては、ＩＡＴ Ｐａｔｃｈコードで有彩色か無彩色かの判定を実装する構成を採っていることにより、無彩色データのログを取得せずに、有彩色データのみをログとして出力することができる。これにより、ログを生成する際にかかる時間を削減しつつ、必要な情報のみが記載されたログを得ることができ、障害発見の作業能率を高めることができる。
【００７９】
［第４実施形態］
第１〜３実施形態においては、説明を簡略するために、テキスト出力に関するログを取得する構成について例示的に説明したが、上記の構成はどのようなグラフィック・オブジェクトについても適用可能である。本実施形態では、テキストとは異なるグラフィック・オブジェクトの一例として、「ペン」オブジェクトの出力についてログを取得する構成について述べる。ペンオブジェクトとは、オペレーティングシステムに仮想的に備えられたグラフィック・オブジェクトであり、デバイスコンテキストに対して線の描画を指示する際に用いられる。
【００８０】
図１８は、本実施形態に対応する情報処理装置に於いて、プリンタ出力データのカラー判別を行なうための、関数定義ファイルの例である。本実施形態では、オペレーティングシステムにＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌというダイナミックリンクライブラリファイルが用意されており、そのライブラリ内には、ＣｒｅａｔｅＰｅｎ２２３、ＳｅｌｅｃｔＰｅｎ２２４、ＳｅｔＳｔａｒｔＰｏｉｎｔ２２５、ＬｉｎｅＴｏ２２６、ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ２２７、ＤｅｌｅｔｅＰｅｎ２２８を含む関数が用意されているものとする。
【００８１】
関数ＣｒｅａｔｅＰｅｎ２２３はペンオブジェクトを生成する関数である。ＣｒｅａｔｅＰｅｎ２２３は、パラメータ（引数）としてペンオブジェクトの色情報を受け取り、指定された色のペンオブジェクトを生成してそのオブジェクトをハンドルを戻り値として返す。関数ＳｅｌｅｃｔＰｅｎ２２４はデバイスコンテキストにペンオブジェクトを関連づける関数である。ＳｅｌｅｃｔＰｅｎ２２４は、パラメータとしてデバイスコンテキストのハンドルとペンオブジェクトのハンドルを受け取り、指定されたデバイスコンテキストにペンオブジェクトを関連づけ、戻り値として関連づけが成功したか否かを示すブール値を返す。
【００８２】
関数ＳｅｔＳｔａｒｔＰｏｉｎｔ２２５及びＬｉｎｅＴｏ２２６はペンオブジェクトを用いた描画を行なうための関数である。ＳｅｔＳｔａｒｔＰｏｉｎｔ２２５は、パラメータとしてデバイスコンテキストのハンドル、描画開始位置の座標（ｘ，ｙ座標）を受け取り、線の始点の座標を設定する。ＬｉｎｅＴｏ２２６は、パラメータとしてデバイスコンテキストのハンドル、描画終了位置の座標（ｘ，ｙ座標）を受け取り、線の終点の座標を設定し、座標が設定された始点と終点を結ぶ線を出力するように指示する。なお、この時出力される線の色はＣｒｅａｔｅＰｅｎ２２３のパラメータで設定された値である。
【００８３】
関数ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ２２７はペンオブジェクトに設定されている色情報を取得する関数である。ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ２２７は、パラメータとしてデバイスコンテキストのハンドルとペンオブジェクトの色情報へのポインタを入力し、ペンオブジェクトの色を取得する。そして、取得した色情報にアクセスできるように色情報へのポインタを設定して、戻り値として色情報の取得が成功したか否かを示すブール値を返す。
【００８４】
関数ＤｅｌｅｔｅＰｅｎ２２８は、ペンオブジェクトを削除する関数である。ＤｅｌｅｔｅＰｅｎ２２８は、パラメータとしてペンオブジェクトへのハンドルを入力し、ハンドルで指定されたペンオブジェクトをメモリから削除する。
【００８５】
ある色の線をプリンタに出力する際には、以下の処理を行う。即ち、
（１）ＣｒｅａｔｅＰｅｎ関数で、特定の色を持つペン・オブジェクトを生成する
（２）プリンタ装置を仮想化したデバイスコンテキストに対して、ＳｅｌｅｃｔＰｅｎ関数で、そのペン・オブジェクトを関連付ける
（３）ＳｅｔＳｔａｒｔＰｏｉｎｔ関数で、描画の開始座標を設定する
（４）ＬｉｎｅＴｏ関数で、描画の終了座標、すなわちデバイスコンテキストに関連付けられたペン・オブジェクトでどの座標まで線を書けばよいかを指示し、描画指令を行う
（５）ＤｅｌｅｔｅＰｅｎ関数でペン・オブジェクトを削除する
このような処理手順に鑑み、プリンタ装置に対応するデバイスコンテキストに対してアプリケーション・ソフトウェアがペンオブジェクトの描画指令を発行する際に、そのペンオブジェクトの色に関するログを、ＩＡＴ Ｐａｔｃｈを用いて取得する処理について、図１９を参照して説明する。図１９は、このような処理の流れを示すフローチャートである。尚、以下の処理は上述したＶＴａｂｌｅ Ｐａｔｃｈを用いて構成してもよい。また、この例では第３実施形態と同様に有彩色の出力指令のログを取得する場合について述べるものとする。
【００８６】
アプリケーション・ソフトウェアがＯＳＧｒａｐｈｉｃＫｅｒｎｅｌ．ｄｌｌの関数呼び出しを開始すると、本実施形態に対応する情報処理装置はログの取得を開始する。即ち、ログ書き込みファイルをＨＤＤ６に作成し、ステップＳ６１において、モジュール名、インターフェース名、関数／メソッド名を取得し、これらの情報をログとしてログ書き込みファイルに追加する。そして、ステップＳ６２において、関数呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリ（ＲＡＭ３）の内容を取得し、ログとしてログ書き込みファイルに追加する。尚、先に述べたように、パラメータには文字列の内容等の画像の形状に関する情報や、描画位置等の画像の位置に関する情報が含まれている。このことは画像がペン・オブジェクトに関するものに限られず、他のグラフィック・オブジェクトに適用する場合も同様である。
【００８７】
ステップＳ６３においては、呼び出された関数がペン描画関数（ＬｉｎｅＴｏ）であるか否かを判定し、ペン描画関数の場合（ステップＳ６３でＹＥＳ）ステップＳ６４へ進み、ペン描画関数ではない場合（ステップＳ６３でＮＯ）ステップＳ６８へ進む。
【００８８】
ステップＳ６４においては、ペン状態取得関数（ＧｅｔＣｕｒｒｅｎｔＰｅｎＡｔｔｒｉｂｕｔｅ）をＩＡＴ Ｐａｔｃｈコードから内部的に呼び出し、ペンオブジェクトに設定された色情報を取得する。次に、ステップＳ６５において、取得した色情報をＲｅｄ値，Ｇｒｅｅｎ値，Ｂｌｕｅ値に変換する。
【００８９】
次に、ステップＳ６６において、取得した色情報が有彩色であるか否かを判定し、有彩色の場合（ステップＳ６６でＮＯ）ステップＳ６７へ進み、ステップＳ６５で得られたＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値をログとしてＨＤＤ６のログ書き込みファイルに他の画像情報（呼び出し時の時刻、パラメータ（画像の位置や形状に関する情報が含まれている）、ポインタ・パラメータの指すメモリの内容等）との対応が分かるように追加する。有彩色でない場合（ステップＳ６６でＹＥＳ）は、ステップＳ６８へ進む。尚、ステップＳ６６における有彩色か否かの判定は、ステップＳ６５で取得したＲｅｄ値、Ｇｒｅｅｎ値、Ｂｌｕｅ値について、Ｒｅｄ値＝Ｇｒｅｅｎ値＝Ｂｌｕｅ値が成立するか否か（成立する場合は無彩色、成立しない場合は有彩色）により行う。ステップＳ６８以降の処理は図１２のステップＳ８以降の処理と同様であるため、説明を省略する。
【００９０】
次に、以上のような処理の結果得られるログについて図２０を参照して説明する。図２０は、本実施形態に対応する情報処理装置において、図１９の処理により取得されるログデータを例示的に示す図である。図２０において、２３０、２３１は、関数ＬｉｎｅＴｏが呼び出されたときに、デバイスコンテキストに対して指定されていた色の情報を示しており、有彩色の場合のログのみが記録されている。実際にどのような色情報に基づいて出力要求がなされたかを時系列順に容易に把握することができる点は、第１〜３実施形態と同様である。
【００９１】
以上のように、本実施形態においては、グラフィック・オブジェクトの出力指示のタイミングで色情報を取得してログに記録することにより、グラフィック・オブジェクトの一つであるペンオブジェクトについてもログを得ることができる。
【００９２】
尚、本実施形態はペン・オブジェクトを例に説明したが、どのようなグラフィック・オブジェクトに対しても有効である。例えば、オペレーティングシステムが提供するグラフィック・オブジェクトとしてブラシ・オブジェクト、ビットマップ・オブジェクトが用意されている場合、すべてのグラフィック・オブジェクトに対して同様の処理を行なうことにより、アプリケーション・ソフトウェアがオペレーティングシステムに対して、プリンタ装置にどのような色の描画を行なうよう指示したかを、ＩＡＴ Ｐａｔｃｈ／ＶＴａｂｌｅ Ｐａｔｃｈの技術を用いて、すべてログ・ファイルに取得することができる。これによって、カラーに関係する障害に関して迅速な原因の特定が可能となる。
【００９３】
［第５実施形態］
第１〜４実施形態においては、ＩＡＴ Ｐａｔｃｈ／ＶＴａｂｌｅ Ｐａｔｃｈを用いてログを出力する構成について述べたが、本実施形態では出力されたログを解析しやすいように、カラーフィールドを持つレコードを明示的に他のレコードと分けて表示するユーザインタフェース（ＵＩ）について述べる。
【００９４】
図２１は、本実施形態に対応する情報処理装置における、ログ表示ユーザ・インタフェースの一例である。このユーザインタフェースにおいては、カラー情報フィールドを持つレコードに関して強調表示する。図２１の例では、２３０のように印を付して表示する。但し、レコードとは１回の関数呼び出しに伴って出力されるログ情報である。これにより、カラー情報フィールドを持つレコードを迅速に特定することが可能である。尚、印ではなく、例えば、カラー情報フィールドを持つレコードに対して、テキストやテキスト・バックグラウンドの色を、カラー情報フィールドを持たないレコードとは別の色に設定するようにしてもよい。また、カラー情報フィールドの有無だけではなく、例えば、ある特定の関数や、モジュール、或いは、ある条件を満たす時刻におけるレコードについて強調表示するようにしてもよい。
【００９５】
また、表題欄２３０をボタンとして提供し、ボタンを押下した際に、印を有するフィールドと有しないフィールドとをソートする機能を提供する。更に、２３１，２３２，２３３，２３４のように、モジュール名や、関数／メソッド名、呼び出された時刻、Ｒｅｔｕｒｎした時刻等を表示し、更に、２３１，２３２，２３３，２３４をボタンとして提供して、ボタンが押下されたときに項目の値に応じてソートする機能を提供する。
【００９６】
また、不図示の検索メニューや検索ショートカットキーを提供し、所望のキーワードに合致するログ項目を検索する機能を提供する。
【００９７】
以上のようなログを表示する構成を採ることで、障害発見の作業能率を高めることができる。
【００９８】
尚、ログ書き込みファイルからレコードを生成する処理について図２３のフローチャートを参照して説明する。
【００９９】
まず、ステップＳ８１において、ログ書き込みファイルを読み込みメモリ（ＲＡＭ３等）に一時的に記憶制御する。次に、ステップＳ８２において、メモリに記憶されたログ書き込みファイルの先頭から参照して、まだ参照していない関数呼び出しに対応するログが存在するか否かを判定する。存在する場合（ステップＳ８２でＹＥＳ）はステップＳ８３へ進み、存在しない場合（ステップＳ８２でＮＯ）は処理を終了する。
【０１００】
ステップＳ８３においては、まだ参照していない関数呼び出しに対応するログで、先頭に近いものを参照する。そしてステップＳ８４において参照したログ情報を取得し、ステップＳ８５において取得したログ情報をレコードとして出力する。ステップＳ８２からステップＳ８５までの処理を繰り返し実行することで、ログ書き込みファイルから全てのレコードを生成することができる。
【０１０１】
尚、各レコードはそれぞれ別個のファイルとして出力されるようにしてもよいし、或いは、一つのファイルにまとめて出力されるようにしてもよい。本実施形態に対応する情報処理装置は、このようにして生成されるレコードに基づいて上述したようなユーザインタフェースを提供する。
【０１０２】
［他の実施形態］
以上、本発明の実施形態例について詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様を取ることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１０３】
尚、本発明は、前述した実施形態の機能を実現するプログラムを、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１０４】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明の技術的範囲に含まれる。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含む。
【０１０５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。
【０１０６】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。
【０１０７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１０８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。 また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【０１０９】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１１０】
【図１】本実施形態に対応する情報処理装置の構成の一例を示す図である。
【図２】本実施形態に対応する情報処理装置のメモリに、複数のモジュールに分割されたソフトウェアがロードされた様子を例示的に示す図である。
【図３】本実施形態に対応する情報処理装置において、ＩＡＴ Ｐａｔｃｈを使用したときのメモリ構成を模式的に示した図である。
【図４】本実施形態に対応する情報処理装置において、ＩＡＴ Ｐａｔｃｈを実行した場合のタイミングチャートである。
【図５】本実施形態に対応する情報処理装置において実行形式ファイルＥＸＥが実行される場合の動作の一例を示す図である。
【図６】本実施形態に対応する情報処理装置において、実行ファイルＥＸＥがＣＯＭサーバでエクスポートされているインターフェースのインスタンスを作成する場合の、メモリ構成の一例を示す図である。
【図７】本実施形態に対応する情報処理装置のメモリ構成を例示的に示す図である。
【図８】本実施形態に対応する情報処理装置において、ＶＴａｂｌｅ Ｐａｔｃｈの処理を実行した場合のタイミングチャートの一例を示す図である。
【図９】本実施形態に対応する情報処理装置において実行形式ファイルＥＸＥが実行される場合の動作の一例を示す図である。
【図１０】本実施形態で用いる関数定義ファイルの内容を例示的に示した図である。
【図１１】本実施形態で用いるテキスト描画コマンドを発行する関数の、関数定義ファイルの内容を例示的に示した図である。
【図１２】第１実施形態において、テキストの色に関するログを取得する処理の流れを示すフローチャートである。
【図１３】第１実施形態におけるログデータを例示的に示した図である。
【図１４】第２実施形態において、テキストの色に関するログを取得する処理の流れを示すフローチャートである。
【図１５】第２実施形態におけるログデータを例示的に示した図である。
【図１６】第３実施形態において、テキストの色に関するログを取得する処理の流れを示すフローチャートである。
【図１７】第３実施形態におけるログデータを例示的に示した図である。
【図１８】第４実施形態において用いる関数定義ファイルの例をあらわす図である。
【図１９】第４実施形態において、ペンオブジェクトの色に関するログを取得する処理の流れを示すフローチャートである。
【図２０】第４実施形態におけるログデータを例示的に示した図である。
【図２１】第５実施形態におけるログデータを表示するユーザインタフェースを例示的に示した図である。
【図２２】本実施形態に対応する情報処理装置において、テキスト描画コマンドを発行する際にテキストの色に関するログを取得する場合のタイミングチャートである。
【図２３】第５実施形態におけるログ書き込みファイルからレコードを生成する処理を示すフローチャートである。
【特許請求の範囲】
【請求項１】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶する記憶制御手段と、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御手段によって記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段と
を備えることを特徴とする情報処理装置。
【請求項２】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって予め設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、予め設定された前記色情報を取得する色情報取得関数を呼び出して前記第２のモジュールから色情報を取得し、当該色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段とを備えることを特徴とする情報処理装置。
【請求項３】
前記色情報は有彩色であるか否かを判定する判定手段を更に備え、
前記出力手段は、前記判定手段により有彩色と判定された前記色情報を前記画像情報と対応づけて履歴情報として出力することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記画像情報は、前記画像出力関数が呼び出された時刻、前記所定の画像の形状に関する情報、前記所定の画像の位置に関する情報、前記第２のモジュールが前記画像出力関数呼び出しの戻り値を返した時刻、該戻り値、色情報の有無の少なくともいずれかを含むことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記出力手段により出力された履歴情報を分割し、１回の前記画像出力関数の呼び出しに伴って出力される前記履歴情報をレコードとして生成するレコード生成手段と、
前記レコード生成手段によって生成された前記レコードを前記画像情報の種類毎に一覧表示する表示手段と、
前記レコードをソートする基準となる前記画像情報の種類の指定を受け付ける指定受付手段と
を備え、
前記表示手段は、前記指定受付手段により指定された前記画像情報の種類毎に、前記レコード出力手段より出力されたレコードの内容をソートして再表示することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記表示手段は所定の条件を満たす前記レコードの内容を強調表示することを特徴とする請求項５に記載の情報処理装置。
【請求項７】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置の制御方法であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶手段に記憶する記憶制御工程と、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御工程によって前記記憶手段に記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力工程と
を備えることを特徴とする情報処理装置の制御方法。
【請求項８】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置の制御方法であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって予め設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、予め設定された前記色情報を取得する色情報取得関数を呼び出して前記第２のモジュールから色情報を取得し、当該色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力工程とを備えることを特徴とする情報処理装置の制御方法。
【請求項９】
前記色情報は有彩色であるか否かを判定する判定工程を更に備え、
前記出力工程は、前記判定工程により有彩色と判定された前記色情報を前記画像情報と対応づけて履歴情報として出力することを特徴とする請求項７又は８に記載の情報処理装置の制御方法。
【請求項１０】
前記画像情報は、前記画像出力関数が呼び出された時刻、前記所定の画像の形状に関する情報、前記所定の画像の位置に関する情報、前記第２のモジュールが前記画像出力関数呼び出しの戻り値を返した時刻、該戻り値、色情報の有無の少なくともいずれかを含むことを特徴とする請求項７乃至９のいずれか１項に記載の情報処理装置の制御方法。
【請求項１１】
前記出力工程により出力された履歴情報を分割し、１回の前記画像出力関数の呼び出しに伴って出力される前記履歴情報をレコードとして生成するレコード生成工程と、
前記レコード生成工程によって生成された前記レコードを前記画像情報の種類毎に一覧表示する表示工程と、
前記レコードをソートする基準となる前記画像情報の種類の指定を受け付ける指定受付工程と
を備え、
前記表示工程は、前記指定受付工程により指定された前記画像情報の種類毎に、前記レコード出力工程より出力されたレコードの内容をソートして再表示することを特徴とする請求項１０に記載の情報処理装置の制御方法。
【請求項１２】
前記表示工程は所定の条件を満たす前記レコードの内容を強調表示することを特徴とする請求項１１に記載の情報処理装置の制御方法。
【請求項１３】
請求項７乃至１２のいずれか１項に記載の情報処理装置の制御方法をコンピュータに実行させるためのコンピュータプログラム。
【請求項１４】
請求項１３に記載のコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体。
【請求項１】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶する記憶制御手段と、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御手段によって記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段と
を備えることを特徴とする情報処理装置。
【請求項２】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって予め設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、予め設定された前記色情報を取得する色情報取得関数を呼び出して前記第２のモジュールから色情報を取得し、当該色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力手段とを備えることを特徴とする情報処理装置。
【請求項３】
前記色情報は有彩色であるか否かを判定する判定手段を更に備え、
前記出力手段は、前記判定手段により有彩色と判定された前記色情報を前記画像情報と対応づけて履歴情報として出力することを特徴とする請求項１又は２に記載の情報処理装置。
【請求項４】
前記画像情報は、前記画像出力関数が呼び出された時刻、前記所定の画像の形状に関する情報、前記所定の画像の位置に関する情報、前記第２のモジュールが前記画像出力関数呼び出しの戻り値を返した時刻、該戻り値、色情報の有無の少なくともいずれかを含むことを特徴とする請求項１乃至３のいずれか１項に記載の情報処理装置。
【請求項５】
前記出力手段により出力された履歴情報を分割し、１回の前記画像出力関数の呼び出しに伴って出力される前記履歴情報をレコードとして生成するレコード生成手段と、
前記レコード生成手段によって生成された前記レコードを前記画像情報の種類毎に一覧表示する表示手段と、
前記レコードをソートする基準となる前記画像情報の種類の指定を受け付ける指定受付手段と
を備え、
前記表示手段は、前記指定受付手段により指定された前記画像情報の種類毎に、前記レコード出力手段より出力されたレコードの内容をソートして再表示することを特徴とする請求項４に記載の情報処理装置。
【請求項６】
前記表示手段は所定の条件を満たす前記レコードの内容を強調表示することを特徴とする請求項５に記載の情報処理装置。
【請求項７】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置の制御方法であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに色情報を設定する色情報設定関数であるか否かを判定し、前記色情報設定関数である場合に、前記色情報を記憶手段に記憶する記憶制御工程と、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、前記記憶制御工程によって前記記憶手段に記憶された色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力工程と
を備えることを特徴とする情報処理装置の制御方法。
【請求項８】
第１、第２のモジュールと、該第１のモジュールから該第２のモジュール内の関数への呼び出しを仲介し、当該呼び出しに応じた該第２のモジュールにおける処理ログを取得するための第３のモジュールとを実行する情報処理装置の制御方法であって、
前記第１のモジュールにより呼び出し要求がなされた関数が、前記第２のモジュールに前記色情報設定関数によって予め設定された色情報を利用して所定の画像の出力を指示する画像出力関数であるか否かを判定し、前記画像出力関数である場合に、予め設定された前記色情報を取得する色情報取得関数を呼び出して前記第２のモジュールから色情報を取得し、当該色情報を前記所定の画像に関する画像情報と対応づけて履歴情報として出力する出力工程とを備えることを特徴とする情報処理装置の制御方法。
【請求項９】
前記色情報は有彩色であるか否かを判定する判定工程を更に備え、
前記出力工程は、前記判定工程により有彩色と判定された前記色情報を前記画像情報と対応づけて履歴情報として出力することを特徴とする請求項７又は８に記載の情報処理装置の制御方法。
【請求項１０】
前記画像情報は、前記画像出力関数が呼び出された時刻、前記所定の画像の形状に関する情報、前記所定の画像の位置に関する情報、前記第２のモジュールが前記画像出力関数呼び出しの戻り値を返した時刻、該戻り値、色情報の有無の少なくともいずれかを含むことを特徴とする請求項７乃至９のいずれか１項に記載の情報処理装置の制御方法。
【請求項１１】
前記出力工程により出力された履歴情報を分割し、１回の前記画像出力関数の呼び出しに伴って出力される前記履歴情報をレコードとして生成するレコード生成工程と、
前記レコード生成工程によって生成された前記レコードを前記画像情報の種類毎に一覧表示する表示工程と、
前記レコードをソートする基準となる前記画像情報の種類の指定を受け付ける指定受付工程と
を備え、
前記表示工程は、前記指定受付工程により指定された前記画像情報の種類毎に、前記レコード出力工程より出力されたレコードの内容をソートして再表示することを特徴とする請求項１０に記載の情報処理装置の制御方法。
【請求項１２】
前記表示工程は所定の条件を満たす前記レコードの内容を強調表示することを特徴とする請求項１１に記載の情報処理装置の制御方法。
【請求項１３】
請求項７乃至１２のいずれか１項に記載の情報処理装置の制御方法をコンピュータに実行させるためのコンピュータプログラム。
【請求項１４】
請求項１３に記載のコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２００６−２８５７９３（Ｐ２００６−２８５７９３Ａ）
【公開日】平成１８年１０月１９日（２００６．１０．１９）
【国際特許分類】
【出願番号】特願２００５−１０６８００（Ｐ２００５−１０６８００）
【出願日】平成１７年４月１日（２００５．４．１）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成１８年１０月１９日（２００６．１０．１９）
【国際特許分類】
【出願日】平成１７年４月１日（２００５．４．１）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]