Wine Traffic #118 For 24 Mar 2002

• Presentation - Regression Testing in Wine
  http://fgouget.free.fr/wineconf2002/presentation/
• Pictures
  http://fgouget.free.fr/wineconf2002/photos/

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:

shell,shell32,shlwapi=n

The issue with black icons is due to something in the native comctl32. If I use additionally:

commctrl,comctl32=n

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 other problems.

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.

Day 1

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
• Documentation

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

The easy ones:

• ddraw
• opengl32
• ws2_32
• wineps

The hard ones:

• ttydrv
• x11drv
• winedos
• user32
• gdi32
• kernel32

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
• Installation
• DirectX
• Printing
• 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 starts wine.

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

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

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

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 attach gdb.

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.

Day 2

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 potential there.

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 Javascript to render its entire interface. Francios of Macadamian also 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.

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

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 in this.

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:

MS Word
Lotus Notes
Quicken"

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

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

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.

-- MR
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'.

• You can see the applications sorted by votes: http://appdb.codeweavers.com/votestats.php
• And the instructions about how to vote are here. You have a total of 3 votes. http://appdb.codeweavers.com/help/?topic=voting

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 votes: [ LINK ]

1. Office (Word, Excel, PowerPoint, Outlook.)
2. Internet Explorer.
3. AOL
4. TuboTax
5. Quicken/QuickBooks
6. Lotus Notes
7. All of the P2P software
8. Juno
9. Act
10. 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.

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.

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)

The specific goal was to clone Lawson 50 times, and have each clone pick up an application. <grin>

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 email flooding.

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

#!/bin/bash

WINECVS="/usr/src/wine/index.html"
CONFOPTS="--prefix=/usr"
WINEOPTS=""
TESTAPPS="app1 app2"
FAILSTRINGS="Unhandled.*exception err:ntdll:RtlpWaitForCriticalSection"
MAILTO="you@yourdomain.com"

# 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
       fi
       cat $app.log | mail -s "wine problems running $app" $MAILTO
       cp $app.log $app.old
       killall wine
      fi
     done;
done;


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.

I've been "toying" with an automatic regression testing system over the past month or so. The results can be seen at:

http://www.astro.gla.ac.uk/users/paulm/WRT/

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;)

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

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

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?

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 PERLDIR = 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 = c:\perl\5.6.1\lib\ExtUtils
• run tests manually by invoking programs/winetest/runtests with the right options.

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 attached it to this email so that someone can pick it up. Please let me know if you do.

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:

use winbase; use winuser;

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.

*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,
dlls/dsound/dsound_main.c, documentation/samples/config:
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
• Cleanups
• 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

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

- 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... Comments?

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

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

1. 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.
2. OpenWine is no good choice because both forks are open source, so it doesn't bring distinction.
3. 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?
4. 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?

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: http://chiharu.hauN.ORG/peace/ 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.

set of shared libraries plus a PE loader

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.