Wine Traffic #216 For 26 Mar 2004

By Brian Vincent

Table Of Contents


This is the 216th issue of the Wine Weekly News publication. Its main goal is to remind you to floss. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at (

Mailing List Stats For This Week

We looked at 168 posts in 477K.

There were 49 different contributors. 25 posted more than once. 22 posted last week too.

The top posters of the week were:

1. News: WineHQ Stats

20 Mar 2004 - 26 Mar 2004 (3 posts) Archive Link: "News"

Topics: News

People: Gavriel StateLinuxWorldGav StateNewsTransGaming

Someone on IRC pointed out CIA is tracking Wine stats ( . The stats are skewed since it tracks things sent to wine-patches rather than wine-cvs. Nonetheless, the numbers are interesting. I suspect some of the other projects that show lots of traffic include regular discussion on their lists as well as patches.

Over at Frank's Corner ( I found a link to a article titled "Linux and Windows: Mixed doubles" ( . Part I goes into a bit of discussion about Wine and part II ( delves into actual configuration of the Wine config file. (Yes, that same config file a bunch of people are working on eradicating once and for all.)

In fact, that task is on the To Do List ( . A few weeks ago we had 19 items marked as complete, 30 in progress, and 18 up for grabs. We've seen more progress and now:

Alexandre is working on the filesystem changes right now. We're likely to see a domino effect of some items once that's complete. Namely, that will set things up for switching the configuration into the registry.

LinuxWorld looked at the capabilities of Linux as a gaming platform. Dee-Ann LeBlanc put together two articles that mention a bit about TransGaming. The first one explores challenges ( faced by Linux. The second goes in-depth ( into libraries that can be used by game programmers. It includes this quote from Gav State:

Our users have asked us to begin adopting the ALSA API in place of the older OSS [Open Sound System, ( ] APIs, and we've begun to look at how best to do that. One option that we're considering is switching to OpenAL, which now has a direct ALSA back end. Doing that right is going to require us to get some extensions added to OpenAL, which we're discussing with OpenAL developers such as Ryan Gordon; driver quality is still an issue.

OpenAL ( was first introduced by Loki and provides a cross-platform 3D audio API.

2. New Task Manager

21 Mar 2004 (1 post) Archive Link: "reactos' taskmgr"

Topics: Utilities

People: Eric PouechReactOS

Eric Pouech ported a Task Manager to Wine:

This is (finally...) the port of ReactOS taskmgr into wine.

There's also a small trick for setting/resetting debug channels on the fly. Just left click on any running program (not application) and in the context popup menu, choose the debug channel edition line. This will require you to have a running dbghelp DLL, which I might provide RSN. In other words, this patch alone won't allow channel manipilation, this patch and the yet to come dbghelp DLL will do.

There's still lot of possible improvement on the UI part for the debug channel editing, so if someone has better ideas for implementing it, please feel free to do it.

The Task Manager is pretty slick, and since it lends itself to screenshots I figured I would make some available:

3. WinAPI Stats on WineHQ

24 Mar 2004 - 25 Mar 2004 (10 posts) Archive Link: "To Do A.11 - Integrate API status into WineHQ"

Topics: News

People: Ofir PetruskaJeremy NewmanFrancois GougetNews

More work on the web site has been done over the past week. I'll summarize those changes in a news article next week. This one developed a thread on wine-devel, so I'll cover it now. Ofir Petruska, who seems to go by hatky, came up with a way to display the output from the winapi_extract tool. Francois Gouget has had a version of this on his personal web site for a while and it was decided it was cool enough that we should integrate it into WineHQ. Hatky came up with a different approach ( that involved using MySQL for part of the logic. Dimi was definitely against using a database, but hatky explained:

It uses DB only for creating the file as a parser becouse it's 3 lines of code instade of 30 line parsing and very very flexable, I talked to laxdragon, he has not problem with it, he is still reviewing it...

Jeremy Newman then took a look at it and made modifications. He announced:

Ok, I have commited a version of hatky's work. It is in one php file instead of split across multiple files.

The file is in the tools cvs (

I ran it once and the output will be here: (

It will be updated when Alexander runs the wine_release script.

There is one bug we noticed, and I'll leave that for someone else to fix. The dll name is only showing the first 5 characters. I double checked, it is getting inserted into the db correctly, so it is happening sometime after the insert.

Thanks hatky for your work.

Francois pointed out that several DLL's needed to be ignored since they were Wine-specific. He provided a list that hatky integrated.

4. A Distributed Test Environment

17 Mar 2004 - 24 Mar 2004 (42 posts) Archive Link: "Win32 packages released on sourceforge"

Topics: Testing

People: Paul MillarChris MorganFerenc WagnerDimi Paun

More discussion took place about setting up a distributed testing framework. When this actually rolls out I'll write up more info about how it works. Some of the details are still being sort out, but basically the process will work like this:

In essence, the process is quite simple. Some discussion took place this week over details. Paul outlined how he has the builds set up:

I'm adding cross-building as part of WRT, so we'd get winetest.exe rebuilt as changes are made to CVS (& everything else too, if people want that). Its nearly there, having worked around some mingw/COFF nasties. There's one last hurdle: winetest.exe itself.

>From what I can see, the script programs/winetest/maketest builds the winetest.rc file. If the variable WINE_BUILD is set, it is used as the first element of the string-table, otherwise an auto-generated string is used, for example "20040322.1508-auto".

This makes winetest.exe build-time-dependant, so screws up the check to see if anything's actually changed.

Can I set WINE_BUILD to some fixed value? If so, what's a good one to use?

Dimi Paun had some suggestions:

The WINE_BUILD value must be valid, we can't distribute a winetest.exe with a fixed value in there. What you can do is fix it at build time to a known value (say YYYYMMDDhhmm), and replace it after the build with the proper value.

Now, when do we build? I don't think we should trigger the build based upon CVS commits, we need it a bit more controlled for a variety of reasons. Here is what I propose:

But the main point here is that we can't build based on CVS commits, we need a well known, controlled point where we build so that developers can reproduce the build and investigate problems.

Discussion then went back and forth.. and back.. and forth about whether to have builds triggered by CVS commits. Paul produced some interesting info concerning CVS commits:

Errr, 'fraid I don't see the 4am part (unless you mean at precisely 04:00:00). Taking data from the past year from:

Downloading the "downloadable version", and running a wee 1-oner:

Gnuplot it with:

The results are: (

There's actually a peak of commits at 4am.

This is of course all UK local time. Do you mean 4am in one of the US-time-zones? (=> ~ 9am-11am or so?).

Hmmm, in the past year there've been patches a 7am, 8am, 11am and 13am. There haven't been any 9am and 10am, but looking at the data it wouldn't be impossible for Alexandre to commit at usual hours of the day or night :)

Actually, the build time isn't *that* time consuming. Running ccache and distcc, it currently takes about an hour to build both native and cross-compilation. With a bit of effort, I'm sure that could be improved a fair bit. As soon as the cross-compilation is finished, the binaries are available to be published.

The time-consuming bit at the moment is running the tests within wine, which is bad because of the way that's done within WRT. That needs fixing, but it's largely independent of the cross-building, publishing steps.

From there the discussion delved into using GPG to sign the binaries. Paul has already implemented that part on the server.

5. Wine Weekly News Issues #90 and #91

24 Mar 2004 (2 posts) Archive Link: "Missing WWN issues"

People: Francois GougetBrian VincentEric PouechNews

Francois Gouget pointed out we have a bit of a gap in Wine Weekly News issues:

Looking through the WINeHQ CVS I noticed that we are missing 4 WWN issues. Fortunately they seem to be available at the Wine Kernel Cousin web site... sort of.

Would some kind soul volunteer for retrieving what can be retrieved?

WWN 88 and WWN 89
Unfortunately these two appear to be empty so there's not much to save.
WWN 90
Eric Pouech's call for a replacement.
WWN 91
Brian Vincent's first WWN.

We changed the XML format a few years ago, so I went back and ported the missing issues. If you're interested in the latest news from 2001, check out issues #90 ( and #91 ( . More interesting than that (at least to me) was Eric Pouech's revelation that parts of issue #88 exist, but had never been published. At some point in the future I'll create issue 88 from those bits.







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.