[Darwine] Re: Wine Emulation: Swapping functions
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.
More information about the wine-devel