Wine Weekly News #85 (2001 Week 10)

Eric Pouech Eric.Pouech at
Tue Mar 6 16:25:55 CST 2001

Eric Pouech (
"The future will be better tomorrow", Vice President Dan Quayle
-------------- next part --------------

                              Wine Weekly News
   All the News that Fits, we print.
   Events, progress, and happenings in the Wine community for March 05,
   2001 .
   Wine-20010305 has been released. Main changes include:
     * Some improvements to the wineserver protocol.
     * The usual common controls fixes/improvements.
     * Version information in builtin dlls.
     * Lots of bug fixes.
Keeping track of Wine
   The following changes from the last two weeks made it into the
   20010305 release.
     * Alexandre Julliard optimized wineserver communication some more
       (including better file descriptor caching), and strived for more
       DLL separation cleanliness.
     * Dmitry Timoshkov (CodeWeavers) added version resources to the core
       built-in dlls.
     * Eric Pouech implemented some shell32 rundll features (making the
       control panel starting to work).
     * David Grant added some copy and delete functions to the shell
     * Workers/Bugfixers: Andreas Mohr (misc), Gerard Patel (16-bit print
       dialog, misc), Michael Stefaniuc (Winsock routing table query),
       Ian Pilcher (PostScript driver), Johannes Schindelin (German
       keyboard layout), Ove K?ven (winelauncher), Lionel Ulmer (OpenGL
       support), Vedan Rodic (DIB depth conversion), Przemyslaw Bruski
       (Mac codepage in locales), Valery Kartel (Ukrainan locale),
       Dominik Strasser, Chris Jacobson
          + CodeWeavers: Fran?ois Gouget (winelib, winemaker, listview
            control), Dmitry Timoshkov (controls, windows, ANSI
            fileapis), Susan Farley (pager control), Aric Stewart
            (clipboard), Chris Morgan (mousewheel sysparam)
Discussions on wine-devel
   This week, 45 posts consumed 190 K. There were 20 different
       contributors, 11 (55%) posted more than once, and 9 (45%) posted
       last week too.
       The top posters of the week were:
     * 7 posts in 17 K by Eric Pouech <Eric.Pouech at>
     * 6 posts in 38 K by "Alexandre Julliard" <julliard at>
     * 5 posts in 17 K by Ian Pilcher <pilcher at>
     * 3 posts in 9 K by lawson_whitney at
     * 3 posts in 23 K by Michael McCormack
       <mccormac at>
     * 2 posts in 9 K by David Elliott <dfe at>
     * 2 posts in 8 K by Andreas Mohr <a.mohr at>
     * 2 posts in 6 K by Vedran Rodic <vedran at>
     * 2 posts in 5 K by Francois Gouget <fgouget at>
     * 2 posts in 4 K by "Ove Kaaven" <ovehk at>
     * 2 posts in 0 K by Robert O'Callahan <roc+ at>
   Wine's speed-up Evolution
   (EdNote: resurrecting [1]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 [2]WWN coverage part #1 and [3]WWN coverage
       part #2) 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
   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
       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.
   Wine press coverage Report
   Eric Pouech posted a link to a [4]C|Net article, 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.
   C Code style Evolution
   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. Fran?ois Gouget replied he preferred the writing of such
   cases as
        while (<test_condition>) {

   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.
        Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove K?ven.


   5. mailto:ridgway at
   6. mailto:pouech at
   7. mailto:ovek at

More information about the wine-announce mailing list