Wine Traffic Brian Vincent

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

News CodeWeavers codeweavers News

CodeWeavers released version 1.1.0 of their Crossover plugin. The additions are fairly impressive. From the release notes:

  • support for multi-user environments
  • support for Windows Media Player streams
  • Truetype font support
  • new plugin support including iPIX, Macromedia Authorware, and Trillian
You can download a copy from their website for $24.95 or get it on CD for $35.95.

Also this week was the release of wn20020228. This may be the last BSD licensed version of Wine released, and certainly the last from Alexandre. The changes include:

  • Client-side font rendering using Xrender.
  • Local server COM support.
  • Many DrawText improvements.
  • A ton of fixes for better MS Office support.
  • Preliminary support for C unit tests.
  • Lots of bug fixes.

Licensing TransGaming

The biggest news of the week is again the licensing debate. Alexandre began bringing the discussion to a close:

I would like to close this discussion now and proceed with the license change. Here's a summary of the various points that have been discussed and the conclusions I draw from them.

License choice

The possible copyleft licenses that have been discussed are:

  • LGPL
  • MPL (Mozilla license)
  • MPL/LGPL/GPL multi-license
  • LGPL with modifications to section 2d
  • xGPL with time delay on code release

As already mentioned, the LGPL is the favorite of the majority of people who voted in favor of copyleft. I have not seen arguments compelling enough to make one of the alternatives a clearly better choice, especially since they all have some other drawbacks that have been discussed. So the logical choice is to go with the LGPL.

LGPL ambiguities

Some people have remarked that in some cases it's not exactly clear what the LGPL allows or doesn't allow. I think this is inevitable given the nature of what the license tries to achieve, and any other license with the same goals would have the same problems. I'm confident that this is not going to be a real problem in practice; border cases can be resolved simply by discussion among the contributors (on this mailing list for instance). The existence of binary drivers for the Linux kernel plainly demonstrates that these things can be worked out.

Header files

Some people have suggested using a different license for header files. I don't think this is really necessary, given that the LGPL doesn't impose extra restrictions on headers compared to the current license (LGPL headers don't influence the license of the code compiled with them, and you cannot really distribute headers without source anyway). And having everything under the same license makes things a lot simpler.


The suggestion of assigning copyrights to an organization to allow relicensing under different terms seems to be generally disliked. It may still be useful to have a non-profit org to manage other aspects of the project, but since setting this up is a non-trivial amount of work I'm not going to pursue it at this point.

I'll shortly be making a general announcement of the change, and I'll then begin switching the CVS tree license to LGPL. If some people feel the need to maintain an X11-licensed fork (though I hope this won't prove necessary), they should use the 20020228 release as the starting point for that tree.

Alexandre went on to list the plan for implementing the change:

  • add COPYING.LIB file containing LGPL version 2.1
  • change LICENSE file to refer to COPYING.LIB
  • add notice/exception in spec compiler output
  • (probably) add notice in all source files following FSF guidelines
  • make new release announcing the change
  • start accepting LGPL patches

Michael Robertson invited everyone to talk about it at the planned Wine conference next week, Since there's two group dinners planned, these might be a good time for the licensing discussion to take place. Unless one of the attendees decides to use their presentation time to cover this topic in a more formal arena.

Needless to say, there were some people who were unhappy with the license change. But the decision seems to have been made. A lot of specific problems will be worked out over time. The first CVS commit for March contained the change. In response, Gavriel State from TransGaming voiced his concerns:

I noted today with disappointment (but not surprise) the switchover in WineHQ CVS to LGPL. While this is going to have significant repercussions on the way that TransGaming works on Wine, I will leave our views on that subject to some other time.

I do have two specific legal issues to raise - I would have raised them earlier this week, but I have not had the time to respond until today.

1) Switching to the LGPL in the manner done today violates the previous Wine license, which states:

... The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The new LICENSE file includes the 'above copyright notice', but not 'this permission notice'. The LGPL can certainly be applied to newly written code, but I believe that it is improper to apply it to all of the existing code in the tree.

The AFPLed TransGaming WineX tree deals with this issue by:

  • Renaming the original LICENSE file to LICENSE.WineHQ
  • Replacing the LICENSE file with the AFPL
  • Identifying all modified files with TransGaming's copyright notice
  • Prefacing the new LICENSE file with the following:
    Source code and other software components explicitly identified as Copyright TransGaming Technologies Inc. is covered by the license below. Other source code and software components are covered by the Wine license, found in the LICENSE.winehq file.

Something similar should suffice for the WineHQ LGPL switch. Explicitly identifying files that now include LGPLed components is probably a good thing regardless.

2) Header files. Under the same logic that allows the Wine project to build header files compatible with Microsoft's own, the appropriateness of applying the LGPL to the header files is suspect. From a post of mine to wine-devel about a year ago:

Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. ( ) The court in that case said:

