[Darwine] Re: Wine Emulation: Swapping functions

[Mike Hearn]

> 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).

Yes QEMU can do syscall conversion iirc, at least in some modes.

> 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 don't think you could get much higher performance than eg, Virtual PC 
to be honest. Maybe if you developed some way of pre-converting the 
binaries beforehand rather than doing it on the fly, but VPC type 
systems have the advantage of having very limited interaction points 
between the host OS and the client OS which can be tightly optimized 
(eg, video ram), so they can perform a lot of tricks you can't do if you 
want to integrate better with the OS.

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

Please do some basic research, otherwise you just come off sounding 
ignorant:

a) Wine is not under the GPL and never was, it's under the LGPL
b) TransGamings Cedega forked from Wine several years ago, back when it 
was under the X11 license which allowed that. So they don't have to 
contribute their code back.
c) That fork was what motivated the switch to LGPL.
d) Quite a few of TransGamings porting projects don't seem to involve 
Wine at any level. For instance Gav told me about a game they ported 
which used Java.

Intererestingly, I think Gav thought the Java port was *harder* than 
Wine ports were due to the huge instability of Java on the Mac platform. 
He said at one point Apple pushed out an online update to Java which 
broke their game and then withdrew it, leaving no way for them to 
duplicate the environment that their customers were having problems with 
(amongst other problems)! So much for "write once, run anywhere" ...

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

You realise that a quartzdrv would not change the fact that Windows apps 
look like Windows apps, right?

All it changes is the way the bits drawn by Wine get to the screen. To 
be honest I think you'd achieve much better results by improving the 
quartzwm so X11 windows integrate better with the dock etc. If quartzwm 
is proprietary (don't recall) then writing a new WM that is equivalent 
and has all the features you need would be another way forward.

While it's interesting from a technical perspective to do a quartzdrv, 
I'm really not convinced you would get better integration than just 
improving the X11 support in the OS, which would obviously also benefit 
those who use Linux/X11 apps on the Mac as well as Wine users.

Anyway .. what I meant by that statement is that if you're running x86 
Wine in QEMU you can't access the Carbon APIs directly. I think in the 
mode where you run foreign binaries QEMU will perform syscall conversion 
but obviously this is of limited use - the OS X APIs aren't accessible 
via syscalls.

One thing you could do I guess is expose each OS X API that you wanted 
as a new "fake" syscall and then use a customized version of QEMU that 
converted it into a Mac API call, ie marshal the calls in and out of the 
emulated environment. You'd still pay a performance penalty but that's 
unavoidable. I'm not sure how you'd deal with callbacks.