Table Of Contents
|1.||1 Mar 2003 - 7 Mar 2003||(2 posts)||News: Gav State and Mike Hearn Interviews|
|2.||7 Mar 2003||(1 post)||Compliance Tests on Longhorn|
|3.||5 Mar 2003 - 6 Mar 2003||(4 posts)||Porting With Winelib|
|4.||3 Mar 2003||(4 posts)||Wine's Library Dependencies|
|5.||1 Mar 2003 - 4 Mar 2003||(12 posts)||FindFirstChangeNotification Patch|
|6.||2 Mar 2003||(1 post)||Wine & Smatch HOWTO|
|7.||2 Mar 2003 - 4 Mar 2003||(7 posts)||Indenting Relay Traces|
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"
People: Mike Hearn, , DesktopLinux, News, TransGaming, Gavriel State
DesktopLinux.com interviewed Gavriel State (http://www.desktoplinux.com/articles/AT8142909722.html) 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 (http://newsforge.com/article.pl?sid=03/03/04/2310251&mode=thread&tid=23) . 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:
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 (http://www.winehq.com/hypermail/wine-devel/2003/03/0193.html) . 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.
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"
People: Matthew Bloch, Francois Gouget, , Joe 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, " http://www.cuj.com/current/feature.htm?topic=current () "
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"
People: Mike Hearn, Marcus 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.
( for f in *.so; do ldd $f | sed '/wine/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.
5. FindFirstChangeNotification Patch
1 Mar 2003 - 4 Mar 2003 (12 posts) Archive Link: "miranda"
People: Geoff Thorpe, Hans Leidekker, Mike McCormack, Alexandre Julliard, Mike Hearn, , Eric 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 (http://www.winehq.com/hypermail/wine-devel/2003/03/0119.html) 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 (http://www.winehq.com/hypermail/wine-patches/2003/03/0073.html) 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"
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: http://people.redhat.com/mstefani/wine/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.
7. Indenting Relay Traces
2 Mar 2003 - 4 Mar 2003 (7 posts) Archive Link: "Relay trace indenting?"
People: Duane Clark, Mike Hearn, Eric Pouech, Enrico 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 (http://www.winehq.com/hypermail/wine-patches/2003/03/0024.html) 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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.