Wine Traffic #160 For 7 Mar 2003

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

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.

IPv6

Doesn't affect Wine, but Longhorn doesn't seem to include IPv6 at all

FileSystem

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.

GUI

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.

Others

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)

Now to the tests:

advapi32_test.exe /registry
/registry: 56 tests executed, 0 marked as todo, 3 failures.

dsound_test.exe /dsound
/dsound: 61 tests executed, 0 marked as todo, 0 failures.

gdi32_test.exe /generated
/generated: 2786 tests executed, 0 marked as todo, 0 failures.

kernel32_test.exe
/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.

msvcrt_test.exe
/file: 2 tests executed, 0 marked as todo, 0 failures.
/scanf: 9 tests executed, 0 marked as todo, 0 failures.

netapi32_test.exe
/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.

ntdll_test.exe
/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.

oleaut32_test.exe
/safearray: 936 tests executed, 0 marked as todo, 8 failures.
/vartest: 1875 tests executed, 0 marked as todo, 0 failures.

rpcrt4_test.exe
/rpc: 901 tests executed, 0 marked as todo, 0 failures.

shell32_test.exe
/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

user32_test.exe
/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.

wininet_test.exe
/generated: 252 tests executed, 0 marked as todo, 0 failures.
/http: 23 tests executed, 0 marked as todo, 1 failure.

winmm_test.exe
/wave: 233 tests executed, 0 marked as todo, 0 failures.

ws2_32_test.exe
/sock: 1096 tests executed, 0 marked as todo, 0 failures.

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

Running:

( for f in *.so; do ldd $f | sed '/wine/s/_=>.*'; done ) | sort | uniq

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

• libc.so.6
• libdl.so.2
• libgcc_s.so.1
• libGLcore.so.1
• libGL.so.1
• libGLU.so.1
• libICE.so.6
• libjpeg.so.62
• /lib/ld-linux.so.2
• libm.so.6
• libncurses.so.5
• libntdll.dll.so
• libSM.so.6
• libstdc++.so.5
• libungif.so.4
• libwine.so
• libwine_unicode.so
• libX11.so.6
• libXext.so.6

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.

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.

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

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

http://bugs.winehq.org/show_bug.cgi?id=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.

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:

http://www.winehq.org/hypermail/wine-patches/2002/11/0246.html

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

ChangeLog:

• implement file change notification using F_NOTIFY

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 ;).

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

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

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

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:

bar
foo

while it should be:

foo
bar