Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #65 For 16 Oct 2000

By Eric Pouech

Table Of Contents


This is the 65th 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 88 posts in 280K.

There were 30 different contributors. 17 posted more than once. 20 posted last week too.

The top posters of the week were:

1. Headlines


People: codeweaversMartin Pilka

2. Wine press

9 Oct 2000 - 10 Oct 2000 (4 posts) Archive Link: "Wine press"

People: Jeremy WhiteCodeWeaversFrancois Gouget

Following last week discussion on Corel and Microsoft deal, Paul E. Merrel posted another article on the subject: a Linux world article reports on Corel's Rene Schmudt (executive VP of Corel's Linux product group) on Wine and .NET from a Corel point of view.

Later on, Paul also posted a LinuxPlanet article where Wine development was discussed, with good parts from Jeremy White (CodeWeavers CEO)

Jeremy felt the need
to briefly 'adjust' an impression that this may have left about something I said to Kevin (EdNote: the LinuxPlanet's article writer).

I personally care more about Winelib than about Wine, and I think Winelib is more relevant to my customers, particularly here in the U.S., where paying for VMWare or Win4Lin isn't that much of a barrier to my potential customers.

I don't speak for the personal goals of the rest of the CodeWeavers team, many of whom care passionately about the Wine loader. Further, we're making a major effort to boost Wine as a whole (in fact, prior to Francois's (EdNote: Francois Gouget) work, all of what we did served to help Wine as a whole as opposed to Winelib). Finally, I'm actually very excited about the progress of Wine (I was just disappointed - I had hoped to show off some cool new 1.0 stuff to Kevin, but the demos didn't work out).

I'm just the nutty kind of geek who gets more of a thrill out of watching 500,000 lines of Windows code compile than I do out of watching Starcraft run <g>.

3. Directory access modes

12 Oct 2000 (6 posts) Archive Link: "Dir readonly problem"

People: Rein KlazesFrancois GougetUwe BonnesDavid ElliotRein Klaze

Rein Klazes proposed a patch for the following issue he had:
A winrar self extracting archive, created a read-only dir and tried to unpack the archive into that dir. Unfortunately readonly for dirs means quite different things, in dos/win the directory is protected from deleting, in unix you cannot create new files in it.

Rein then proposed a simple fix: not to create the directory with read only attribute, but this triggered a few comments.

David Elliot proposed another solution: the directory would be created read-only, and any file operation on this directory would imply a set of operations (set the dir attribute to writable, do the file operation, reset the dir attributes to their original state). This should also be done in an atomic way, involving dir locking/unlocking. However, portability of such a solution across all known Unix file system would certainly raise lots of issues (like chmod on a FAT system).

Some other people suggested, like Uwe Bonnes, suggested implementing the tricks on the wine server side. But this wasn't a good suggestion either.

Francois Gouget had the final word, stating that Rein's first proposal was in fact the correct solution:
All the solutions that have been discussed on wine-devel are too complex and flawed at the root because of the semantics difference: FILE_ATTRIBUTE_READONLY applied to a directory means 'make it so this directory cannot be deleted'. This is impossible to do in Unix (except on systems that support ACLs).

Francois even tested the same type of operation using Samba, and the Windows read-only directories were created with read-write attributes.

David Elliot agreed with Francois latest proposal. The only remaining solution shall be based on ACL, but is another magnitude of complexity.

4. Graphics optimization

12 Oct 2000 - 15 Oct 2000 (21 posts) Archive Link: "optimization using assembler"

People: Mark DufourEric PouechUlrich WeigandPatrik StridvallHuw DaviesPatrik StridvalMark

Mark Dufour, after reading the benchmark results (see BROKEN KCREF),
wondered if windows does many of the involved operations so much faster than wine because of x86 optimizations. Wouldn't wine run much faster in many areas if assembler equivalents were written for critical operations, for different processors ? I understand that some maintenance problems would result from this...

Eric Pouech gave a quick overview of the situation:
Results from the benchmark are also slow because:

Eric also explained, that most of bitmap handling relied on the X11 rendering engine, and then used fault handlers on memory used by Wine internal data and X11 data for the bitmaps to synchronize the two of them. In this area, he added
I doubt assembly would help (unless we build our own rendering engine)

Mark get lurking around to find some possible improvements and asked whether the coordinate computation code according to the DC mapping could be optimized: since MM_TEXT is a widely used mapping mode, and there's no need to rescale the coordinate, just change the origin, Mark noted that lots of computation were not useful.

Patrik Stridvall proposed a way to code this, based on the fact that a mapping shall be constant across a graphic operation call (like LineDraw), so different paths doing only the requested conversions according to the mapping could be implemented.

Ulrich Weigand wasn't sure this would bring some speed (had to be tested), but rather suggested to update the coordinate conversion macro with Patrik's proposal and let the compiler do the rest of the job with common subexpression elimination (in this case applied to the mapping testing). He also didn't like Patrik's code duplication because:
But I was rather trying to search for a solution that affects maintainability of the code as little as possible, while still offering as much performance improvement as possible.

Generally, the problem with performance optimizations is that they tend to make the code less maintainable, by introducing code duplication, special cases, even things like inline assembly etc. At least in the current state of Wine, I tend to think maintainability more important than performance ...

Huw Davies also pointed that current coordinate handling missed the world transformation from NT (requiring more than just a translation / scale operation). Supporting this would imply changing most of the coordinate transformation code.

Patrik Stridval then proposed another approach: instead of having one set of all functions for DC operation, Wine should support for each function four different implementations of the function depending of the mapping. The DC should know which one to use ; Patrik proposed four levels:
  1. no modification needed
  2. translation applied
  3. translation and scaling applied
  4. world transform
and would directly call the right function, hence reducing the cost of comparison in the functions.

However, Patrik agreed that
Premature optimization is the root to all evil"
and wondered
if we should wait with these kind of optimizations until after Wine 1.0.

5. Another Explorer project

15 Oct 2000 (2 posts) Archive Link: "GXExplorer Open Source Project"

People: Paul E. MerrellJuergen Schmied

Paul Merrell reported a another open source effort around Windows basic software:
Just ran across the EXExplorer open source project, which is developing a Delphi-based replacement for the Windows Explorer and file manager on the Windows platform. . I don't remember seeing it mentioned on this list before.

Y'all will know far better than me whether that project might complement the Wine effort, but it occurred to me that there might be some expertise there that might be useful to you.

Juergen Schmied answered:
It's just one more program what can be used with wine. I don't think we are trying to supply a set of applets to replace the windows ones since all of these are already available as native applications. I see the focus of the wine project (exe-loader part) more in supplying a possibility for executing games(joe user) and special customer applications (corporate user).

The GXExplorer works quite good with wine but you have to use some native dll's since it's using quite a bit of the ole stuff. Last time I tried (some months ago) I had to use ole* dlls and many registry keys from a native windows. This program is a good test for the build in shell32, comctl32 and ole* since it uses many advanced features.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.