Wine Weekly News #85 (2001 Week 10)
Eric Pouech
Eric.Pouech at wanadoo.fr
Tue Mar 6 16:25:55 CST 2001
--
---------------
Eric Pouech (http://perso.wanadoo.fr/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 .
_________________________________________________________________
_________________________________________________________________
Headlines
_________________________________________________________________
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
filedialog.
* 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 wanadoo.fr>
* 6 posts in 38 K by "Alexandre Julliard" <julliard at winehq.com>
* 5 posts in 17 K by Ian Pilcher <pilcher at concentric.net>
* 3 posts in 9 K by lawson_whitney at juno.com
* 3 posts in 23 K by Michael McCormack
<mccormac at aals27.alcatel.com.au>
* 2 posts in 9 K by David Elliott <dfe at infinite-internet.net>
* 2 posts in 8 K by Andreas Mohr <a.mohr at mailto.de>
* 2 posts in 6 K by Vedran Rodic <vedran at renata.irb.hr>
* 2 posts in 5 K by Francois Gouget <fgouget at free.fr>
* 2 posts in 4 K by "Ove Kaaven" <ovehk at ping.uio.no>
* 2 posts in 0 K by Robert O'Callahan <roc+ at cs.cmu.edu>
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
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.
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
<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.
Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove K?ven.
_________________________________________________________________
References
1. http://www.winehq.com/News/2001-08.html#4
2. http://www.winehq.com/News/2000-36.html#3
3. http://www.winehq.com/News/2000-37.html#0
4. http://linux.cnet.com/linux/0-2136864-7-4961586.html
5. mailto:ridgway at winehq.com
6. mailto:pouech at winehq.com
7. mailto:ovek at winehq.com
More information about the wine-announce
mailing list