Jim White wrote:
I think they were only converting the syscalls but I don't really remember .... Gav told me various stories of their Mac porting efforts at WineConf.
It would be interesting to chat with those folks indeed. I take it that given that their product is dependent on Wine, which is GPL, the relevant code which enables it to run on Mac OS X must be available as well? That would dramatically simplify what we need to do!
As Mike has pointed out, only a very small portion of our code is covered by the LGPL (and none of this is used in our Mac products), and our Mac code is not publicly available. Even if it was, it wouldn't likely help you very much with your ultimate goals.
That said, you're certainly welcome to check out our Mac work in binary form. You can check out the demo of Indiana Jones and the Emperor's Tomb here: http://www.macgamefiles.com/detail.php?item=17958
I am somewhat restricted on what I can say with regards to the endianness issues with respect to cpu emulators. We're not using them in any of our Mac products that are currently shipping. There is a wide continuum of possible solutions, each of which has its strengths and weaknesses (and many of which you guys are already thinking about). Obviously, the speed of the translated code makes a key difference to which solution makes the most sense. The exact problem you're trying to solve also affects the decision: porting from source vs binaries, full application vs a small library, etc.
I will point out a useful performance stat from the non-emulated gaming side of things that may give you something to consider. In a typical game, CPU time is split mostly between OpenGL and application code. With a few pathological exceptions, well under 10% of CPU time is spent in Wine code. As much as 30-40% of time can be spent in game logic and related code. If the app has a software renderer, or is more 2D oriented, that can jump to 90%+ time in application code. Clearly, any translated code would have to be very very efficient, regardless of where the line is drawn on endianness conversion.
Anyhow, we're certainly watching the QEmu and Darwine project keenly, and are looking forward to seeing what you guys come up with.
Take care, -Gav