PowerPC MacOSX work...

[Stefan Dösinger]

Am Montag, 25. Mai 2009 20:33:28 schrieb mghughes at embarqmail.com:
> No No No People...  Please read the messages before replying.
I did, but they were not clear to me. To be honest, I am still not sure what 
you want to achieve.

> For the record...  I am not looking to run another full out emulation.
> The best example of what I have in mind is what Apple did when they
> moved their processor base from 68K to PPC.  And I am wondering if the
> same could be done for Wine.  By the looks of things some of the
> framework to make that happen are already there in the form of thunk
> code...  Apple used what they called trampolines iirc.
Do you mean running the Windows app in an emulator, Wine on the native CPU and 
inserting trampolines or something else that switches in and out of the 
emulator whenever there's a call from the app to Wine code, or from Wine code 
back to the app?

Something like that exists - the Win16 support that switches the x86 CPU in 16 
bit or 32 bit mode whenever the control is passed between Wine and the app. 
It would probably be comparably easy to adopt this for Win16 on PPC.

There are a number of issues that make this much, much harder on Win32 vs PPC.

1) COM interfaces. They pass around function pointers, and there is no DLL 
entry point for a COM method. You'd have to write a thunk DLL for each DLL 
that uses COM objects.

You'll need a glue DLL that has some PPC code that knows how to convert 
parameters and call into the emulator. And you'll need glue x86 code that 
knows how to break out of the emulator and call the PPC side of the glue DLL.

2) Wine vs App call. If I understand things correctly, Wine never calls a 
Win16 entry point in Wine. There are many cases where a Wine DLL calls 
another Wine dll. E.g. WineD3D calls gdi32 and opengl32. You'll have to find 
a way to figure out where a call came from, and more important, figure out 
where a call is going to if you're calling a callback function.

3) API explosion: Back in the Win 3.1 day the Win16 API has been pretty 
compact. Nowadays there are hundreds of DLLs that have hundreds to thousands 
of functions or COM methods.

So running Win32 apps in an emulator on a PPC-native Wine is most likely 
possible from a technical point of view, but it is a very complex job. In 
terms of final usability the needed effort is probably spent more efficiently 
by improving the emulator, just run Wine in the emulator and thunk the 
comparably small Linux syscall interface(qemu already does that).

The advantages of Wine-level thunks is that the theoretical best performance 
is better. This is probably true especially with D3D rendering. E.g. instead 
of converting a A8R8G8B8 texture from big endian to little endian one might 
just replace the pixelformat with B8G8R8A8. A setup like that could also 
allow us to run 32 bit apps on Wine64, and end the "you guys need a proper 
ABI" whine from distro maintainers.

It's an open source project, so everybody is free to take the code and give it 
a try :-)