At Wineconf tonight, people were talking about whether integrating bits of wine into the kernel was useful, and how much should be moved in. (Hello task ornaments!) Anyway, I mentioned that somebody had integrated a PE loader into BSD. Here's the page: http://chiharu.hauN.ORG/peace/ I think this is pretty darn cool, and hope somebody does something similar for Linux.
- Dan
On Sat, Mar 16, 2002 at 10:55:41PM -0800, Dan Kegel wrote:
At Wineconf tonight, people were talking about whether integrating bits of wine into the kernel was useful, and how much should be moved in. (Hello task ornaments!) Anyway, I mentioned that somebody had integrated a PE loader into BSD. Here's the page: http://chiharu.hauN.ORG/peace/ I think this is pretty darn cool, and hope somebody does something similar for Linux.
On Linux, support for 'foreign' binary types has been generalized using the binfmt_misc interface which is controllable at runtime through /proc. Debian goes so far as to provide a package called 'binfmt-support' which automates setup of additional userland executable loaders. It actually works quite well with Wine, in fact.
Steve Langasek postmodern programmer
Steve Langasek wrote:
On Sat, Mar 16, 2002 at 10:55:41PM -0800, Dan Kegel wrote:
At Wineconf tonight, people were talking about whether integrating bits of wine into the kernel was useful, and how much should be moved in. (Hello task ornaments!) Anyway, I mentioned that somebody had integrated a PE loader into BSD. Here's the page: http://chiharu.hauN.ORG/peace/ I think this is pretty darn cool, and hope somebody does something similar for Linux.
On Linux, support for 'foreign' binary types has been generalized using the binfmt_misc interface which is controllable at runtime through /proc. Debian goes so far as to provide a package called 'binfmt-support' which automates setup of additional userland executable loaders. It actually works quite well with Wine, in fact.
I can't shake the feeling that it'd be useful to have basic PE support in the OS, and make Wine be essentially a set of shared libraries.
- Dan
On Sun, Mar 17, 2002 at 12:15:51PM -0800, Dan Kegel wrote:
Steve Langasek wrote:
On Sat, Mar 16, 2002 at 10:55:41PM -0800, Dan Kegel wrote:
At Wineconf tonight, people were talking about whether integrating bits of wine into the kernel was useful, and how much should be moved in. (Hello task ornaments!) Anyway, I mentioned that somebody had integrated a PE loader into BSD. Here's the page: http://chiharu.hauN.ORG/peace/ I think this is pretty darn cool, and hope somebody does something similar for Linux.
On Linux, support for 'foreign' binary types has been generalized using the binfmt_misc interface which is controllable at runtime through /proc. Debian goes so far as to provide a package called 'binfmt-support' which automates setup of additional userland executable loaders. It actually works quite well with Wine, in fact.
I can't shake the feeling that it'd be useful to have basic PE support in the OS, and make Wine be essentially a set of shared libraries.
The Linux kernel maintainers are likely to disagree with you, since when binfmt_misc support was added, even Java was kicked out of the kernel. ;) In any case, I think the current situation is really pretty close to what you want. Just as ELF library resolution is actually done by a userland process (ld.so), so is PE resolution (through wineserver). With binfmt_misc, PE executables are supported as well as Java or any scripting language, without the dangers associated with adding large and potentially buggy loading routines directly to the kernel.
My understanding is that effectively, Wine already /has/ evolved to the point that it's little more than a set of shared libraries plus a PE loader. The fact that the PE loader runs in userland instead of as part of the kernel is a definite advantage, IMHO.
Steve Langasek postmodern programmer
Steve Langasek wrote:
I can't shake the feeling that it'd be useful to have basic PE support in the OS, and make Wine be essentially a set of shared libraries.
The Linux kernel maintainers are likely to disagree with you, since when binfmt_misc support was added, even Java was kicked out of the kernel. ;)
Actually, Linus seemed open to the idea of adding win32 support to the kernel, if it was useful.
In any case, I think the current situation is really pretty close to what you want. Just as ELF library resolution is actually done by a userland process (ld.so), so is PE resolution (through wineserver).
I totally agree that a userland program like ld.so, but specific to pe executables, should be responsible for loading PE files.
My understanding is that effectively, Wine already /has/ evolved to the point that it's little more than a set of shared libraries plus a PE loader.
It's moving in that direction, but I'm not convinced that it's completely decruftified yet. Ideally, things should be so cleanly refactored that it is possible to load PE executables that make linux calls, without requiring ANY win32 stuff (no DLL's). On top of that "native linux PE environment", you should be able to load a trivial win32 "hello world" program, and have the PE equivalent of ld.so load just the one DLL from /usr/lib/wine needed to satisfy the 'write to console' call. Is it indeed really that clean already? Or will Wine refuse to load a PE file that makes direct Linux system calls and imports no DLLs from /usr/lib/wine?
- Dan
Dan Kegel dank@kegel.com writes:
Is it indeed really that clean already? Or will Wine refuse to load a PE file that makes direct Linux system calls and imports no DLLs from /usr/lib/wine?
It will work, but Wine will still need to load ntdll because that's where the PE loader is. And you can't really separate the PE loader from the rest of ntdll since it needs to interface with memory management etc. You could write a separate PE loader but then it couldn't be used to load real Window apps.
-
Alexandre Julliard -
Dan Kegel -
Steve Langasek