Wine Traffic #38 For 10 Apr 2000
Table Of Contents
This is the 38th 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 87 posts in 206K.
There were 30 different contributors.
18 posted more than once.
17 posted last week too.
The top posters of the week were:
- 11 posts in 22K by Alexandre Julliard <email@example.com>
- 8 posts in 21K by Francois Gouget <firstname.lastname@example.org>
- 7 posts in 16K by Uwe Bonnes <email@example.com>
- 5 posts in 17K by gerard patel <firstname.lastname@example.org>
- 5 posts in 16K by Andreas Mohr <email@example.com>
- Full Stats
'Programming Windows' test suite effort
Archive Link: "PrgWin95 testing kit update"
Francois Gouget announced a new location for his Programming Windows
test suite effort (read the first
Francois also announced some enhancements in the results, but still
many areas to be looked upon (bugs in redraw, as well as symbol
definition issues, like NULL or some mathematical symbols).
I have just released the version 0.1.3 of my 'Programming
Windows 95' testing kit for Wine. I also moved it to a new Web site to
avoid the commercial banners of the previous web hosting service. You
can get everything about version 0.1.3 at:
As was suggested in the newsgroup I also put up a 'Getting started
with Winelib' page at:
Requests to the server
Archive Link: "Wine ate my registry"
Ulrich Weigand, Alexandre Julliard, , Gérard Patel, Dave Pickles, Uwe Bonnes
Dave Pickles a very long ago reported some problems while Wine was
saving the registry. No one really took care at that time. Two weeks
ago, Uwe Bonnes experienced the same kind of problems and decided to
take a look at it. After some tests, he reported some strange
behavior. Gérard Patel also looked at it and found was was going
wrong: at some point the code sets a request buffer for the server,
and fills it with different values. Setting up a request buffer
require to get a buffer (there is one buffer per thread), and then
write some values in it. The found bug by Gérard lied in the fact that
part of the code writing the values was calling another function,
which, in turn, was also making a call to the server. This second call
was trashing the values already written in the buffer (as there's a
buffer per thread, the same buffer was used).
After providing a (now obvious) fix, Uwe asked:
Alexandre Julliard answered:
But this seems to be a general issue. If after initialization of some
value in the request buffer a function calls somehow results in
another server call, these initialized values may get silently
How to tackle that problem? Should server calls be stackable? Put a
CriticalSection around the server call? But this is a server call
itself. Check some usage count? But it should probably be thread
specific too. Or carefully check the code that after some
initialization no other server call is done? But both latter solutions
will give many wrong alarms as we might request the buffer much
earlier then we initializes the values.
In fact it may make sense at some point to support stackable requests,
so that signal handling can work properly. At the moment signals do
not work if they happen while we are filling a request buffer, which
means that we cannot single-step through a server call with the
built-in debugger for instance.
For people also interested in server handling issues, Gérard Patel
wrote a short newbie oriented
documentation on the subject.
Documenting Wine API coverage
Archive Link: "A case for Wine and Contributing to Wine"
Francois Gouget, Jeremy White, CodeWeavers, , Patrik Stridvall
While discussing around Francois Gouget PrgWin95 effort, Patrik
Stridvall and Francois put together some scripting tools which give
some statistics on API coverage in Wine.
They defined three states for an API:
Even if not 100% correct (for example, for the latest kind, it's hard
to tell whether is the functionality implemented is 10% or 90%
correct, at least it's more than 0), this gives an overview of Wine's
Look at for the details of this
Francois was rather disappointed by the first raw results:
- real stub: nothing is done in C file)
- pseudo stub: some code has been written, but part of the
function contains a
FIXME("bla bla stub"); somewhere
- implemented: there's a real implementation of the function)
The stats do not look too good :-(. There's more stubs
than I expected. I guess that for them to be meaningful we would
really need to perform an analysis of which functions are really used
Jeremy White replied that:
Jeremy also noted some bad sides to the approach:
a PHP/MySQL database that we are hoping to release to the world 'soon'
which does this. You can upload a dumpbin of xxx.dll and xxx.lib and
it will store the authoritative list of APIs supplied by that version
of xxx, along with ordinals, API names, and (where available)
You can then edit any given API and enter subjective data about
the quality of its implementation. You can also upload a zip file
containing dumpbins of all of the .exes and .dlls of a particular
application. That 'project' can then be analyzed for external
I'm hoping we can add a whole bunch of applications, and then
start doing some analysis to find out which APIs are most needed, of
those, which need the most help, and so on.
We have all this right now, but we're making a clean copy (to
remove confidential customer data).
Note that this method only provides a static analysis of what an app
really uses. You can get mislead, because many apps do
LoadLibrary/GetProcAddress and so you miss those APIs. Also, the new
COM interfaces tend not to be caught by this approach. Still, it's a
Crash on startup
Archive Link: "RH6.2"
As already reported some weeks ago for
Debian distro, lots of other ones
blow when used with wine, with a nice bug in glibc. So RedHat 6.2 and
Mandrake 7.0 users, if your wine crash at startup, either upgrade your
glibc package (if a fix is available), or set LC_ALL to en in your
(t)csh: setenv LC_ALL en
(b(a))sh: LC_ALL=en ; export LC_ALL
Sharon And Joy