The new Application DB ( http://wine.codeweavers.com/appdb/ ) 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 appdb@codeweavers.com.

Areas we need help on:

• Add Apps and App Versions.
• Comments on Apps
• Application Owners (the app db has a privilege system where you can be owner of an app.)
• Screenshots (lots of 'em)

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

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

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?

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

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.

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

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.

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.

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.

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

[offset is in ecx:edx]
testl $0x3ff, %edx
jne L(einval)
shrdl $12, %ecx, %edx                 /* mmap2 takes the offset in pages. */
shrl $12, %ecx


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.