Mike Hearn wrote:
It seems it's turned from being an normal (albiet static) app which reserves the areas needed then boots wine, into a reimplementation of ld-linux.so?
This isn't all bad. Consider: we could add the ability to load PE executables and shared libraries into this private ld-linux.so. At that point, the need for winelib executables to be shared libraries goes away, doesn't it? And that would make everybody very, very happy, as it would solve the problem that made mono and everybody else fork wine just so they could load Windows DLLs into native linux apps.
Or am I confused? Wouldn't be the first time... - Dan
On Sun, 11 Apr 2004 02:20:16 -0700, Dan Kegel wrote:
This isn't all bad. Consider: we could add the ability to load PE executables and shared libraries into this private ld-linux.so.
I think that would be a very bad idea, frankly. The real glibc rtld is huge. We do *not* want to maintain a dynamic linker along with the rest of the codebase. This kind of preloader doesn't do dynamic linking itself you understand: it is simply a "proxy" linker, which invokes the real one.
At that point, the need for winelib executables to be shared libraries goes away, doesn't it?
Not really, it's more complex than just dynamic linker stuff. We need to initialize the whole Wine environment before passing control to the app. I think it could be possible to fiddle this anyway with alternate entry points and stuff so you can type ./myapp instead of wine myapp.exe.so
And that would make everybody very, very happy, as it would solve the problem that made mono and everybody else fork wine just so they could load Windows DLLs into native linux apps.
No, it would not solve these problems, which are mostly related to setting up the Win32/Wine environment on the fly and have not much to do with the dynamic linker.
Paul Davis has been doing some good work on this lately - it seems a workable solution is in sight. At least for now Mono have something they can use which doesn't require forking Wine.
thanks -mike