Re: Wine preloader redux
Dan Kegel [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine preloader redux
Am Dienstag, 4. März 2008 10:24:25 schrieb Alexandre Julliard: Dan Kegel [EMAIL PROTECTED] 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? signature.asc Description: This is a digitally signed message part.
Re: Wine preloader redux
Stefan Dösinger [EMAIL PROTECTED] writes: Am Dienstag, 4. März 2008 10:24:25 schrieb Alexandre Julliard: Dan Kegel [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine preloader redux
On Tue, Mar 4, 2008 at 1:24 AM, Alexandre Julliard [EMAIL PROTECTED] 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.
Re: Wine preloader redux
Dan Kegel [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Wine preloader redux
Alexandre Julliard [EMAIL PROTECTED] 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?
Re: Wine preloader redux
Dan Kegel [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: Wine preloader redux
Alexandre Julliard [EMAIL PROTECTED] 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())?
Re: Wine preloader redux
Dan Kegel [EMAIL PROTECTED] writes: Alexandre Julliard [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
