On Tue, 29 Apr 2008, Peter Beutner wrote: > Steven Edwards schrieb: >> On Mon, Apr 28, 2008 at 3:51 AM, Steven Edwards <[EMAIL PROTECTED]> wrote: >>> On Sun, Apr 27, 2008 at 9:19 AM, Dan Kegel <[EMAIL PROTECTED]> wrote: >>> > 2. You never clear that environment variable... what happens >>> > when an app just tests for the existence of a DLL by >>> > trying to load it? We don't want to print an error then. >>> > (That's why I originally suggested clearing the env var >>> > after the app finished loading. That's still broken -- it >>> > won't catch errors in helper exes -- but it's better than nothing.) >>> >>> I assume you mean if the application is just checking manually for the >>> dll via GetModuleHandle or LoadLibrary? I'll write a test case for >>> this to see if it causes a problem. My assumption was that the failure >>> case for that was at a higher level but I'll check with a test case. I >>> don't think we need to clear the variable....what I mean is I wonder >>> if there is a way to set the variable to be inherited by all child >>> processes launched by start.exe.so in unix mode. I'll look in to this >>> as well. >> >> I assumed the code path must be different so I wrote a test app that >> tried to do a GetProcAddress or LoadLibrary on a non-existent dll and >> was right, It did not throw the messagebox. > > But I think it will still trigger the msg box if the application is checking > for > an existent foo.dll via LoadLibrary and foo.dll depends on a missing xyz.dll. > It won't trigger if you clear the environment variable as Dan said. > I'm not sure though which way is the right one here.
Windows doesn't do that - when my application tries to load a module that links against a missing DLL then LoadLibrary simply fails without showing any message. The "ignore it if LoadLibrary fails" logic is common in many programs that use optional plugins. Paul Chitescu
