Wine Weekly News #84 (2001 Week 09)

Thu Mar 1 10:44:13 CST 2001

please find enclosed the latest WWN issue
A+
-- 
---------------
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/)
"The future will be better tomorrow", Vice President Dan Quayle
-------------- next part --------------

                              Wine Weekly News

   All the News that Fits, we print.

   Events, progress, and happenings in the Wine community for February
   26, 2001 .
     _________________________________________________________________

     _________________________________________________________________

Discussions on wine-devel
     _________________________________________________________________

   This week, 67 posts consumed 246 K. There were 32 different
       contributors, 12 (37%) posted more than once, and 14 (43%) posted
       last week too.
       The top posters of the week were:

     * 9 posts in 20 K by "Ove Kaaven" <ovehk at ping.uio.no>
     * 6 posts in 26 K by Eric Pouech <Eric.Pouech at wanadoo.fr>
     * 6 posts in 23 K by "Alexandre Julliard" <julliard at winehq.com>
     * 5 posts in 28 K by Ian Pilcher <pilcher at concentric.net>
     * 4 posts in 12 K by FT Rathore <mawali at news.icns.com>
     * 3 posts in 7 K by Gerald Pfeifer <pfeifer at dbai.tuwien.ac.at>
     * 3 posts in 10 K by Andreas Mohr <a.mohr at mailto.de>
     * 3 posts in 0 K by Robert O'Callahan <roc+ at cs.cmu.edu>
     * 2 posts in 7 K by "Patrik Stridvall" <ps at leissner.se>
     * 2 posts in 6 K by gerard patel <gerard.patel at asi.fr>
     * 2 posts in 5 K by David.Goodenough at dga.co.uk
     * 2 posts in 23 K by Martin Pilka <mpilka at codeweavers.com>

   local IP and registry Issue

   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.

   Setting up a Wine's test harness Evolution

   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
   [1]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 [2]ActiveState 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:
     * non-interactive: no user interaction is needed
     * interactive: user interaction is needed

   As already covered (see [3]this article ), 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:
     * test case compiled and run under Windows,
     * test case compiled under Windows, and run with wine
     * test case compiled under Unix as a Winelib application

   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.

   Fran?ois Gouget also liked the C/C++ tests because " The downside of
   interpreter-based tests are:
     * they won't test the Winelib headers or Winelib specific issues
     * I imagine that some of our potential test writers would be windows
       programmers (after all these tests would be nothing more than
       simple Windows applications). They would probably be more
       comfortable writing tests in C/C++.

   "

   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.

   Wine .so files' names Issue

   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 [4]for the details) should be stored in
   /usr/lib/wine (as FSH 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.

        Credits: [5]Doug Ridgway, [6]Eric Pouech, and [7]Ove K?ven.
     _________________________________________________________________

References

   1. ftp://wine.codeweavers.com/pub/other/perlwine.tar.gz
   2. http://www.activestate.com/
   3. http://www.winehq.com/News/2000-43.html#0
   4. http://www.winehq.com/News/2000-51.html#FTR
   5. mailto:ridgway at winehq.com
   6. mailto:pouech at winehq.com
   7. mailto:ovek at winehq.com