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