Wine Weekly News #85 (2001 Week 10)

-- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle 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@wanadoo.fr * 6 posts in 38 K by "Alexandre Julliard" julliard@winehq.com * 5 posts in 17 K by Ian Pilcher pilcher@concentric.net * 3 posts in 9 K by lawson_whitney@juno.com * 3 posts in 23 K by Michael McCormack mccormac@aals27.alcatel.com.au * 2 posts in 9 K by David Elliott dfe@infinite-internet.net * 2 posts in 8 K by Andreas Mohr a.mohr@mailto.de * 2 posts in 6 K by Vedran Rodic vedran@renata.irb.hr * 2 posts in 5 K by Francois Gouget fgouget@free.fr * 2 posts in 4 K by "Ove Kaaven" ovehk@ping.uio.no * 2 posts in 0 K by Robert O'Callahan roc+@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@winehq.com 6. mailto:pouech@winehq.com 7. mailto:ovek@winehq.com