Hi, I may be telling you nonsense here, I hope Alexandre hits me with a cluestick next Wineconf if I do, but this is my 2c on such a project.
On Saturday 02 April 2011 02:19:33 Yale Zhang wrote:
- What's the best design: whole system VM (qemu) or process VM (qemu &
wine)?
A process VM already exists. It is called qemu. I don't know if it works with Wine, but it works with basic Linux apps. I could run a statically linked ARM ls on a x86 PC(ie, the reverse of what you want). For Libraries the normal Linux multilib scheme would apply, or a chroot. The advantage of this scheme is that the Linux syscall interface is comparably small, but you need every Linux library as x86 library and translate everything.
If you want to run x86 Windows apps on ARM I suggest to forget about Wine. Write an app that runs x86 Windows apps on ARM Windows. This wrapper app would be a ARM Windows app. If done properly it will automagically run on ARM Wine. This way you don't have to bother about Alexandre, your app naturally lives as a separate project etc. Plus, you only translate the app itself and not the libraries.
The big drawback of that approach is that it is a *lot* of work. You'll have to translate between x86 and ARM on every library call that leaves the app's own code. You'll have to write a wrapper version of every function, COM method, callback of every DLL in C:\windows\system32. This is a *lot* of work, probably comparable to the amount of work needed for Wine itself. What you have going for yourself though is that you can start small, you don't have to implement everything at once. Start with a console hello world app, implement some kernel32 thunks. Go on with Windows, add user32 and gdi32 etc etc etc.
A technical challenge is that the Windows DLLs call each other. But that would stay inside the host domain(ie, ARM), and the app doesn't see this anyway. But you'll have to translate pointers, handles etc consistently. And if there's a callback from the library back into the app(e.g. ddraw.dll:DirectDrawEnumerate) you'll have to translate it back.
If you make it flexible enough to deal with potential alignment differences(ARM doesn't need that, but PPC does) as well as separate address spaces then you could achieve more goals at once: PPC, Mips, etc support, run x86 apps on x86_64 without Linux x86 libs(although it will be much slower than the classic multilib approach)