Wine Traffic #34 For 13 Mar 2000

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

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 source is available... to whoever owns the book or can get it at a library
the programs are simple and very well documented
they do exhibit problems in Wine (at execution time) and in Winelib (mostly at compile time)
they cover relatively diverse subjects (graphics, keyboard, message handling, try the API cross-reference...)

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

Some statistics:

there's 102 C files, 4 C++ ones, 66 C files compiled fine, none of the C++ files compiled correctly
the first 5 chapters contain 20 examples, 8 show some anomaly and 6 exhibit a behavior which I'm not sure is correct

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?

I have not fully tested all the examples in the book. I'm currently at chapter 11. Nine more to go.
I have not yet updated the Makefiles since the Winelib compilation procedure changed. I shall update this.
I have two other books to test:
- Programming MFC which I will test with Wine only (unless someone can tell me how to compile the MFC with Winelib)
- The developer's guide to the Win32 API for Windows NT and Windows 95
There's various enhancements to do to the perl script I use

and the most important:

Fixing the problems uncovered by these tests

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?

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.

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.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	8 Mar 2000	(1 post)	Testing Wine
2.	10 Mar 2000 - 13 Mar 2000	(4 posts)	Wine evolution vs porting Wine to different OSes

Wine Traffic #34 For 13 Mar 2000

By Eric Pouech