Wine Traffic #302 For 12/23/2005
By Brian Vincent
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Mailing List Stats For This Week
* Threads Covered
1. (2 posts) News: Wine 0.9.4
2. (8 posts) Short Term Release Schedule
3. (1 post) OSDL Desktop Summit
4. (1 post) Case Study: SynaptiCAD
5. (17 posts) Possible LGPL Violation: SpecOpS Labs
6. (3 posts) Building Wine on Sparcs
7. (4 posts) Trace Logs on Windows
Introduction
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 www.winehq.org (http://www.winehq.org)
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:
* 27 posts in 33K by julliard at winehq.org (Alexandre Julliard)
* 23 posts in 23K by dank at kegel.com (Dan Kegel)
* 21 posts in 42K by Aric.Cyr at gmail.com (Aric Cyr)
* 17 posts in 29K by wine-devel at kievinfo.com (Vitaliy Margolen)
* 18 posts in 29K by rob at codeweavers.com (Robert Shearman)
* Full Stats
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:
* 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.
Download (http://www.winehq.org/site/download) , compile, be happy.
The Darwine (http://darwine.opendarwin.org/) 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:
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.
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 (http://appdb.winehq.org) and Bugzilla (http://
bugs.winehq.org) 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 (http://www.winehq.com/?issue=299#
Desktop%20Summit) ) 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 (http://lists.osdl.org/pipermail/
desktop_architects/2005-December/000354.html) mailing list:
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.
We get no respect!
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
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 ).
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"
Topics:
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 (http://www.syncad.com/) success with Winelib; it's online
at
http://kegel.com/wine/isv/synapticad.html (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.
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 (http://news.inq7.net/infotech/index.php?index=1&story_id=60585)
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:
+ WWN #220 (http://www.winehq.com/?issue=220#Project%20David%20?)
2. Then Ge van Geldorp discovered that Wine really was part of it:
+ WWN #222 (http://www.winehq.com/?issue=222#
Project%20David%20Uses%20CodeWeavers%20CrossOver%20Office)
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:
+ OSViews (http://www.osviews.com/modules.php?op=modload&name=News&file=
article&sid=1454)
(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 (http://www.winehq.com/?issue=241#SpecOps%20Labs%20Steps%20Up)
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 (http://
www.specopslabs.com/partners-stratigicpartners.htm) 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 (http://www.microsoft.com/whdc/devtools/
debugging/default.mspx) 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
kernel.org. All pages on this site are copyright their original authors, and
distributed under the terms of the GNU General Public License version 2.0.