Re: Create DLL stub files in c:\windows\system
On Saturday 4 September 2004 14:25, Mike Hearn wrote:
Make apps that search for the DLL files directly happy by creating empty files for each shipped library
There are applications (eDonkey is one of them IIRC) that call LoadLibray() themselves on a number of DLLs. 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. -Hans
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.
On Saturday 4 September 2004 15:28, Mike Hearn wrote:
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
Actually it was calling LoadLibraryEx() with the flag LOAD_LIBRARY_AS_DATAFILE set. If I read dlls/kernel/module.c correctly such a call will fail if the requested file is not a valid PE file. You could make it look like a valid PE file by just adding a PE header, but the next failure would probably be on accessing some resource or something else inside the DLL. -Hans
On Sat, 2004-09-04 at 14:52, Hans Leidekker wrote:
You could make it look like a valid PE file by just adding a PE header, but the next failure would probably be on accessing some resource or something else inside the DLL.
Well, yes, I know. But solving that one 100% reliably means making a cross compiler a buildreq of Wine, and that would be a big pain not to mention the difficulty involved with linking PE DLLs to native ELF libraries. It's probably best to just fix these sorts of apps as we find them on a case by case basis.
On Saturday 4 September 2004 16:29, Mike Hearn wrote:
Well, yes, I know. But solving that one 100% reliably means making a cross compiler a buildreq of Wine, and that would be a big pain not to
That would be developer pain traded for user pain. We like that don't we?
mention the difficulty involved with linking PE DLLs to native ELF libraries.
I don't understand this. Is this the consequence of having PE DLLs in c:\windows\system? Couldn't we still use the ELF variant for that (compiled from the very same source?). I mean, the PE DLLs would only serve as dummies for apps that need them, not used by Wine itself in case there is an ELF variant available. Hmm, maybe this is getting too complicated?
It's probably best to just fix these sorts of apps as we find them on a case by case basis.
We have some cross compiled DLLs on sourceforge now which we could point users to. -Hans
On Sat, 2004-09-04 at 15:45, Hans Leidekker wrote:
On Saturday 4 September 2004 16:29, Mike Hearn wrote:
Well, yes, I know. But solving that one 100% reliably means making a cross compiler a buildreq of Wine, and that would be a big pain not to
That would be developer pain traded for user pain. We like that don't we?
No it would definitely cause user pain as well. Look at what happened when we made a static libc a buildreq for the preloader - a whole ton of people found they couldn't build the latest version of Wine, or that their distro didn't provide a static libc or that they didn't know what the right package name was. There were a lot of confused users on #winehq, wine-users, linuxquestions.org (ie newbie forums). Unfortunately while we continue to have a large userbase who installs wine by compiling it from the source, we have to keep Wine easily buildable on all the major distros. In the end we pulled the static libc requirement for other reasons - some people had an ELF TLS enabled static builds which caused crashes as %gs wasn't initialised.
mention the difficulty involved with linking PE DLLs to native ELF libraries.
I don't understand this. Is this the consequence of having PE DLLs in c:\windows\system? Couldn't we still use the ELF variant for that (compiled from the very same source?). I mean, the PE DLLs would only serve as dummies for apps that need them, not used by Wine itself in case there is an ELF variant available. Hmm, maybe this is getting too complicated?
Well yes, we could build each DLL twice, but that seems very inefficient. I think if we wanted to switch to PE builds we'd want to do it properly. Besides, if we do find apps that do their own dynamic linking for copy protection or whatever, then the PE DLLs couldn't be dummies as they'd actually be loaded and run. Which does lead to the question of how we can ever support such apps (hopefully they are hypothetical). Programs that do their own dynamic linking won't be linked against the native ELF support libraries we use to implement Wine.
We have some cross compiled DLLs on sourceforge now which we could point users to.
Yes. Difficulty is knowing when an app is playing up because it's screwing around with the on disk binaries. That's not something we could ever expect users to diagnose.
Le sam 04/09/2004 à 10:29, Mike Hearn a écrit :
On Sat, 2004-09-04 at 14:52, Hans Leidekker wrote:
You could make it look like a valid PE file by just adding a PE header, but the next failure would probably be on accessing some resource or something else inside the DLL.
Well, yes, I know. But solving that one 100% reliably means making a cross compiler a buildreq of Wine, and that would be a big pain not to mention the difficulty involved with linking PE DLLs to native ELF libraries.
What we could do is if such a cross-compiler is detected at build time, use it to build PE dlls in addition to ELF dlls (or in place of? Not sure yet). If no cross-compiler is detected, nothing different from now happens.
It's probably best to just fix these sorts of apps as we find them on a case by case basis.
How? Remove a particular touched dll from c:\windows\system? If you have two apps, one wanting the 0-sized dll and the other one choking on it, what do you do? Vincent
On Sat, 2004-09-04 at 15:49, Vincent Béron wrote:
What we could do is if such a cross-compiler is detected at build time, use it to build PE dlls in addition to ELF dlls (or in place of? Not sure yet). If no cross-compiler is detected, nothing different from now happens.
That would lead to the same program working for one person and not for another, for no obvious reason. You could argue that already happens, but I think we should try and avoid introducing even more ways it can occur.
How? Remove a particular touched dll from c:\windows\system? If you have two apps, one wanting the 0-sized dll and the other one choking on it, what do you do?
Well I doubt any app actually relies on a DLL being empty, that'd never work on Windows. If you find an app which requires more than the filename to exist then yes, you could can just overwrite it with a real PE file.
On Sat, Sep 04, 2004 at 04:08:11PM +0100, Mike Hearn wrote:
On Sat, 2004-09-04 at 15:49, Vincent B??ron wrote:
What we could do is if such a cross-compiler is detected at build time, use it to build PE dlls in addition to ELF dlls (or in place of? Not sure yet). If no cross-compiler is detected, nothing different from now happens.
What happens to binary distrobutions? (Ugh.) Does it mean that now, the maintainer *must* have a cross-compiler? And that the user must have X, Y, and Z, to make the cross-compiled DLL/binaries work?
That would lead to the same program working for one person and not for another, for no obvious reason. You could argue that already happens, but I think we should try and avoid introducing even more ways it can occur.
What about implementating this as a temporary measure? Then some apps would work now. And then when you properly fix this, as a couple, more complex, patches later, then more apps would work. Then again, that would mean work that would not be heading in the right direction. And then keeping a generic, official list maintained somehwere of possible reasons (and in which version they were introduced) about where it (works for him, but not for me) could happen? Similar to an FAQ, or a response that developers and experienced users can give someone if something otherwise unknown of this nature goes wrong, and then debug further if those tips don't help. You could also use the "suggested" field of some packaging systems -- i.e. in Debian, you could make mingw packages "suggested" for the wine (source?) package(s). I don't know, but you could think that a cross-compiler would make sence for wine, since it *is* supposed to run Windows apps, but, I mean, either way... It does make worth noting that there are about one million more headaches with other apps/drivers/etc that are just as bad as requiring a cross-compiler. (Binary linux drivers for a Winmodem is one that comes to mind, another is other "standard" apps, like gnome and kde, that require their own 20-50 MB library or libraries.)
How? Remove a particular touched dll from c:\windows\system? If you have two apps, one wanting the 0-sized dll and the other one choking on it, what do you do?
You mean choking because wine is incomplete, and having the dll exist causes wine to do things it wouldn't do if there was no false dll file? How about startup/environment scripts?
Well I doubt any app actually relies on a DLL being empty, that'd never work on Windows. If you find an app which requires more than the filename to exist then yes, you could can just overwrite it with a real PE file.
What happens when someone comes up with a program that relys on a zero-size wine-dll and that runs on wine, but not Windows? Just my 2 cents. --Michael Chang
-- codebase introduction/induction documentation, anything? -- Im new to the wine codebase and see several bugs I am wanting to handle, however my main concern at this immediate time is trying to sort out cross-compatability issues... I have completely hand-installed DirectX 9.0c at this time along with dxdiag.exe and additional DXMedia runtime components along with the DCOM and several other subsystems from Windows 2000 professional the majority of this functions cleanly and as expected... however there is a number of "missing"/"undefined" functions and I would like to not only see a stub presence for these... but also would like to attempt making a functional replication of the functions concerned appear within the wine libaries for compatible completeness at least to the Windows 2000 pro release libraries I am using, -- Creation of DLL stub libraries in "C:/Windows/*" heirarchy -- Question...What is the problem defined here? Wine DLL's being compiled to PE objects and usable on Windows for replacing commercial code with GPL code ? or providing a Linux based set of files to show a more "complete" "Wine" package installation ? I see PE file building as more of a binary distribution option... and would suggest that it remain an option for those like myself who keep up to date based on CVS source updates and building from that, that way Cross-Compilation and other issues don't cloud development I am currently wanting to have a cross-compilation environment so I can test out several ideas... of which a couple of them would be more applicable to the Darwine project than the Wine project for PowerPC systems. why not have a "wine.dll" that is *NEVER* PE compiled and have that present itself for any "wine on linux" specific compatability calls and present any and all other loadable objects as if they were origin format native within the active runtime environment? Awaiting clarification, Belxjander Serechai
I have completely hand-installed DirectX 9.0c at this time along with dxdiag.exe and additional DXMedia runtime components along with the DCOM and several other subsystems from Windows 2000 professional
Well, native DirectX (DirectDraw+Direct3D at least) requires some kernel/driver support that Wine cannot really provide. This is one reason why we have our own implemention. If you want better games support you'd be better off working on our own implementation.
the majority of this functions cleanly and as expected... however there is a number of "missing"/"undefined" functions and I would like to not only see a stub presence for these... but also would like to attempt making a functional replication of the functions concerned appear within the wine libaries for compatible completeness at least to the Windows 2000 pro release libraries I am using,
Most of these will be undocumented and very complex to reverse engineer. I would not bother.
-- Creation of DLL stub libraries in "C:/Windows/*" heirarchy --
Question...What is the problem defined here?
Wine DLL's being compiled to PE objects and usable on Windows for replacing commercial code with GPL code ? or providing a Linux based set of files to show a more "complete" "Wine" package installation ?
The latter.
why not have a "wine.dll" that is *NEVER* PE compiled and have that present itself for any "wine on linux" specific compatability calls and present any and all other loadable objects as if they were origin format native within the active runtime environment?
Yes, that's not a bad idea for if we went down that route. But I think we want to keep using ELF DLLs for as long as possible. thanks -mike
Mike Hearn <mike(a)navi.cx> writes:
On Sat, 2004-09-04 at 15:49, Vincent Béron wrote:
How? Remove a particular touched dll from c:\windows\system? If you have two apps, one wanting the 0-sized dll and the other one choking on it, what do you do?
Well I doubt any app actually relies on a DLL being empty, that'd never work on Windows. If you find an app which requires more than the filename to exist then yes, you could can just overwrite it with a real PE file.
It's not that the app wants the dll to be empty, it's that it can deal with the file not being there at all, but it can't deal with the file being there but empty (since that would never happen on Windows). So in many cases creating empty files makes things worse than not having the files at all. -- Alexandre Julliard julliard(a)winehq.org
It's not that the app wants the dll to be empty, it's that it can deal with the file not being there at all, but it can't deal with the file being there but empty (since that would never happen on Windows). So in many cases creating empty files makes things worse than not having the files at all.
What would the app do if it found the DLL but it was empty? Do you mean that it maps it and rummages around the headers manually? Well, we seem to be in a bit of a quandry then. Some apps require the DLLs to be physically present, and others can't deal with it if they are but empty. So the only solution seems to be to actually have real PE DLLs in the virtual windows drive, but this would mean huge changes to Wine. Hmmm. What about if the files aren't empty, but just contain the headers - would that make the apps you're thinking of happy? thanks -mike
Hi, On Tue, Sep 07, 2004 at 09:58:44AM +0100, Mike Hearn wrote:
It's not that the app wants the dll to be empty, it's that it can deal with the file not being there at all, but it can't deal with the file being there but empty (since that would never happen on Windows). So in many cases creating empty files makes things worse than not having the files at all.
What would the app do if it found the DLL but it was empty? Do you mean that it maps it and rummages around the headers manually?
Well, we seem to be in a bit of a quandry then. Some apps require the DLLs to be physically present, and others can't deal with it if they are but empty. So the only solution seems to be to actually have real PE DLLs in the virtual windows drive, but this would mean huge changes to Wine.
Hmmm. What about if the files aren't empty, but just contain the headers - would that make the apps you're thinking of happy? Probably. That's why I wrote a helper to create full-featured NE/PE file headers already more than 4 years ago, before my Codeweavers internship, but it got lost when I accidentally deleted that Wine tree instead of the local one (the one right there in the terminal window instead of the one about some 5000 miles away in the other terminal window ;-). I just said something like "oops, that surely must have been wrong". ;-\ Needless to say I didn't feel too inclined to recreate the tool from scratch at that time, and I didn't bother later either.
It'd be cool if you actually did it now - just make damn sure to not make the mistake of deleting the wrong Wine tree ;-) Andreas Mohr
On Tuesday 7 September 2004 10:58, Mike Hearn wrote:
Well, we seem to be in a bit of a quandry then. Some apps require the DLLs to be physically present, and others can't deal with it if they are but empty. So the only solution seems to be to actually have real PE DLLs in the virtual windows drive, but this would mean huge changes to Wine.
How big would these changes actually be? The configure check for a cross compiler is already there. We have a 'crosstest' make target that produces PE executables alongside the ELF executables in the test directories. I'm wondering what would actually be needed for an analogous 'crossdll' target. The reason or one of the reasons for the current practice of out-of-tree cross builds is that Wine's build tools should not be cross compiled, correct? Any other obstacle? -Hans
I'm wondering what would actually be needed for an analogous 'crossdll' target. The reason or one of the reasons for the current practice of out-of-tree cross builds is that Wine's build tools should not be cross compiled, correct? Any other obstacle?
Well, as I said before the main reason to do it would be apps that do their own linking. But then, how do we link eg wininet.dll to the native OpenSSL libraries? you'd have to statically link them all I guess.
Le mar 07/09/2004 à 09:50, Mike Hearn a écrit :
I'm wondering what would actually be needed for an analogous 'crossdll' target. The reason or one of the reasons for the current practice of out-of-tree cross builds is that Wine's build tools should not be cross compiled, correct? Any other obstacle?
Well, as I said before the main reason to do it would be apps that do their own linking. But then, how do we link eg wininet.dll to the native OpenSSL libraries? you'd have to statically link them all I guess.
We'd have to actually code what some say is possible and why it's not a good thing to run Wine as root: let a Windows application (or dll) to make native Linux library calls. Actually, what we want is exactly what we currently do: native Windows dll already call into ELF libraries (albeit special ELF files). Vincent
Actually, what we want is exactly what we currently do: native Windows dll already call into ELF libraries (albeit special ELF files).
Yes, but we can do this because we control the dynamic linker. The only reason I can think of (are there others?) to build the DLLs as real PE DLLs is so apps that do their own linking can work. But then if they are doing their own linking, how do they get connected to ELF files?
participants (8)
-
Alexandre Julliard -
Andreas Mohr -
Belxjander Serechai -
Hans Leidekker -
michael＠cherryblossom.homelinux.com -
Mike Hearn -
Mike Hearn -
Vincent Béron