[Darwine] Re: Wine Emulation: Swapping functions

Jim White jim at pagesmiths.com
Wed Aug 25 06:34:04 CDT 2004

Mike Hearn wrote:

>> I think you are going in the wrong direction with this; the right way
>> IMO is to compile Wine for x86 and run the whole Wine+app under the
>> CPU emulator. Otherwise you'll have to write wrappers for each of the
>> 15,000 APIs.
> Certainly dealing with the syscalls alone is a lot easier than flipping 
> on every Windows API. You may wish to talk to TransGaming. They've 
> actually *done* what you guys are trying to do, and run x86 
> software/games on a Mac. IIRC they found it unworkable (due to 
> endianness conversion) even when using virtualization software more 
> advanced than QEMU, however they were focussing on games where 
> performance is critical. So maybe it doesn't matter to you guys.

I agree that flipping the syscalls is a much more promising approach 
than the WIN32 API.  I'm also thinking that there is bound to be some 
relevant code around aleady (perhaps even in QEMU).

While the current phase of the Darwine effort is concerned with making 
something that works, naturally performance is an important issue.  In 
fact one of the architectural motivations for Darwine is that it will be 
able to achieve much higher performance than approaches that virtualize 
the OS (in addition to the objectives of not having to run Windows).

 > 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!

> The problem with running x86 Wine in QEMU is that it's harder to access 
> the OS X APIs. I guess you could use some kind of IPC to do it but you'd 
> end up recreating the X protocol for Quartz which seems a bit silly 
> (amongst other things).

Hmmm, not sure what you mean there.  Initially we patched winegcc to 
make the OS X API accessible, but at Alexandre's suggestion to Pierre 
we've switched to binding to the symbols dynamically.  Of course using 
the native Carbon API is necessary, otherwise we're stuck in the X11 box 
which is as foreign to the Mac user as having Windows running via VPC.

Jim White

More information about the wine-devel mailing list