Wine Traffic #85 For 5�Mar�2001

By Eric Pouech

Table Of Contents

Introduction

This is the 85th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 45 posts in 190K.

There were 20 different contributors. 11 posted more than once. 9 posted last week too.

The top posters of the week were:

1. Headlines

People:

Wine-20010305 has been released. Main changes include:

2. Wine's speed-up

15�Feb�2001�-�26�Feb�2001 (19 posts) Archive Link: "Speeding up wineserver syncronization objects with shared memory"

People: Gavriel State,�Alexandre Julliard,�,�Ove Kaaven,�TransGaming

(EdNote: resurrecting old article) Gavriel State put out a speed issue in current Wine code:

We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes.

Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock.

After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module approach. After re-reading the thread (EdNote: you call also look at WWN coverage part #1 and BROKEN KCREF) and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work.

Gavriel and Ove Kaaven proposed to use a shared memory section between every process and the Wine server to help speeding up the lock/unlock operations.

Alexandre Julliard didn't like the approach at all:
I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important.

As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too.

Gavriel tried to minimize the impact on system stability of his proposal, but he couldn't convince Alexandre of it.

Robert O'Callahan put on the table some other algorithms to tackle the issue. Unfortunately, they either required some "ugly" (read not accepted by Alexandre Julliard features) like letting the wine server call back some function on the client side, or using the already rejected shared memory approach.

As a conclusion (since none went out of the discussion), it may be possible that Gav (with TransGaming) writes an almost right but quick implementation of the mutexes, but which wouldn't be commited into the main Wine tree because it wouldn't be completely right.

3. Wine press coverage

22�Mar�2001�-�2�Mar�2001 (2 posts) Archive Link: "Wine press"

People: Bill O'Brien,�,�Eric Pouech

Eric Pouech posted a link to a C|Net article (http://linux.cnet.com/linux/0-2136864-7-4961586.html) , making a comparison of three Linux products, letting Windows applications run on Linux. Those products are Wine (of course), VMware and Win4Lin.

The article is pretty much product (and end user) oriented, hence the final bad ranking for Wine (so far, the Wine had put more effort into adding feature, rather than putting a 1.0 version). However, the potential for Wine is here. It just needs some more (oouch) work to terminate the developments.

Here are the overall comparison from the CNET Linux Center's review by Bill O'Brien:
Product Overall rank (1..10) The good The bad The bottom line
VMware Workstation 2.03 9 Provides a self-contained Windows environment that makes its Linux host platform nearly immune to collateral damage. It's expensive. VMware is an essential IS tool for multiplatform application management.
NeTraverse Win4Lin 2.0 7 Simple installation; good documentation; works as promised. No DirectX or Windows networking support. Win4Lin is a bargain Windows emulation platform if you need just the basics.
Wine 5 Runs Windows apps without Windows; strong user community Difficult to use; spotty application support; still under heavy development. With its innovative approach to Windows compatibility, Wine is destined to play a major role in the world of Linux. But for now, it's not quite ready for prime time.

4. C Code style

4�Mar�2001 (6 posts) Archive Link: "for loop fixes"

People: Alexandre Julliard,�Andreas Mohr,�,�Francois Gouget

After an unwanted semi-colon had been found where it shouldn't: loops of the form:
   for (i = nFirst; i <= nLast; i++);
   {
     /* do something */
   }
, Andreas Mohr proposed several things.

First of all, he wanted to add a space between the closing parenthesis and the semi-colon to indicate clearly the intent of putting an empty C expression. Francois Gouget replied he preferred the writing of such cases as
	<init_expression>;
	while (<test_condition>) {
	     <update_expression>;
	}
Alexandre Julliard more than agreed: he converted such cases into the while form of the loop.

Andreas also looked for other places plagued with the same default and found another one (which he of course fixed).

Unsurprinsignly, this almost started a flame war on coding style (how many spaces for a tab, which indentation style...). But it didn't happen. Wine developers seemed to like sticking to the rule of letting the developer do what best fits him (her), even if this doesn't provide a consistent coding style across the source files.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.