Create DLL stub files in c:\windows\system

Mike Hearn mike at navi.cx
Sat Sep 4 10:06:45 CDT 2004


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.




More information about the wine-devel mailing list