1.0 idea - ntdll - add a messagebox for missing dlls
paulc at voip.null.ro
Tue Apr 29 09:44:53 CDT 2008
On Tue, 29 Apr 2008, Peter Beutner wrote:
> Steven Edwards schrieb:
>> On Mon, Apr 28, 2008 at 3:51 AM, Steven Edwards <winehacker at gmail.com> wrote:
>>> On Sun, Apr 27, 2008 at 9:19 AM, Dan Kegel <dank at kegel.com> 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.
More information about the wine-devel