Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #77 For 8 Jan 2001

By Eric Pouech

Table Of Contents

Introduction

This is the 77th 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 128 posts in 488K.

There were 45 different contributors. 24 posted more than once. 21 posted last week too.

The top posters of the week were:

1. COM macros and preprocessor

31 Dec 2000 - 3 Dec 2001 (27 posts) Archive Link: "compilation error on uuid.c"

People: James Juran, 

James Juran reported errors while compiling Wine with Red Hat 7.0 gcc (2.96) compiler. After some testings, it turned out that a recent patch was mis-interpreted by the pre-processor.

The definition and the implementation of the COM virtual tables in Wine is done using a set of macros. Some cases are somewhat difficult: some methods in those vtables have the same name as a regular API function (GetObject and GetClassInfo are the two known examples). But, as Windows, some APIs are present under two forms (Ansi and Unicode); in that case two functions are defined (one is suffixed with A for Ansi, the other one for W for Wide (aka Unicode) (for example fooA and fooW). Then a macro foo is defined either as fooW (resp fooA) if the manifest constant UNICODE is defined (resp. not defined).

This behavior is mostly implemented for the sake of Winelib programs. For the Wine internal code, the suffixed version only are supposed to be called. To enforce this rule, the headers turn the foo macro (while compiling Wine) into a dummy identificator to catch the error.

The COM macros in order to be in sync will all this did some tricks:

It finally turned out some recent gcc versions did trigger this error.

Some suggestions to cope with that were suggested:

2. Another libc2.x and dl-library issue

1 Jan 2001 - 3 Jan 2001 (12 posts) Archive Link: "libc2.2 pthread segfault"

People: Andreas Mohr, , James Abbatiello

Andreas Mohr reported a segmentation fault at startup. This seemed to occur right after he upgraded Debian libc6 2.2-6 to libc6 2.2-8.

After some testings, the same type of errors with dlopen as already worked around before (BROKEN KCREF) stroke once again.

James Abbatiello proposed another patch (in the same vein as the one he already wrote for the previous issue), except that in the current case the dl error code had to be cleared before calling any dl functions.

However, after some testings Andi found out Debian libc6 2.2-8 to cause lots of issues to his notebook, and wondered if the patch against a poor libc version was needed.

As of today, no patch has been applied. Since Debian libc6 2.2-9 fixes this very issue (read works correctly without this patch), it's very likely Wine will never be compatible with 2.2-8. Anyone using this libc version is requested to upgrade.

3. Revisiting Wine application database

28 Dec 2000 - 2 Jan 2001 (11 posts) Archive Link: "[LONG :-)] Some ramblings about the Wine Application Database"

People: Lionel Ulmer, Francois Gouget, Jonathonm Griffiths, Jeremy White, , Jon Griffiths

Lionel Ulmer started a long thread by posting a long proposal revisiting the internals of Wine's application database. It's the database containing the test results from existing Windows applications against the different Wine versions.

Here are the main parts;
Goals

The ultimate goals of this database are:
  1. list all working and non working applications. With the 'scoring' of applications, we can have an idea of:
    • the progress of Wine
    • the most wanted applications
  2. for working applications, this database should be the reference on HOW to get them working (ie last working version of Wine, Wine configuration regarding native / builtin DLLs, ...).
  3. when Wine will be out of alpha state, this database could be the basis for a distributed regression testing system (if we get enough people involved in the Wine project by taking 'ownership' of an application and do regular bug reports / regression testings).

Some other ideas could be:
  1. if we add some 'relay statistics' in Wine code (of course, there will be problems with COM objects where relaying does not work for now) and incorporate these statistics in the database, we could have a list of the most frequently used Windows calls.
(feel free to add new ideas for improvements :-) )

Then, Lionel got into describing his view on the database content. He put several questions to be looked after:

Lots of people largely agreed with Lionel's first proposal (and enhance it a bit somewhat). Francois Gouget gave a more detailed description of an important actor in this process: application maintainer.
That's where I describe the role of the application owner as I see it.

He definitely should have the application installed and, very preferably, he should also be using it regularly (or testing it regularly if it is not yet in the usable state). You are right in pointing out that he cannot test all possible but I contend he does not have to. His role would be to:

Jon Griffiths proposed to have two different ratings
with and without an official O/S installed. This is important because the difference between the two gives us a clearer picture of how much work is outstanding on replacing the core dlls. Knowing which Wine dlls don't work for an app is also important. I would probably use that information to decide where to hack around if I wanted to do something different for a while.

Jeremy White proposed some scheme to help keeping the database usable:
I think the biggest problem with the app database is that we get garbage in, it produces garbage out. I think we should not report or even use any user scores until a trusted app db maintainer has validated that user experience (and possibly users can become trusted reporters). Too many people say 'Hey! The main screen came up! That's a 5! Witness the Slashdot post about MS Office 2k. (anyone actually try to use Office 2K in Wine to author a sizable document?).

I think we need to overreact to the problem (a misleading and crufty apps database) and provide a rigorous, simple, and scrupulously honest apps db.

Lionel, Jeremy and Francois then started to discuss in greater details the data model of such a database. There's now a common understanding of what needs to be done and the global rules for building it... only remains the hours of coding and debugging to put it in place. Any volunteers ?

4. CDROMs handling

6 Jan 2001 (4 posts) Archive Link: "CDROM_GetLabel return code"

People: Ryan Cuming, Andreas Mohr, 

Ryan Cumming proposed a patch to the CD ROM label handling:
This patch causes CDROM_GetLabel to always return zero in the event of failure. In some cases it was setting the label to an empty string and returning one, which prevented DRIVE_GetLabel from falling back to the drive label explicitly set in ~/.wine/config.

Ryan was happy this patch let "Red Alert: Aftermath" installer to run without tweaking the CD Rom information from the ~/.wine/config file.

Before going further, a quick reminder on CD. CD can be of various forms. The most known are the CD Audios (which contain music) and CD containing data (using the ISO 9660 format). Under Linux, the second type requires to be mounted, and if the iso 9660 file system is supported in the OS, content of the CD can be read as any device (hard disk...). The first type can be read by CD Audio players.

CD can also be mixed: they contain both audio tracks and binary data. This latter format is not properly handled in Wine because of the duality of accesses which are cannot be easily intertwined.

In some cases, Wine is not able to get the label from an ISO 9660 drive. To cope with that, the user can add a default label to the Wine's config file which will be returned in that case (of course, it's not an universal solution because the label changes with every CD, and the entry in the configuration file is linked to the CD ROM device, not the CD ROM itself).

Going back to Ryan's patch, Andreas Mohr completely agreed on Ryan's proposal (the old code setting an empty string in case of failure wasn't correct). However Andi suggested to always have a default value for the label (like "[Drive E]" in the case the user didn't set up a default label in the ~/.wine/config file).

Later on, Ryan proposed again his patch, returning a blank string if no default label has been set. Ryan also proposed
to read the ISO9660 label, even on a mixed mode CD. This is actually successful on the "Red Alert: Aftermath" CD-ROM, allowing the installer to start up without setting the CD-ROM's label in my WINE config.

Andi didn't like the last part:
Uuuuhh. I don't think this is a good idea.

This will result in media error output for certain types of mixed-mode CDs, and I don't think we want that.

Better implement the "real" mixed-mode CD handling first... (needs to use the "raw sector read" ioctl()s for that).

 

 

 

 

 

 

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.