X86/PPC linking (was Re: [Darwine] Re: Wine Emulation: Swapping functions)

[Mike Hearn]

  >> b) TransGamings Cedega forked from Wine several years ago, back when
>> it was under the X11 license which allowed that. So they don't have to 
>> contribute their code back.
>> c) That fork was what motivated the switch to LGPL.
> 
> 
> Well that makes sense.  I couldn't make heads or tails of their 
> licensing.  Although it does say something about the Wine of WineX 2 
> being LGPL.  In any case it seemed clear that whatever they had is not 
> free.  Also I can't see why they would want to do any X86 emulation at 
> all since games do usually need maximum performance.  I have to figure 
> that they are using Winelib.

Parts of it are LGPLd, parts are X11d and parts are under the AFPL. What 
license things are under is pretty important you know.

> That was indeed true before OS X.  Typically ironic/tragic of Apple that 
> the machines most in need of WORA had lousy Java.  Fortunately on OS X 
> the Java is at least as good and in some cases (such as Swing 
> performance) is better than on Windows.

No, TransGaming has only ever worked with OS X. I'm afraid these stories 
were about quite recent behaviour (last two years or so).

> This is another area that integration opens up for innovation.

No it doesn't. If you want native theming you'd have to implement a 
UXTHEME bridge to appearance manager. X11/Quartz is orthogonal to this 
issue.

> Of course even so, as I said to begin with, such driver layering is 
> devastating to performance and any hope of order-of-magnitude speed up.

The truly graphics performance critical parts for games and such go via 
DGA/GL anyway, so I'm not convinced about that. It's like saying X11 on 
Windows can't possibly beat X11 on Linux because it has to go via the 
GDI, yet it can sometimes happen.

> The ideal method would be to handle this with a trick loader that can 
> link to PPC code which is escaped from the X86 emulation.  We can 
> automatically generate X86 DLLs for the PPC dynamic libraries (and hence 
> the OS X APIs) which have little emulation escape thunks in them.  There 
> is zero performance penalty since the emulator can compile such escapes 
> as direct native calls.  Callbacks use a similar sort of little thunk 
> which calls the emulator with a given X86 address.

> I would really like to get away from having to write all the little 
> wrappers to deal with the namespace problem.  I believe we can solve 
> that with a suitable naming convention as we began to do with the 
> winegcc patch.

In order to write such thunks you would need a type description of the 
entire Windows API, as pointed out by Rob. Generating this in a usable 
form from the headers would be incredibly hard.

> Alternatively we could go with with dynamic binding as proposed by 
> Alexandre and have a syscall (or emulation escape) to call PPC code. 
> This is probably the easiest to implement but leaves us with extra call 
> overhead (although apparently this is something that is currently done 
> in Wine and is quite small).

Well more to the point it means you're emulating both the app and Wine, 
which won't be performant.

> As for swapping functions, the preceding discussion reiterates my belief 
> that we should confine such fussy business to the relatively small bit 
> of code that calls into OS X, will be relatively stable over the long 
> haul, and over which we have full control.  And as for the concern over 
> having Wine be X86 and hence incurring emulation overhead, this would be 
> one of the first bits of code which would be a candidate for having its 
> emulator-compiled code cached.

If you look at how many native imports Wine requires on Linux to get 
full functionality I don't think you can say it's relatively small. It's 
many thousands of functions, possibly more. It's hard to measure because 
so much is dynamically loaded.