Wine Traffic #84 For 26�Feb�2001

By Eric Pouech

Table Of Contents

Introduction

This is the 84th release of the Wine's kernel cousin publication. It's main goal is to distribute widely what's going on around Wine (the Un*x windows emulator).

Mailing List Stats For This Week

We looked at 67 posts in 246K.

There were 32 different contributors. 12 posted more than once. 14 posted last week too.

The top posters of the week were:

1. local IP and registry

19�Feb�2001�-�21�Feb�2001 (2 posts) Archive Link: "TCP/IP networking and registry keys"

People: Alan Chandler,�Ove Kaaven,�

Alan Chandler wrote:
I spent most of the weekend trying to get Grand Prix Legends GPL to work. I achieved my first goal of getting it to run in server mode.

One of the things I needed to get the game to do, was to recognize that there where some interfaces it could talk TCP/IP out of. It took me some time to realize that under windows it was doing this by looking for the key [System\\CurrentControlSet\\Services\\Class\\NetTrans] and was then enumerating the keys under it to establish an IP address ie the following:

[System\\CurrentControlSet\\Services\\Class\\NetTrans\\0000]
"IPAddress"="10.0.10.100"

The thought occurred to me that maybe the tool the builds the registry during wine install could actually create these keys - since it is essentially a key part of the system (and other similar keys are also built in the same way).

Ove Kaaven agreed on the utility of the key itself, but noted that
the IP address can change between Wine invocations (PPP, DHCP, and things like that), so it would have to be a dynamic key, generated at Wine startup or something like that.

There is already some keys which are dynamically generated (like the processor information - Pentium, stepping... - or copying the contents of the init files into Wine specific registry keys to ease the reading of those configuration afterwards), so the approach could be extended.

However, Ove wondered how the network interfaces could be gotten from the OS in a portable way ? There hasn't been any answer so far.

2. Setting up a Wine's test harness

14�Feb�2001�-�23�Feb�2001 (12 posts) Archive Link: "Perl/Wine extension for perusal"

People: John F Sturz,�Alan Gonzalez,�Jeremy White,�Alexandre Julliard,�Francois Gouget,�CodeWeavers,�,�codeweavers,�Joshua Thielen,�Eric Pouech

John Sturtz (re)-opened the long awaited issue of bringing up a test harness for Wine (and its implementation of the Windows API).
I work for CodeWeavers here in St Paul. Awhile back, I was set to the task of working on winetest, a Wine application which provided a flex/bison-based parser for a little scripting language from which Wine API functions could be called. The idea was that one could write test scripts which would call Wine API functions and examine the results, and the scripts could be used for regression testing of Wine.

The scripting language began life with a rather Perl-ish syntax, and as functionality got added, it got more so. Eventually (about the time I had implemented a pack function, and wanted an unpack), I decided to see if I could write a Perl extension that provided a gateway for calling Wine API functions. That way, scripts for regression testing could be written directly in Perl instead.

John then provided a first implementation of this (you can find it at ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz (ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz) ).

Basically, what you can do with this is invoke some tests like:

    $atom = kernel32->GlobalAddAtomA("bark");

Joshua Thielen pointed out that some existing Perl modules for Win32 (from the ActiveState (http://www.activestate.com/) site) allowed to provide the same interface as John's work (which was Linux based only). Alan Gonzalez also noted that this
will work out of the box on cygwin for windows using the perl 5.6.1 that is bundled with it.
Jeremy White then started to figure out what the test harness should contain:
I think it would be great if we could start to define (and build) a test harness. I think that there are a lot of people who would help write test scripts, who might otherwise be unable to help with Wine development. The more the merrier, I always say...

Jeremy started to split out the test cases into two categories:

As already covered (see BROKEN KCREF), a free test tool for X11 regression test has not been found yet, making the second category a bit difficult to run.

Eric Pouech proposed to have a two pass approach to run the test. First the test case is run and outputs some results which are stored into a file. Then, the contents of this file is compared against a reference file.

This would allow, beyond the simple regression idea - running twice the same program should provide the same results -, to compare the output between running the program under Windows and running it under Wine.

Eric also liked to idea of writing test cases in C which would allow to test three cases:

Alexandre Julliard really backed up the idea of the Perl test scripts:
The idea of using an interpreter like Perl is precisely that you don't need to compile anything to run tests. I think this is important because not everybody has a Windows compiler. It also allows using the exact same test script under Windows and Wine, so that you don't have to worry whether your Windows binary exactly matches your Winelib binary.

Eric and Alexandre further argued whether it was more common not to find a compiler or not to find a Perl interpreter on a PC/Windows box.

Francois Gouget also liked the C/C++ tests because
The downside of interpreter-based tests are:

The thread ended with Eric and Alexandre still arguing on some other points. All the details of the test harness are not settled down yet, but the effort of providing such an environment has started. We'll keep you posted with the advances.

3. Wine .so files' names

23�Feb�2001�-�24�Feb�2001 (12 posts) Archive Link: "huge library renaming ?"

People: Andreas Mohr,�,�Ove Kaaven

Andreas Mohr asked whether all the Wine libraries shouldn't be renamed to libwineXXX to avoid any conflict with existing libraries. Wine already had a clash with libole.so and gnumeric.

After some discussion on how the current distributions were doing their packages (Debian, RedHat...), Ove Kaaven explained what should be the final scheme.

The Wine DLL files (to be semantically correct, read the .so files containing Wine's DLLs ; see BROKEN KCREF) should be stored in /usr/lib/wine (as FHS suggests). All the other .so files (like libwine_unicode, libwine_tsx11...) should be stored into /usr/lib (or any directory pointed by /etc/ld.conf). /usr/lib/wine shouldn't be referenced by the /etc/ld.conf configuration file.

Any program (winelib or wine itself) which wants to import a file will do it through the import directive of its .spec file (and will not require the support of the linker (like using -lfoo) for that).

In other words, all is already in place for a proper storage, avoiding any naming conflicts.

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.