World Wine News

• Improvements to the IDL compiler.
• Some infrastructure work for loadable driver support.
• The usual assortment of Direct3D improvements.
• IME support in the edit control.
• Better support for AVI animations.
• Debugging support improvements.
• Relay traces now work on NX platforms.

<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 regressions 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 this 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>

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?

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

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.

Otto Wyss wrote:

> This discussion about "The Linux Desktop Integration Interface" is
> really amazing to read, it looks so obvious to me that the top inhibitor
> for a Linux desktop adoption is the application shortage
> (http://www.osdl.org/dtl/DTL_Survey_Report_Nov2005.pdf ).

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>

<grin>

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

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

http://kegel.com/wine/isv/synapticad.html

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.

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.

In fact, the only person that can demand anything with regard 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...

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:
   • WWN #220
2. Then Ge van Geldorp discovered that Wine really was part of it:
   • WWN #222
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 somehow made it into their tree. In fact, they specifically denied using CXO:
   • OSViews
   (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.
   • WWN #241
   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.

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?

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?

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.