(57)【要約】【課題】  印刷課金。【解決手段】  Ｗｉｎｄｏｗｓ（登録商標）のＡＰＩ呼び出しログを取得するＰＡＴの機能に、カラー判別の機能を追加し、アプリケーションがＷｉｎｄｏｗｓ（登録商標）に対してカラーデータを渡している証拠を取り、カラーかモノクロかで異なる印刷料金の課金のユーザクレームの解決を図る。ＤＩＢのビットマップ形式ごとにチェック関数を用意しておき、どの形式か判別してカラー属性が設定されているかどうかのトレースを容易にする。【選択図】  図１５
2006040216.tif 000002
【特許請求の範囲】
【請求項１】
複数にモジュール分けされているソフトウェアにおいて、あるモジュールから別のモジュール内に存在する関数への呼び出しを、ログ取得のためのルーチンにリダイレクトする手段を有し、リダイレクトしたログ取得ルーチン内部に計時手段を有し、リダイレクトしたログ取得ルーチン内部に呼び出し時のパラメータを判別する手段を有し、リダイレクトしたログ取得ルーチン内部で元の関数を呼び出す手段を有し、元の関数を呼び出す際に、その関数からの戻りをログ取得ルーチンにリダイレクトさせる手段を有し、リダイレクトしたログ取得ルーチン内部で関数からの戻り値を判別する手段を有する、ソフトウェア評価システム。
【請求項２】
上記ソフトウェア評価システムにおいて、あるモジュールから別のモジュール内に存在するCOMサーバのメソッドへの呼び出しを、ログ取得のためのルーチンにリダイレクトする手段を有し、リダイレクトしたログ取得ルーチン内部に計時手段を有し、リダイレクトしたログ取得ルーチン内部に呼び出し時のパラメータを判別する手段を有し、リダイレクトしたログ取得ルーチン内部で元のメソッドを呼び出す手段を有し、元のメソッドを呼び出す際に、そのメソッドからの戻りをログ取得ルーチンにリダイレクトさせる手段を有し、リダイレクトしたログ取得ルーチン内部でメソッドからの戻り値を判別する手段を有する、ソフトウェア評価システム。
【請求項３】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンにリダイレクトする手段として、呼び出し元がメモリにロードするインポート関数アドレステーブルを、ログ取得のためのルーチンがロードされたメモリアドレスに書き換える手段を有する、ソフトウェア評価システム。
【請求項４】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンにリダイレクトする手段として、呼び出し元がメモリにロードするVirtual Address Tableを、ログ取得のためのルーチンがロードされたメモリアドレスに書き換える手段を有する、ソフトウェア評価システム。
【請求項５】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンが、呼び出された関数の情報を記録する手段を有し、書き換える前のインポート関数アドレステーブルに記載された元の関数を呼び出す手段を有する、ソフトウェア評価システム。
【請求項６】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンが、呼び出されたメソッドの情報を記録する手段を有し、書き換える前のVirtual Address Tableに記載された元のメソッドを呼び出す手段を有する、ソフトウェア評価システム。
【請求項７】
上記ソフトウェア評価システムにおいて、ログ取得ルーチン内部で、関数/メソッドの呼び出された時刻、及び関数/メソッド呼び出し時のパラメータ、関数/メソッドから処理が戻った時刻、及び関数/メソッドからの戻り値をログとして記録する手段を有する、ソフトウェア評価システム。
【請求項８】
上記ソフトウェア評価システムにおいて、ログ取得ルーチン内部で、関数/メソッド呼び出し時のパラメータをメモリアドレスと判別する手段を有し、関数/メソッド呼び出し時の該当メモリアドレスの内容を保持する手段を有し、関数/メソッドから処理が戻った時点での該当メモリアドレスの内容を保持する手段を有し、関数/メソッド呼び出し時及び関数/メソッドから処理が戻った時点での該当メモリアドレスの内容を、ログとして記録する手段を有する、ソフトウェア評価システム。
【請求項９】
上記ソフトウェア評価システムにおいて、各モジュールのエクスポートする関数一覧を取得する手段を有し、メモリに配置されたインポート関数アドレステーブルのうち、何れの関数をログ取得ルーチンにリダイレクトするかの設定を、エクスポートする関数一覧から選択する手段を有する、ソフトウェア評価システム。
【請求項１０】
上記ソフトウェア評価システムにおいて、各COMサーバのエクスポートするインターフェース及びメソッド一覧を取得する手段を有し、メモリに配置されたVirtual Address Tableのうち、何れのメソッドをログ取得ルーチンにリダイレクトするかの設定を、エクスポートするインターフェース及びメソッド一覧から選択する手段を有する、ソフトウェア評価システム。
【請求項１１】
上記ソフトウェア評価システムにおいて、各モジュールのエクスポートする関数一覧、もしくは各COMサーバのエクスポートするインターフェース及びメソッド一覧をファイル形式で供給する手段を有し、そのファイル内に、エクスポートされたそれぞれの関数/メソッドにおけるパラメータ及び戻り値の定義を記述する手段を有し、その定義ファイルから、何れのモジュールの、何れの関数/メソッドの、何れのパラメータ、あるいは何れの戻り値をログ取得ルーチンにより記録するかの設定を、選択する手段を有する、ソフトウェア評価システム。
【請求項１２】
上記ソフトウェア評価システムにおいて、何れのモジュールの、何れの関数/メソッドの、何れのパラメータ、あるいは何れの戻り値をログ取得ルーチンにより記録するかの設定を、ファイルとして保存する手段を有し、そのファイルを読み込む手段を有し、エクスポートする関数一覧、もしくは各COMサーバのエクスポートするインターフェース及びメソッド一覧として供給されたファイルを読み込む手段を有し、その2つのファイルに示された情報を以って、インポート関数アドレステーブル、もしくはVirtual Address Tableの何れのアドレスを、ログ取得のためのルーチンがロードされたメモリアドレスに書き換えるか選択する手段を有する、ソフトウェア評価システム。
【請求項１３】
上記ソフトウェア評価システムにおいて、関数/メソッドがプリンタ装置への出力能力を有するか否かを定義する手段を有し、定義されたプリンタ装置への出力能力を有する関数/メソッドのパラメータとして得られる出力属性を保持する構造体へのハンドルを読み出す手段を有する、ソフトウェア評価システム。
【請求項１４】
上記ソフトウェア評価システムにおいて、定義されたプリンタ装置への出力能力を有する関数/メソッドのパラメータとして得られる出力属性を保持する構造体へのハンドルから、構造体のメンバを読み出し、どの構造体メンバがビットマップ情報への関連を持つかを定義する手段を有し、ビットマップ情報への関連を持つ構造体メンバから、ビットマップ情報構造体を得る手段を有する、ソフトウェア評価システム。
【請求項１５】
上記ソフトウェア評価システムにおいて、ビットマップ情報構造体が持つビットマップが、複数ある形式のうち何れ形式のビットマップであるかをあらかじめ定義する手段を有する、ソフトウェア評価システム。
【請求項１６】
上記ソフトウェア評価システムにおいて、複数ある形式のうち何れの形式のビットマップであるかの定義手段を用いて、得られたビットマップ情報構造体が持つビットマップが何れの形式であるかを判断し、その形式に基づきデータ内容をピクセル単位で読み出す手段を有する、ソフトウェア評価システム。
【請求項１７】
上記ソフトウェア評価システムにおいて、ピクセル単位で読み出されたビットマップのデータ内容から、それぞれの色要素に分解して取得する手段を有し、それぞれの色要素の強さを数値として取得する手段を有し、各色要素の強さの数値を比較する手段を有し、各色要素の強さの数値を比較するに際して、プリンタ装置へのカラー指定能力を持つ出力属性のデータ内容が有彩色であるのか否かを判別する手段を有し、有彩色であると判別したことを以って、カラー指定能力を持つ出力属性のデータ・ログを明示するためのキーをデータ・ログのファイルに保存する手段を有する、ソフトウェア評価システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数にモジュール分けされたソフトウェアの動作確認、デバッグ及び評価において、モジュール自体に変更を加えることなく、モジュール内に用意された関数の呼び出しをログとして記録し、解析する手段を与えることで、ソフトウェアにおける再現率の低い障害の原因を特定し、開発の工数を削減する効果を与える。
【背景技術】
【０００２】
再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得することによって対処している場合が多いが、従来、処理ログの取得はソフトウェアのモジュール自体に手を加えて、処理ログ取得ルーチンを追加することによって行なわれている。プリンタ装置等の出力装置においても、例えば特定のカラーを意図して出力したデータに対して、出力結果が異なる、という障害が発生することがあるが、そういった障害の特定に際しても、モジュール自体に手を加えて、処理ログ取得ルーチンを追加し、ソフトウェアの各モジュールを通ったカラー・データのログをモジュール毎に取得して、それらを解析する、という手段が取られることが多い。
【特許文献１】特開２００２−７１０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上記従来の技術には8点の問題点がある。
【０００４】
１．ユーザの動作環境でもログを取得しつづけるためには、モジュール本体にログ取得用の変更が入ったものを使用する必要がある。
【０００５】
２．モジュール毎にログ取得を行なうため、生成されたログはモジュール単位の物となってしまい、ソフトウェア全体の処理を、完全に時間順のログとして取得するのが困難である。
【０００６】
３．全体の処理ログとしての見通しが悪いため、ログを解析して問題点を発見するまでのプロセスに工数がかかる。
【０００７】
４．カラー・データのすべてをログに保存すると、ログ取得に多大な時間がかかる。
【０００８】
５．カラー・データのすべてをログに保存すると、ログ・ファイルのサイズが膨大になる。
【０００９】
６．その結果、必要なデータを発見できず、あるいはすべて解析する時間が取れずに、障害の原因究明まで至らないことがある。
【００１０】
７．ビットマップでの描画がカラーで描かれているかどうかの判断は、ビットマップ作成時には容易だが、いつ使用されるかをトレースするのは困難である。
【００１１】
８．グラフィックライブラリのバージョンが異なる環境では、それぞれのバージョンに合わせたログ取得用モジュールを用意しなければならない。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明においては、あるモジュールから別のモジュール内に存在する関数の呼び出しが行なわれる際の仕組みである、メモリに保持されたインポート関数アドレステーブル、もしくはvirtual address tableを利用して、モジュール間の関数呼び出しをフックし、モジュール名、関数名、インターフェース名、メソッド名、時刻、パラメータ、戻り値等をログに記録するという手段を持った、ログ記録の機能を設ける。また、関数定義ファイルに、カラー出力に関連する関数/メソッドを定義する手段を設け、カラー関連の障害に関わりのないログ記録を省く。また、明示的にカラー出力を指定しないビットマップの描画においては、ビットマップの形式からそのデータ内容を調べる手段を設ける。それらを使用することで、カラー出力に関連する障害の原因を迅速に特定することを可能とする。
【発明の効果】
【００１３】
本発明を施したソフトウェア評価システムを用いることで、ソフトウェアの問題点を解析する工数が削減される。特に、プリンタ装置にカラー出力を行なう際に、従来は取得が難しかった、アプリケーション・ソフトウェアとオペレーティングシステムとの間でビットマップ描画コマンドがどのようにやり取りされているかの情報を、アプリケーション・ソフトウェア及びオペレーティングシステムのソースコード及びオブジェクトコードを、一切変更せずに取得する手段を提供することで、プリンタ装置のカラー出力に関連する障害の解決にかかる工数が削減される。
【発明を実施するための最良の形態】
【００１４】
＜実施形態１＞
図１は、本発明を施したソフトウェア評価システムの構成をあらわす図である。説明を簡略化するために、本実施例では、本ソフトウェア評価システムが1台のPC内部に構築されるものとするが、本発明の特徴は1台のPC内部に構築されるか、あるいは複数のPCにネットワークシステムとして構築されるかによらず有効である。
【００１５】
本ソフトウェア評価システムを搭載するコンピュータには、CPU1、チップセット2、RAM3、ハードディスクコントローラ4、ディスプレイコントローラ5、ハードディスクドライブ6、CD-ROMドライブ7、ディスプレイ8が搭載されている。また、CPUとチップセットを繋ぐ信号線11、チップセットとRAMを繋ぐ信号線12、チップセットと各種周辺機器とを繋ぐ周辺機器バス13、ハードディスクコントローラとハードディスクドライブを繋ぐ信号線14、ハードディスクコントローラとCD-ROMドライブを繋ぐ信号線15、ディスプレイコントローラとディスプレイを繋ぐ信号線16が搭載されている。
【００１６】
本発明を施したソフトウェア評価システムを説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。
【００１７】
通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行なう実行ファイルEXE(23)と、モジュールとして存在しEXEの補完的な役割を担うダイナミックリンクライブラリDLL(27)とに分かれており、メモリにはEXEとDLLの両方がロードされる。EXEはコードセグメント(28)とデータセグメント(29)、そしてインポート関数アドレステーブル(22)から成っている。更に、インポート関数アドレステーブルは、関数の所属するDLLによって分かれており(21,24)、DLLごとにそれぞれの関数がロードされたアドレスが書かれている(30〜35)。DLLの関数の実体は、DLLごとに分かれて(25, 26)ロードされ、それぞれの関数は該当するDLLの一部としてロードされる(36〜41)。この図では、1本のEXEがA.DLL及びB.DLLの2つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はFunc AA, Func AB, Func AC, Func BA, Func BB, Func BCの6個となっている。
【００１８】
EXEのコードセグメント内にあるコードが関数Func AAを呼び出す場合には、まずインポート関数アドレステーブル内に書かれたFunc AAのアドレス(30)が読み込まれる。ここには実際にはA.DLLの一部として読み込まれたFunc AAコード(36)のアドレスが書かれており、そのアドレスをコールすることによって、EXEのコードはA.DLLのFunc AAを呼び出すことができる。
【００１９】
図３は、本発明を施したソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してIAT Patch(Import Address Table Patch)という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。
【００２０】
ログ取得が開始されると、メモリ内にはIAT Patch用のDLLであるC.DLL(58)がロードされる。C.DLLはインポート関数アドレステーブル(52)内に書かれた関数のアドレスを、C.DLL内のログ取得コードであるFunc CAA, Func CAB, Func CAC, Func CBA, Func CBB, Func CBCのアドレスに書き換える(61〜66)。C.DLL内のFunc CAA, Func CAB, Func CAC, Func CBA, Func CBB, Func CBCのコード(73〜78)は、ログを記録すると共に、元々関数呼び出しを受けるべくメモリにロードされている、該当する関数であるFunc AA, Func AB, Func AC, Func BA, Func BB, Func BC(67〜72)を呼び出す。
【００２１】
図４は、図３におけるIAT Patchの処理をあらわすタイミングチャートである。説明を簡略化するために、この図ではEXEがA.DLL内のFunc AAを呼び出す際に、IAT Patchによるログ取得コードがどのように動作するかの例をあらわしている。
【００２２】
EXE(91)がFunc AAをコールすると(94)、C.DLL内にあるログ取得コードがDLL名/関数名をメモリに保存し、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタ・パラメータの指すメモリ内容を、メモリに保存する(95)。その後C.DLLは本来呼び出されるはずであった、A.DLL(93)内のFunc AAをコールする(96)。A.DLLのFunc AA処理(97)が終了し、C.DLLに制御がリターンすると(98)、C.DLLはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタ・パラメータが指すメモリ内容を、メモリに保存する(99)。その後、C.DLLは保存したログ情報をファイルに書き込み(100)、あたかもA.DLLのFunc AAが通常通りに終了したかのように、EXEにリターンする(101)。
【００２３】
図５は、本発明を施したソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のEXE(113)が、DLL-1(116)やDLL-2(117)内の関数を呼び出すが、ここではAPIトレーサと呼ばれるログ取得コードを埋め込み(114)、処理ログを生成している(115)。APIトレーサは、DLL-1やDLL-2の関数定義を記述したファイル(111)と、どのDLLのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ(112)を元に動作する。
【００２４】
図６は、本発明を施したソフトウェア評価システムにおいて、通常、実行ファイルEXE(118)がCOMサーバでエクスポートされているインターフェースのインスタンス作成時に、通常の状態でどのようにメモリにロードされるかを説明する。
【００２５】
通常、インターフェースのインスタンス作成を行なうと、COMサーバ内で、要求されたインターフェース(121, 122)と、そのメソッド(130〜135)が作成され、それらは、メモリ上に両方がロードされる。ここで、virtual address tableは作成された各インターフェース毎に作られ(118, 120)、作成要求を行ったEXEに渡される。このvirtual address tableには各メソッドの作成されたアドレスが書かれている(124〜129)。EXEはこれら情報を利用し、各インターフェースに対して呼び出しを行なう。この図では、1本のEXEがInterface A及びInterface Bの2つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Method AA, Method AB, Method AC, Method BA, Method BB, Method BCとなっている。
【００２６】
EXEのコードが関数Method AAを呼び出す場合には、まずvirtual address table内に書かれたMethod AAのアドレス(124)が読み込まれる。ここには実際にはCOMサーバのInterface Aの一部として作成されたMethod AAコード(130)のアドレスが書かれており、そのアドレスをコールすることによって、EXEのコードはInterface AのMethod AAを呼び出すことができる。
【００２７】
図７は、本発明を施したソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してVTable Patch(virtual address table Patch)という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。
【００２８】
ログ取得が開始されると、メモリ内にはVTable Patch用のDLL(143)がロードされる。このDLLはvirtual address table(136, 138)内に書かれたメソッドのアドレスを、DLL内のログ取得コードであるMethod A'A, Method A'B, Method A'C, Method B'A, Method B'B, Method B'Cのアドレスに書き換える(145〜150)。DLL内のMethod A'A, Method A'B, Method A'C, Method B'A, Method B'B, Method B'Cのコード(157〜162)は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるMethod AA, Method AB, Method AC, Method BA, Method BB, Method BC(157〜162)を呼び出す。
【００２９】
図８は、図７におけるVTable Patchの処理をあらわすタイミングチャートである。説明を簡略化するために、この図ではEXEがCOMサーバ内のInterface AのMethod AAを呼び出す際に、VTable Patchによるログ取得コードがどのように動作するかの例をあらわしている。
【００３０】
EXE(163)がMethod AAをコールすると(166)、DLL内にあるログ取得コードがモジュール名/インターフェース名/メソッド名をメモリに保存し、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタ・パラメータの指すメモリ内容を、メモリに保存する(167)。その後DLLは本来呼び出されるはずであった、COMサーバ(165)内のMethod AAをコールする(168)。COMサーバのMethod AA処理(169)が終了し、DLLに制御がリターンすると(170)、DLLはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタ・パラメータが指すメモリ内容を、メモリに保存する(171)。その後、DLLは保存したログ情報をファイルに書き込み(172)、あたかもCOMサーバのMethod AAが通常通りに終了したかのように、EXEにリターンする(173)。
【００３１】
図９は、本発明を施したソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のEXE(176)が、COMサーバ-1(179)やCOMサーバ-2(180)内のメソッドを呼び出すが、ここではAPIトレーサと呼ばれるログ取得コードを埋め込み(177)、処理ログを生成している(178)。APIトレーサは、COMサーバ-1(179)やCOMサーバ-2の関数定義を記述したファイル(174)と、どのCOMサーバのどのインターフェースのどのメソッドのvirtual address tableを書き換えてログを取得するかの設定シナリオ(175)を元に動作する。
【００３２】
図１０は、本発明を施したソフトウェア評価システムの関数定義の一例であり、一般的に広く用いられているIDLにより、記述されている。本発明を施したソフトウェア評価システムに於いては、このIDLをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、本発明は付加バイナリ情報取得のための定義手段を提供することを特徴とするものであり、関数定義はIDLでなくても構わない。例えば、通常のテキストファイルを用いることも可能であり、XMLなどのマークアップ言語を用いることも可能である。
【００３３】
図１１は、本発明を施したソフトウェア評価システムに於いて、プリンタ出力データのカラー判別を行なうための、関数定義ファイルの例である。
【００３４】
本実施例では、オペレーティングシステムにOSGraphicKernel.dllというダイナミックリンクライブラリファイルが用意されており、そのライブラリ内に、矩形描画を行なうためのRectangle関数(201)が用意されている。Rectangle関数の第一パラメータはデバイスコンテキスト(202)、すなわちオペレーティングシステムによって仮想化された「面」に対するハンドルである。デバイスコンテキストにはディスプレイ向けのものとプリンタ向けのものが用意されており、Rectangle関数の第一パラメータでプリンタ向けのハンドルを選択して、その他のパラメータを入力することにより、プリンタ装置に対して矩形の描画コマンドが発行される。
【００３５】
またビットマップ転送のBitBlt関数(203)には第１パラメータparam0として転送先デバイスコンテキスト(204)が、第6パラメータparam5として元データのデバイスコンテキスト(205)が渡される。一般にビットマップの描画は、メモリデバイスコンテキストからプリンタ用デバイスコンテキストに転送することで行なわれる。同様にビットマップ拡大・縮小転送のStretchBlt関数(206)には第１パラメータparam0として転送先デバイスコンテキスト(207)が、第6パラメータparam5として元データのデバイスコンテキスト(208)が渡される。
【００３６】
図１２は、本発明を施したソフトウェア評価システムに適用される、アプリケーション・ソフトウェアがプリンタ出力データを作成する際に用いる、ビットマップ構造体の例である。
【００３７】
この例のビットマップ構造体は、ビットマップに関する情報を持つヘッダ(211)、どどの数値がどのカラーを意味するかを持つカラーテーブル(212)、矩形領域の各ピクセルの持つカラーを数値で持つピクセルビット(213)からなる。またビットマップ情報ヘッダは、１ピクセルあたりのビット数を表すビットカウント数(214)、圧縮方法compression(215)、カラーテーブル212の要素の個数を表すカラーテーブル数(216)のような内容を持つ。
【００３８】
図１３は、本発明を施したソフトウェア評価システムに適用される、アプリケーション・ソフトウェアがプリンタ出力データを作成する例である。この例を用いて、ビットマップ描画を行なう際にどのようにカラーの設定を行なうかを説明する。
【００３９】
アプリケーション・ソフトウェアでは、まず、ビットマップ情報ヘッダ211、カラーテーブル212およびピクセルビット213の実体を置くメモリを確保しておく(221)。カラーテーブル212に実際使用するテーブルの内容を、確保したメモリ上へ書き込み(222)、またピクセルビット213の内容をメモリ上へ書き込む(223)。またこれらで使用する内容に関する情報を元に、ビットマップ情報ヘッダのビットカウント数214に値を書き込む(224)。圧縮方法215、カラーテーブル数216も同様にして値を埋める(225, 226)。
【００４０】
その後、プリンタへのデバイスコンテキストを取り(227)、作成したビットマップ構造体からデバイス依存のビットマップを作成する(228)。またプリンタと互換性のあるメモリデバイスコンテキストを作成し(229)、そのメモリデバイスコンテキストに対してデバイス依存のビットマップを選択する(230)。メモリデバイスコンテキストをプリンタデバイスコンテキストへ展開する(231)ことで、プリンタへ出力したことになる
この例からわかるように、231の展開時に初めてカラー情報をプリンタに対して送るが、実際にカラー情報を設定するのは、ずっと前のステップである223, 224である。
【００４１】
図１４は、本発明を施したソフトウェア評価システムに於いて、IAT Patch及びVTable Patchを用いて、プリンタ装置に対応するデバイスコンテキストに対してアプリケーション・ソフトウェアが描画コマンドを発行する際に、その描画された色を判別する処理をあらわす流れ図である。
【００４２】
処理が開始されると(S1)、ログ取得を開始し、モジュール名、インターフェース名、関数/メソッド名をHDDに保存する(S2)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をHDDに保存する(S3)。次に、関数がカラーを描画する可能性のある関数であるかを判別し(S4)、もしカラー描画する可能性のある関数であれば、その関数のパラメータであるデバイスコンテキストから、カラー属性が実際に設定されているかどうかを調べる(S5)。その後、元の関数を呼び出し(S6)、関数からリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をHDDに保存する(S7)。この処理はユーザから終了の命令があると(S8)終了する(S9)。
【００４３】
S4においてカラーを描画する設定でない場合、やはり元の関数を呼び出し(S10)、ユーザから終了の命令があると終了する(S9)。
【００４４】
このビットマップ描画の例では、S4においてBitBltが呼ばれた際に、S5でカラー属性の設定を調べ、元の関数を呼び出し、リターン時の時刻、戻り値、ポインタ・パラメータの指すメモリ内容をHDDに保存する。
【００４５】
図１５は、本発明を施したソフトウェア評価システムに於いて、カラーを描画する関数で実際にカラーの属性が設定されているかをチェックする流れ図である。図１４のS5をより詳細に記述したものである。
【００４６】
処理が開始されると(S11)、描画関数にパラメータとして渡されるデバイスコンテキストのハンドルから、デバイスコンテキストを得る(S12)。例えばBitBltの場合図１１の205で示したように、描画元のデバイスコンテキストのハンドルは、第6パラメータで渡ってくることが関数定義ファイルからわかるので、そこから得ることができる。次に得られたデバイスコンテキストからデバイス依存ビットマップを得る(S13)。そしてデバイス依存ビットマップから、それを作った元となるデバイス非依存のビットマップ構造体を得る(S14)。これは図１２で示している構造体そのものである。
【００４７】
ビットマップ構造体のビットマップ情報ヘッダ211のメンバである、ビットカウント、compression215を元にして、チェックする処理を判断して(S15)、カラーチェックの処理を行なう。この流れ図には、ビットカウントが１のRGBの場合(S16)、ビットカウントが８のランレングス圧縮がかかっている場合(S17)、およびビットカウントが24であるトゥルーカラーの場合(S18)のみ描かれている。図の関係で省略するが、実際にはビットカウントが４、８、１６、３２等のケース、また4ビットランレングス圧縮のケースがあり、それぞれのケースに合わせたチェック処理がある。いずれかのチェック処理を行なうと終了する(S19)。
【００４８】
図１６は、本発明を施したソフトウェア評価システムに於いて、ビットカウントが1、すなわち1ビットカラーのビットマップにおいて実際にカラーが設定されているかをチェックする流れ図である。図１５のS16をより詳細に記述したものである。
【００４９】
処理が開始されると(S21)、まずカラーテーブル212を見て、そこに設定されている最大2つの要素を見る(S22)。もしいずれも無彩色であれば、このビットマップにはカラーが書かれることはないので、終了する(S29)。
【００５０】
いずれかが有彩色である場合は以下の処理へ進む。カラーテーブルは一般にRGB形式だが、そうでない場合にはRGB形式に変換しておき(S23)、インデクスiの値を０にして(S24)、全ピクセルのチェックに入る(S25)。
【００５１】
i番目のピクセルの値0もしくは1を見て、カラーテーブル212の有彩色を持つ要素であれば(S26)、そのピクセルは有彩色であると判断し、見つけたピクセルの色をS23で変換したRGB形式でHDに保存する(S27)。もし有彩色を持つ要素でなければ次のピクセルのチェックへ移る(S28)。全ピクセルのチェックが終われば処理を終了する(S29)。
【００５２】
図１７は、本発明を施したソフトウェア評価システムに於いて、ビットカウントが24、すなわちTRUEカラーのビットマップにおいて実際にカラーが設定されているかをチェックする流れ図である。図１５のS18をより詳細に記述したものである。
【００５３】
処理が開始されると(S41)、まずインデクスiの値を０にして(S42)、全ピクセルのチェックに入る(S43)。i番目のピクセルである24ビットを取り出しRGBの値に変換する(S44)。もしそのピクセルが、有彩色と判断されれば(S45)、見つけたピクセルの色をRGBの値でHDに保存する(S46)。もし有彩色でなければ次のピクセルのチェックへ移る(S47)。全ピクセルのチェックが終われば処理を終了する(S48)。
【００５４】
これらの処理により、カラー出力の関数でのみチェックを行なうことで、いつ使用されるかが不明なカラーのビットマップ作成関数のトレースや関連付けなどの複雑な処理をしなくても、カラー出力を検出することが可能である。
【００５５】
またこのような仕組みを準備することで、OSやグラフィックライブラリのバージョンにより、サポートされるビットマップ形式が異なる場合でも、その形式に合わせたチェック用の関数を追加・削除するだけで対応できる。
【００５６】
例えばMicrosoft Windows（登録商標）での描画では、DIB(Device Independent Bitmap)といわれるフォーマットを用いており、現在ビットカウントが２すなわち2ビット/ピクセル形式のビットマップはWindows（登録商標） CEでのみサポートしているが、仮に、新しいバージョンの他のWindows（登録商標）でのサポートが行なわれた場合には、CEで用いられているチェック用関数をWindows（登録商標）に追加し判断部分のみ修正すればよい。全くあらたな形式がサポートされた場合でも、チェック用の関数の作成・追加と判断部分の修正で対応することが可能である。ログの取得モジュールそのものには、大きく手を入れる必要がない。
【００５７】
以上述べたように、IAT Patch及びVTable Patchを用いてカラー出力を検出することにより、プリンタ装置等へのカラー出力において発生した障害に対して、アプリケーション・ソフトウェアがオペレーティングシステムに対してどのような指示を行なった結果その障害が発生したのかを、明示的に知ることができる。また、カラー出力機能を持つ関数に対応するログ・レコードに対してのみ、カラー情報フィールドを含むようなログを生成することで、その後にカラー関連の処理のみを抽出することを容易なものとしている。このことは、カラー関連の障害の原因を特定する際に、より迅速な作業が可能であることを意味している。
【図面の簡単な説明】
【００５８】
【図１】実施例１におけるソフトウェア評価システムを搭載した、コンピュータの構成をあらわす図である。
【図２】実施例１を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。
【図３】実施例１におけるソフトウェア評価システムを搭載した、コンピュータのIAT Patch使用時のメモリ構成をあらわす図である。
【図４】実施例１におけるソフトウェア評価システムのIAT Patchを使用時のタイミングチャートである。
【図５】実施例１におけるソフトウェア評価システムのIAT Patchを使用時の内部構成をあらわす図である。
【図６】実施例１を説明するためにあらわした、COMサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。
【図７】実施例１におけるソフトウェア評価システムを搭載した、コンピュータのVTable Patch使用時のメモリ構成をあらわす図である。
【図８】実施例１におけるソフトウェア評価システムのVTable Patchを使用時のタイミングチャートである。
【図９】実施例１におけるソフトウェア評価システムのVTable Patchを使用時の内部構成をあらわす図である。
【図１０】実施例１におけるソフトウェア評価システムの関数定義ファイルの例をあらわす図である。
【図１１】実施例１におけるソフトウェア評価システムの関数定義ファイルの例をあらわす図である。
【図１２】実施例１におけるソフトウェア評価システムのビットマップ構造体の例である。
【図１３】実施例１におけるソフトウェア評価システムのプリンタに出力するアプリケーション・ソフトウェアの例である。
【図１４】実施例１におけるソフトウェア評価システムのカラーログ保存処理の流れ図である。
【図１５】実施例１におけるソフトウェア評価システムのビットマップにカラー属性が設定されているかをチェックする処理の流れ図である。
【図１６】実施例１におけるソフトウェア評価システムのビットマップが１ビットカラー形式の場合のチェック処理の流れ図である。
【図１７】実施例１におけるソフトウェア評価システムのビットマップが24ビットカラー形式の場合のチェック処理の流れ図である。
【符号の説明】
【００５９】
１  ＣＰＵ
２  チップセット
３  ＲＡＭ
４  ハードディスクコントローラ
５  ディスプレイコントローラ
６  ハードディスクドライブ
７  ＣＤ−ＲＯＭドライブ
８  ディスプレイ
１１  ＣＰＵとチップセットを繋ぐ信号線
１２  チップセットとＲＡＭを繋ぐ信号線
１３  チップセットと各種周辺機器とを繋ぐ周辺機器バス
１４  ハードディスクコントローラとハードディスクドライブを繋ぐ信号線
１５  ハードディスクコントローラとＣＤ−ＲＯＭドライブを繋ぐ信号線
１６  ディスプレイコントローラとディスプレイを繋ぐ信号線
【図１】
2006040216.tif 000003
【図２】
2006040216.tif 000004
【図３】
2006040216.tif 000005
【図４】
2006040216.tif 000006
【図５】
2006040216.tif 000007
【図６】
2006040216.tif 000008
【図７】
2006040216.tif 000009
【図８】
2006040216.tif 000010
【図９】
2006040216.tif 000011
【図１０】
2006040216.tif 000012
【図１１】
2006040216.tif 000013
【図１２】
2006040216.tif 000014
【図１３】
2006040216.tif 000015
【図１４】
2006040216.tif 000016
【図１５】
2006040216.tif 000017
【図１６】
2006040216.tif 000018
【図１７】
2006040216.tif 000019