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