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