Paul Chitescu schrieb:
On Tue, 29 Apr 2008, Peter Beutner wrote:
Steven Edwards schrieb:
On Mon, Apr 28, 2008 at 3:51 AM, Steven Edwards winehacker@gmail.com wrote:
On Sun, Apr 27, 2008 at 9:19 AM, Dan Kegel dank@kegel.com wrote:
- 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.
So clearing the env variable would be the correct thing. But still not entirely satisfying as mentioned above by Dan.
I just tried to solve it differently, doing it entirely in ntdll. (and probably you could even do it without using a global variable) It certainly avoids all that pain dealing with environment variables ;).
Not really heavily tested, but I think it works.