| |
▼DULLさん：
>▼ひよひよさん：
>
>>ということですが、CrystalCPUID.exe だけ最適化でも OK だったりしませんか？
>両方の最適化をOFFにしないとダメです。
ふむふむ。
>>なんにせよ、次回リリースからは最適化オフで出したいと思います。
>個人的には最適化ON/OFFの両方を公開する方が良いと思います。
>OFFバ〜ジョンは頻繁にバ〜ジョンアップしないで確認用とか。
それも一案ですが・・・。
>スタックが狂っているようなので原因を考えると
>・アセンブラでPUSH/POP等を間違っている。
>・呼び出し規約の_stdcallと_cdeclが間違っている。
呼び出し規約までは考えてことがありませんでした。
ありそー。
>後者を疑って/Gz(強制 _stdcall使用)を試しました。
>CrystalCPUID.exe は libpng の仕様でビルド失敗。
>SysInfo.DLL は /Gz を通過したので実行してみました。
libpng をはずせばうまく動いたりするんでしょうか？
#define USEPNG
あたりをコメントアウトして、libpng のリンクをやめれば
PNG サポートをオフにできるかと思います。
この状態で、最適化してもうまく動くんであれば、libpng を
使うのを辞めて、GDIPlus に切り替えるという方針も・・・。
>結果は起動中に「ページ違反」が発生。
>アドレスがいつもの落ちるアドレスと同じだったので
>もしかしたらこれが原因かも知れません。
怪しい。
>過去に私も libpng を使った事がありますが
>ファイル処理で関数ポインタを使う方法があります。
>このへんで呼び出し規約を間違ったりとか…？
libpng はずぅ〜っと、前にコンパイルしたものをそのまま
使っている(セキュリティは？？？)ので、
ちょっと考えてもいいのかもしれません。
>libpng のソ〜スを持ってきて -DPNGAPI __stdcall で
>ビルドして回避できないかと考えたりします。
>
>さらに pcidll.c の initialize() の
>char path[MAX_PATH];
>
>これだとパスが245文字以上のフォルダで実行されると
>path[] にはファイル名も入るのでバッファが
>オ〜バ〜フロ〜してしまう可能性があると思います。
>（ファイル名が固定なので確立はかなり低いですが…）
Windows って 256 文字以上のパスって基本的に実現できないんですよね？？？
MAX_PATH は WinDef.h で 260 と定義しているので大丈夫だと信じています。
>ではでは。
なんだか、神の香りがしてきた今日この頃です。
一段落したら、Special Thanks コーナーに追加させていただきますね。
libpng は疑ったことが一度もありませんでした。
この件が解決すれば、今まで動かない〜とレポートしてくださった方の環境でも動くようになるのかも。
|
|
