World Wine News

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.

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.

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

cvs checkout wine
mkdir build
cd build
../wine/configure --enable-gcov
make depend && make
cd dlls/lzexpand/tests
make test
cd ..
gcov ../../../wine/dlls/lzexpand/lzexpand_main.c
0.00% of 3 lines executed in file ../../../wine/include/wine/unicode.h
Creating unicode.h.gcov.
0.00% of 4 lines executed in file /usr/include/ctype.h
Creating ctype.h.gcov.
0.00% of 6 lines executed in file /usr/include/bits/string2.h
Creating string2.h.gcov.
100.00% of 3 lines executed in file ../../../wine/include/winbase.h
Creating winbase.h.gcov.
50.83% of 240 lines executed in file ../../../wine/dlls/lzexpand/lzexpand_main.c
Creating lzexpand_main.c.gcov.
less lzexpand_main.c.gcov

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 :

    9: 545: if ((mode&~0x70)!=OF_READ)
    6: 546:    return fd;
M     3: 547: if (fd==HFILE_ERROR)
#####: 548:    return HFILE_ERROR;
    3: 549: cfd=LZInit(fd);
    3: 550: if ((INT)cfd <= 0) return fd;
    3: 551: return cfd;

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:

INT file;
/* Check for nonexistent file. */
file = LZOpenFile("badfilename_", &test, OF_READ);
ok(file == LZERROR_BADINHANDLE, "LZOpenFile succeeded on nonexistent file\n");
LZClose(file);

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:

rm *.da *.gcov
cd tests
rm *.ok
make
make test
cd ..
gcov ../../../wine/dlls/lzexpand/lzexpand_main.c
0.00% of 3 lines executed in file ../../../wine/include/wine/unicode.h
Creating unicode.h.gcov.
0.00% of 4 lines executed in file /usr/include/ctype.h
Creating ctype.h.gcov.
0.00% of 6 lines executed in file /usr/include/bits/string2.h
Creating string2.h.gcov.
100.00% of 3 lines executed in file ../../../wine/include/winbase.h
Creating winbase.h.gcov.
51.67% of 240 lines executed in file ../../../wine/dlls/lzexpand/lzexpand_main.c
Creating lzexpand_main.c.gcov.
less lzexpand_main.c.gcov

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:

10: 545: if ((mode&~0x70)!=OF_READ)
  6: 546:    return fd;
  4: 547: if (fd==HFILE_ERROR)
  1: 548:    return HFILE_ERROR;
  3: 549: cfd=LZInit(fd);
  3: 550: if ((INT)cfd <= 0) return fd;
  3: 551: return cfd;

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

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.

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.

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.