[Darwine] Re: Wine Emulation: Swapping functions

[Gavriel State]

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

-- 
Gavriel State, Co-CEO & CTO
TransGaming Technologies Inc.
gav at transgaming.com
http://www.transgaming.com

Let the games begin!