You can't do that yet, but it is a step in that direction. The general idea is that Wine is getting organized on two layers: the PE .dll libraries, which are si

You can't do that yet, but it is a step in that direction. The general idea is that Wine is getting organized on two layers: the PE .dll libraries, which are similar to a Windows userspace, and the Unix libraries, which act as a sort of "kernel". The interface between the two is standardized and is kind of close to a system call interface (we actually call those "syscalls", even though what I can "kernel" is still a bunch of userspace .so libraries, so the processor is not really switched to kernel mode, and there is no hard enforcement of boundaries; also, many of these syscalls are much higher level than what you'd usually expect from a real kernel-userspace boundary). Once all modules are converted (there are still a few missing, unfortunately the hard ones, but people are working on those), the PE world interact with the external system only through this "syscall" interface. The Unix world is required to be compiled for the external system's architecture, but the PE world can be whatever you want, provided that you do the appropriate things at the syscall interface. For example, you can have 32 PE libraries and 64 bit Unix libraries, and at the syscall interface you switch the processor back and forth between 32 and 64. Or you can have x86 PE and ARM (or whatever) Unix, and you enable/disable an emulator at syscalls.