Wine Traffic #66 For 23�Oct�2000
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:
- 12 posts in 35K by Uwe Bonnes <email@example.com>
- 8 posts in 18K by gerard patel <firstname.lastname@example.org>
- 7 posts in 18K by Patrik Stridvall <email@example.com>
- 7 posts in 13K by Ove Kaaven <firstname.lastname@example.org>
- 6 posts in 20K by Jeremy White <email@example.com>
- Full Stats
- Winehq has now a full featured search engine (where you can look
up for old mails, patches, WWN articles and more...). Have a look at
- Another mailing list has been created. It's wine-users, which
also acts as a gateway to comp.emulators.ms-windows.wine
newsgroup. You are now able to read/write to the news group without
having an NNTP access, or get digests of the posting, or even do
searches using the newly installed search engine. Interesting URLs
Wine testing effort
Archive Link: "ALS Update & Regression Testing"
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):
Eric Pouech proposed two options for the last part:
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
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?
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:
- The Test Environment Toolkit (
TET) which seems to be the
tool used for X11 protocol and XLib regression suite
- DejaGnu + tk/tcl + expect
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:
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...
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.
Wine HOWTO license
Archive Link: "Wine-HOWTO will be FDL"
Jutta Wragge, Wine HOWTO maintainer, announced:
A copy of the FDL license (good for documentation and books) can be
found at http://www.gnu.org homepage
or at Jutta's website
As a reminder, Wine HOWTO can be grabbed at
We argued about the license for more than half a year.
The decision is made: The Wine-HOWTO will be FDL.
A tool to help Wine making
Archive Link: "Announce: Winemaker"
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:
- fix the filename case issues
- fix the include statements (both \ vs. / and case issues)
- performs the standard Dos to Unix conversions
- generate Makefiles using autoconf
Basically you do:
$ winemaker --lower-uppercase
$ ./configure --with-winelib-root=<wherever your wine sources are>
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:
- adding more support for the MFC
- probably add a configure option similar to the
- add support for wrapper executables (for the MFC
- prepare it for inclusion in the Wine source tree
- move the Readme to the Winelib user guide
- write a man page
- remove the configure script (only keep configure.in)
- merge the auxiliary files into the main perl script using
the DATA filedescriptor
The longer term goals are:
- adding support for the Visual C++ project files. This should
greatly increase winemaker's accuracy (and we should blow past the 80%
for the Petzold 98 :-).
- adding support for direct analysis of the executables
themselves using a tool like pedump (to detect which libraries they
are linked with, etc.)
Archive Link: "Open Source MFC Replacement WRT Wine?"
Andrew Lynch,�Gavriel State,�Francois Gouget,�
Andrew Lynch posted a rationale of a SourceForge Project (
http://sourceforge.net/projects/ofc/) 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.
Gavriel State responded Andrew's agreement upon MFC licensing options:
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
This project could potentially solve that problem by replacing MFC
with a open source/free equivalent.
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.
Wine application database
Archive Link: "Wrong entries in your apps database (long)"
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:
User wants to know two things:
- Does my application work?
- How can I make it work?
Major flaw with current app db is input data quality. Ways to fix that
- Have a designated "Mr/Ms Apps" to monitor/review comment
- Have some form of a moderation system to let end users know the
quality of a given persons entry. Maybe just self evaluations, maybe
having 'owners' have higher value.
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.
(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).
||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.
||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.
||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
Sharon And Joy