Wine Traffic #302 For 12/23/2005

By Brian Vincent

Table Of Contents


This is the 302nd issue of the Wine Weekly News publication. Its main goal is to cut new skins. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at (

Mailing List Stats For This Week

We looked at 359 posts in 672K.

There were 96 different contributors. 59 posted more than once. 38 posted last week too.

The top posters of the week were:

1. News: Wine 0.9.4

(2 posts) Archive Link: "News"

Topics: News

People: Alexandre Julliard,�Darwine

Merry Christmas!

Alexandre released Wine 0.9.4 this week. In the announcement he noted the following new items:

Download ( , compile, be happy.

The Darwine ( guys have been tracking the new release schedule as well. In their release they note, " there is only a ppc version, but that should be enough to test the concepts of the distribution, and prepare the ground for the x86 version. "

2. Short Term Release Schedule

(8 posts) Archive Link: "Create new mailing list wine-isv?"

Topics: Project Management

People: Tony Lambregts,�Alexandre Julliard,�

A thread within a thread popped up that led Tony Lambregts to question how releases are done now. It's a valid question since there really hasn't been much of a discussion about the new release schedule Alexandre seems to be following. Tony wrote:

<Rant> Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release.

We had at least one known regression creep into 0.9.3. and maybe more that could have been corrected if we had some warning. I think that going to beta without any real attempt to provide even the most basic freeze release cycle is not a good thing. At the very minimum I would think that we should know when the releases are going to happen but we do not even know that. </Rant>

Alexandre replied:

The idea is that people should test the releases. The point of the beta phase is to encourage end users to test, and for this to happen they need to be able to get binary packages, which is what the releases are about. This is why I'm making releases more frequently too, so that end users are able to test effectively without having to build from CVS.

The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?

That led Tony to ask a few more questions to clarify how things are progressing:

Perhaps it's partly a matter of perception then.

If I understand you 0.9 was a major release then, and 0.9.1 and company are minor releases, with the next major release being 1.0. So I anticipate that we will have a major freeze before 1.0 just like we had before 0.9?

Since I'm pretty sure we do not have the resources to do nightly's like they did for Mozilla, then once certainly every two weeks is better than once a month.

If we could count on a release every two weeks that would be ideal. That way people like me who use CVS ( or GIT) could help prevent regressions even getting into the minor releases, which in turn would encourage more people to use the minor releases. I would prefer to see that releases were done on a Tuesday, myself, since I have more free time to track down regressions on a weekend and with some luck get them fixed on Monday. IMO doing this would be very beneficial to application maintainers without really changing very much what you are currently doing.

The next step up from this of course is to create a branch for bug fixes only but at this point I cannot say how beneficial that would really be.

One more thing. At the rate we are using up minor numbers we will be looking at at 1.0 being released sometime in March. This seems not to bad to me since having a major release twice a year seems pretty reasonable. Are we planning on doing release candidates for 1.0? Or are we just freezing the main branch. It seems to me that with GIT having release candidates is a lot easier then it would be with CVS.

Alexandre said there definitely would be a freeze before 1.0 and replied point by point:

The 0.9.x releases should be viewed as snapshots of the current tree. They should be more stable than the alpha snapshots but that's really because I'm being more reluctant to commit big changes as we move forward. And this will be more and more the case until we get to 1.0; it's a gradual freezing process, the temperature is going down a few degrees with every snapshot.

I'm planning to stick to the two weeks schedule, yes. Maybe weekly releases would be even better, but IMO that would require more automation of the release process so that the packages are available faster.

There are usually a bunch of changes on Monday since they accumulate during the weekend, so I prefer to make releases on Wednesday or Thursday to leave some time for things to settle down.

There's no rule that says minor numbers have to be one digit ;-) I think it's likely to be 12 rather than 6 months between major releases, but we'll see...

And yes, the 1.0 release will be off the main branch, that's where everybody is working so that's where 1.0 will be. After 1.0 there could of course be a 1.0.x stable branch in parallel with the development branch.

So there ya have it. That's how releases are being done and that's what you can expect until further notice. If you regularly run a program with Wine, it would be great if you could follow the releases and make sure your program continues to run. The AppDB ( and Bugzilla ( are great ways to track and report problems.

3. OSDL Desktop Summit

(1 post) Archive Link: "[Desktop_architects] Portland, a w(h)iney comment"

Topics: Project Management

People: Jeremy White

We mentioned a few weeks ago (WWN #299 ( ) there was a desktop summit being sponsored by OSDL. Well, Jeremy White and Dan Kegel both attended the event and Jeremy wrote the following over on OSDL's desktop_architects ( mailing list:

Otto Wyss wrote:

I have to confess that I was struck by this gap at our meeting as well. Missing applications was the #1 bullet point on the summary page of that report, and not running Windows application was the #3 bullet point on the second half of that summary page; I think it was clearly a key issue, and yet it was not squarely addressed (although helping ISVs is obviously a critical step).

I find it further fascinating that no one displayed any interest in the Wine Project during the Portland meetings. Again, referring to the #1 bullet of the user survey, missing applications included Photoshop, Quicken, AutoCAD, and PageMaker.

No one seems to care that Wine runs 3 of those 4.

<Rodney Dangerfield> We get no respect! </Rodney Dangerfield>


Like Mr. Dangerfield, then, I'm going to bull ahead and share what I would have liked to have said anyway.

The honest truth about Wine is that, while it's an amazing technology, it is not yet at the stage where everything "just works".

However, we are starting to get much closer to a point where it is much more broadly useful. In October, for the first time in our 12 year history, Wine officially shifted out of Alpha and into Beta. That change did not come lightly, and should be taken as a critical signal.

That is: Wine is a genuinely useful tool. It may not run every application; it may not run the application you need. However, it is missing very few 'big pieces', so it is reasonable to believe that any given application will need only a modest amount of elbow grease in order to be made useful.

I know that many folks have 'moral' issues with Wine (I struggle with that all the time; how do you think I feel about taking peoples money to make IE work?). And I also know that Wine is not always the best tool for the job. However, I think it is critical that it be included in the calculus of any migration, as it can often be a vital part of a successful transition.

My greatest fear is that people will try Wine, have it fail, and then discard it. A better approach is to try Wine, if it fails, *ask* how hard it would be to make it work, and then use that in any migration decision. I hate that people spend tens or hundreds of thousands of dollars on Windows Terminal Services when a fraction of that money could have gotten them a much nicer solution with Wine. We need the cash; Microsoft doesn't.

That's it; didn't have that much to say; but now I feel better <grin>

And the honest truth is that I didn't really need to present in Portland; we didn't have any major gaps that group could have addressed. While Wine certainly depends on a range of other projects, we've actually found folks are pretty good to us (when we bother to ask). And our greatest need is simply more developers, more money to pay those developers, and the completion of the good work the Software Freedom Law Center has started on our behalf (or, to paraphrase, send lawyers, guns, and money <grin>).

So, while that's not really a summary of the event, it does illustrate a bit of what went on. It's really important for people to get in the same room and discuss these kind of issues, so it's great OSDL is fostering such discussions. While Jeremy might have felt his presence wasn't necessary, it's important for Wine to involved in the greater community.

4. Case Study: SynaptiCAD

(1 post) Archive Link: "New Wine ISV case study: Synapticad"


People: Dan Kegel

Dan Kegel updated a case study from last year to include on his ISV page:

Thanks to Stefan Munz of ITOMIG, I now have a nice writeup by Dan Notestein about SynaptiCAD's ( success with Winelib; it's online at

It was first written about a year ago, but languished in cyberspace. I think I've given it its first home on a web site, and updated it a bit after emailing with Mr. Notestein.

From that page:

Given the huge amount of GUI code, a traditional port from Windows to Unix was simply not feasible and the maintenance effort to keep two such code bases in sync would be tremendous, so WineLib has been an excellent solution for us. If we were starting product development for the first time today, a cross-platform framework would be the obvious way to go, but trying to convert to a different framework API now would also be a huge undertaking.

The case study also made a reference to SynaptiCAD's internal development team, notably Eric Frias and Juraj Hercek, submitting patches back to Wine.

5. Possible LGPL Violation: SpecOpS Labs

(17 posts) Archive Link: "has the LGPL licence fell through ?"

Topics: Licensing

People: Jeremy White,�Brian Vincent

Apparently ( SpecOpsLabs has released a product based on their Project David stuff. What is that? Well, we don't really know. The last time it came up it was determined they had simply stolen CodeWeaver's CrossOver product. They haven't bothered to engage in any dialog with the community, so it's unknown what their intentions are.

Tom Wickline pointed out the link above and Willie Sippel followed up by mentioning it was a part of TurboLinux FUJI. Tom ask if anyone knew where the source code to the Wine changes were and Jeremy White reminded him:

In fact, the only person that can demand anything with regart to the LGPL is someone that is running their software. So if someone has bought a copy of TurboLinux 11 in Japan, they have the right to demand a copy of the source code to the Wine bits in Project David; presumably they'd have to ask Turbo Linux.

Be great if someone would do that...

Aric Cyr didn't feel there was anything to get worked up over so I listed what's happened so far:

Well, there is such a thing as contributing to the community as opposed to ripping it off. They are perfectly within their rights to work in a bubble or not share any of their ideas with anyone. They can also make simple bugfixes in Wine and not even bother to submit a patch to wine-patches. Heck, they don't even need to send a thank you note. That's not the right thing to do and we all know it.

Wine has a track record of being ripped off by companies. Perhaps it's not as bad as other projects, such as Samba, but it's definitely happened. So far SpecOpsLabs have a pathetic track record that only seems to be getting worse. Let's run this down from the beginning:

  1. They showed off a product without any explanation that Wine was involved. In fact, at first they completely denied Wine was part of their product:
  2. Then Ge van Geldorp discovered that Wine really was part of it:
  3. That was followed shortly thereafter by Mike McCormack discovering a CrossOver only hack was visible in a screenshot. So they basically ripped off CodeWeavers. SpecOpsLabs never had an explanation for why a CrossOver specific bug some how made it into their tree. In fact, they specifically denied using CXO: (Given the choice between believing Mike, who probably knows all of the gory details about that bug, or SpecOpsLabs.. well, I think I'd trust Mike any day of the week. And twice on Sundays.)
  4. Then SpecOpsLabs sent one email to wine-devel asking for info on how to contact Alexandre. Honestly, how difficult is it to find Alexandre's email address? How many "Alexandre Julliard's" do you think turn up when you type the name into Google? Several members of the Wine community graciously replied to the email with no response from them. Everyone asked for more info so if they planned on contributing that there wouldn't a duplication of effort.

All in all, we've graciously asked them to contribute and not gotten a response in return. You know what pisses me off though? They can't even spend five minutes sending a thank you note to wine-devel.

Merry Christmas, SpecOps. I hope you enjoy your gift of 1.7 million lines of code.

Aric looked into it and noticed on SpecOps' Partners ( page that IBM and TurboLinux were both listed. Given their long history with the community, presumably both of those companies would want to make sure the licensing was followed.

So, anyone out there have TurboLinux FUJI? Do you have the source code changes to Wine?

6. Building Wine on Sparcs

(3 posts) Archive Link: "SPARC assembly won't compile, problems with NT headers"

Topics: Ports

People: Troy Rollo,�Alexandre Julliard,�Eric Frias

Troy Rollo wanted to know how to get Wine to compile on Sparc:

winegcc from the current WineHQ produces assembly output for SPARC systems that cannot be processed by the assembler.

  1. "operation combines symbols in different segments" error.
    This problem arises because the imports code attempts to generate a relocation involving symbols in different segments (one in the text segment and one in the data segment). SPARC assemblers (including gas on a SPARC) cannot deal with relocations involving symbols in different segments. This only affects position independent code and can be avoided by changing the assembly code output in imports.c to something simpler.
  2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data section}"
    This problem is more sinister. It arises from the same limitation as the first problem, but is not susceptible to being worked around. The offending code is the code that attempts to generate the NT header of the executable - specifically the SizeOfImage element. I can't see any way at this point to provide for this calculation to be done until after the linker output is generated. I suspect the solution to this problem is to just output a zero in this location and have winegcc modify the executable image to insert the correct values after the linker has created it.

Does anybody have any objections to this solution or another approach to suggest?

Alexandre suggested, " You can probably fix it by defining an _end symbol, like we do for MacOS. You certainly don't want to try modifying the binary after it has been built."

Eric Frias (of the aforementioned SynaptiCAD) provided a patch for winebuild to fix both problems, the second doing what Alexandre suggested, " I've attached the patches we're using for winebuild on SPARC. This fixes both of the problems you're encountering. I'm not sure if the fix is the right one, but it works quite nicely :-) We use gcc/gas. "

7. Trace Logs on Windows

(4 posts) Archive Link: "Comparing a complicated program startup to windows"

Topics: Debugging

People: Corey McClymonds,�Dmitry Timoshkov

With Wine you can easily generate debugging logs that trace the API's called by a program. Corey McClymonds asked if there was a way to do that on Windows, apparently to be able to compare the code paths used by Windows DLL's and Wine's:

There is a game, known as Continuum, that has a very complicated setup before it actually starts the game, to prevent cheating. Due to this, the relay is very large, about 4MB, before it starts to repeat itself. I have gotten the +loaddll and the +seh logs at the bottom. I was just wondering, would it be possible to do the same startup on a Windows machine, and compare its relay to the relay from Wine. If this is possible, how would I go about this?

Dmitry Timoshkov explained how to do it:

Get Debugging Tools for Windows ( and use logger.exe to get a log similar to Wine relay log. Use +relay,+seh debug switches to create a log under Wine, +loaddll is not useful at all for your purposes.

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.