Create DLL stub files in c:\windows\system

[Mike Hearn]

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.