Project: x86 to ARM binary translator
Stefan Dösinger
stefandoesinger at gmx.at
Sat Apr 2 05:34:43 CDT 2011
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>
More information about the wine-devel
mailing list