筆者にとっては Susie でプラグインが満足に動作しさえすれば特に問題は無い(^^;のだが、暇つぶしに有名どころの Susieプラグイン対応アプリケーション の挙動を調べていく。
どの SPI対応アプリ でも動作させるにはどのようにプラグインを作成したらいいのか、SPI対応アプリ はこのように実装したほうがいい、というような情報も扱っていく。
・Susie ver0.46
・Grapholic Version 1.7
・ViX V2.1
・Linar version 1.6(version 1.6.50β)
この他にもいろいろあるが、フリーソフトである、それなりに広く使われている、カタログ(サムネイル)表示できる、00IN だけでなく 00AM にも対応している、プラグインの設定ダイアログを表示できる、というようなもっともらしい理由は後で考えた(^^;(独断と偏見)。
ベータ版については挙動が異なる場合のみ記述している。
Windows98SE でテストした。NT系 では結果が異なるかもしれない。
各アプリケーションの16ビット、32ビットDIB への対応状況を調査する。
テスト画像は、増田 隆氏 の「まんでる version 1.70」(マンデルブロー集合描画ソフト)で作成した画像を、「SeeDIB.exe」で変換したものを使用した。
トップダウン や RLE の対応状況についても調査する。
トップダウン の BMP はバイナリエディタで biHeight の値を書き換えて作成した。RLE の BMP は「SeeDIB.exe」で変換して作成した。
・テストで使用した BMP ファイル(174,592 バイト)
この調査には 後藤あきら氏 の「Susie32 Bitmap Plug-in Ver.0.10.6501」(現在入手不可?)を使用した。このプラグインは設定により、16ビット、32ビットDIB を 24ビットDIB に変換せずそのまま返してくれる。RLE、トップダウンもそのまま返す設定がある。
「SeeDIB.exe」は
http://support.microsoft.com/support/kb/articles/Q94/3/26.asp
からダウンロードしたソースを Visual C++6.0SP4 でコンパイルしたものを使用した。
・Susie ver0.45a
DIBの種類 カタログの表示 「開く」での表示 16ビットBI_RGB 本体がこのBMPを処理した場合はOK。
プラグインが返した場合は真っ黒に表示される。本体がこのBMPを処理した場合はOK。
プラグインが返すとクラッシュする?(ver0.45gではOK)16ビットBI_BITFIELDS 本体はこのBMPに対応していない。
プラグインが返した場合は真っ黒に表示される。プラグインが返すとクラッシュする?(ver0.45gではクラッシュしないものの正常に表示されない) 32ビットBI_RGB 真っ黒に表示される。
(ver0.45hでは、本体がこのBMPを処理した場合はOK。プラグインが返した場合は真っ黒に表示される。)本体がこのBMPを処理した場合は正常に表示されない。(ver0.45hではOK)
プラグインが返した場合はOK。32ビットBI_BITFIELDS 本体はこのBMPに対応していない。
プラグインが返した場合は真っ黒に表示される。プラグインが返すとOK。(ただしver0.45gでは正常に表示されない) トップダウン 本体がこのBMPを処理しようとした場合はクラッシュする。
プラグインが返した場合は真っ白に表示される。本体がこのBMPを処理しようとした場合はクラッシュする。
プラグインが返した場合は正常に表示されない(高さはマイナス表示)。RLE 本体がこのBMPを処理した場合はOK。
プラグインが返した場合はクラッシュする。OK
・Susie ver0.46
DIBの種類 カタログの表示 「開く」での表示 16ビットBI_RGB 本体がこのBMPを処理した場合はOK。
プラグインが返した場合は真っ黒に表示される。OK 16ビットBI_BITFIELDS 本体はこのBMPに対応していない。
プラグインが返した場合は真っ黒に表示される。本体はこのBMPに対応していない。
プラグインが返した場合は正常には表示されない。32ビットBI_RGB 本体がこのBMPを処理した場合はOK。
プラグインが返した場合は真っ黒に表示される。OK 32ビットBI_BITFIELDS 本体はこのBMPに対応していない。
プラグインが返した場合は真っ黒に表示される。本体はこのBMPに対応していない。
プラグインが返した場合は正常には表示されない。トップダウン 本体がこのBMPを処理しようとした場合はクラッシュする。
プラグインが返した場合は横に細長く表示される。本体がこのBMPを処理しようとした場合はクラッシュする。
プラグインが返した場合は正常に表示されない(高さはマイナス表示)。RLE 本体がこのBMPを処理した場合はOK。
プラグインが返した場合はクラッシュする。OK
・Grapholic Version 1.7
DIBの種類 プレビュー 表示 16ビットBI_RGB DecDIB.GHPがこのBMPを処理した場合はOK。
Ifbitmap.spiが返した場合は真っ黒に表示される。OK 16ビットBI_BITFIELDS DecDIB.GHPがこのBMPを処理した場合はOK。
Ifbitmap.spiが返した場合は真っ黒に表示される。DecDIB.GHPがこのBMPを処理した場合はOK。
Ifbitmap.spiが返した場合は正常に表示されない32ビットBI_RGB DecDIB.GHPがこのBMPを処理した場合はOK。
Ifbitmap.spiが返した場合は真っ黒に表示される。OK 32ビットBI_BITFIELDS DecDIB.GHPがこのBMPを処理した場合はOK。
Ifbitmap.spiが返した場合は真っ黒に表示される。DecDIB.GHPがこのBMPを処理した場合はOK。
Ifbitmap.spiが返した場合は正常に表示されないトップダウン DecDIB.GHPが処理した場合には16ビット、32ビットトップダウンは期待通りには表示されなかった。
Ifbitmap.spiが返すとクラッシュする。DecDIB.GHPが処理した場合には16ビット、32ビットトップダウンは期待通りには表示されなかった。
Ifbitmap.spiが返すと正常に表示されない(真っ黒で高さはマイナス表示)。RLE DecDIB.GHPが処理した場合にはOK。
Ifbitmap.spiが返すとクラッシュする。DecDIB.GHPが処理した場合にはOK。
Ifbitmap.spiが返すとクラッシュする。
Grapholic作者が某掲示板に、Grapholicはプラグインが16・32ビットDIBを返す事は想定していない、と書いてあった。
次のバージョンでは対応されるかもしれない。
・ViX V1.6
DIBの種類 カタログ 表示 16ビットBI_RGB OK 本体がこのBMPを処理した場合はOK。
プラグインが返した場合は正常に表示されない。16ビットBI_BITFIELDS OK OK 32ビットBI_RGB OK OK 32ビットBI_BITFIELDS OK OK トップダウン 本体はこのBMPに対応していない。
プラグインが返した場合はアイコン表示になる。本体はこのBMPに対応していない(エラーメッセージが表示される)。
プラグインが返した場合はエラーメッセージが表示される。RLE 本体がこのBMPを処理した場合は OK。
プラグインが返した場合は正常に表示されない。本体がこのBMPを処理した場合は OK。
プラグインが返した場合には RLE4 は正常に表示されない。RLE8 は OK。
・ViX V2.0
DIBの種類 カタログ 表示 16ビットBI_RGB OK OK 16ビットBI_BITFIELDS OK OK 32ビットBI_RGB OK OK 32ビットBI_BITFIELDS OK OK トップダウン 本体がこのBMPを処理した場合は OK。
プラグインが返した場合はアイコン表示になる。本体がこのBMPを処理した場合は OK。
プラグインが返した場合はエラーメッセージが表示される。RLE 本体がこのBMPを処理した場合は OK。
プラグインが返した場合は正常に表示されない。本体がこのBMPを処理した場合は OK。
プラグインが返した場合には RLE4 は正常に表示されない。RLE8 は OK。
・Linar version 1.5
DIBの種類 サムネイル表示 表示 16ビットBI_RGB 本体はこのBMPに対応していない。
プラグインが返した場合はエラーが出る。NG 16ビットBI_BITFIELDS 本体はこのBMPに対応していない。
プラグインが返した場合はエラーが出る。NG 32ビットBI_RGB 本体はこのBMPに対応していない。
プラグインが返した場合はOK。プラグインが返した場合はOK。 32ビットBI_BITFIELDS 本体はこのBMPに対応していない。
プラグインが返した場合は色が化ける。プラグインが返した場合はOK。
・Linar version 1.6
DIBの種類 サムネイル表示 表示 16ビットBI_RGB OK OK 16ビットBI_BITFIELDS OK OK 32ビットBI_RGB OK OK 32ビットBI_BITFIELDS OK OK トップダウン 本体はこのBMPに対応していない。
プラグインが返した場合はアイコン表示になる。本体はこのBMPに対応していない。
プラグインが返した場合は「画像表示できません」。RLE 本体がこのBMPを処理した場合は OK。
プラグインが返した場合は正常に表示されない。(1.6.28βではOK)OK
●ちょっと考察
16ビットや32ビットの DIB を表示することはそんなに難しい事なのだろうか?
試しに GetPicture で画像データを取得して SetDIBits ファンクションに渡すプログラムを書いて実行したところ、これらの DIB を問題無く表示することが出来た。
ただしこれは単にそのまま表示するだけのプログラムだ。各アプリはもっともっと複雑なことをしているはずである。例えばサムネイル表示する場合などは画像の縮小を Win32 API で処理していてはかなり汚くなってしまうし、また、画像データは処理しやすいように内部で独自のデータ形式で保持していることも十分に考えられる。
この内部データへの変換時やサムネイル作成時に16(32)ビットBI_RGB(BI_BITFIELDS)への対応が考慮されていないか、対応に不具合があるものと思われる。サムネイル表示と普通に表示させた時の結果が異なるが、これはサムネイル作成はそれ用のルーチンで処理しているということなのだろう。
調査してみたものの、Susieプラグイン を作成するときは 16(32)ビットDIB を返してはいけないというのが常識になっているので問題は無いだろう。16(32)ビットBMP の読み込みには 24ビットで返してくれる Susieプラグイン を利用すると良い。いっそのこと BMP の読みこみすらも本体が処理するのではなく、プラグインまかせにしても良いのではないかと筆者は考えてしまうのだが。
●ちょっと考察2
トップダウンと RLE の対応状況は芳しくない。が、それほど困る事はないだろう。プラグインが RLE で返すとは考え難いし、Microsoft のツールでさえ トップダウンDIB には対応していない(対応しない仕様を作るな)。
よって本体が RLE の BMP に対応していれば通常の使用には問題無いといえる。
●まとめ
アプリ名 16・32ビットDIB対応 備考 Susie × 対応しているとはいえない。 Grapholic △ BMP は○だが、DIB は対応しているとはいえない。 ViX ○ V2.0以降を使用する事。 Linar ○ version 1.6以降を使用する事。
各アプリケーションがどのようにプラグインを利用しているのかを調査する。
拙作の「TEST00IN ver0.11a」「TEST00AM ver0.08」の結果を元にした。
※間違いの無いように気をつけてはいるのですが、この結果は一例に過ぎないかもしれません...
■Susie ver0.45a
起動時に設定 - プラグインでチェックしているものが読みこまれる。
プラグインの有効・無効の設定を変更しても、この設定が有効になるのは Susie の次回起動時。
●画像ファイルを表示する際の呼び出しシーケンス
・1.IsSupported
非0 を返すと2.へ。
0 を返すと1-1.へ。
・1-1.IsSupported
また同じ条件で呼ばれる。
0 を返すと 今度は 128バイトずらしたメモリを渡される。
非0 を返すと2.へ。
・2.GetPictureInfo
どのような値を返しても 3.へ
・3.GetPicture
0 を返すと表示される。
●00IN 備考
GetPluginInfo
infono buflen 0 8 1 128 2以降 255
Plug-in APIバージョン はチェックされる。
00IN か 00AM なのかはこの文字列で判断される。
2n+2、2n+3 のペアを返した数だけ IsSupported の呼ばれる回数が増えるようだ。
IsSupported 常にメモリ渡し。 GetPictureInfo flag は 0(ディスクファイル入力)。
書庫内ファイルは 1(メモリ上のイメージ)。
オフセットは IsSupported で 非0 を返したときのもの。
PictureInfo は 0 初期化されていない。
返却した PictureInfo は hInfo 以外は使用されていないようだ。
0 以外を返してもエラーにはならない。
GetPicture flag は 0(ディスクファイル入力)。
書庫内ファイルは 1(メモリ上のイメージ)。
オフセットは IsSupported で 非0 を返したときのもの。
pPrgressCallback は NULL ではない。
biXPelsPerMeter, および biYPelsPerMeter は(解像度ではなく)アスペクト比として使用されるようだ。
GetPreview GetPicture に同じ。
カタログ作成時にのみ呼び出される。
-1 を返すと GetPicture が呼ばれる。
ConfigurationDlg 特に無し。
しいていえば、戻り値は何を返しても問題無い。
●書庫ファイルを展開する際の呼び出しシーケンス
複雑なのでパスです(^^;
IsSupported, GetArchiveInfo, GetFileInfo はしつこいほど頻繁に呼ばれます。
●00AM 備考
GetPluginInfo 00IN に同じ。 IsSupported 00IN に同じ。 GetArchiveInfo flag は 0(ディスクファイル入力)。
書庫内ファイルは 1(メモリ上のイメージ)。
オフセットは IsSupported で 非0 を返したときのもの。
この関数の成否はエラーコードで判断されない。
*lphInf が NULL かどうかで判断しているようだ。
GetFileInfo flag は 0x180 と謎のビットがある。
基本的にディスクファイル入力、ファイル名の大文字小文字を同一視する。
書庫内ファイルはメモリ上のイメージ入力。
オフセットは IsSupported で 非0 を返したときのもの。
まず最初に”_THUMBNL.SUE”を聞いてくる。
GetFile 基本的にディスクファイル入力、出力先はメモリ。
書庫内ファイルはメモリ上のイメージ入力。
ConfigurationDlg 00IN に同じ。
●Susie ver0.45a → ver0.45g でのプラグイン関係の変更点
起動時にプラグインは一度ロードされて GetPluginInfo の後にアンロードされる。後は設定と必要に応じてロード、アンロードされる。
プラグインの読みこみモードの設定変更が有効になるのは次回起動時。
カタログをバックグラウンドで作成可能になったため、プラグインはスレッドセーフを気にする必要がある。
●Susie ver0.45g → ver0.45h でのプラグイン関係の変更点
アーカイブ内のファイルやファイル情報をキャッシュする機能が追加された。
GetFileInfo は呼び出さなくなったようだ。
これまでメモリ入力で渡されるデータのサイズは、
おそらく GetFile で返されたハンドルで LocalSize したサイズと思われる(4の倍数切り上げ)。
ver0.45h からは GetArchiveInfo で得た fileInfo の filesize が渡されるようになったようだ。
Susie本体はメモリ入力時のデータサイズをきちんと見ているようで、
fileInfo の filesize が実際より少ない場合には、BMP画像の上部分が黒く表示されたり、
コピーしたときにデータが途中で切れてしまう。
fileInfo の filesize が 0 の場合には、これまで通りの LocalSize したサイズが渡されるようだ。
■Grapholic Version 1.7
起動時にプラグインは一度ロードされて GetPluginInfo の後にアンロードされる。後は設定と必要に応じてロード、アンロードされる。
プラグインの有効・無効の設定の変更は即有効。ただし起動時のチェック時に存在していないプラグインは設定できない。
メモ:
「TEST00IN」「TEST00AM」を アタッチ、デタッチ、GetPluginInfo を通知するようにすると起動時のデタッチ後に落ちてしまう。
●画像ファイルを表示する際の呼び出しシーケンス
・プラグインの確定
ファイルの拡張子から対応プラグインを推定しているようだ。
プラグインの優先順位はとりあえず不明ということにしておく。
画像チェックを実行するとIsSupported が呼ばれる。
オフセット 0 が対応していなければ、オフセット 128 で呼ばれる。
・表示
画像タイプのプラグイン以外は使用されない。
まず IsSupported が呼ばれる。
オフセット 0 が対応していなければ、オフセット 128 で呼ばれる。
IsSupported で 非0 を返すと GetPictureInfo が呼ばれる。
GetPictureInfo で何を返しても GetPicture が呼ばれる。
GetPicture で 0 を返すと表示。
●00IN 備考
GetPluginInfo buflen は 512。
Plug-in APIバージョン はチェックされる。
00IN か 00AM なのかはこの文字列で判断される。
IsSupported 常にファイルハンドル渡し。 GetPictureInfo flag は常に 0(ディスクファイル入力)。
書庫内ファイルは一度ファイルに展開されるため。
オフセットは IsSupported で 非0 を返したときのもの。
PictureInfo は 0 初期化されている。
返却した PictureInfo は使用されていないようである。
0 以外を返してもエラーにはならない。
GetPicture flag は常に 0(ディスクファイル入力)。
オフセットは IsSupported で 非0 を返したときのもの。
pPrgressCallback は NULL ではない。
biXPelsPerMeter, および biYPelsPerMeter は(解像度ではなく)アスペクト比として使用されるようだ。
ver0.45aでは、メモリ入力時のlenは4の倍数に切り上げられている。
(他のバージョンは未確認。)
GetPreview 全く使用されない。 ConfigurationDlg 特に無し。
●書庫ファイルを展開する際の呼び出しシーケンス
まず IsSupported が呼ばれる。
オフセット 0 が対応していなければ、オフセット 128 で呼ばれる。
IsSupported で 非0 を返すと GetArchiveInfo が呼ばれる。
ファイル数の分だけ GetFileInfo, GetFile が呼ばれる。
●00AM 備考
GetPluginInfo 00IN に同じ。 IsSupported 00IN に同じ。 GetArchiveInfo flag は常に 0(ディスクファイル入力)。
オフセットは IsSupported で 非0 を返したときのもの。
GetFileInfo flag は常に 0x80。
ディスクファイル入力、ファイル名の大文字小文字を同一視する。
オフセットは IsSupported で 非0 を返したときのもの。
GetFile flag は常に 0x100。
ディスクファイル入力、出力先はメモリ。
ConfigurationDlg 00IN に同じ。
■ViX V1.6
起動時に、設定で指定されたフォルダのプラグインを全てロードして GetPluginInfo。終了するまでプラグインはロードされたまま。プラグインの有効・無効の設定の変更は即有効。
書庫内書庫はサポートされない。
メモ:
ファイルの拡張子により使用するプラグインが決まるようだ。
対応拡張子にマッチしないファイルに対してプラグインは使用されない。
●画像ファイルを表示する際の呼び出しシーケンス
IsSupported をオフセット 0 で呼ぶ。
非0 を返すと GetPicture が呼ばれる。
●00IN 備考
GetPluginInfo buflen は 512。
Plug-in APIバージョン はチェックされる。
00IN か 00AM なのかはこの文字列で判断される。
("00IM", "00AN" も受け付ける。)
不明なバージョンでも終了するまでロードされたまま(使用される事は無い)。
書きこんだ文字列は戻り値のバイト数分以外は捨てられるようだ。
IsSupported 常にメモリ渡し。 GetPictureInfo 全く使用されない。 GetPicture flag は 0(ディスクファイル入力)。
オフセットは 0。
書庫内はメモリ入力。(設定によりテンポラリファイル経由も可)
pPrgressCallback は NULL ではない。
biXPelsPerMeter, および biYPelsPerMeter は使用されない。
GetPreview GetPicture に同じ。
カタログ作成時にのみ呼ばれる。
-1 を返すと GetPicture が呼ばれる。
ConfigurationDlg 特に無し。
●書庫ファイルを展開する際の呼び出しシーケンス
書庫ファイルは拡張子で判断される。(設定によりチェックさせることもできる)
IsSupported が何度か呼ばれる。
非0 を返していると GetArchiveInfo が呼ばれる。
IsSupported がまた呼ばれる。
ファイル数の分だけ IsSupported, GetFileInfo, GetFile を繰り返す。
メモ:
設定 - プラグイン で、「書庫ファイル操作」にチェックを入れ、「書庫ファイルの実質チェック」にもチェックする。この設定で、書庫ファイルを選択し、「フォルダ作成+すべて解凍」を実行させると、書庫ファイルの展開後に、プラグインの対応拡張子にマッチするファイル(指定した書庫ファイルとは別のファイル)が書庫チェックされる。基準は不明。他のタイミングでもチェックされるかもしれない。
●00AM 備考
GetPluginInfo 00IN に同じ。 IsSupported 00IN に同じ。 GetArchiveInfo flag は常に 0(ディスクファイル入力)。
オフセットは 0。
GetFileInfo flag は常に 0x80。
ディスクファイル入力、ファイル名の大文字小文字を同一視する。
オフセットは 0。
GetFile flag は常に 0x100。
ディスクファイル入力、出力先はメモリ。
ConfigurationDlg 00IN に同じ。
●ViX V1.6 → V2.0 でのプラグイン関係の変更点
起動時にプラグインデータベースと照合する。
未登録や更新されたプラグインはロードされ、GetPluginInfo で情報を取得しデータベースに登録する。
ロードされていないプラグインは必要になったときにはじめてロードされるが、後はロードされたままで終了まで解放される事は無い。
仕様?:
「画像のロード」をプラグイン優先にしていても、*.jpg対応のプラグインは使用されない?
メモ:
設定 - プラグイン で、「書庫ファイル操作」にチェックを入れ、「書庫ファイルの実質チェック」にもチェックする。
この設定では、よくわからないタイミングで、プラグインの対応拡張子にマッチするファイルが書庫チェックされる(バックグラウンドで)。対象になる基準は不明。
■Linar version 1.5
起動時に、設定で指定されたフォルダのプラグインを全ていったんロードする。ロードするときには GetPluginInfo を呼ぶ。「選択したプラグインのみをロードする」でなければ終了するまでプラグインはロードされたまま。プラグインの有効・無効の設定の変更は即有効。もちろん起動時のチェック時に存在していないプラグインは設定できない。
書庫内書庫はサポートされない。
●カタログ作成時の呼び出しシーケンス
IsSupported がファイルハンドル渡しオフセット 0 で呼ばれる。
(書庫内はメモリ渡しになる。)
「Macintoshバイナリの調査をする」にしている場合は、オフセット0、128、256、384、512と呼ばれる。
バグ?:オフセット0、オフセット512以外で非0を返しても非対応とされる。(version 1.6ではこのようなことはない)
IsSupported で対応していれば GetPictureInfo が ファイル入力オフセット 0 で呼ばれる。
(書庫内はメモリ入力になる。)
「Macintoshバイナリの調査をする」にしている場合は、オフセット0、128、256、384、512と呼ばれる。
GetPictureInfo でエラーを返しても GetPicture が ファイル入力オフセット 0 で呼ばれる。
(書庫内はメモリ入力になる。)
「Macintoshバイナリの調査をする」にしている場合は、オフセット0、128、256、384、512と呼ばれる。
メモ:
カタログにアイコンで表示されているファイルは、なんらかのタイミングで何度でもチェックし表示しようとする。
この不毛な敗者復活戦はWM_PAINT?で始まるため「TEST00IN」は注意して使う事・・・。(WM_PAINT?で関数が呼ばれる→プラグインのウィンドウ開く、閉じる→WM_PAINT?で関数が呼ばれる...)
他にもコメント入力時のサムネイルもWM_PAINT?で表示しているようだ。
●画像ファイルを表示する際の呼び出しシーケンス
カタログで表示に使用したプラグインを使用するようだ。
GetPicture がファイル入力オフセット0で呼ばれる。
(書庫内はメモリ入力になる。)
「Macintoshバイナリの調査をする」にしている場合にエラーを返すと、オフセット128、256、384、512 で呼ばれる。
●00IN 備考
GetPluginInfo buflen は 256。
Plug-in APIバージョン はチェックされる。
00IN か 00AM なのかはこの文字列で判断される。
IsSupported ファイルハンドル渡し。
書庫内はメモリ渡し。
GetPictureInfo カタログ作成時にのみ呼ばれる。
flagは 0(ディスクファイル入力)。
書庫内はメモリ入力。
PictureInfo は 0 初期化されている。
返却した PictureInfo は情報一覧ビューに使用される。
GetPicture flagは 0(ディスクファイル入力)。
書庫内はメモリ入力。
pPrgressCallback は NULL ではない。
biXPelsPerMeter, および biYPelsPerMeter は使用されない。
GetPreview 全く使用されない。 ConfigurationDlg 特に無し。
●書庫ファイルを展開する際の呼び出しシーケンス
拡張子で書庫ファイルとみなされる。(「書庫ファイルをツリーに表示する」設定にしなければ書庫ファイルは扱えない)
IsSupported がファイルハンドル渡しオフセット 0 で呼ばれる。
「Macintoshバイナリの調査をする」にしている場合は、オフセット0、128、256、384、512と呼ばれる。
非0 を返すと GetArchiveInfo が呼ばれる。
GetFile が同じファイルに対して何度か呼ばれる。
●00AM 備考
GetPluginInfo 00IN に同じ。 IsSupported 常にファイルハンドル渡し。 GetArchiveInfo flag は常に 0(ファイル入力)。
GetFileInfo 全く使用されない。 GetFile flag は 0x100。
ファイル入力、出力先はメモリ。
ConfigurationDlg 00IN に同じ。
●Linar version 1.5 → version 1.6 でのプラグイン関係の変更点
IsSupported は常にメモリ渡しになった。
●Linar version 1.6 → version 1.6.16β でのプラグイン関係の変更点
GetArchiveInfo の戻り値は無視される。lphinfのハンドル検査で成否判定。
fileInfo の position が 0 か、filesize が 0 の場合 GetFileInfo を呼ぶ。
らしい...(確認していません^^;)
Susieプラグイン の仕様の通りに対応アプリケーションを作成したはずだが、動作しない Susieプラグイン があるのは何故だろうか?
Susieプラグイン の仕様は明確にされていないところもあり、プラグイン製作者によって実装が異なる場合がある。それでも仕様の範囲内であればその差は吸収できるはずだ。しかし、中には Susie で動作しさえすれば良いとばかりに、Susie では使用されない部分は実装していないこともある。そのようなプラグインもサポートしたいのならば、Susie と同様なプラグイン呼び出しをするしかないだろう。
ここでは Susieプラグイン が実際にはどのように実装されているのかを調査し、プラグインをどのように扱ったら良いのかを検討していく。
●00INプラグイン
GetPluginInfo
infono ... 0 バージョン番号は「4バイト」だが、実際には {'0','0','I','N','\0'} と5バイト書きこむのがほとんどである。
バッファを4バイトしか用意しないと {'0','0','I','\0'} を返すものもある。
よって、バッファは 5 バイト以上用意するべきだろう。
1 以降 文字列は NULL終端 されると思われるが、もしもバッファサイズが足りない場合でも必ず NULL終端 されるだろうか?
返す「書きこんだバイト数」は strlen で計算した値(NULLターミネータは数えない)であることも多い。
心配ならば、buflen にはバッファサイズ-1 を渡し、NULL終端 する。
IsSupported ファイルハンドルを渡すとファイルがより良くチェックされるように思われるかもしれないが、そのようなことはほとんど無いだろう。Susieでは常にメモリで渡されるためか、メモリ渡しでは対応するがファイルハンドル渡しでは対応しないプラグインもあるようだ。
個人的には、プラグインの作者にファイルハンドル渡しにも対応してもらいたいところだ。
IsSupported では「対応している」「対応していない」のどちらかしか返されないためエラーが起きても判断のしようがない。
GetPictureInfo この関数で得られる情報は「画像ファイルの情報」であって、GetPicture で返される DIB の情報 ではない。(Susie では 16・32ビットDIB に対応していないことから、GetPictureInfo では 16ビット であっても、GetPicture で返される DIB は 24ビット、ということがある)
Susie でもあまり重要視されない関数であることから、実装されていない、または常にエラーを返すプラグインもあるようだ。
画像内のテキスト情報を得るための関数と割り切るしかないのかもしれない。
関数に渡す PictureInfo 構造体は 0 で埋めておくのが無難である(プラグインの中には、特定のメンバにしか値を書きこまないものがある)。
GetPicture lpPrgressCallback に NULL を渡されることがあるのを考慮していないプラグインが存在する。
これは仕様にもあるのだからプラグイン作者に修正してもらいたいところだ。コールバック関数の必要無いアプリケーションであっても、何もしないダミーのコールバック関数を渡すようにするといいだろう。
このことはコールバック関数が渡される他の関数でも同様である。
00INプラグインでは、ファイル入力かメモリ入力かの違いで苦労することは無さそうに思われるが、Susieでは基本的にファイル入力で書庫内のファイルはメモリ入力であることからか、どちらか片方の入力しか受け付けないプラグインがある。
GetPreview -1 を返すだけの関数でも実装しなければならないはずだが、この関数が無いプラグインも存在するようだ。
ConfigurationDlg 唯一この関数だけが実装していなくても構わない関数のはずである。
-1 を返すだけの関数をインプリメントするのもまぎらわしい。
必要でなければ実装するべきではないだろう。
●00AMプラグイン
GetPluginInfo 00INプラグインに同じ。
IsSupported 00INプラグインに同じ。
GetArchiveInfo Susie では GetFile の前に必ず GetFileInfo が呼ばれるためか(さらには Susie では GetArchiveInfo が頻繁に何度も呼ばれるためか?)、GetArchiveInfo ではダミーの情報を返すプラグインがあるようだ。
一度展開しなければ filesize(元のファイルサイズ)を得ることができないアーカイブ形式のプラグインが filesize を 0 に設定する程度で、position がダミー情報のプラグインは未確認。
※Susie ver0.45h 以降は GetFileInfo は呼ばれず GetArchiveInfo のみ使用されている。
Plug-in package ver0.05 の lhasad.spi は、GetArchiveInfo を呼び出すと成功しても 2 が返ってくる。
対処法としては渡すハンドルに NULL を入れて呼び出した後も NULL であるかを見るか、呼び出した後に有効なハンドルであるかを見る。Susie は前者の方法で判断しているようであるから、同じチェック方法で十分だろう。
Plug-in package ver0.06 の00AMプラグインは、GetArchiveInfo の戻り値は最下位バイト以外不定。(Susieの質問箱:1806。検索ワード「enum」)
Plug-in package ver0.07 の lhasad.spi は、GetArchiveInfo を呼び出すと成功しても返ってくるのはあいかわらず 2 だ。
lhasad.spi ver0.05 で GetArchiveInfo をメモリ入力で呼び出すとページ違反になることがある。LZHヘッダが LEVEL 1 のものは問題無いようだが、LEVEL 2 のヘッダの場合は渡したデータサイズを超えてアクセスする。LEVEL 2 ヘッダの場合の終端判定に不具合があるようだ。
(lhasad.spi ver0.06 で修正された、と思われる)
lhasad.spi の代わりに AmLzh.spi を使用すると良いだろう。
GetFileInfo GetFileInfo を呼ばなければ真の情報が得られないプラグインや、GetFileInfo が実装されていないプラグインがある(Susie ver0.45h 以降から GetFileInfo が呼ばれないため?)。 GetFile 後回しにしてしまったが、00AMプラグイン ではメモリ入力を受け付けないプラグインがある。
これは Susieプラグイン の仕様では、メモリ入力では対応が難しい形式があるためであろう。(Susie ではメモリ入力で渡されるのは書庫内のファイルのみ、ということもあるが)
「ファイル上の位置」だけではファイルを取り出すのが困難なものは、無理をしてメモリ入力に対応しているものがある。アーカイブファイル全体がメモリに読み込まれていて position 位置のアドレスを渡される、と期待して前方のアドレスにアクセスするものがあるようだ。
仕様にはファイルへの出力もあるが、Susie では使用されないためか実装していないプラグインがある。
実装されていたとしてもファイルへの出力は使用しないほうが無難である。メモリ出力を使用してアプリケーション側でファイルに出力するべきだろう。
ConfigurationDlg 00INプラグインに同じ。
2003.03/20
・このページはこのままにして新しい情報は新しいページで。
2001.09/09
・Susie ver0.46、ViX V2.1、Linar version 1.6.50βについて調査。
「DIBへの対応」更新。
・「プラグインの扱い」Susie の 変更点更新。
2001.08/20
・プラグインの挙動の00AMプラグイン更新
GetArchiveInfo と GetFileInfo。
2001.08/10
・Susie ver0.45i、ViX V2.01β5、Linar version 1.6.28βについて調査。
「DIBへの対応」更新。
・「プラグインの扱い」SusieのGetPicture更新。
・プラグインの挙動の00AMプラグイン更新
Plug-in package ver0.06 の 00AMプラグイン について。
もっと以前の履歴