Wine Traffic #38 For 10 Apr 2000

By Eric Pouech

Table Of Contents

Introduction

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:

1. 'Programming Windows' test suite effort

 Archive Link: "PrgWin95 testing kit update"

People: Francois Gouget, 

Francois Gouget announced a new location for his Programming Windows test suite effort (read the first announce (wn20000313_34.html#0) ):
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:

http://fgouget.free.fr/wine/PrgWin95/ (http://fgouget.free.fr/wine/PrgWin95/)

As was suggested in the newsgroup I also put up a 'Getting started with Winelib' page at:

http://fgouget.free.fr/wine/winelib-en.shtml (http://fgouget.free.fr/wine/winelib-en.shtml)

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

2. Requests to the server

 Archive Link: "Wine ate my registry"

People: 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:
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 overwritten.

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.

Alexandre Julliard answered:
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 (http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2000-04/Subject/article-39.html) on the subject.

3. Documenting Wine API coverage

 Archive Link: "A case for Wine and Contributing to Wine"

People: 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:
  1. real stub: nothing is done in C file)
  2. pseudo stub: some code has been written, but part of the function contains a FIXME("bla bla stub"); somewhere
  3. implemented: there's a real implementation of the function)
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 progress.

Look at for the details of this coverage (http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL/archives/2000-04/Subject/article-26.html) .

Francois was rather disappointed by the first raw results:
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 by applications.

Jeremy White replied that:
<CodeWeavers>have 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) parameter counts.

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 dependencies.

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

Jeremy also noted some bad sides to the approach:
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 good start.

4. Crash on startup

 Archive Link: "RH6.2"

People:

As already reported some weeks ago for Debian distro (wn20000306_33.html#3) , 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 environment:

(t)csh: setenv LC_ALL en

(b(a))sh: LC_ALL=en ; export LC_ALL

 

 

 

 

 

 

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.