Wine Traffic #66 For 23�Oct�2000

By Eric Pouech

Table Of Contents


This is the 66th 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 97 posts in 351K.

There were 34 different contributors. 18 posted more than once. 20 posted last week too.

The top posters of the week were:

1. Headlines


2. Wine testing effort

12�Oct�2000�-�19�Oct�2000 (7 posts) Archive Link: "ALS Update & Regression Testing"

People: Jim Graham,�Doug Ridgway,�Alexandre Julliard,�CodeWeavers,�,�Jeremy White,�Douglas Ridgway,�Eric Pouech,�Codeweavers

Jim Graham reported a small note of a BOF held at Atlanta Linux Showcase (October 11, 2000):
Initial reports are that there was a lot of interest, and quite a few in attendance. They even drank 3 bottles of real Wine (geez, I always miss out on the good shows!).

One of the hot topics of discussion related to regression testing. CodeWeavers is in the process of developing a suite of regression tests for non-graphical components of Wine, but it sounds like there may be a need for testing the graphical aspects of Wine as well.

Does anyone know of or have experience with free/open-source/etc tools that allow for development and implementation of regression test suites for GUI components?

Eric Pouech proposed two options for the last part:

Jeremy White gave a shot at TET (even got confused with the two versions of the product, one of them being open source under Artistic license, the other being supported but thru annual fees), but didn't give a final word on TET's usage for Wine regression testing.

Douglas Ridgway asked another relevant question:
It's not clear to me why the tool needs to be free. It makes it easier for the community to contribute, but since test suite maintenance and regression testing must be centralized anyway, a commercial solution is not out of the question. We could work with products designed for X or Win32. Of the Win32 products, Microsoft Test should be investigated, but I'm sure there are lots of others as well.

Alexandre Julliard had a different view on the matter:
Regression testing must not be centralized. It must be distributed just like development is. We want anyone who writes a piece of code to be able to implement the corresponding tests, and to run the tests every time they change something to the code.

This doesn't mean we cannot have a designated QA person coordinating the testing process, but we must make sure it is possible for everybody to participate. So yes, the tools have to be free.

Anyway, the overall discussion on Wine regression process hasn't really started yet, lots of items still have to be discuss. It's likely Codeweavers will put out a proposal for the matter when they get something a bit solid in their thinking/tools benchmarking...

3. Wine HOWTO license

19�Oct�2000�-�20�Oct�2000 (3 posts) Archive Link: "Wine-HOWTO will be FDL"

People: Jutta Wrage,�

Jutta Wragge, Wine HOWTO maintainer, announced:
We argued about the license for more than half a year.

The decision is made: The Wine-HOWTO will be FDL.

A copy of the FDL license (good for documentation and books) can be found at homepage or at Jutta's website ( ( )

As a reminder, Wine HOWTO can be grabbed at (

4. A tool to help Wine making

17�Oct�2000 (1 post) Archive Link: "Announce: Winemaker"

People: Francois Gouget,�

A craftsman definitively needs good tools. Francois Gouget helped a bit the wine community, announcing:
Winemaker is a perl script designed to help you bootstrap the conversion of your Windows projects to Winelib. More precisely winemaker can perform the following operations:

Basically you do:

   $ winemaker --lower-uppercase
   $ ./configure --with-winelib-root=<wherever your wine sources are>
   $ make

And that's it, you have a Winelib application. Of course it's not always that simple: winemaker does many educated guesses (which could be wrong); the application written in a non portable way (or Winelib incomplete). But it does manage to build more than 70% of the Petzold 98 examples with no more work than the three lines above.

So it's not complete yet but I think it's advanced enough to be useful. Plus what I'm really hoping for is your feedback.

The next steps (as currently planned) are:

The longer term goals are:

5. MFC replacement

18�Oct�2000 (4 posts) Archive Link: "Open Source MFC Replacement WRT Wine?"

People: Andrew Lynch,�Gavriel State,�Francois Gouget,�

Andrew Lynch posted a rationale of a SourceForge Project ( ( ) dubbed OFC:
The Open Foundation Classes (OFC) are a frameset of C++ classes for applications running under windows (32bit). They are 100% compatible with the MFC and will be improved in various ways. All not compatible parts are signed with a prefix.

and added
This project is still in its pre-Alpha infancy but it appears to address one of the main obstacles to successful porting to WineLib of Win32/MFC apps: MFC itself is no longer portable nor is open source/free.

This project could potentially solve that problem by replacing MFC with a open source/free equivalent.

Gavriel State responded Andrew's agreement upon MFC licensing options:
MS changed the license to MFC in MSVC 6.0 Service Pack 3 to remove the 'windows only' clause. That said, I wouldn't recommend actually shipping a WineLib ported MFC app without talking to a Lawyer first, just to be on the safe side.

Francois Gouget, also considering the project in its infancy, answered a bit on Wine and OFC cooperation mode:
If their project does take off I think we should provide them with the necessary support so that it compiles out of the box with Winelib. Then maybe some of the Wine folks could be interested in contributing but that's up for individual developers to decide.

6. Wine application database

18�Oct�2000 (1 post) Archive Link: "Wrong entries in your apps database (long)"

People: Jeremy White,�,�codeweavers

While discussing the current application database issues, Jeremy White wrote a bit on the new directions for the application database (
We sat down with a bunch of Wine hackers about a month ago and wrote down the following rambling notes about the apps database:

Design goals User wants to know two things:

Management Issues/Goals: Major flaw with current app db is input data quality. Ways to fix that include:

Major goal: Make it easy for users to participate by taking ownership of an application. Many, many people want to help Wine, but it ain't easy to help. Let's make it easy to help. So, if someone owns an app, it's up to them to monitor comments on it, track bugs (close bugs), and make sure quality level is high for application description.

Technical issues: (Sorry, Doug) Probably not worth preserving current code base; probably best to start from scratch.

Corollary: Probably best not to auto import current apps data (it's quality is not considered high); best would be to have "Mr/Ms Apps" enter clean data.

Major architectural change: Create a hierarchy of data. For example:
                     User comment 1
                     User comment 2
                     User comment 1
... Critical failing of current system: many redundant entries for the same product. We need to fix that.

Reviews (aka user comments) should expire.

We should track hit counts on apps (auto magic way of knowing which apps are most desired).

Idea: Host per app web pages. Make it easy for the 'owner' of an app to maintain said web page. The idea is to pull the StarCraft and Notes howtos into the logical home for them.
Idea: Tie the apps database to the api database. The idea is that we know from the apps database which apps are the most popular. We know from the api database which DLLs/entry points are used by those apps. We can then create a report out of the api database of the list of the DLLs most needed by the top ten apps, and then people writing test scripts (something Alexandre and John Sturtz are working on), have a prioritized todo list. Again, this helps us find useful things for the many volunteers to do.
Idea: Tie the apps database to bugzilla. If users have a problem with an app, it's a bug, and should be in bugzilla. If we can get to a point where we can easily get a report that says 'here are all the bugs that Quicken depends on'. Or, here are the five bugs, the fixing of which will make 50 apps suddenly work. This would be wicked cool.

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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.