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 #160 For 7 Mar 2003

By Brian Vincent

Table Of Contents


This is the 160th release of the Wine's kernel cousin publication. It's main goal is to give me something to do while recovering from Silverton and Crested Butte. It also serves to inform you of what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 243 posts in 977K.

There were 59 different contributors. 27 posted more than once. 26 posted last week too.

The top posters of the week were:

1. News: Gav State and Mike Hearn Interviews

1 Mar 2003 - 7 Mar 2003 (2 posts) Archive Link: "News"

Topics: News

People: Mike HearnDesktopLinuxNewsTransGamingGavriel State interviewed Gavriel State of TransGaming. Rather than strictly focus on WineX, it discusses Linux and the gaming industry. Good stuff.

Also interviewed this week was Mike Hearn. Mike has been contributing to Wine for a little while now, but he's also been working on another project involving packaging and installation. Newsforge published an article about that project and the issues he's running into.

2. Compliance Tests on Longhorn

7 Mar 2003 (1 post) Archive Link: "Windows Longhorn 3683 complaince status"

Topics: Microsoft Windows, Testing

People: Mathew McBride

Mathew McBride had an opportunity to run Wine's commpliance tests on a Longhorn build - what will be the successor to Windows XP. All in all, it's quite encouraging. Mathew also gave a short review of features in the new OS:

I've managed to get hold of Windows Longhorn Build 3683. All tests should be simular to WinXP at the moment with notable changes in:

Internet Explorer
Internet Explorer cannot download files. It appears to have been fixed in 4008. Use Mozilla instead. It's way better.
DirectX appears to be the 899 build, not the 900 build being distributed at the moment on Microsoft's website. Sources tell me that the version in 4008 still has the same build identifier and same size. DirectX diag is unable to run Display tests, claiming a button was pressed.
Doesn't affect Wine, but Longhorn doesn't seem to include IPv6 at all
Changes introduced by WinFS Storage services (which needs to be turned off because it sucks a lot of CPU power) are unclear at the moment
Compliance mode
There is a WinXP compliance mode. But it only seems to affect the build identifier used.
I had to force Explorer.exe into Safe Mode in the .NET Framework manager to stop it from delaying the playing of the welcome sound. Also included is a new theme called Plex and a XML based sidebar. A new XML based display panel is also included, but has been mothballed in 4008. The sidebar includes a desktop switching panel. You only have 4 of them, however.
TabletPC apps (Journal etc.) are included and also drag the system down a bit. But journal.exe seems to be missing. Anyone have any idea about these services and weather they have any place in Longhorn/NT 6.0:
  • Fusion Isolation Service
  • Castle Service
  • Logon Hours (This appears to be more domain oriented, I didn't see this in XP SP1)

Windows still has the nasty activation feature, and as usual, includes a timebomb of 360 days. Both of these have been disabled in the registry. It turns out, that the leaked build also contains Beta's of:

Which means that a Syncronised Server and Client release will probably happen in 2004/5. I was not able to test out the Web servers, because I am using a FAT32 Filesystem. (I did switch to Enterprise though, but soon went back)

I should note that some of the above is slightly edited in order to be more readable. Mathew went on to describe test output. In order to make this more readable I'll just include a short summary:

Now to the tests:

3. Porting With Winelib

5 Mar 2003 - 6 Mar 2003 (4 posts) Archive Link: "Winelib article in this month's C/C++ User's Journal"

Topics: Winelib

People: Matthew BlochFrancois GougetJoe Casad

Matthew Bloch wrote in announcing, " An immodest plug for my introductory Winelib article that the CUJ editor Joe Casad was soliciting through thist list back in December. It's now in the print journal and on their web site at the (temporary, by the looks of things) link above. Thanks to the people who offered criticism before publication; hopefully in the three months since I wrote it the information isn't too out of date!"

The URL he provided didn't work, but Francois Gouget located the article at, ""

The article is well written and contains Matthew's first hand account of porting a game using Winelib.

4. Wine's Library Dependencies

3 Mar 2003 (4 posts) Archive Link: "Wine dependancies"

Topics: Documentation

People: Mike HearnMarcus Meissner

Mike Hearn wrote in with a neat list for reference:

I thought I'd find out what libs Wine actually required, at least on my build.


in the $prefix/lib/wine/ directory produced the following list:

The inclusion of libgcc_s and libstdc++ is from the Direct3D code I think, I didn't realise there were deps on the c++ libs.

Otherwise, it's a remarkably short list. I think maybe quite a few of the libs are detected at runtime, I know there was a patch to make OpenGL code detected like this (as opposed to enabled at compile time) - despite having a driver for the Jack sound server in this directory for instance, there is no dependancy on libjack. The other libs are fairly standard and would be present on almost all installations. A few, like the C++ libs and ncurses aren't a part of the LSB and at present would need to be statically linked.

Marcus Meissner pointed out a few other things:

You missed,,,, (,, which are loaded dynamically :) is also pulling the C++ libraries.

Also we currently access glibc lowlevel code, which does not help in portability.

5. FindFirstChangeNotification Patch

1 Mar 2003 - 4 Mar 2003 (12 posts) Archive Link: "miranda"

Topics: Filesystems

People: Geoff ThorpeHans LeidekkerMike McCormackAlexandre JulliardMike HearnEric Pouech

Geoff Thorpe reported a problem, part of which was this missing function:

fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial).

