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).
DesktopLinux.com 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.
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:
- Longhorn XP Home
- Longhorn .NET Server Web Edition
- Longhorn .NET Server Standard
- Longhorn .NET Server Enterprise
- Longhorn .NET Server Datacenter (mothballing of this edition is likley, Unisys is only vendor of 2000 Datacenter and there is no 2003 Datacenter edition)
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:
/registry: 56 tests executed, 0 marked as todo, 3 failures.
/dsound: 61 tests executed, 0 marked as todo, 0 failures.
/generated: 2786 tests executed, 0 marked as todo, 0 failures.
/alloc. 58 executed, 0, 0
/atom 229398 executed, 0 ,0
/codepage 2 executed, 0 ,0
/drive 158 executed, 0, 0
/environ 39 executed, 0, 0
/file: 487239 executed, 0, 0
/format_msg 58 executed, 0, 0
/generated 609 executed, 0, 0
/locale: 112 executed, 0 , 11 failures.
/path: 1730 executed, 0, 2 failures.
process: 285 tests executed, 0 marked as todo, 6 failures.
thread: 112 tests executed, 0 marked as todo, 0 failures.
/file: 2 tests executed, 0 marked as todo, 0 failures.
/scanf: 9 tests executed, 0 marked as todo, 0 failures.
/access: 23 tests executed, 0 marked as todo, 1 failure.
/apibuf: 15 tests executed, 0 marked as todo, 0 failures.
/wksta: 14 tests executed, 0 marked as todo, 0 failures.
/error: 813 tests executed, 0 marked as todo, 5 failures.
/generated: 1279 tests executed, 0 marked as todo, 0 failures.
/rtlbitmap: 224 tests executed, 0 marked as todo, 0 failures.
/rtlstr: 38 tests executed, 0 marked as todo, 0 failures.
/safearray: 936 tests executed, 0 marked as todo, 8 failures.
/vartest: 1875 tests executed, 0 marked as todo, 0 failures.
/rpc: 901 tests executed, 0 marked as todo, 0 failures.
/generated: 272 tests executed, 0 marked as todo, 0 failures.
/shlfileop: 121 tests executed, 0 marked as todo, 13 failures.
urlmon_test.exe did not execute at all
/class: 80 tests executed, 0 marked as todo, 0 failures.
/generated: 1524 tests executed, 0 marked as todo, 0 failures.
/sysparams: 358 tests executed, 0 marked as todo, 0 failures.
/win: 373 tests executed, 0 marked as todo, 0 failures.
/wsprintf: 4 tests executed, 0 marked as todo, 0 failures.
/generated: 252 tests executed, 0 marked as todo, 0 failures.
/http: 23 tests executed, 0 marked as todo, 1 failure.
/wave: 233 tests executed, 0 marked as todo, 0 failures.
/sock: 1096 tests executed, 0 marked as todo, 0 failures.
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
The article is well written and contains Matthew's first hand account of porting a game using Winelib.
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.
( for f in *.so; do ldd $f | sed 's/ =>.*//'; done ) | sort | uniq
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 libXrender.so, libfreetype.so, libjack.so, libcups.so, (libcrypto.so, libssl.so), which are loaded dynamically :)
libfreetype.so is also pulling the C++ libraries.
Also we currently access glibc lowlevel code, which does not help in portability.
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
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.
- implement file change notification using F_NOTIFY
Alexandre hasn't applied it yet.
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: http://people.redhat.com/mstefani/wine/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.
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.