Computer programs pose unique problems for the application of the "idea/expression distinction" that determines the extent of copyright protection. To the extent that there are many possible ways of accomplishing a given task or fulfilling a particular market demand, the programmer's choice of program structure and design may be highly creative and idiosyncratic. However, computer programs are, in essence, utilitarian articles -- articles that accomplish tasks. As such, they contain many logical, structural, and visual display elements that are dictated by external factors such as compatibility requirements and industry demands... In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for the purposes of copyright. When specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement.

The LGPL acknowledges this legal issue in section (5):

When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law.

Rather than be subject to this ambiguity, it may be simpler for the headers to fall under the previous license, since the previous license still needs to be there regardless.

Alexandre felt the method used to switch license was fine, It is definitely not improper, this is allowed by the sublicense case of the license. In that case obviously the old permission notice no longer applies; I'm still going to add it somewhere for documentation purposes, so that part of the license will be respected. As far as identifying files in CVS that can be used under the old license, Alexandre explained a new tag, From now on all files should be considered as containing LGPL components. I have added a "Before-LGPL" tag that allows retrieving previous versions when necessary. It doesn't make much sense IMO to try to identify specific files since the LGPL applies to whole libraries, not files. He also felt header files should be under the same license just so moving stuff around would be easier.

Gav still felt that the interpretation of the sublicense part of the license was suspect:

To grant a right to 'sublicense' means that a licensee is allowed to license a copyright work to someone else - the terms under which a licensee can sublicense are still covered by the original license, which required that permission notice to be included with the code.

Perhaps Eben Moglen can be helpful here. It's a shame that he has not had any input into this process to this point; there are a number of issues that have been brought up that it would probably be worth discussing with him.

