World Wine News

I am proud and happy to announce the release of a new binary labeled Darwine 20040820 DP. This binary is based upon the 20040813 wine release. The majority of changes for this release can be viewed:

http://cvs.winehq.org/cvsweb/wine/ChangeLog

It is being released as a DEVELOPER PREVIEW so USE AT YOUR OWN RISK! It is not yet suited for mass distribution or general user use. This release in addition to all of the fixes from the wine team includes many Mac OS X optimizations and fixes. It also includes WineHelper a native Mac OS X application that helps launch .exe's. It allows for .exe's to be double clicked in the finder like any other application and essentially bypasses the need to run wine via the command line.

The Darwine libraries have been moved from their default installation location of /usr/local to a more Mac OS X friendly location /Library/Darwine. Applications and WineHelper are installed in /Applications/Darwine.

This new binary also automatically uninstalls the previous binary if it is found to be installed. For uninstall to occur the user must enter an administrator's password. If the correct password is entered the uninstaller will return some errors however the old version of Darwine will be removed and the install of this new binary can commence by reopening the installer package. A new uninstaller is included with this release that simplifies the uninstall process thanks to the new location of libraries.

The binary has been split into two releases one being this release and a soon to be released Darwine SDK. The Darwine SDK will contain the source for both wine and WineHelper, all of the header files, winegcc, winebuild tools and many examples and scripts that will allow open source apps to be compiled using these tools.

Please report bugs to the darwine SourceForge Bug Tracking System, and to the darwine-devel mailing-list. Also any comments, questions or concerns can also be posted to the darwine-devel mailing-list. Enjoy this new release.

Other Darwine news is that there was an interview with moi on osViews:

Text:

http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=2046

Broadcast:

http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=2047

And perhaps the most interesting news is that Darwine's lead developer Pierre d'Herbemont has successfully ported QEMU (fast X86 emulator) to Mac OS X:

QEMU on Mac OS X
by Pierre d'Herbemont
2004-07-04 at 11:07:13

I am proud to announce that QEMU is now working on Mac OS X.

• Original announcement on the qemu-devel list
• Download the installer for Mac OS X
• Screenshots of QEMU running on Mac OS X
• The FreeOSZoo , to download ready-to-run images of QEMU virtual computers, pre-installed with a Free Operating System and a set of popular free software.

I would like to thanks Matt Reda for its collaboration.

osViews : Why aren't you just porting QEMU and then running Wine through the port of QEMU?

Jim White : QEMU is a processor... um, its a computer emulation... and so it runs an operating system. So, QEMU is a virtualization environment. So, its doing that job. It already runs Linux... under QEMU that just came to pass this last week or two. So Wine would run now under Linux... under QEMU.

But that's not what Darwine's about. Darwine is the idea that by incorporating the x86 emulation with the Wine environment, that we can run applications without running a separate operating system.

[....]

The reason that Darwine has a special case [which] could be interesting is... when you talk about emulation, then the next question people ask after, 'does it work' is 'well, how fast does it go?' So one of the reasons why Darwine... could in the long run be worth while is on that issue alone.

The opportunities for optimization are very very high with the Darwine approach because the problem that a general processor emulator has is its compilation window... Like QUMU compiles instructions... and compiles them into native code and runs that, but since it doesn't know things like 'what are code blocks' and this sort of thing... it's very limited in what it can do there.... its window translating scheme.

But with Darwine, down the road... since we know things like, 'what are code blocks' things could could actually be natively translated. {This allows} a block of code to be compiled in native code and not have to use dynamic compilation at all. Performance could potentially get MUCH better than systems that use operating system virtualization.

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.

The ideal method would be to handle this with a trick loader that can link to PPC code which is escaped from the X86 emulation. We can automatically generate X86 DLLs for the PPC dynamic libraries (and hence the OS X APIs) which have little emulation escape thunks in them. There is zero performance penalty since the emulator can compile such escapes as direct native calls. Callbacks use a similar sort of little thunk which calls the emulator with a given X86 address.

I would really like to get away from having to write all the little wrappers to deal with the namespace problem. I believe we can solve that with a suitable naming convention as we began to do with the winegcc patch.

Alternatively we could go with dynamic binding as proposed by Alexandre and have a syscall (or emulation escape) to call PPC code. This is probably the easiest to implement but leaves us with extra call overhead (although apparently this is something that is currently done in Wine and is quite small).

By using suitable macros we can make the source independent of which method is used.

The thing we don't get away from is that any code which calls OS X routines from X86 code *will* have to deal with endianess. There is overhead here, but we can be careful to use code that the emulator does a good job translating. Of course if there is substantial code (which would be unusual) it can simply be compiled as a PPC dynamic library.

