Wine Traffic #118 For 24 Mar 2002
Table Of Contents
This is the 118th 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
Mailing List Stats For This Week
We looked at 485 posts in 1752K.
There were 98 different contributors.
62 posted more than once.
44 posted last week too.
The top posters of the week were:
- 39 posts in 102K by Roland <firstname.lastname@example.org>
- 31 posts in 128K by Michael Cardenas <email@example.com>
- 22 posts in 52K by Eric Pouech <firstname.lastname@example.org>
- 18 posts in 48K by Brett Glass <email@example.com>
- 17 posts in 43K by Alexandre Julliard <firstname.lastname@example.org>
- Full Stats
News: Crossover Review, Lindows.com Ruling
9 Mar 2002 - 24 Mar 2002
Archive Link: "News"
CodeWeavers, , Jeremy Newman, Lindows.com, News, TransGaming, Gavriel State
great review of CodeWeavers' Crossover Plugin over at MozillaNews.org.
There's a bunch of nice screenshots.
MandrakeSoft released version
8.2 of their distribution. According to the notes, the version of
Wine included is from CodeWeavers.
look at the successes of TransGaming was recently added to their
They also added new column, check out
A preliminary ruling in favor of Lindows.com was handed down.
A preliminary injunction against Lindows.com was also dismissed
thereby allowing them to continue using the name.
[ 1 ]
[ 2 ]
[ 3 ]
[ 4 ]
LindowsOS Sneak Preview 2 should be out soon. This time Wine
developers will have access to it.
Also, I want to thank Jeremy Newman of CodeWeavers for showing
me the excellent Tidy project.
The XML this page comes from should be much better now.
Wineconf 2002 Resources and Summary
18 Mar 2002 - 21 Mar 2002
Archive Link: "wineconf 2002: final things"
Francois Gouget, Guy Albertelli, Michael Cardenas, , Dan Kegel, Codeweavers, Max, Mike McCormack, TransGaming, CodeWeavers, James Hatheway, Huw Davies, Ulrich Weigand, Jeff Tranter, Apple, ReactOS, Lindows.com, Patrik Stridvall, Ove Kåven, Steven Edwards, Mark, Transgaming, Bob La Quey, Gavriel State, Marcus Meissner, Alexandre Julliard, Michael Robertson, Sylvain Petreolle, Jeremy White, Xandros, Eric Pouech, Hetz Ben Hamo, Andreas Mohr, Francois Jacques, Ulrich Czekalla, Guy Alberte, Jeremy Newman, Uwe Bonnes
Wineconf 2002, hosted by Lindows.com, was held March 15 and 16th in San Diego.
Many key Wine developers attended. Topics included both technical and business
presentations. Alexandre gave the keynote address. Lively discussion involved
licensing and some of the business models put forth by various Wine related companies.
If you're interested in the presentations, the Linux
Public Broadcast Network taped them and put them
online. More will be added in the future, what's on the site right now is the streamed
content that was broadcast on Friday and Saturday. Tapes were made and work is being done to
get that content online. By the way, for amusement try viewing Michael Robertson's
"Lindows.com and WINE" presentation
on a slow modem connection - the animated movements are pretty funny when you only get a tenth of
the normal framerate.
The presentations are excellent. Michael Robertson's included a lot of detail about
LindowsOS - I suggest checking it out. Not only does he present a unique revenue model,
but he shows off some of the stuff they're working on. (And yes, it still runs as root,
yes it uses a UMSDOS filesystem. No, you might not like it, but your Mom might.)
Gavriel State talked about TransGaming. He gave a really cool demo of Max Payne, which
required DirectX 8.0 functionality. Gav also presented a plan for working with the LGPL
tree that involves "trading" patches from their work in return for patches they need.
James Hatheway's presentation on the JScript engine was also interesting for a lesson
in gluing code together from other projects (Mozilla in this case.) Michael Cardenas'
summary below includes more detail.
Andreas Mohr placed a bunch of photos and his presentation online at:
Likewise, Francois Gouget did the same:
Marcus Meissner took a picture of
the Wine team and annotated the names of the folks in it.
He noted that it didn't contain the people who weren't there on Friday. Marcus added
several other pictures from San Diego.
Sylvain Petreolle was curious about a screen shot of IE running. Guy Albertelli gave
some details about running IE:
I was going to write a summary of the various presentations, but Michael
Cardenas of Lindows.com wrote an excellent one:
IE 4 and IE5.5 (I don't have IE 5 or IE 6 yet) run fair (not well) with the
standard config dll selection and the following overrides:
The issue with black icons is due to something in the native comctl32. If I
I will get the black icons. This started back in the summer of 2001 I think.
The builtin comctl32 displays the icons correctly. However it does have some
Note IE is one of the main test vehicles that I use to work on rebar and
toolbar. It is a great test program. It seems to use most of the documented
interfaces for comctl32 and a lot of undocumented ones (see discussion of
the toolbar mesage 0463).
Wineconf 2002 - by Michael Cardenas
In Alexandre Julliard's keynote speech, the most recent event on the Wine
timeline was WineConf2002, marking it as one of the significant events in
the history of the wine project. It was definitely significant to me, being
the first open source conference I have had the chance to attend, much less
help coordinate and plan. I'm the lead wine engineer at Lindows.com, so I
helped to organize the conference. Some of the attendees told me in
conversation how tremendously grateful they were to have been brought
together and to have been recognized, but I was just as grateful to get to
meet all of them. The goal of the conference was to bring together the wine
community to energize them and help them organize their efforts more, and I
think the conference was a success in both regards.
The day began with Michael Robertson welcoming everyone and inviting
Alexandre to begin his keynote address. Alexandre's speech was "Wine: Past,
Present and Future". He said that he had a hard time trying to come up with
a presentation about something that everyone in the room didn't already know
about. He went through the history of wine, beginning with a binary loader
written by others. He also showed the initial versioning scheme, since the
current versioning scheme is a source of disagreement. His presentation
showed how they had reached version 0.8 in 1994 after a year of work,
feeling that 1.0 was about 6 months away, which brought a round of laughter.
Apparently, that has been something all the developers have heard a lot. The
speech also brought a round of laughter when he showed the end of the wine
timeline. The last thing in the timeline, after WineConf 2002, was release
1.0, the date for it was July 2037. He did encouragingly say that it might
be ready in June, not July.
Alexandre detailed the features required to get to Wine 1.0.
- Address Space Separation
- Window Management
- Dll Separation
- Wine Server Protocol
- Regression Testing
Going on, he Alexandre proceeded to detail each point. Address space
separation and window management are two features that Alexandre has worked
primarily on, and that are mostly done. The remaining work is for him to do.
Regarding regression testing, Alexandre said that there are 10,000 API's
that need regression testing, so some serious work needs to be done
developing a testing suite of any scope.
Dll Separation was the next issue addressed. Dll Separation involves
making sure that Dlls only call functions from other Dlls that they depend
on, and not call functions in Dlls out of dependency order. A good deal of
work has been done to solve this problem, but more remains. Alexandre showed
in his presentation the dlls which remain to be separated, in order of
The easy ones:
The hard ones:
Alexandre went on to discuss his wish list for the future, which wine 0.9
does not depend on directly. These issues are:
- Font support
- Common Controls/Dialogs
- DIB Engine
In addition, the discussion of better Windows/Wine boot procedures was
discussed. Specifically the command line handling should be moved into a
separate application. Alexandre discussed having a very small loader that
In order to keep the rest of the discussions focused on achieving the goals
set forth by Alexandre, the next discussion session was devoted to the path
to 0.9 and was led by Jeremy White, with feedback from the entire group.
Jeremy asked why dll separation was necessary for Wine 0.9. Alexandre
pointed out that it was important for backwards compatibility. With full dll
separation, there should be less chance of breaking applications by changing
the dlls, which was important for Wine 0.9. Also, dll separation should help
with getting the dlls to compile on windows. The conclusion about dll
separation was that Dimitrie O. Paun, Patrik Stridvall, Alexandre, and
Gavriel State would work on it.
Jeremy asked what remained to be done for Window Management. Alexandre said
that there was still work required for window managing, focus problems, and
window switching. Alexandre is going to continue to work on this.
Window management was discussed and the conclusion was that Mike McCormack,
Alexandre, and Ulrich Weigand would work on this.
The next issue discussed was regression testing. The goal is for a developer
to be able to make a code change, and before checking it in, type "make
test" and the test suite will test regressions in the API and let the
developer know if anything is broken by his change. At this point there is a
framework in place, and there are a few tests to test the framework.
Francois Gouget, Patrik, Dimitrie, and Steven Edwards agreed to work on
Documentation was agreed on to be mostly complete. The only remaining work
to do is to bring it up to date and to move from a faq-o-matic to a standard
faq. Andreas Mohr, Jeremy Newman, and Urivan Saaib from OsoComm were all
volunteered to work on this. There was some discussion as to what the focus
of the documentation should be, users or developers. A suggested item for
the faq was that when a person is trying to fix a broken app, they should
try using desktop mode, managed mode, and different windows versions using
the --winver command line option.
The next topic was bugzilla. It was generally agreed by everyone that we all
need to use bugzilla heavily to get to Wine 0.9. I brought up the fact that
although it might be obvious, if we don't concentrate on a quantifiable
number of bugs, we won't ever get to 0.9. Dimitrie brought up the issue that
it is important to have small enough bugs that developers can work on them.
He said for example, that if you're looking at the bug list, you might see
Dll separation and say, "next!". Small, accomplishable tasks are important
to have documented. Dimitrie suggested posting the top 10 or 20 bugs to
wine-devel every other week, and I suggested putting the in WWN. A new
mailing list will be created, called wine-bugs so that people can be
notified of new bugs and hopefully respond to users in a timely manner.
Lastly, someone asked whether we should choose a beta tag for a particular
release, because it would motivate more users to download and try wine,
since it implies a degree of stability.
After lunch, Frederic Boulanger gave a presentation about Macadamian: "who
we are, what we do". Macadamian did a lot of work for Corel on Wine. Now
they offer a variety of services including XP development, J2EE, web
services, and Linux development. They have done software for commercial
devices, wireless devices with a small footprint, and bioinformatics. One
case study discussed was groove networks. Groove needed a linux client in a
short amount of time so Macadamian used wine to get the groove windows
client to work on linux. Due to the success of that project, they were
chosen to develop a native client of groove's software. Macadamian worked on
Corel WordPerfect and Draw for Linux. They also developed Corel Draw
Essentials, the first Windows XP application.
The next presentation was Gavriel State of Transgaming's presentation on
licensing. He began with a little background on who he is. Gavriel worked at
Corel and ported Corel Draw to the Mac using a portability layer like wine,
for the Mac. Corel then decided to move to linux, and called on his team and
their porting experience. Working with Macadamian and CodeWeavers, Corel was
able to port their entire office suite to linux in 18 months. In mid 2000,
Gavriel left Corel to start Transgaming. He decided that the best way to get
linux onto the desktop was to support games on linux. He was involved in
starting Xandros, the Corel Linux spin off, but when it was complete he
focused again on Transgaming.
To begin the licensing discussion, Gavriel asked the questions "why do
people work on wine? why does transgaming work on wine?". Basically
transgaming works on wine because they get a lot out of it, and they want to
give a lot back. He said they they only keep the code that they believe is
required for them to differentiate themselves as a company. Also, there's a
large benefit in making the code available to everyone which is that people
will work on that code. He the discussed that wine is more than just a
windows compatibility layer for linux, and can have far broader
applications. Also, he asked everyone to raise their hands if they make
money off of wine and only about half of the attendees raised their hands.
He said that the best way to improve wine would be if everyone could afford
to spend as much time on it as possible. Gavriel went on to say that
Transgaming cannot legally release the code that they've written do properly
support copy protection in games due to the DMCA.
As this point, Gavriel announced that Transgaming would maintain an X11
branch of wine. Transgaming will continue to contribute their non strategic
code under the X11 license. He said that he hopes that many developers will
submit their patches under dual licenses. He asked that winehq continue to
be the repository for the X11 cvs tree.
He went on to discuss the value of a patch. He said that the LGPL license
assumes that all patches are created equal, and that he did not necessarily
believe that this was true. Going on, he said that Transgaming would be
willing to trade some of the code that they've written, and release it under
the X11 license in exchange for code that they need written, such as a DIB
engine. He even offered a cash prize, of $2000 USD for a wineserver kernel
module. There was some discussion about the points he had made, but no
Jeremy White was the next speaker, and he told the story of Codeweavers. He
said that one day while debating the greatest video game ever, he started
looking for an Atari 2600 emulator to show Combat to some other developers.
In doing so, he came across wine, and immediately was fascinated. Later, he
decided to follow the adage that to do something great, you must do what you
love, and decided to start a company to work on wine. The goal of
CodeWeavers is to remove the barrier to allow people to leverage wine. He
feels that Microsoft has created a great barrier for anyone trying to leave
the path they have set forth. CodeWeavers has worked on a number of
consulting projects and is now selling a product successfully, Crossover for
linux. He said that his ideal goal would be for someone to be able to go to
a store, buy a piece of windows software, and know that they could be
confident that it will run in linux.
The next presentation was an excellent detailed discussion of the wine
debugger, how it works, and how to use it. He said that Eric Pouech was the
primary author, but he was unable to attend the conference. He also said
that Alexandre had contributed to the debugger as well. One issue discussed
was "why have a wine debugger?" The answer is that debugging wine involves a
mixture of builtin, or linux code and native, or windows code. Also, it
involves a mixture of codeview/pdb symbol data and stabs/DWARF symbol data.
Also, the wine debugger requires support for non-standard execution models
such as win16 segmented addressing and msdos real mode. The debugger must
also support win32 threads as they are implemented by wine.
Winedbg, the wine debugger, is a win32 command line application. It works by
waiting in a WaitForDebugEvent call until the wineserver creates an
exception event and puts it in the debug queue. A more detailed discussion
can be found in Ulrich's presentation.
There are a number of things that need to be done to winedbg to improve it.
The main ones Ulrich listed were user interface, unicode support, and
improved C++ support.
A discussion of substitutes for Wine followed. Win32 debuggers can be used,
such as the MSVC remote debugging stub. Gdb can also be used, but support
needs to be added to Gdb for codeview symbol information and for Wine
I brought up the issue that to have Codeview debug information, you need the
source for the app. Ulrich responded by mentioning that the Windows NT SDK's
have symbol information for some system dlls. Francois Jacques of Macadamian
asked how difficult it would be to be able to use gdb. He said that the
effort involved would be worth it because using gdb would allow Wine
developers to use IDE's. I pointed out that that would be a great step in
getting more Windows developers to work on wine. I also brought up the issue
that the wine debugger seems to catcfh a lot of seg faults that applications
can handle. Dimitrie and Ulrich said that you can set the debugger to break
on first chance exceptions, pass the exception back to the application with
the pass command, or setup a specific behavior for a specific signal to
avoid this problem. I asked what debugging strategies were used in general
and the majority agreed that they mostly work with relay traces, but use the
debugger for specific circumstances. In addition, Dimitrie
pointed out that he often sets up winedbg to halt on a sigstop, and then
The next presentation was the ReactOS demo by Jason Filby and Steven
Edwards. ReactOS is an OS that attempts to be compatible with WindowsNT
applications and drivers. Their current development plan is to have a
release every six months. Since ReactOS is based on the NT architecture, it
has a hardware abstraction layer, which makes it very portable. It also has
subsystems, like, for example, a Java subsystem. Currently it has console
application support and the win32 subsystem is the focus of development.
They are going to attempt to support WindowsNT drivers. The developers use
mingw as their compiler. They worked on regsvr32, which was LGPL, so they
contributed their work back to the wine project. The current graphics engine
was demonstrated, which is now able to draw lines and some primitives, as
well as rendering a builtin font.
The first day ended with a Mexican dinner at a restaurant near the
conference, paid for by CodeWeavers. We all ordered more beer when we heard
this. I sat at the same table with Dimitrie, who had the most interesting
stories. Lindows.com gave Alexandre Julliard a plaque for his tremendous
dedication and effort on the wine project.
The second day of the conference was kicked off by Patrik Stridvall's
presentation on writing quality code. He discussed some common approaches to
developing wine such as developing whatever isn't implemented, and focusing
on specific applications, and discussed problems with each of these methods.
He made some forward thinking suggestions, such as developing dlls for
windows, that could gather statistics on what functions are called and with
what parameters. Dan Kegel discussed using bitmap screenshots with a
predefined group of fonts and comparing them with current output from Wine.
The conclusion of Patrik's presentation was that regression testing was the
primary method that Wine developers would be able to maintain quality code,
which led into the next presentation nicely.
Francois Gouget gave the next presentation, on the current regression
testing framework. He began by discussing previous efforts at regression
testing wine, and how they had been too ambitious. He mentioned that the
method of comparing screenshots had been tried before, and had not been very
successful. The new framework is more limited and simple, but will hopefully
lead the way to a complete regression suite. He pointed out that there are
now Perl and C frameworks, ready to have test cases written for them. Some
regression test examples he mentioned were calling windows functions and
testing their return values, or testing window messages and verifying their
behavior. In the current framework, each test case is a file. To compile and
run the tests, you just type "make test". Francois showed a perl and a C
example in his presentation, and they can be found in the source tree.
Running the tests on windows is not ready yet, they can be run, but they
most be run individually. Someone asked if the test framework is thread safe
yet, and Francois said it is not. Francois Jacques of Macadamian pointed out
that this might make networking tests difficult, but Francois pointed out
that you could use CreateProcess to launch a server, and then keep the
client code in the test script.
At this point, Patrik reiterated the value of having a statistics gathering
dll that runs in windows and records the functions called and their
parameters. I talked to him later about this, asking him if we could make
some kind of a loader in windows, so that we could capture a relay trace of
a windows application, so that we could make a test script out of it.
Someone made a call for some documentation on how to write a new test case,
to which Francois said that the way to make one is to take an existing test
script and modify it.
Bob La Quey of OsoComm asked if there was any way to automatically generate
test cases, since there are so many api calls. This idea was met with a
resounding NO from the wine developers, because the API's must be understood
to make a working test case. I later spoke to Bob, Patrik and Francois
about the possibility of writing a tool that would translate a Wine relay
trace for a working application into a test case. They agreed that there
would be a lot of difficulties in doing this, but I still think there is
Jeff Tranter of Xandros made the next presentation entitled "Corel, looking
back". The initial project for the Corel linux team was to port WordPerfect
Office 2000 to linux. They investigated doing a source port, but do to the
difficulties of cross platform development, such as compiler differences, a
binary port was chosen instead. Corel packaged their apps as Rpm's and
Debian packages because the windows graphical installer didn't work under
wine. They also developed a graphical front end for their linux installers.
At this point Dan Kegel asked about Corel shipping the MS runtime dlls, and
if MS has changed the license. Gavriel pointed out that it was still
possible under the current license.
Some things that Jeff said worked well were that good developers could get
up to speed on wine fast, with little prior experience. What didn't work
well was keeping up with Wine, since it wasn't regression stable at the
time, and the difficulty of supporting multiple linux distributions. Next
Jeff discussed the future, and Xandros. Xandros has licensed the Corel Linux
OS, and not the applications, so their future is uncertain.
I asked what QA methods they had used and he said that they had focused on
manual testing. Towards the end he said that they began to develop a
regression testing suite for wine, but did not get very far. Uwe Bonnes
asked if any useful features were still in the Corel tree that had not been
moved into the public tree, and Jeff said that all the useful code had
probably been extracted.
Hetz Ben Hamo asked, via IRC and Andreas Mohr, if Xandros is using KDE3, and
if they're working on it. Jeff said that they're looking forward to when it
will be released and will use it then.
David Hawkes of Cadlink technologies made the next presentation, "A unique
application for wine". His company, Signtopia, has a product called Signlab,
which is a windows application for designing signs. They wanted to make it
available to their customers over the web. They looked into many other
solutions such as terminal server, Citrix, Graphon, and a rewrite in Java.
Due to licensing concerns, they decided to use Wine and VNC. Some of the
limitations were Wine's slow startup and some visual glitches. To get around
this, they use a number of pre-started wine sessions and they removed the UI
and made the application work from a web form. To improve the performance,
they moved to Tight VNC and provided some sponsorship for the development.
The next presentation was by Ove Kåven and Gavriel State and discussed
DirectX and Wine. Gavriel discussed detailed info on how directX functions
in wine with openGL, including pseudo code. He discussed how a number of
important functions are implemented, such as DrawPrimitive. His presentation
contains a detailed discussion of these issues. This was followed by a very
impressive demo of their technology. Gavriel showed 3dMark 2000 running on
wine, Age of Empires, and Alice. Gavriel's sound didn't work, so the
attendees were treated to a demo of modprobing the sound card and cat'ing
files to the dsp. During the Alice demo, he discussed the need for a
wineserver kernel module. Alice uses a mutex to synchronize the rendering
with the sound, and due to the heavy reliance on this, the wineserver takes
up about 60% of the CPU, which was demonstrated by showing the top command
while ALice was running. Patrik Stridvall asked about SMP support and
Gavriel says that winex and wine support SMP and both show a considerable
speed improvement on SMP boxes. Gavriel passed the microphone to Ove
Kåven to answer questions. Dan Kegel asked if there is BSD support and
Ove said there is no support yet.
Michael Robertson took the stage next, giving a presentation on "Lindows.com
and WINE". He started with a little history. He discussed that he had
started mp3.com for two reasons, to make money and to make the world a
better place. MP3.com gave attention to the many independent artists, and
gave the mp3 format enough momentum that it could not go away. Michael said
that he feels that the current software market is not good for consumers,
because of the lack of choice, and that he doesn't want to wait for the
federal government to fix the situation. He then made the point that if you
look at Windows XP and Linux, they're very comparable, probably 80%
functionally comparable. If that's the case, he asked, why are only 5% of
the people in the world using Linux? He feels that what linux needs is
better packaging, presentation and distribution.
Then Michael asked "how does somebody compete with Microsoft?". There are
around 30 people at Lindows.com and there are around 600 people in
Microsoft's legal department alone. He says that the fight can't be just
Lindows.com vs. MS. Like mp3.com, all the artists and the consumers came
together to make digital distribution of music a reality. Similarly, he
feels that when all the open source developers are brought together with
consumers, everyone can benefit.
Lindows.com's focus, says Michael, is on ease of use, providing a gentle
migration path and making it easy for people to get and install new
software. To that end, Lindows is developing a web based system to make it
simple for users to get new software and install it with ease. Michael
summed up by saying that the best thing for Linux would be to have 5 or 10
million new users. Once that happens, there will be better hardware and
software vendor support. That is his goal at Lindows.com.
Steven Edwards asked about licensing and Michael said that LindowsOS will be
licensed per person and, per machine. Dan Kegel asked if Windows apps from a
user's machine are available once LindowsOS is installed, and Michael said
yes. Hetz Ben Hamo asked, via IRC and Andreas Mohr, why LindowsOS logs the
user in as root. Michael responded by saying that for ease of use, it's
important. He said that his mother won't understand that she has to enter a
password every time she wants to change the time. Also, he compared
LindowsOS to MacOS, where the user is also a superuser. He says that
Lindows.com is focusing on locking the doors to the outside world, but
leaving the doors inside the house unlocked. Dan Kegel said that he thinks
that "security issues will convince you to change."
Marcus Meissner was the next presenter, discussing Wine packaging. He asks,
what does a user want from a wine package? Ideally, he says, someone should
be able to just install it, double click a file and have it run. Also
printing should work out of the box. He discussed the attempt to have one
package for multiple platforms and the difficulties. These include CUPS
support, OpenGL support, and integration with the distribution. He discussed
vendor supplied installations versus third party installations, as well as
Caldera's approach. Dimitrie asked if there should be a .spec file so that
anyone can make a package. Alexandre responded by saying that only a few
people need to make packages, and those people should know how. Also, a spec
file would create the danger of having broken packages floating around. Dan
Kegel asked about an rpm for console mode only wine and Marcus said this
would not be difficult to make. Gavriel asked about what the FSB says about
third party wine installations, to which Marcus said that third party
software such as Transgaming's must go in /opt.
Wine/Windows bootup handling and documentation was the next presentation,
given by Andreas Mohr. Andreas began by thanking Lindows.com for the
conference, saying that he really appreciated it. He also said that he
wanted to make a statement about Linux companies that had failed due to
users who expect everything to be free, as in beer, and that users should
support companies who support the community. He then discussed the program
winebootup, which he is developing, which will handle wine booting
procedures. Also, he is developing an uninstaller like the Add/Remove
Programs control panel, which supports both wise and installshield installed
applications. I asked what happens in Wine when an application asks for a
reboot, and he said nothing happens. There was some discussion as to what
should happen. Should wine exit? Should the wineserver exit? How should
installers be supported? Francois Gouget pointed out that another problem is
that some applications ask for a reboot, and a naive user might then reboot
the machine, and the state of the installation will be incomplete. Andreas
pointed out that a general session management scheme needs to be developed
and implemented, but no one is currently planning on working on that yet.
James Hatheway's presentation was next, about how he implemented an
ActiveScript aware jscript.dll. Due to a client's request, he was assigned
to develop his own jscript.dll, desipte the fact that the MS dll is freely
distributable. He explained what ActiveScript is, a platform for
applications to handle scripting languages, without having to know how those
languages are implemented. Using spidermonkey, he was able to develop a
jscript dll that allowed groove networks' client to work. The client uses
discussed a tool, which lets applications replace embedded internet explorer
components with a Gecko browser. James' presentation discussed a lot of
details of COM and the IDispatch pointer, which most of the developers found
unfamiliar. James himself described the functionality as "black magic".
The final presentation of the conference was Huw Davies' presentation on
"how to make fonts look nice in wine". The answer, he said, is to not use X!
Which was met with a round of applause and laughter. He then discussed some
of the limitations of X fonts such as the fact that their metrics are worked
out at load time. This means that font sets such as katakana or hebrew can
have huge load times since they have so many glyphs. He also demonstrated a
number of truetype fonts with transformations applied such as rotations, 3d,
curved text and gradient text.
Huw discussed the fact that his implementation relies on Freetype. Freetype
is a free TrueType font renderer. He also discussed the requirements for
someone who wants to use it and compile it. He also mentioned that there are
still patent issues with Apple and the TrueType format.
Dan Kegel asked if Huw's code has gone back to the public tree yet. Huw said
that yes, he had a few small patches, but most of it had gone back. Gavriel
State pointed out that some windows fonts are missing certain information
tables and asked if they are supported by Huw's code. Huw said that they
probably weren't and that he'd get a copy of those fonts and look into it.
Gavriel also suggested that the Corel tree has lots of code for handling
PostScript fonts and that Huw should look into it. Ulrich Weigand pointed
out that now that client side font rendering is done, the hardest part of
the DIB engine is complete. Dmiitry asked when the patent on TrueType
expires and Huw said he wasn't sure.
Dimitrie went back to the DIB engine saying that once they break it up into
smaller pieces, it would be easy for a developer to say, add a function that
draws an ellipse. This was agreed on by everyone but a foundation needs to
be put in place to begin the work. Gavriel State added that he thought the
hardest part of the DIB engine would be the bit blitting and blending modes.
Huw added that other font support, such as AddFontResource, should be
trivial to implement now. I commented that Photoshop 6 won't launch because
of AddFontResource, trying to add a .fon file.
After Huw's speech, the attendees talked amongst themsleves for another hour
and a half. Dimitrie, Gavriel and Ove began working on the DIB engine, doing
some design on a whiteboard. Lots of other design conversations took place
and had taken place for the last two days. Ulrich Czekalla took the
opportunity of Alexandre's proximity to talk about COM and inter process
communication over lunch the first day.
The second night, there was a dinner at a bar and grill, but I unfortunately
couldn't attend. I left the conference with an overwhelming feeling that I
am extremely lucky to be in a community of such talented, dedicated,
passionate people. I just want to thank Lindows.com for putting it together,
and thank all the attendees for coming and providing such wonderful energy
and so much knowledge. I'm eagerly looking forward to wineconf 2003.
Why Wine is Like Playing the Guitar
19 Mar 2002
Archive Link: "Why Wine is like playing the guitar"
Topics: Project Management
Michael Robertson, Dimitrie Paun, Francois Gouget, Steven Edwards, , Michael Cardenas, Codeweavers, Lindows.com, Apple, codeweavers
Michael Robertson gathered his thoughts after Wineconf 2002 and
Dimitrie Paun replied,
Ok, I've had some time to digest the two packed days of wineconf. It was
great being around so many smart and passionate people. I've long since given
up coding, so much of it went over my head but the various biz presentations
hit home and I had a chance to talk to many of you to crystallize some
We need 20 million avid Linux desktoppers. Look at what Apple's
vocal minority gets them. With 4% marketshare they command sections in
stores. They get hardware with Mac/Win drivers. They get documentation in the
box. Even stores dedicated just to them. That's what we need to get Linux
really going. If we can get the user inertia and the business inertia around
Linux, then that will take it to new heights. I believe Wine will play a role
But I think a slight re-focusing may be necessary. Have you ever tried to
learn how to play the guitar? I think most people have at one time. First you
start learning chords and you say to yourself "I'm going to learn all the
chords so I can play all the songs". After about struggling through 4 of the
700 chords, you realize that it will take until 2037 to learn all the chords.
To make guitar rewarding, you have to start with a list of popular songs and
learn the chords just for those. This way you get that feeling of success and
it motivates you to stick with it, even if it's just learning Happy Birthday.
I believe a similar strategy could really energize Wine.
We need a "top 10 tree".
What WINE needs is a specific value promise to the consumer. In many ways,
the same challenge confronts WINE that confronts Linux. Great things will
happen *if* we get a bunch more users. But to get more users, there needs to
be some specific value that people get from Wine. And it can't be fleeting
value. It needs to allow them to do something specific and when they get the
new version, it needs to no take away that value, but add more.
The challenge we have now is that the goal for WINE is an architectual one
(learn every chord). While nobody can deny the value of a solid underpinning,
users don't care about the architecture. They want to hear music! And
with Wine this means "what programs can I run?"
I would also suggest that focusing around specific applications focuses
energies of developers on solving specific user problems. The more problems
you solve, the more users will get excited about Wine.
One question arose at wineconf which never got addressed. "How do we get more
people excited about Wine?" I've been thinking about that. I believe a
specific part of the answer is making Wine actually work for a subset of
programs. Take it from a theoretical white paper stage to a stage where
people actually use it. I'm not suggesting its at a white paper stage, but
rather if the world can't use it with any regularity for even a narrow set of
applications, the perception is it's nothing more than theory.
What I believe needs to happen is that we have a 'top 10' tree. A version of
Wine for which the primary goal is to do a good job of running a set version
of win32 programs. This serves both parties. It gets developers all
laser-focused on the same goal. Because we've narrowed the universe we can do
specific testing. And perhaps MOST important, consumers know what to expect.
If you tell them "we have a Linux OS which will run Win32 programs, they'll
bring out a geneology program from 1992 which won't run and then they'll
think it sucks. If however the public commitment is "this software is
designed to run the following:
and it actually works, you have a believer. You have someone who will get
excited and will offer their help. You give momentum to Wine. You get program
sponsors (those willing to oversee ongoing supervision/testing of programs.
You get more people offering to be on documentation teams. And you get more
One final thought. I think the only tenable way to implement a Top 10 type
approach is to get widespread support. Lindows.com alone is too small to do
this in a timely fashion. So is Codeweavers, transgaming, etc. The only
approach with any chance of success is one which leverages the entire
I can assure you that Lindows.com would put our full weight behind such an
endeavor. While we only have a couple of coders, we've got a super QA
department. We've got solid organizational skills. We have an enthusiastic
user base we can tap for testing and support.
I'll shutup now before I get banned from wine-devel.
Ok, those are my thoughts.
This is well understood by most people, and this is what we call 09/1.0.
That's why it is so important to nail the tasks left for 0.9. You see, 0.9 is
not 'all chords', but rather 'a handful of notes' such that we start 'playing
a few tunes well'.
As far as applications go, Francois Gouget mentioned that the Wine
application database allowed
people to vote for what applications they wanted to work the most:
Steven Edwards gave list of applications he felt should be included:
What seems to be missing is a count of the votes for a specific
application on the application's page itself.
You can also vote for the bugs you want to see fixed most.
- To vote for a bug you want to see fixed, go to that bug and then
click on 'Vote for this bug'. This sends you to another page. Set the
number of votes you want to spend on that bug (you are allowed a total
of 5 votes), and then click on 'Submit'.
- You can view how many people have voted for a given bug directly on
that bug's page.
- Use the following query to get a sorted list of the bugs by number of
Steven also felt for each item on the list it was important to provide
an "upgrade" path to a native application that did the same thing.
Michael Robertson replied,
- Office (Word, Excel, PowerPoint, Outlook.)
- Internet Explorer.
- Lotus Notes
- All of the P2P software
- The Palm Desktop
I think millions of people have voted already on the titles they'd like to
run and the results are evident by actual consumer usage of software titles.
The list that Steven made seemed solid to me.
Michael Cardenas provided links to the top ten titles sold by
Amazon and CNET.
Although, both of those lists are of dubious value since they include Microsoft OS's such as Windows
2000 and Windows XP. They also contain products that have excellent native equivalents such as
CD burning software.
As far as testing applications is concerned, some of that is covered in the next thread...
Road to 0.9
17 Mar 2002 - 20 Mar 2002
Archive Link: "Road to 0.9"
Topics: Project Management
James Hatheway, Alexandre Julliard, Jeremy White, Yven Leist, Francois Gouget, , Michael Cardenas, Tony Lambregts, Andriy Palamarchuk, Jeremy Newman
James Hatheway started off this thread with:
A couple of people took exception to the wineserver protocols being considered
done to which Alexandre replied,
As I said I would do at the conference, I am posting notes on the
road to Wine 0.9 (tasks that Alexandre requires to consider WINE
at the 0.9 stage), and the names of the people who volunteered to get
the ball rolling on each point.
For Wine 0.9
- Dll seperation (being able to build on windows being a "Wish") -
Dimi, Patrick, Steven, Alexandre, Scott
- Address Space Seperation - Alexandre
- Window Management - Ulrich, Mike, Alexandre
- Wine Server Protocols (DONE)
- Regression Testing - Francois, Andridy, Patrick, Dimi, Andi, Steven
- Documention -> Call for a FAQ maintainer
Urivan, Andi, Jeremy Newman
- Bugzilla - Francois, Andridy, Jeremy Newman- to create a wine-bug maillist
ALL should commit to using bugbase
The other keypoint that was brought up was that: we need to drive users in and make it easy
for them to help with (A) Docs, (B) Bugs, and (C) Testing apps
The point is not to freeze the protocol completely, it will clearly
continue to evolve even after 1.0. The idea is that once the protocol
is declared frozen all future changes are done in a way that preserves
backwards compatibility. And the mechanisms to do that are mostly in
place now, which is what I mean by saying it is finished.
Alexandre went on to list a few exceptions and noted some of the work
Tony Lambregts wondered what was meant by "Testing apps". James
Basically, the idea that we had was the concept of getting users
to volunteer to "own" an app, ie. responsible for yelling when
we break an app. This already sort of happens, but never
in a formal way. We never decided the details, but I envisiage
having one person volunteering to each test their favourite app on every
release and filing bugs. (in a way that is helpful, we'll have docs for that)
Jeremy White felt James didn't quite understand the application
The specific goal was to clone Lawson 50 times,
and have each clone pick up an application.
Jeremy had some ideas concerning the application database as a
possible tool for helping with application testing:
Yven Leist had some software he uses regularly with Wine.
He volunteered to test it regularly to make sure no regressions
have taken place. Yven and Michael Cardenas discussed automating
a test so that regular builds from CVS could be tested rather
than just the monthly releases. Yven put together a small script
As a side note, the design for the app db called
for a 'maintainer' field. The thought was that
people trying to use that app could (possibly) email
the maintainer. Sort of a live discussion/support area
for each app. Hmm. Maybe just email each new
comment posted to the maintainer rather than encourage
The further thought was that with each new release cut,
there could be a 'sounding off' process, whereby each registered
maintainer would validate that the new release
worked with their app. A user of the app db
could then see a list of 'verified' Wine releases.
We didn't really have a clear vision of exactly
what was necessary, but Jer (Newman, that is) is very good
at tweaking that stuff, so if others have
better ideas, fire away.
Of course, Jer has a mile high pile of
*other* things he has to get done first
Andriy Palamarchuk wondered exactly
what the goal should be for regression testing since there's almost no end to the number of tests
that could be developed. Francois Gouget replied,
# make sure we have the latest stuff..
cd $WINECVS && cvs -z3 up -dP && configure $CONFOPTS && make && make install
for app in $TESTAPPS; do
wine $WINEOPTS $app > $app.log &
sleep 360 # starting the app might take some time..
for string in $FAILSTRINGS; do
if [ $(grep -i -c -e "$string" $app.log) != 0 ]; then
# maybe we want a diff against the old log..
if [ "$1" = "-d" ]; then
echo -e "\n\tdiff against old logfile\n" >> $app.log
diff -u $app.log $app.old >> $app.log
cat $app.log | mail -s "wine problems running $app" $MAILTO
cp $app.log $app.old
I think the goals is to have a complete Framework in place for 0.9.0
and to have enough tests to be reasonably confident that we won't need
to change it. For more information on testing, see the link above
to Francois' presentation.
As far as testing goes.. read on..
17 Mar 2002 - 23 Mar 2002
Archive Link: "Automatic Regression Testing"
Paul Millar, Geoffrey Hausheer, Francois Gouget, Geoff Hausheer, , Andriy Palamarchuk
Paul Millar announced:
Only Andriy Palamarchuk replied. He felt sending email to a mailing
list was the appropriate thing to do when something broke.
Geoff Hausheer had some questions about actually using the testing
I've been "toying" with an automatic regression testing system over the
past month or so. The results can be seen at:
Currently its only using the Perl framework, which doesn't test too much
at the moment. Hopefully this will change soon.
Comments gratefully received (and any criticisms too, I guess;)
Francois Gouget replied:
I was considering writing a few regression tests for wine,
and after reading Francois' presentation, I thought
perhaps a File I/O would be a good one to implement
(especially since he mentions CreeateFile). So I began
thinking about how to go about it, which led me to the
Has any thought been given to creating a sandbox for
regression tests? For instance, let's look at creating a
test for File I/O. This requires creating/deleting
files/directries, the ability to locate files, etc.
But I don't see anything in the framework that lets me do
this portably on all systems. In wine, I can't gaurantee
that the test directory (which I could probably write to)
is mapped to a Windows drive. On all platformes, I don't
see how I can write to an arbitrary location on C:, since
it may be unwriteable, and even if it's not, people
probably don't want extraneous wine stuff littered around
their drive when something goes wrong.
I'm now thinking I'll try something more straight-forward
as my first attempt, but this type of test seems like it'd
be very useful, and I don't see how to do it with today's
Francois stressed the importance of keeping tests as simple as possible.
He suggested rather than trying to anticipate what is needed to just
use what's already there and after a few tests have been created check
to see what could be done to simplify them.
Geoff wrote back and wondered how he could actually get the
perl tests to run,
I believe most file tests don't need to write to arbitrary locations
on the C:\ drive. For such tests, the best is probably to change the
current directory to $Temp (should be defined on Windows too) and create
files and directories there.
Some other tests will need a writable c:\ drive... or other. Maybe
tests should check a WINETEST_DRIVE environment variable.
In any case, tests should cleanup after themselves, i.e. call
DeleteFile after they are done with a file, and be able to cope in case
they were abruptly terminated, i.e. not fail if the file already exists,
or Delete it before hand.
I thought the entire point was to make it so you don't need a c-compiler, yet
I can't seem to get the tests to run without the winetest application (which
I've been unable to build on windows so far). Is it planned that this
executable be distributed with wine, or am I missing something else?
Francois explained how to do it right now and what remains to be
Geoff then ran into problems with accessing structures and
constants using perl. So he began rewriting his test in C. Francois
explained how to access that stuff in perl:
Well, that's part of the unfinished items. Currently you have to:
- install Perl on Windows The best seems to be to get Perl from source
and compile it, e.g. with Visual C++.
- get the whole Wine tree to Windows
- tweak programs/winetest/Makefile.win32 to adapt to the directory where
you have perl installed.
Typically just replace
c:\perl\5.6.0\lib\MSWin32-x86\CORE XSUBPPDIR =
c:\perl\5.6.0\lib\ExtUtils with PERLDIR =
c:\perl\5.6.1\lib\MSWin32-x86\CORE XSUBPPDIR =
- run tests manually by invoking programs/winetest/runtests with the
Yes, that's the plan: regularly generate a zip file to put on WineHQ,
so that people can just grab the zip file and run some batch script to
invoke all the tests.
Perl tests aside, I have started working on a perl script that would
generate Makefiles suitable for running the C tests on Windows using
Visual C++. But it's not finished yet and I had to stop working on it
for a while. I
it to this email so that someone can pick it up.
Please let me know if you do.
Geoff went on to
create some tests for memory allocation. He put a lot of comments
in it for anyone who would like to learn from it.
You can get the constants by doing 'use xxx;' where xxx is the name
of the C header that would contain the constants in C. Dor instance:
For structures... there was a perl sample that created a Windows that
was floating around. But I cannot find it anymore. Does anyone know
where it is?
If I remember correctly you are supposed to 'pack' the data so that
its layout matches the C structure (and unpack it to get the data). I am
not certain if there were plans to provide macros to do this.
17 Mar 2002 - 19 Mar 2002
Archive Link: "aRts driver resubmit"
Chris Morgan, Sylvain Petreolle, , Eric Pouech
Chris Morgan submitted an aRts driver to
Wine and noted the following additions:
Eric Pouech had some recommendations for improving, so Chris made
some tweaks to it. Sylvain Petreolle reported:
*dlls/winmm/winearts, arts.c, arts.h, audio.c, winearts.drv.spec, Makefile.in:
Chris Morgan <cmorgan>
Added aRts driver to wine
*configure, configure.ac, dlls/Makefile.in, include/config.h.in,
Chris Morgan <cmorgan>
Changes for aRts driver, added commented out entry to WinMM section
of sample config file, added configure time checks
for artsc support.
Fixed since the last patch thanks to Erics mail:
- Stream now closed correctly, doh
- Volume code handles mono/stereo 8/16 bit
- Configure stuff is now no longer hardcoded
I used it successfully under :
- Dark Reign The Future of War 1.0
- Monster Truck Madness
- Quake III Arena
20 Mar 2002 - 21 Mar 2002
Archive Link: "Re: The X11 fork"
Topics: X11 Tree
Ove Kaaven, Sean Farley, Roland, , TransGaming, CodeWeavers, Ove Kåven, Uwe Bonnes
Ove Kåven felt some discussion on wine-devel was going astray
Uwe Bonnes suggested sending all patches to wine-patches for now with
the explicit message that patch could be licensed under both the LGPL
and the X11 licenses. Sean Farley suggested the names "Aroma" and "Bouquet"
for the new project -
Allright people, maybe we need to get something going... Very few of the
questions I initially asked in this thread have really been answered. I
did *not* ask whether to stay with X11 or lock out the LGPL fork, how to
capture mindshare, or whether the X11 fork can be justified, yet that
seems to be pretty much all that has really been discussed here. If
necessary, all of that can be addressed later. The important thing now is
to get the fork started, not what to do with it. So, back to my original
- What do we call the fork.
Nothing too new on this front. There's still disagreement between people
that want a Wine-derived name ("OpenWine") and people that want a name
without Wine in it ("Theleme"). Unless someone gives us further input,
then Eric and I will just decide on whatever.
- Where do we host it.
Suggested options include SourceForge, WineHQ (if CodeWeavers and
Alexandre gives permission), TransGaming, and the Apache Group. But it's
also just been suggested to put the project on bkbits.net, and manage the
project tree using BitKeeper rather than CVS. This actually seems like a
pretty good idea to me. And if it's good enough for Linus...
- Who is in charge.
Gerard has been the only person with real input here, suggesting Eric and
me. That's OK, as long as it's democratic (nobody seems to have voted
- Who's in.
We'll compile the full list of who have been willing to license their
submissions under the X11 once the fork is up and running.
Two sets of smells from "Open"ing a bottle of wine. Sean also
felt sticking with CVS would be easiest for now since that's what everyone
knows. Ove noted that for those just learning BitKeeper there are a lot
of comparable commands to ease the learning curve.
Roland felt sticking with a name containing "Wine" was a good idea:
As far as where to host it, he added,
I think we should use a Wine derived name. Why is that? Because a lot of
people already know WINE. If we use a name like "Theleme" people will call
it: "Ohh, thats another version of WINE." So the WINE-name has already
"stuck". I already saw this happening one time in real life. At the
university people changed the name of a little newspaper made by students.
The funny thing is everyone continued to call it by its old name, so they
went back to the original name. It is not wise to change the name of a
product if it has already "stuck" with a great part of users/developers. So
IMHO we should have a Wine derived name.
- OpenWine is no good choice because both forks are open source, so it
doesn't bring distinction.
- My suggestion is the name "FreeWine" to make a real distinction, since
our license gives more freedom than the LGPL this name makes sense. Besides
it also has a very positive conotation. Imagine a software review comparing
WINE & FreeWine. Which name would attract more sympathie?
- The name isn't that important, lets focus on getting a working product.
Call it "XYZ" if you want...
I personally feel that the US has pretty restrictive law in a lot of
software related cases, like the DMCA, etc... I also fear lawsuits from M$
if Wine ever becomes a real danger. Thus I would feel better if WINE was
hosted on some server outside the US in a country where there is low
probability of legal trouble. Look at the Bnetd project, it hat to be shut
down because of pressure by Blizzard. My favourite would be China, I think
it is possibly the country where Microsoft and the US-law have less
influence. What do you think?
BSD PE Loader
16 Mar 2002 - 17 Mar 2002
Archive Link: "PE loader integrated into BSD"
Dan Kegel, Steve Langasek, Alexandre Julliard,
Dan Kegel mentioned,
Steve Langasek pointed out,
At Wineconf tonight, people were talking about
whether integrating bits of wine into the kernel
was useful, and how much should be moved in.
(Hello task ornaments!) Anyway, I mentioned that
somebody had integrated a PE loader into BSD. Here's the page:
I think this is pretty darn cool, and hope somebody
does something similar for Linux.
On Linux, support for 'foreign' binary types has been generalized using
the binfmt_misc interface which is controllable at runtime through /proc.
Debian goes so far as to provide a package called 'binfmt-support' which
automates setup of additional userland executable loaders. It actually
works quite well with Wine, in fact.
Steve added that Wine was heading towards being
set of shared libraries plus a PE loader
Dan wondered just how far along Wine was though. Alexandre said,
Wine will still need to load ntdll because that's
where the PE loader is. And you can't really separate the PE loader
from the rest of ntdll since it needs to interface with memory
management etc. You could write a separate PE loader but then it
couldn't be used to load real Window apps.
Sharon And Joy