Alexandre replied, Well, it's included now. I can certainly include the text in every source file if you like, though it's not clear that this is necessary (and it wasn't done before either). The spirit of the license is clearly respected since the copyright notices are still there, the warranty statement is practically identical in the LGPL, only the permission text is different obviously because the permissions under the new license are different. I really don't see a problem here.

Project Management Licensing Kenneth Davis Ove Kåven Eric Pouech Gerard Patel Ove Kåven posted the first message about using the existing Wine code under the X11 license:

Since it's official that Wine has gone LGPL, it's also official that there will be an X11-licensed fork. So far, 4 independent movers have stepped forward, all volunteering to look after this fork; Kenneth Davis, Gerard Patel, Eric Pouech, and me. Several others have stated their support for it, and will contribute either directly or indirectly (by licensing their Wine contributions under the X11 license). While we would like to move forward with this, and request that as many Wine contributors as possible give us permission to apply their contributions to the X11 fork, we must first decide on a few things.

  • What do we call the fork.
    Kenneth suggested "winem", and already created a sourceforge project with this name. Afterwards, Gerard suggested "Theleme" to him (from "Abbey of Theleme"). Then later, Eric mailed me and suggested OpenWine. Others?

  • Where do we host it.
    SourceForge is an option, but in the long term it would be preferable with a somewhat more independent place to host it.

  • Who is in charge.
    While a development model where more than one person can do stuff like committing patches etc may be a good idea, we still ought to choose someone that's ultimately responsible...

    Or, would we maybe rather prefer to have a WineCorp in charge?

  • Who's in?
    If you want to join the X11 fork, or just support our efforts by continuing to license your patches under the X11 license, let us know.

Anything else?

Joerg Mayer suggested hosting it at, I don't think there will be too many hard feelings in the lgpl-wine team (at least I hope so) and it looks like there will (hopefully) be quite a lot of cooperation between the two teams.

Alexandre also pointed out, I guess this is obvious to everybody except Brett, but I just want to make it clear that any code that gets added to the X11 fork can also be merged into the LGPL tree. In fact, allowing this was the only reason for the license change from BSD-like to X11 a couple of years ago, which at the time everybody agreed was a good thing. If the contributors to the X11 fork do not want this to happen they will have to change to a license that explicitly prevents it.

There will likely be a lot more posts on this topic, so look for this thread to continue.

Project Management CodeWeavers

On Thursday, February 28th Jeremy Newman from CodeWeavers announced:

NOTICE!! NOTICE!! NOTICE!! will be moving to a new home in Minnesota. We are trying to make this move as seamless as possible, but we can't guarantee that there will not be any downtime. I will post another message to the mailing lists when I have a more definite time of shutdown of the old server. WILL be on-line for Web, FTP and CVS access. The area that could have the longest downtime is the mailing lists.

Once the transfer is complete,,, and will be one and the same site.

If you run a mirror of please contact me to make arrangements for access.

Further questions can be directed my was as well.

A few days later, on Tuesday, Jeremy announced:

The move is complete, but not without some issues.

The 1st issue is that our mailing lists (mailman) sent out a huge amount of email because the newsgroup gateway changed. It basically thought all the messages on were new. Apologies go out to the users whose email inboxes we filled up.

So in the meantime, the newsgroup gateway, and the NNTP server on are offline until further notice.

If you notice any other issues that I am not aware of, please let me know. There is a lot of things to a site that has been running as long as has.

There was no reply, which is probably a good thing.

Project Management codeweavers

Jason Phillips was going through some bug lists and mentioned, I'm new to Wine development and was checking out bug #11 (from "tasklet" meta-bug #406) I added some comments for it. It seems beyond the scope of a beginner type bug. See bug for details.

Francois Gouget replied:

I moved it to a new list called FIXMEs. It is intended as an intermediate list for fully diagnosed bugs. That's the third list but don't worry, I intend to stop there.

Now, I really must get going on that contrib page.

If you look at the section of the bug detail "Bug XXX depends on:" you'll see a list of bugs for that category. "Tasklets" are the easiest ones.

Commercial Development Transgaming Xandros ReactOS

Next Friday and Saturday will be hosting Wineconf. The presentations will be video taped by and a URL will be posted later. Michael Robertson posted an updated agenda for next weekend:

There are 2 areas that we'll be focusing on:

Business issues - This will be a combination of presentation from companies talking about their business experience with WINE as well as talks on the non-technical issues facing WINE.

Wine Technology - There will be some advanced topics as well as some more general overviews. Since ( will be on hand to shoot video of all the session, our goal is to have a video series that those newer to wine can view at anytime via the net to get up to speed. Alexandre's keynote will set the tone and provide a roadmap for many of the discussions. Alexandre's keynote will kickoff the conference.

NOTE: Presentations listed below with a * designate a Friday presentation. If there's no asteric, then the presentation will be on Saturday. For maximum diversity, we will be alternating between technology presentations and business. There will be two technology presentations and then one on a business topic. Repeat.

Wine Technology

WINE Past, Present and Future [Julliard]*
Supporting Drag and Drop between Wine and non-Wine windows [Weigland]*
How To Make Fonts Look Great In Wine [Davies]*
Package streamlining of WINE [Meissner]*
DirectX [Kaaven]*
IActiveScript, or how jscript.dll was reimplemented using the Mozilla JScript engine, lots of glue, and a little bit of luck". [Hatheway]*
Beyond Trial And Error, Alternative Ways To Insure Quality Code [Stridvall]
A Howto For Regression Testing [Gouget]
Winedoc and Automated Verification [Paun]
Wine/Windows bootup handling and documentation/end user representation [Mohr]
Package streamlining of WINE [Meissner]
TBD [Czekalla]

Business Talks

Macadamian - Making It As A Software House [Boulanger]*
An Unique Commercial Application for WINE [Cadlink Technology/Hawkes]*
Gaming and Beyond [Transgaming/State]*
ReactOS - Where it's at, where it's going [ReactOS/Filby]
Corel, A Look Back [Xandros/Tranter] And WINE [Robertson]


Jeff Law wrote:

I've been following Wine development for the last 6 months, mostly watching for improvements for the 2 Windows applications I actually care about -- Quicken and TurboTax.

Quicken has been mostly usable for that entire time period; however it's behavior has significantly improved. Far fewer hangs, crashes and other undesirable behavior. I won't enumerate the problems y'all have fixed, but the user-visible progress has been great. There's still some rough edges, but the improvements have been huge.

TurboTax was basically unusable until recently -- but when I returned from a short vacation and updated my wine sources, all the show-stopping issues with TurboTax had been resolved. Amazing.

The one issue in both tools that I still need to check on is both consistently ran out of GDI space, which I've hacked around with some tweaks to gdiobj.c.

There was a 3rd application I've been evaluating (RentTracker) which was also unusable in mid-Feb, but which appears to work flawlessly now.

I just wanted to let you know that you've made great strides recently and your work is greatly appreciated.


Mehmet Yasar experienced a problem running Microsoft Visual Studio 6:

Microsoft Visual Studio 6 is crashing when opening an existing projet, with current CVS version of Wine (Wine20020122 was OK).

Comparing both, I have found the change that triggers the crash. It is function StgOpenStorage in OLE32/storage32.c, line 5595 :

    hr = StorageImpl_Construct(
       - FALSE);
       + !(Fad.nFileSizeHigh || Fad.nFileSizeLow) /* FALSE */ );
TRACE shows that Fad.nFileSizeHigh = Fad.nFileSizeLow = 0;

As you can see in TRACE the crash occurs in StorageImpl_WriteBigBloc. I suppose Wine is trying to write to a readonly opened file ? (because file is opened with GENERIC_READ)

I hope this will help finding a fix.

Mike McCormack replied:

I created the problematic change in question.

Without the change, when StgOpenStorage is called with an existing zero length file as the filename, it fails because it suceeded in opening the file but expects it to have valid content...

Unfortunately, the change was merged incorrectly from the big CW patch. (the Fad structure is not initiaized)

Could you try this patch instead please?

Mehmet reported the patch worked.

Fixes Ove Kåven TransGaming

Sander van Leeuwen wondered:

What's the current state of OOP COM objects in Wine? I've noticed a lot of related changes, but have yet to find an InstallShield 6 installer that works. (I did copy the stdole*.tlb files to the windows & system directory)

Before I start debugging this, I'd like to know if it is supposed to work at all.

Marcus Meissner wrote back, I am not sure when and how this NdrDllRegisterProxy appeared, but I am experiencing the same problem. Ove Kåven posted a small patch showing why it works for TransGaming. He felt the patch was pretty bad and would almost certainly be rejected. The patch worked for Marcus and he felt it should be included.

And related to this, Marcus mentioned debugging wasn't very useful, Oh and debugging might not really help, support for proxies registered with NdrDllRegisterProxy needs to get implemented.

Ove replied, I've been working on this as part of my COM restructure. I've implemented NdrDllRegisterProxy and large pieces of rpcrt4's marshaling framework. I'd like to release it to WineHQ, but Gav still wants something in exchange. (If we can't get money, we'll consider releasing it if a Wine developer agrees to work on stuff that may be useful for us, like an ALSA driver, and/or a Wine kernel module to speed up synchronization primitives (like mutexes), or maybe more DirectShow work, or something of the kind.)