Wine Traffic #248 For 12�Nov�2004

By Brian Vincent

Table Of Contents

Introduction

This is the 248th issue of the Wine Weekly News publication. Its main goal is to telemark. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 137 posts in 570K.

There were 51 different contributors. 24 posted more than once. 32 posted last week too.

The top posters of the week were:

1. News: Ekush LGPL Violation?; AppDB Additions

6�Sep�2004�-�12�Sep�2004 (2 posts) Archive Link: "News"

Topics: News

People: Ge van Geldorp,�Tony Lambregts,�Chris Morgan,�,�codeweavers,�Microsoft,�ReactOS,�News

A story appeared on Slashdot this week about an apparent LGPL license violation with a product known as Ekush (http://www.akshor.com/) . In particular, they have redistributed slightly modified ReactOS binaries. ReactOS, in turn, uses Wine for it's Win32 subsystem. Ge van Geldorp, who has also contributed to Wine, wrote on Slashdot:

The release of Ekush caused some uproar in the ReactOS community, since it soon became apparent that Ekush was not much more than a repackaged version of ReactOS. Doing a simple string search for ReactOS on the Ekush binaries showed a number of hits.

Shortly after this was reported on the ReactOS mailing list, the Ekush website went down "for maintenance". Today they are back with a slightly altered set of binaries, which no longer contain the ASCII string "ReactOS". However, they forgot to search for Unicode strings... Ekush is not only violating the rights of ReactOS by deriving a product without releasing the modified source, they also derive code of (and are violating the rights of) Wine, FreeType and QEmu.

Now, there's nothing illegal about changing GPL'ed sources and not making the changes available for download. However, if you request the source code it must be made available. What's of more concern is that the copyright information has been removed. Allegedly, they've also added some stuff that's not legal to redistribute. The ReactOS guys have put together a nice summary (http://blight.eu.org/reactos/ekush.html) of the situation and proof of their claims.

On a more positive note, Chris Morgan and Tony Lambregts hacked on the Wine AppDB (http://appdb.winehq.org) this week and added support for maintainers. One problem with the database is simply keeping it up to date. The hope is that people will sign up to become maintainers of an application and then make sure comments are up to date and any other relevant info. This is actually quite similar to how CodeWeaver's Compatibility Center (http://www.codeweavers.com/site/compatibility/) works. For instance, if you check out Wine's page on Microsoft Word 2000 (http://appdb.winehq.org/appview.php?appId=10&versionId=67) you'll notice there's a big fat button that says "Log in to become an app maintainer". Guess what? If you set up an account and log in you'll be given an option to be an app maintainer.

If you regularly use an application it would really help to maintain a page in the AppDB. The time commitment is minimal and it could really help others. For instance, on the Word 2000 you'll find something like 136 comments. A bunch of them are from 2001 one and clearly aren't relevant. There's also no screenshot. By maintaining the app you can clean up the comments, post comments of your own, and soon you'll be able to add your own screenshot. Lastly, if you're a PHP hacker you might be interested in working on the AppDB itself. If so, contact Chris Morgan (mailto:chmorgan_at_charter.net) .

2. Cxbx: Xbox Emulator Ported

11�Nov�2004 (1 post) Archive Link: "Cxbx"

Topics: Winelib

People: Caustik,�Dimitrie Paun,�,�Dimi Paun

There's a little project called Cxbx (http://www.caustik.com/cxbx/) you might have heard of. It's an Xbox emulator that, until now, has only run on Windows. It's also open source. Why has it only run on Windows? There's a great description on the website of how it works:

The first step to creating an Xbox Emulator was determining the hardware and software systems used by the Xbox. Since the Xbox is pretty much a PC dressed up like a console, the hardware component was easy enough. The software side was a bit more complicated. The Xbox uses a stripped down and partially modified Windows 2000 Kernel. The Xbox also only executes a single process at a time.

In order to emulate an Xbox game, it is necessary to simulate the game's environment. For the Xbox, this means making the game believe that it is running on a very specific set of PC hardware, running a very specific operating system. The operating system is simulated by intercepting kernel function calls, and wrapping them around existing NTDLL functions within Windows 2000 and Windows XP. The specific hardware is simulated by intercepting code that is known to touch the hardware at the lowest level possible. For Direct3D, this means simulating the Direct3D API by wrapping it around the Windows Direct3D API.

That makes a lot of sense. If you think about it though, Wine also has a NTDLL and we also have a Direct3D implementation so in theory you could use those instead of the native Windows ones. It just so happens Dimi Paun spent some time doing a Winelib port. He reported this week, " Willie Sippel suggested I port the Cxbx Xbox emulator to Winelib. And I did, patch attached. It seems like we need a multimon.h, any takers?"

I almost included the patch here to show how ridiculously small it is - about a total of ten lines (http://www.winehq.com/hypermail/wine-devel/2004/11/att-0273/01-wine.diff) changed in Cxbx. Now, before you run off and get all excited about this, you should be aware that XBox emulation with Cxbx still needs a lot of work. In fact, Turok Evolution is the only playable game. How well does it work under Wine? Well, no idea on that. One of the important things here is just how little work was needed to support it on Linux. Who knows, maybe someday it will let you play Halo 2.

3. Gcov Support

10�Nov�2004 (1 post) Archive Link: "Re: Enabling gcov code coverage"

Topics: Testing

People: Aaron Arvey,�,�cvs

A patch (http://www.winehq.org/hypermail/wine-patches/2004/11/0136.html) came in this week to add Gcov (http://gcc.gnu.org/onlinedocs/gcc/Gcov.html) profiling support to Wine. For the most part, the patch just enables it with gcc when Wine is compiled. What you end up with is a way to see how well Wine's test suite actually tests API's. Aaron Arvey submitted the patch and also included some really nice docs on how to use Gcov. Rather than cover the patch, which in itself isn't that interesting, I'll include what Aaron wrote about using it:

The Wine test suite doesn't actually test all of Wine. Surprised? You shouldn't be. It's difficult to write a truly complete test suite. Fortunately, gcc comes with a tool called 'gcov' that will tell you exactly which code is not yet tested.

To use gcov on wine, do the following:

  1. Configure wine with the --enable-gcov option to configure, then do a clean build of wine as normal.
  2. Run part or all of the Wine test suite. For example, if you're interested in how well kernel32.dll is tested, just do
      cd dlls/kernel/tests
      rm *.ok
      make test
  3. Run gcov on the source files for the part of Wine you're interested in testing. For instance,
      cd dlls/kernel
      for a in *.c; do gcov $a; done
    For each file, it will output statistics about what percentage of the code has been tested, as well as an annotated source file showing exactly which lines were exercised by the test suite.

For instance, to find out what lines of dlls/lzexpand/lzexpand_main.c are not yet tested by dlls/lzexpand/tests, you might do (the following example uses an out-of-tree build):

Look through the output file lzexpand_main.c.gcov for a line that has #### instead of a line count. Here's one, in the function LZOpenFile:

gcov output consists of three components: the number of times a line was run, the line number, and the actual text of the line. (If a line is optimized out by the compiler, it will appear as if it was never run, so --enable-gcov disables optimization.) gcov is telling us that line 548 is not exercised by the test suite. This is bad, because it means the test suite might miss a bug. In this case, fixing the problem is simple: since this is the only place LZOpenFile returns HFILE_ERROR, we just have to add a situation to dlls/lzexpand/tests/lzexpand_main.c where LZOpenFile ought to return HFILE_ERROR, and verify that it does. For example, the following lines added to dlls/lzexpand/tests/lzexpand_main.c would do the job:

Once we add this, we naturally want to find out if the new line actually does exercise the line in question. To do this, clear the histograms (line counts) by removing *.da, remove the old *.gcov output files, remove the *.ok so make test knows it needs to actually run the test, and rerun it:

Sure enough, gcov reported that lzexpand_main.c has 51.67% coverage instead of 50.83%. That's nearly a one percent improvement, which is awfully good. The output file confirms this:

So there you have it: that's how to use gcov to increase the coverage of the wine test suite.

4. Emacs Flymake Support

8�Nov�2004 (1 post) Archive Link: "Update to flymake patch"

People: Mike Hearn,�,�cvs

Mike Hearn posted a change on wine-devel to add Flymake (http://flymake.sf.net) Emacs mode for Wine development:

This adds support for the lovely flymake-mode, which compiles C as you write it in the background and highlights errors and warnings. It's an update to the patch I sent in about a year ago.

Since then GNU Emacs has changed (in cvs) so I've attached the version of flymake-mode you need to make it all work.

Not expecting this to get merged so it goes to wine-devel.

5. Network Config Not Updating

10�Nov�2004�-�11�Nov�2004 (4 posts) Archive Link: "wine notes & /etc/resolv.conf"

Topics: Fixes

People: Grant Williamson,�Andreas Mohr,�Mike Hearn,�

Grant Williamson ran into a networking problem and asked for some help:

is there a patch anywhere, which will allow wine to reread the /etc/resolv.conf file.

i.e. application Lotus Notes a) start Notes whilst connected to home network. /etc/resolv.conf gets populated by home dhcp server b) start vpn connection to work /etc/resolv.conf gets populated with extra name servers c) try and connect to work Notes, server fails, as it cannot resolve named address If you start Notes after the vpn connection is started, then /etc/resolv if correctly populated and the problem does not occur. Same issue happens when u suspend your machine and start in a different location.

Andi Mohr didn't think Wine was the culprit and explained:

Wine doesn't read the resolv.conf file, at all (ok, I didn't check, but I'd be very surprised if it did).

Wine uses bog-standard networking support APIs, there's no magic involved in connecting to the net.

As such the problem is probably that Wine makes use of an API that somehow doesn't take into account a changed name server configuration.

Mike Hearn seemed to recognize the problem and confirmed Andi's idea, " This is a glibc problem. I'm pretty sure Red Hat fixed this recently as part of their NetworkManager work. It might be in Fedora Core 3, I'd ask on fedora-devel."

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.