Project: x86 to ARM binary translator

[Stefan Dösinger]

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:
> 2. 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20110402/fbceea1e/attachment.pgp>