loaddll が失敗したときの freedll - 秀丸エディタβ版 - スレッド03589, 2003/12/14

loaddll が失敗したときの freedll

Iranoan さん　03/12/14 21:29

　秀丸担当さん今日は、Iranoan です。
　loaddll が失敗したとき、freedll をしても、呼び出し先の DllMain() 関
数内の DLL_PROCESS_DETACH が呼び出されません。DllMain() のヘルプを見る
と、DLL_PROCESS_DETACH は、
> DLL のロードに失敗したこと、プロセスが終了すること、FreeLibrary を呼び
> 出したことのいずれかの理由で、呼び出し側プロセスの仮想アドレス空間から
> DLL をアンロードしようとしていることを示します。
とあります。そこで
(1) loaddll の結果にかかわらず、freedll を実行した時点
(2) loaddll が失敗した時点
のどちらかで、DLL_PROCESS_DETACH の処理をするようにして頂けないでしょ
うか?
　##それとも私が使用している環境
> GCC.EXE (GCC) 3.3.1 (mingw special 20030804-1)
が悪いのかな?

　loaddll が失敗した時は、プロセス終了時点に DLL_PROCESS_DETACH の処理
がされるようですが、鶴亀はシングル・プロセスマルチ・スレッドなので、常
駐を含め全ての鶴亀を終了させる必要があって、DLL の一般公開を考えると、
注意事項としても説明が非常にしにくいです。
　こちらの環境は、Windows98+IE6.0+秀丸 Ver.4.10β4 です。

RE:03589 loaddll が失敗したときの freed

杉浦　まさき さん　03/12/15 01:45

Iranoan さん、こんばんは。
杉浦　まさきです。

>　loaddll が失敗したとき、freedll をしても、呼び出し先の DllMain() 関
>数内の DLL_PROCESS_DETACH が呼び出されません。

気になったので調べてみました。で、DllMain(DLL_PROCESS_ATTACH)
から FALSE が返った時に DllMain(DLL_PROCESS_DETACH) が
呼ばれないのは確かなんですが、その犯人は __DllMainCRTStartup()
（※）です。上記の場合 DLL_PROCESS_DETACH は
__DllMainCRTStartup() に届いていますが、上の状況のときは
何もせずに関数から抜けています。

んで…回避策は色々あるとは思いますが、
DLL_PROCESS_ATTACH が失敗した時に後始末を終えてしまうのが
一番なのでは？と思います。

※C-Runtime Library を初期化するための「本当の」
　DLL エントリポイント関数で、ユーザー定義の DllMain() は
　その関数の中で呼ばれています。ただし、gcc では違う名前に
　なっているかもしれません。

RE:03591 loaddll が失敗したときの freed

Iranoan さん　03/12/15 12:59

　秀丸担当さん、杉浦さん今日は、Iranoan です。
> 気になったので調べてみました。
　態々調べて頂きありがとございます。
　##本業がお忙しいとのことでしたので、ご登場されるとは思っていませんで
した(^^)。

> DllMain(DLL_PROCESS_ATTACH)
> から FALSE が返った時に DllMain(DLL_PROCESS_DETACH) が
> 呼ばれないのは確かなんですが、その犯人は __DllMainCRTStartup()
> （※）です。
　そうなんですか。そうなると、
> DLL_PROCESS_ATTACH が失敗した時に後始末を終えてしまうのが
> 一番なのでは？と思います。
確かにこの方法が無難ですね。どうも有り難うございました。

　というわけで、要望は取り下げます。→秀丸担当さん