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.