As for swapping functions, the preceding discussion reiterates my belief that we should confine such fussy business to the relatively small bit of code that calls into OS X, will be relatively stable over the long haul, and over which we have full control. And as for the concern over having Wine be X86 and hence incurring emulation overhead, this would be one of the first bits of code which would be a candidate for having its emulator-compiled code cached.

Attached is a very preliminary driver for native graphics on OS X. So far all it does is let you make windows. No events or drawing work yet (I was baffled by the GetDC function. It looked like the existing drivers only call windows functions, and I didn't see any way for setting the window's context.) To compile this requires a patch by Pierre d'Herbemont to deal with conflicting function names in windows and Carbon. He said he will send it here. Also, to get the windows to focus, you have to place the executable in an application bundle. I just took one I had sitting around, copied the wine binary over the executable in the bundle and ran it from the commandline like so:

/Users/ribrdb/Desktop/winemine.app/Contents/MacOS/CarbonTest winemine

Things are getting busy with work, so I'm not sure when I'll have more time to work on this.

Well, by 'the entire Wine development team' you mean Alexandre :-) ?

I, for one, am happy that people are using our driver model to write new drivers as it could serve as a proof of concept that our driver model is sound (think about GL / Cairo / 'DBI engine' kind of drivers).... Heck, if we only wanted to support one driver, why do all the job of doing a clean separation and not include X11 in Wine's GDI directly ?

Well the driver model is lifted from Windows so I think it is sound. And as for why we use separate drivers, well, when the DLL separation is complete it means we can make a real Windows box display via X11 which is Just Plain Cool :)

It also allows for portability to operating systems that don't have X11. Mac OS X does have X, in fact it's a modified XFree but with some proprietary bits added. So I'm thinking the added effort is not worth the gain. I'm not a Mac user though so who knows, maybe the extra native-ness is worth all the pain

I played a bit with smatch and Wine (after reading http://people.redhat.com/mstefani/wine/smatch/ ), to try to get over what I mentionned in my last email (regarding winapi_check and cross-calls in parenthesis).

I attach the smatch script to generate the results I have. It's still not perfect (the listview.c references are wrong, for example), but as it's tied to gcc it can detect some calls which otherwise would not be caught. For example, the calls to GetWindowLongA in header.c are in a macro.

Not all of them are bugs: caution is needed when checking, although reducing the number of false positive would likely be welcome (either by modifying the script or patches).

Also take note (Francois? Any perl hacker?) that the method used to find the cross-calls (winapi_check) is not 100% proof. There are some valid C statements which contain a cross-call which are not found. Look at dlls/lzexpand/lzexpand_main.c GetExpandedNameW:

INT WINAPI GetExpandedNameW( LPWSTR in, LPWSTR out )
{
 INT ret;
 DWORD len = WideCharToMultiByte( CP_ACP, 0, in, -1, NULL, 0, NULL, NULL );
 char *xin = HeapAlloc( GetProcessHeap(), 0, len );
 char *xout = HeapAlloc( GetProcessHeap(), 0, len+3 );
 WideCharToMultiByte( CP_ACP, 0, in, -1, xin, len, NULL, NULL );
 if ((ret = GetExpandedNameA( xin, xout )) > 0)
     MultiByteToWideChar( CP_ACP, 0, xout, -1, out, strlenW(in)+4 );
 HeapFree( GetProcessHeap(), 0, xin );
 HeapFree( GetProcessHeap(), 0, xout );
 return ret;
}

The A call is between parenthesis and winapi_check can't find it. winapi_check would need to be modified to find those, as I'm sure that's not the only one in the whole tree.

Attached is a non-perfect patch for review. This is a migration of the wineserver to use epoll instead of poll (if it's available).

current known issue with this patch:

1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile if epoll not available at compile time)
2. Segfaults on wine exit.
3. Lots of debug asserts.

Comments welcome.

If you're going to use syscalls instead of epoll_create etc, then you don't need to check whether epoll functions exist in glibc, since you're not using them anyway.

In any case, seeing that getting your patch accepted will take some effort, it's probably a good idea to use the glibc version functions first, and deal with the problem of missing epoll functions in older glibcs in a separate patch.

The patch is not yet ready for commit, but I do have preliminary benchmarks: The attached program (compiled as winelib) was used. ulimit -n was raised to 10240.

With the current wine code:

real 0m41.076s
user 0m5.070s
sys 0m7.722s

the main wine process was taking 10% CPU time, and wineserver was taking over 60% cpu time. load average was over 2

With my preliminary path:

real 0m20.985s
user 0m5.316s
sys 0m11.421s

main wine process was still taking 10%, but so was wineserver. load average was about 1.5.

We can see that there is a significant drop in actual execution time, even though there is an INCREASE in user+system processing time. I believe this is not a fluke (results are pretty consistent), but rather that the poll behavior was taking a huge toll on the system in areas where it wasn't attributed towards wine, even though it was wine related. I would take the real time measurement as the indicative one.

Ideas for better benchmarks would be greatly appreciated.