wineconf summary

[michael cardenas]

Here's my wineconf summary. It's not much of a summary, since it's so damn 
long. I wanted to record as much as possible for the developers that weren't 
there because I think a lot of ideas and direction was generated and should 
be shared among the community. 

I put in <> brackets in areas where I need correction, and I am going to 
correct some of those myself.

Andi, I'd like to put this on winehq somewhere with the presentation files 
hyperlinked from the same page. Once I get all the presentations, I'll 
provide you with them. Once it's ready, maybe we can submit it to slashdot 
for everybody who couldn't be there. 

I really want to thank all of you for your participation. I not only learned 
a lot, I also had a really great time meeting and getting to know all of you. 
And I think that next time, Andi should buy the beer. 










-------------- next part --------------

Wineconf 2002 - by michael cardenas
-----------------------------------
 
In Alexandre Julliard's keynote speech, the most recent event on the Wine timeline was WineConf2002, makring 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 greatful they were to have been brought together and to have been recognized, but I was just as greatful 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 everynoe in the room didn't already know about. He went through the history of wine, beginning with a binary loader written by <author> and <author>. He also showed the initial versioning scheme, since the currnet 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. Bob le Quay from OsoComm asked Julliard to explain what the problem is exactly. 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 Dimitry O. Paun, Patrick 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 contine to work on this. 

Window management was discussed and the conclusion was that Mike McCormack, Alexandre, and Ulrich Weigland 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, Patrick, Dimitry, and Steven ,last name> 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. Dimitry 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. dimitry 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, <name> asked wether 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 <last name> 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 Corle 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. Transgamign 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 <last name> of Macadamian asked how difficult it would be to be able to use gdb. He said that the effort involved would be worth it becasuse 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. Dimitry 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, Dimitry 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 <last name> . 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. Sicne ReactOS is based on the NT architecture, it has a hardware abstraction layer, which makes it very portable. It also hads 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 Dimitry, 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 Patrick 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 Patrick'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 hda been too ambitious. He mentioned that the method of comparing screenshots had been trie 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 soruce tree. Running the tests on windows is not ready yet, they can be run, but they most be run individually. <name> Asked if the test framework is thread safe yet, and Francois said it is not. Francois <last name> 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, Patrick 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 Le Quay 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 sensical test case. I later spoke to Bob, Patrick 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 thier 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 <last name, spelling> 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 Kaaven and Gavriel State and discussed DirectX and Wine. Gavriel discussed detailed info on how directX functions in wine with openGL, including pseudocode. 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. Patrick 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 Kaaven 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 wht 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 soruce 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. 

Steven <last name> asked about licensing and Michael said that LindowsOS will be licensed per person, per machine. Dan Kegel asked if Windows apps from a user's machine are available once Lindows is installed, and Michael said yes. Hetz Ben Amo <spelling> 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 looking 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. Dimitry 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 managemtn 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 <last name> 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 umfamiliar. James himself described the functionality as "black magic". 

The final presentation of the conference was Huw Davie's 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 <couldn't hear the name> 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. Gavrial also suggested that the Corel tree has lots of code for handling PostScript fonts and that Huw should look into it. Ulrich Weigland 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. 

Dimitry 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. Dimitry, 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 Czellka 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 unfortnately 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 2002.