WWN Issue 66

This is the 66th release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

This week, 97 posts consumed 351 K. There were 34 different contributors. 18 (52%) posted more than once. 20 (58%) posted last week too.

The top 5 posters of the week were:

12 posts in 35K by Uwe Bonnes
8 posts in 18K by gerard patel
7 posts in 13K by Ove Kaaven
7 posts in 18K by Patrik Stridvall
6 posts in 20K by Jeremy White

Headlines
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 http://www.winehq.org/search.html 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 are: http://www.winehq.org/mailman/listinfo/wine-users to subscribe http://www.winehq.org/pipermail/wine-users/ for the archive.

Headlines

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 http://www.winehq.org/search.html
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 are:
- http://www.winehq.org/mailman/listinfo/wine-users to subscribe
- http://www.winehq.org/pipermail/wine-users/ for the archive.

Wine testing effort	12 Oct 2000 00:00:00 -0800	Archive
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: The Test Environment Toolkit ( TET ) which seems to be the tool used for X11 protocol and XLib regression suite DejaGnu + tk/tcl + expect 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...

Wine testing effort

12 Oct 2000 00:00:00 -0800

Archive

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:

The Test Environment Toolkit ( TET ) which seems to be the tool used for X11 protocol and XLib regression suite
DejaGnu + tk/tcl + expect

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

Wine HOWTO license	19 Oct 2000 00:00:00 -0800	Archive
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 http://www.gnu.org homepage or at Jutta's website ( http://www.witch.westfalen.de/Wine-HOWTO/gfdl.html ) As a reminder, Wine HOWTO can be grabbed at http://www.witch.westfalen.de/wine/index.html

Wine HOWTO license

19 Oct 2000 00:00:00 -0800

Archive

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 http://www.gnu.org homepage or at Jutta's website ( http://www.witch.westfalen.de/Wine-HOWTO/gfdl.html )

As a reminder, Wine HOWTO can be grabbed at http://www.witch.westfalen.de/wine/index.html

A tool to help Wine making 17 Oct 2000 00:00:00 -0800 Archive

A tool to help Wine making	17 Oct 2000 00:00:00 -0800	Archive
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> $ 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: adding more support for the MFC probably add a configure option similar to the '--with-winelib-xxx' options add support for wrapper executables (for the MFC initialization issues) 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.)

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>
   $ 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:

adding more support for the MFC
- probably add a configure option similar to the '--with-winelib-xxx' options
- add support for wrapper executables (for the MFC initialization issues)
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.)

MFC replacement	18 Oct 2000 00:00:00 -0800	Archive
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. 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.

MFC replacement

18 Oct 2000 00:00:00 -0800

Archive

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.

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.

Wine application database

18 Oct 2000 00:00:00 -0800

Archive

While discussing the current application database issues, Jeremy White wrote a bit on the new directions for the application database (http://wine.codeweavers.com/): 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:

Does my application work?
How can I make it work?

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

Have a designated "Mr/Ms Apps" to monitor/review comment quality
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.

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:

         Microsoft
             Word
                 95
                     User comment 1
                     User comment 2
                 97  
                     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.

World Wine News