On Sat, 04 Sep 2004 15:15:33 +0200, Hans Leidekker wrote:
There are applications (eDonkey is one of them IIRC) that call LoadLibray() themselves on a number of DLLs.
LoadLibrary should check the Wine DLL path first, as far as I know at least for DLLs that default to builtin. So if the program does LoadLibrary("c:\windows\system\user32.dll") for instance, it should still load the builtin DLL just fine. At least this is my understanding. Before wineprefixcreate there were lots of custom scripts for building the fake windows directory and touching these files was a common technique.
Could be that they do their own linking as part of some anti-debugging technique, I don't know, but it's perfectly legal for application to do that anyway.
For these apps having empty DLL files will not be enough. I actually was able to fool the app by putting MinGW cross compiled Wine DLLs in the system directory until it needed kernel32.dll, which doesn't compile. I had to resort to a native win2k kernel32.dll to get it past this but this may still be a good alternative to your empty DLL files.
For the vast majority of apps, empty files should be enough. Some will want to examine the headers and a tiny minority might actually try and do their own PE linking instead of letting the OS do it.
For the ones that examine the headers by opening the file directly, I did think about this while writing the patch (but, had only limited time, so went for the tried-and-true approach). I think the best way to deal with that is just having a simple native ELF app (ie not winelib) that dlopens each library in the Wine DLL path, then extracts the PE header from the binary and writes it out. We already compile PE headers into the ELF DLLs to make apps that walk the headers in memory happy, it would not be hard to generate them at prefix creation time.
Maybe Alexandre has some thoughts on this though. The alternative I guess is to hack the FS code so if we detect the app is opening an empty DLL file in c:\windows\system we map the PE headers in and feed it that.