Say, it looks like at some point in the past, an alternate approach was looked at for reserving special addresses: http://bugzilla.kernel.org/show_bug.cgi?id=2255 If that kernel issue were resolved, would that let us get rid of the preloader?
"Dan Kegel" dank@kegel.com writes:
Say, it looks like at some point in the past, an alternate approach was looked at for reserving special addresses: http://bugzilla.kernel.org/show_bug.cgi?id=2255 If that kernel issue were resolved, would that let us get rid of the preloader?
Not really, we'd still need to support older kernels, and the preloader is more flexible anyway. Why would you want to get rid of it? We haven't had any trouble with it for a long time.
Am Dienstag, 4. März 2008 10:24:25 schrieb Alexandre Julliard:
"Dan Kegel" dank@kegel.com writes:
Say, it looks like at some point in the past, an alternate approach was looked at for reserving special addresses: http://bugzilla.kernel.org/show_bug.cgi?id=2255 If that kernel issue were resolved, would that let us get rid of the preloader?
Not really, we'd still need to support older kernels, and the preloader is more flexible anyway. Why would you want to get rid of it? We haven't had any trouble with it for a long time.
Might that fix our problem with the VM limitation for video drivers?
Stefan Dösinger stefan@codeweavers.com writes:
Am Dienstag, 4. März 2008 10:24:25 schrieb Alexandre Julliard:
"Dan Kegel" dank@kegel.com writes:
Say, it looks like at some point in the past, an alternate approach was looked at for reserving special addresses: http://bugzilla.kernel.org/show_bug.cgi?id=2255 If that kernel issue were resolved, would that let us get rid of the preloader?
Not really, we'd still need to support older kernels, and the preloader is more flexible anyway. Why would you want to get rid of it? We haven't had any trouble with it for a long time.
Might that fix our problem with the VM limitation for video drivers?
No, the memory needs to be reserved one way or another.
On Tue, Mar 4, 2008 at 1:24 AM, Alexandre Julliard julliard@winehq.org wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=2255 If that kernel issue were resolved, would that let us get rid of the preloader?
Why would you want to get rid of it? We haven't had any trouble with it for a long time.
Because getting rid of it might make it much easier to turn winelib into a normal library, thus enabling plain old linux apps to at least statically link it in and thereby become able to use windows dlls without having to use the preloader.
"Dan Kegel" dank@kegel.com writes:
Because getting rid of it might make it much easier to turn winelib into a normal library, thus enabling plain old linux apps to at least statically link it in and thereby become able to use windows dlls without having to use the preloader.
We could have that as an option for Winelib apps, though I don't think it would make things really easier, just differently complicated.
Alexandre Julliard julliard@winehq.org wrote:
Because getting rid of it might make it much easier to turn winelib into a normal library, thus enabling plain old linux apps to at least statically link it in and thereby become able to use windows dlls without having to use the preloader.
We could have that as an option for Winelib apps, though I don't think it would make things really easier, just differently complicated.
The scenario I'm imagining is: Lots of people want to use a particular windows dll in their Linux apps. Joe Developer writes a nice wrapper library using winelib to hide the fact that win32 is involved at all. Fred Developer uses Joe's library in his app. Currently, Fred has to switch his app around to be run via the wine preloader. With the scheme Mike was thinking of in http://bugzilla.kernel.org/show_bug.cgi?id=2255 Fred wouldn't have to do that; he'd only have to link in a static library (named, say, wine-reserve-win32-vma.a), and then link in Joe's library any old way. That sounds a lot easier to me. Did I miss something?
"Dan Kegel" dank@kegel.com writes:
The scenario I'm imagining is: Lots of people want to use a particular windows dll in their Linux apps. Joe Developer writes a nice wrapper library using winelib to hide the fact that win32 is involved at all. Fred Developer uses Joe's library in his app. Currently, Fred has to switch his app around to be run via the wine preloader. With the scheme Mike was thinking of in http://bugzilla.kernel.org/show_bug.cgi?id=2255 Fred wouldn't have to do that; he'd only have to link in a static library (named, say, wine-reserve-win32-vma.a), and then link in Joe's library any old way. That sounds a lot easier to me. Did I miss something?
I'm not sure you can do the ELF magic with a static library, but even if you could there's a lot more to the initial setup than the preloader; that's why winelib apps are shared libraries, so that we can do all the work that needs to be done before they get loaded.
Alexandre Julliard julliard@winehq.org wrote:
I'm not sure you can do the ELF magic with a static library, but even if you could there's a lot more to the initial setup than the preloader; that's why winelib apps are shared libraries, so that we can do all the work that needs to be done before they get loaded.
What's one other thing that couldn't reasonably happen at global constructor time (i.e., just before main())?
"Dan Kegel" dank@kegel.com writes:
Alexandre Julliard julliard@winehq.org wrote:
I'm not sure you can do the ELF magic with a static library, but even if you could there's a lot more to the initial setup than the preloader; that's why winelib apps are shared libraries, so that we can do all the work that needs to be done before they get loaded.
What's one other thing that couldn't reasonably happen at global constructor time (i.e., just before main())?
Global constructor time is too late, by this time dependent libraries will have been loaded and initialized, which will crash and burn if some of them are Windows dlls. Also you need the environment and command line setup before the global constructors are run. You also need to setup the process stack, which you can't do inside a constructor that you have to return from.
-
Alexandre Julliard -
Dan Kegel -
Stefan Dösinger