PE loader integrated into BSD
vorlon at dodds.net
Sun Mar 17 16:29:08 CST 2002
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.
More information about the wine-devel