Kernel Traffic
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #98 For 20�Jun�2001

By Brian Vincent

Table Of Contents


This is the 98th 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).

There was an article over at osOpinion about Wine this week. I wouldn't exactly call it an in depth review, but there are a few interesting (if rehashed) points it brings up. Check it out at:

Mailing List Stats For This Week

We looked at 94 posts in 389K.

There were 36 different contributors. 15 posted more than once. 18 posted last week too.

The top posters of the week were:

1. Update: Application Database

11�Jun�2001�-�13�Jun�2001 (12 posts) Archive Link: "Apps DB round 2"

People: Jeremy Newman,�CodeWeavers,�,�codeweavers

Jeremy Newman from CodeWeavers has been doing a lot of work revamping the application database. He asked for feedback concerning the site and for help adding programs. A lot of ideas went back and forth concerning changes that should be made. Jeremy wrote:

The new Application DB ( ) is starting to fill up. But, we still need your help before we totally unleash it on the Wine community. We need as much feedback, comments, and flames [:-)] as possible this week. We need volunteers to take responsibility for updating Apps in the DB. If you would like to help, email the appDB team at

Areas we need help on:

The new application database is much easier to read compared to the old one. It makes finding information on various versions of software quite easy and the screenshots are pretty nice. (including, among others, one of Diablo II.)

2. Using Naturally Speaking

10�Jun�2001�-�11�Jun�2001 (4 posts) Archive Link: "Missing functionality in mmaux"

People: Florian Bauer,�Eric Pouech,�

Florian Bauer was having a problem using Naturally Speaking with Wine and inquired about some of the issues he discovered:

I tried to run Naturally Speaking, a speech recognition software under wine without a real windows installation. It installs just fine, but when I try to run it, it tries to adapt the audio settings. That fails, and I get the following fixme's from wine:

fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000007)
fixme:mmaux:MIX_GetLineInfo Unhandled component type (00000008)

I looked at the sources, and it seems that this is due to missing case clauses in the function MIX_GetLineInfo in mixer.c . Unfortunately, I don't know enough about C programming and the Windows and OSS API's involved to add the missing parts myself. Is it likely that this will be fixed soon?

I would love to use NatSpeak under linux, because then I could delete my Windows 98 Partition... Anyway, keep up the good work

Eric Pouech replied with a possible quick fix,

it just misses the wavein component types

as a quick fix, you can try to duplicate the case MIXERLINE_COMPONENTTYPE_MIC with MIXERLINE_COMPONENTTYPE_WAVEIN, but I'm not sure it'll fix all your issues, and let the program fully run. I'll have a closer look at it this week-end, if I have some time

Florian didn't reply whether it worked or not.

3. Licensing Concerns

11�Jun�2001�-�18�Jun�2001 (13 posts) Archive Link: "Use the libreadline in Winedbg, if available"

People: Daniel Walker,�Marcus Meissner,�Ove Kaaven,�Uwe Bonnes,�Patrik Stridvall,�Alexandre Julliard,�,�Patrik Stridval,�Ove K�ven

A couple of different threads appeared this week concerning licensing. Last year Wine switched from a BSD-style license to the X11 one. The first thing that came up was just a simple question posted by Daniel Walker:

If Microsoft picked up some of the code in Wine , wouldn't they need to include the copyright, permissions notice, and the authors list? It looks like the license isn't clear as to where the Copyright needs to be displayed? Could anyone clear this up?

Marcus Meissner "" replied that no, it's not required that it be displayed. Ove K�ven further explained:

I don't remember whether the Wine license was identical to the BSD license (it may not have been), but the big reason was that it was incompatible with the GPL. The BSD license doesn't prohibit a company from using the code (if they give credit where credit is due, which they do with any licensed technologies anyway), rather its "advertising clause" is a restriction that the GPL does not have, so Wine could not be linked with GPL-ed software if it used the BSD license, which would be too bad...

