Wine Traffic #34 For 13�Mar�2000

By Eric Pouech

Table Of Contents

Introduction

This is the 34th 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 65 posts in 250K.

There were 30 different contributors. 14 posted more than once. 20 posted last week too.

The top posters of the week were:

1. Testing Wine

8�Mar�2000 (1 post) Archive Link: "Testing Wine with Programming Windows 95"

People: Francois Gouget,�

Francois Gouget started a wide Windows API testing:
I have been testing Wine and Winelib using the examples contained in the book "Programming Windows 95" by Charles Petzold (a classic).

I think this can be a nice way of testing Wine:

The detailed results of these tests are available at: http://www.multimania.com/fgouget/wine/PrgWin95/ (http://www.multimania.com/fgouget/wine/PrgWin95/)

Some statistics:

I used a perl script to help in generating/updating the web pages, generating Makefiles for Winelib, cross-referencing the API calls (hence my recent interest in dumpbin/pedump), generating a tar file ready for download, etc.

Now what?

and the most important:

Concerning this last point, Francois proposed several ways of sending back the issues he found like using Wine bug tracking system, posting the detailed bug reports to the developers-list... It's likely some of those will show up real soon.

2. Wine evolution vs porting Wine to different OSes

10�Mar�2000�-�13�Mar�2000 (4 posts) Archive Link: "I'm afraid you broke Wine on FreeBSD 3.3"

People: Gerald Pfeifer,�Alexandre Julliard,�,�J�rgend Lock,�David Elliot

There was a bit of a discussion after David Elliot's patches to enhance have been applied to the CVS tree. Gerald Pfeifer complained
One should never just copy code from system headers and I really think Alexandre never should have approved something like that.

As a matter of fact I have been disappointed several times lately when Alexandre applied patches that broke Wine on non-Linux platforms due to typos or "there's nothing apart from Linux" coding. :-(

What's the purpose of an extremely strict development model if even the simplest such issues are not caught during patch review?

David's agreed that his patch has been only tested on linux boxen and needed some more work (which he already started, with feedback from J�rgend Lock).

Alexandre Julliard gave some explanation on his review process:
Like it or not, in some cases copying system headers is the sensible thing to do, and we are already doing it at several places. In this specific case I don't know if it's really necessary, but the code has been like that for a long time anyway.
and regarding the development model:

I'm not gcc, I review the code for logical correctness, not syntax errors. I know it can be frustrating when the code doesn't compile, which is why I discourage #ifdef usage, but in some cases there is no choice. If you are not using the same system as the majority of the developers, you have to live with the occasional glitch (frankly, how hard was it to fix it?)

Personally I prefer to have a WINASPI that works on Linux and may need a couple of #ifdefs to compile on FreeBSD, than one that compiles everywhere but doesn't work. And I'm not going to reject code improvements on the off-chance that they may not always compile on every system out there, especially when neither me nor the original developer have any way to check it.

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.