Wine Traffic #34 For 13�Mar�2000
Table Of Contents
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:
- 8 posts in 37K by David Elliott <firstname.lastname@example.org>
- 7 posts in 16K by Bertho Stultiens <email@example.com>
- 4 posts in 9K by Huw D M Davies <firstname.lastname@example.org>
- 4 posts in 21K by Juergen Lock <email@example.com>
- 4 posts in 12K by Francois Gouget <firstname.lastname@example.org>
- Full Stats
Archive Link: "Testing Wine with Programming Windows 95"
Francois Gouget started a wide Windows API testing:
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.
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:
- 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.
- 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
- There's various enhancements to do to the perl script I use
and the most important:
- Fixing the problems uncovered by these tests
Wine evolution vs porting Wine to different OSes
Archive Link: "I'm afraid you broke Wine on FreeBSD 3.3"
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
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
Alexandre Julliard gave some explanation on his review process:
One should never just copy code from system
headers and I really think Alexandre never should have approved something
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.
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
Sharon And Joy