World Wine News

Our users have asked us to begin adopting the ALSA API in place of the older OSS [Open Sound System, www.opensound.com ] 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.

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 manipulation, 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.

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

Ok, I have committed 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 http://cvs.winehq.org/cvsweb/tools/winapi_stats.php

I ran it once and the output will be here: http://www.winehq.org/winapi_stats

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.

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-dependent, 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?

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:

• decide on a time at night when the tree is very unlikely to change (say 4am).
• every day, at 4:10am we do: cvs up -D YYYYMMDD0400 (this way we know _precicely_ what we built, and we can reporduce it)
• do the build (fix WINE_BUILD), check if the winetest.exe really changed.
• if it changed, edit WINE_BUILD and set it to YYYYMMDD0400.
• publish the result as winetest-YYYYMMDD0400.zip via the CGI script

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.

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

http://www.winehq.org/hypermail/wine-cvs/

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

grep -h Date: 200[34]\.*|cut -d: -f2-|while read d; do date -d "$d" +%k >> output; done; sort -n output | uniq -c | awk '{print $2,$1}' > commit.dat

Gnuplot it with:

plot [-0.5:23.5] "commit.dat" not w boxes

The results are: http://www.astro.gla.ac.uk/users/paulm/cvs_commit.png

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 at 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.

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.