A few days later Uwe Bonnes "" submitted a patch that uses libreadline in the debugger if its available rather than the built-in one. Uwe wanted to be able to use the arrow keys while debugging and libreadline would allow him to trap the vt100 codes. Marcus Meissner "" pointed out that libreadline couldn't be linked against non-GPL code. But Patrik Stridvall "" quickly replied that it was enough for the code to be GPL-compatible, which Wine's license is. Even in this instance Alexandre Julliard didn't think it was worth the trouble and wrote:

But then the code can no longer be distributed under a non GPL compatible license, while this is allowed by the Wine license.

I think the benefit of using readline in the debugger is much too small to justify the potential license issues this would cause.

Patrik Stridvall replied with:

> But then the code can no longer be distributed under a non GPL
> compatible license, while this is allowed by the Wine license.

winedbg _binaries_ compiled with --enable-readline quite possibly.

As far as the source code to winedbg is concerned maybe but probably not. It might depend on whether --enable-readline or --disable-readline is the default, but that remains to be tested in court, but it is not certain it matters at all. The court might quite reasonably rule that no linking to readline has taken place yet and thus no derived work can have been created and even if they hold that some sort of linking has taken place it might not consider it a derived work.

In short linking, especially potential linking, do not always imply a derived work which is all that matters as far as the law is concerned.

Also note that I'm not convinced that any court will hold that the GPL is different from the LGPL in any relevant way with the possible exception of in bad faith trying to circumvent the requirements by trying to be "clever".

Of course it is a little unclear that you really can do unlawful circumvention of license requirements. This is a like claiming that somebody circumvented trespassing your land by moving around it. Either you trespass or you do not. Either you violate the license or you do not.

The analogy is quite good even in other areas: Even if you are on somebodies land you do not nessary trespass either because of copyright like "fair use" requirements in the law of most countries.

As a sidenote: In Sweden "fair use" concerning trespass is so extensive that I never heard about _any_ case concerning it.

> I think the benefit of using readline in the debugger is much too
> small to justify the potential license issues this would cause.

Only the debugger (winedbg) links with readline => only the debugger can be effected.

Trying to claim, even though you didn't, that Winelib is effected is absurd since it is independent of the debugger. Distributing the debugger with WineLib is merly an aggregation nothing more.

Alexandre wrote back with:

In theory any library that the debugger uses will also fall under the GPL. And someone shipping Wine binaries may not be aware that parts of it need to be GPLed, and they will get flamed to death on Slashdot.

I mostly agree with you that the FSF stance on dynamic linking has no basis in copyright law, but I'm not interested in providing the test case. So if you want to use readline you can patch your local copy, but I won't ship this in the main distribution.

4. Virtual Memory Problems

10�Jun�2001�-�13�Jun�2001 (17 posts) Archive Link: "Re: virtual memory problems with Linux 2.4.5"

People: Mike McCormack,�Lawson Whitney,�Alexandre Julliard,�

Mike McCormack wrote,

I have found a problem with Wine and the Linux 2.4.5 Kernel. The Kernel no longer return EINVAL when offsets are not page aligned... it simply does the mapping ignoring the lower bits of the offset. This small patch fixes that problem.

Lawson Whitney thought he saw the same problem and did a little experimenting. He found:

Not only does it look like it could easily be a misaligned mmap, Mike's little patch makes the crash go away. Using mmap instead of mmap64 or using kernel 2.2.14 instead of 2.4.5 also takes away the crash. Sorry the config test doesn't seem to catch it - it looks as if it should. I will take a better look at some debugmsgs and straces after supper.

Alexandre zeroed in on what looked like the problem and discovered it was a problem with glibc 2.1.3:

That's a bug in glibc 2.1.3. This is from the mmap64 source:

But of course 0x3ff only tests 10 bits, not 12, so if bits 10 or 11 are set they will be silently dropped. This has been fixed in glibc-2.2.

Another related problem is that even without this bug, mmap64 will always refuse to do an unaligned mmap, even if the kernel might have accepted it (with kernel 2.2.x for instance). Maybe the best solution would be to directly call the mmap syscall instead of mmap2 when mapping executables, this would fix both problems.

The next day Alexandre posted a patch that did just that - it implemented a direct system call with 64-bit file support. It seemed to solve the problem with many people reporting success.

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.