Basically this function waits for a change to the underlying filesystem. Eric Pouech felt the implementation would be hard. Mike Hearn thought FAM was standard enough that it could be used. Hans Leidekker also thought about FAM and wrote in about some initial work:

You know, a couple of weeks ago I looked at the possibilities of a FAM based implementation, as suggested in bugrequest #588:

There are other solutions (dnotify, fmon on FreeBSD), but FAM is available now on RedHat and Mandrake distributions, which gives it an avantage. Furthermore, FAM will fall back to a polling strategy when kernel level support is absent. I think it's the best candidate.

The real question is: does FAM provide enough functionality to implement all of FindFirstChangeNotification and friends? The short answer is no. For example, Win32 change notifications can be obtained for complete subtrees, e.g you can ask to be notified of changes to C:\ and everything beneath. As far as I can tell FAM only supports directory level notifications.

In addition, I found that there isn't a straight mapping from Win32 change events to FAM monitoring events: under Win32 you ask for directories to be watched for certain events: file deletions, added files, changes to file attributes and some more. With FAM, you watch a directory OR a file for changes. This could mean that, in order to mimic Win32 behaviour, one would have to watch both the specified directory and ALL files in that directory to gather all necessary information. And then FAM doesn't support file deletion events. We could of course regain those by doing some extra bookkeeping, but it starts getting hairy.

All of this did not scare me enough however to actually implement some of this API on top of FAM. And you know what, it already works! It's really neat to see that Word file dialog automatically refresh when you add a file to the directory you're looking at!

I will try to clean it up sometime and submit what I have. Don't know if it's worth doing that though since it implements so little of the API.

Mike McCormack didn't like the idea at all:

Please don't write a FAM dependent implementation. This introduces an unnecessary dependency in Wine, and as you mentioned a polling solution to this problem is wasteful or CPU time.

I submitted a patch a couple of months ago that implements a kernel based solution (using F_NOTIFY) to the problem, which IMO is much nicer.

My patch is at:

Dimi wanted to know why it wasn't applied, Alexandre explained, " It needs some portability work, and I haven't found the time to do that. And now of course it will need to be adapted to the new fd management."

Mike wrote back with a patch updated to the fd management stuff but didn't know what the portability problems were. Alexandre replied, " Mostly the RT signal stuff. You can't just #define RT_SIGNAL_NOTIFY if it's missing..."

Mike updated his patch with the following note:

This patch implements file change notification. It contains a fix for portability and some changes to avoid race conditions with signal handlers.


Alexandre hasn't applied it yet.

6. Wine & Smatch HOWTO

2 Mar 2003 (1 post) Archive Link: "Wine and Smatch"

Topics: Debugging

People: Michael Stefaniuc

Michael Stefaniuc put together instructions describing his work with Smatch - the source code checker. We've also covered this in the past few issues. His announcement:

I've written a web page about Wine and Smatch:

It includes also a table with the bugs found by the smatch scripts. I could need a hand with the bugs (status BUG, UKNOWN) cause I don't know how to fix them correctly (and for some locking BUG's i am not sure that they are real bugs).

Now that the fight with the web page is over I can go to write more smatch scripts ;).

The page is an excellent description of installing Smatch, how to run it against the Wine source code, and how to use various scripts.

7. Indenting Relay Traces

2 Mar 2003 - 4 Mar 2003 (7 posts) Archive Link: "Relay trace indenting?"

Topics: Debugging

People: Duane ClarkMike HearnEric PouechEnrico Horn

Duane Clark was wondering if there was something to help with debugging traces:

Just wondering if anyone has written a script or something that does indenting of relay traces. I don't know how other people handle these, but I find that I invariably spend a lot of time indenting the calls in relay trace files to make them easier to follow. It would seem like something that someone would already have an automated method of handling (or maybe I'm the only one that does this).

A few people discussed how it could be done, then Mike Hearn pointed out there was a tool to do this:

I was under the impression this is what tools/examine-relay did?

I never understood exactly how it does the indents though, it does it in a slightly non-intuitive way

Eric Pouech felt it wasn't so bad:

non intuitive ? the only issue examine-relay currently have is that it doesn't split the output on the thread by thread basis... so, non intuition may mean thread switch ;-) basically, examine-relay scans every relay output... and recreates the stack on a per thread basis... if it encounters a CALL, it pushes the info as a func call... if it's a RET, it pops the function call

Enrico Horn thought it was hard to read for a different reason:

I think by non-intuitive he means that the calling function is displayed BELOW the called function. this is because of the way the script works. And I call that non-intuitive too. I think it should be the other way around.

then it writes out the function so basicly if foo calls bar then the display look like this:

while it should be:

Duane adapted the code and submitted a new tool called "indent-relay". Alexandre didn't like the idea of another tool. So Duane adapted the current examine-relay tool to take an argument that selects full listing mode. Alexandre committed it the next day.







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.