Wine Traffic Brian Vincent

This is the 315th issue of the Wine Weekly News publication. Its main goal is to upgrade. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
News CodeWeavers James Hawkins Slashdot Juan Lang Mikolaj Zalewski Kai Blin News Marcus Meissner Mike Hearn Ulrich Czekalla Eric Pouech

The big news this week once again focuses on Google. They've selected 630 project for their Summer of Code program. Wine was mentioned on internetnews.com for receiving 7 projects. If you head over to Google's site, you'll see there's actually 6 and you can see what those projects are:

  • Implementing Wine Oleview application (more info)
    • by Piotr Caban, mentored by James Hawkins
  • Improve riched20 (more info)
    • by Matthew Finnicum, mentored by Mike Hearn
  • Clam AntiVirus integration in Wine (more info)
    • by Christoph Probst, mentored by Marcus Meissner
  • Improve mswsock.dll (more info)
    • by tukasz Chrost, mentored by Eric Pouech
  • Shell integration (covered below)
    • by Mikolaj Zalewski, mentored by Ulrich Czekalla
  • NTLM signing/sealing using GENSEC (more info
    • by Kai Blin, mentored by Juan Lang

So there ya have it. Those info links mostly go to the Wine Wiki where most of the students have posted info about what they're working on.

The Google Picasa port made worldwide headlines last week. There were a few naysayers complaining about Wine being buggy, Wine sucking, blah, blah. For the most part, users were quite happy Google decided to bring their application to Linux, even if it meant using Wine. The fact that Google supported the Wine project by hiring developers at CodeWeavers and contributed patches back to Wine wasn't overlooked in the least. Most major news stories picked up on that. The local St. Paul, Minnesota newspaper also picked up the story and wrote an article about CodeWeavers and their work for Google. By far the best editorial I read on the subject was written by Brian Proffitt of Linux Today.

I found a nice blog showing screenshots of Picasa. It looks, well, like Picasa. You'll notice the integration with the taskbar menu. Jeremy White of CodeWeavers replied on Slashdot about the port:

the Picasa for Linux product is far more tailored for Linux than that [ed note: the native Windows version] would be; it doesn't give you drive letters, it knows how to integrate into your file system, it knows how to connect to your desktop environment; it has a whole raft of other Linux specific features. I think it's even reasonable to hope that as it matures, it will become even more fully tailored to Linux.

But the bottom line is simple - try it. You may be surprised at how handy it is. And today you have one more application on Linux than you had yesterday. I'm not sure how anyone can be upset by that.

Finally, last week I alluded that Google Earth would be coming to Linux. I assumed that involved another Wine effort. Apparently I may have been mistaken since a post on LWN.net alluded to the fact that it may not be Wine based.

Multimedia Darwine

Over the past week there's been some exciting developments for Wine on MacOS. First, a new audio driver was committed based on work by Emmanuel Maillard and Ken Thomases. The new CoreAudio code lives in dlls/winmm/winecoreaudio and seems based on the JACK audio driver. The patch was quite large and Alexandre asked that it be broken into a couple of different chunks. Shortly after that was done the code was committed.

Then a few days ago Emmanuel mentioned he had taken up work on the Quartz display driver for Wine. We've discussed that topic in the past. It seems X apps on MacOS X aren't integrated very well into the desktop and a native Quartz driver would be much better suited for using Wine on MacOS. Emmanuel wrote:

Quartz driver is up to date on Darwine CVS.

Winemine is playable on both PPC and x86 but it looks fine only on PPC, the x86 driver suffer strange rendering bugs.

See wiki for building the driver: http://wiki.opendarwin.org/index.php/Darwine:quartzdrv

I will update wiki soon with issues and todo for Quartz driver.

Emmanuel also provided a screenshot of winemine running.

Project Management Dan Kegel

Dan Kegel wanted to know what needed to be done for Wine to hit 1.0. Up until we hit beta status we maintained a nice list of everything we wanted to get done. For the most part we completed everything. Now it's time to think about the path toward a release. Alexandre has said in the past he's getting pickier about the patches going in. The new release cycle helps provide a finer grained testing point for regressions. Overall though, what should we be getting done? Dan provided a link to Bugzilla showing bugs currently slated to be fixed before 1.0. Raphael Junqueira had some ideas:

But i think we must fix users most hated bugs as:

  • dsound deadlocks/craps
  • openGL problems (multi contexts, fb/visual configs)
  • lotus problems

Note: it would be interesting to add user votes to wine-bugs (ala kde) to better see user needs.

Mike Hearn thought window management was a big issue, IMHO we should really nail the window management problems. The WM rewrite was supposed to fix our woes with unmanaged windows and fullscreening for ever but it hasn't happened yet.

Along those lines, Dan felt the OpenGL child window bug, #2398, was critical but wasn't sure it would get fixed. Over the past week or so there's been renewed interest in getting that bug fixed, but apparently no one capable of fixing it has time right now. Discussion of that bug consumed a lot of the rest of the thread.

In the end, Dan provided a list of things he'd like to see fixed. It included getting Windows developers to take Wine seriously by getting IDE's and debuggers working well. He also listed some broken installers that needed to get working.

In general, it there didn't seem to be much of a consensus on what tasks were needed for 1.0. Discussion has occurred off and on about a DIB engine, but it seemed to be generally acknowledged that task wasn't necessary for 1.0. Lastly, although Alexandre didn't weigh in on the discussion, he does maintain a list of things he wants to get working.

Project Management Michael Stefaniuc Microsoft Tony Lambregts cvs

Along similar lines as Wine 1.0, Mike Hearn sent an email to gather feedback about how we're doing as a project:

As the Summer Of Code begins and new blood joins us all at once, I thought it'd be a good time to open a discussion on how we are doing as a project.

Questions to consider:

  • Is Wine improving or is the regression rate matching the improvement rate?
  • Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
  • Are we turning away potential developers for any reason? Could we do more to attract new hackers?
  • Are the projects fundamental processes serving us well?
  • Any other thoughts for improvement?

In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase.

>From my own perspective I think Wine is doing better than ever before. What prompted this email is the realisation that in the past few days I've used Wine nearly every day to run a variety of apps - from games to utilities - and it's succeeded with every single one. Not always perfect but always good enough. I am no longer surprised when Wine runs an app correctly as I was when I first came to the project, these days I nearly take it for granted. Though this may be due to having developed a feel for what will work and what won't :)

So clearly we're doing something right ... I also think we are doing OK with attracting and keeping new hackers. The influx of new Direct3D talent lately is fabulous for instance. The experiences of our SoC students will be useful in assessing how to improve the learning curve and we need to tap this resource better than we did last year.

In other words, I think we're doing pretty well. I feel more positive about the project that I have done for a long time. It seems like as Win32 stagnated and slowed down over the past 6 years we've been able to turn the tide and add our own code faster than Microsoft can, which is the tipping point.

So areas for improvement?

  • We seem to be doing very well in recruiting hackers who work on one particular DLL or area and solidly improve that, but a less well when it comes to 'general purpose' hackers who just take random apps and make them work.

    It might just be that I'm out of touch but I don't see as much patch traffic these days along the lines of "This patch set fixes XYZ app" followed by 6 patches to 6 different DLLs.
  • No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :(
  • Integration with other projects is still a weak area. Desktop/kernel/X integration could all use some work. I know I know, I'm guilty in not doing my bit here too .... maybe I will find my hack-fu returning sometime soon and work on the fullscreen patch again :)
  • App specific patches. Well I don't expect policy here to change anytime soon but extreme cases like the WoW VMA layout problem which affects tons of users do highlight the issue.
  • A few random things I already got into arguments about (forums, libwine api etc) :)

What do you guys think?

This thread brought forth a lot more comments than the discussion about Wine 1.0. Raphael Junqueira responded with some general comments about a few of those areas:

Well, winecfg need more improvements to be really usable (ie. understandable) by a non-technical end user. We need to improve the Wine base installation: users should not have to always use winecfg to configure wine; many things must be detected at installation/runtime.

We must work on (free/gnome/kde) desktop integration too.

For developers, i think we miss (in wiki):

  • Wine developer beginning HowTo
  • Wine committing process (explaining why AJ never respond when patches are refused :p )
  • simili-doxygen APIs (to find what is implemented/how/where some docs, and status)

From the there discussion branched out into what we could be doing to better help developers. There's an evil misconception that pops up from time to time that Wine developers are rude and not easy to get along with. The reality is, most of the rude comments on wine-devel come from folks who aren't developers but happen to be subscribed to the list. There was some discussion about that, but no concrete plan to tackle it.

One interesting turn the discussion took involved how developers seem to be treated differently. If you're familiar at all with Linux kernel development, you know that Linus requires a lot of patches to be filtered through other "maintainers" before getting to him. Wine's not big enough to necessitate procedures like that, but it does seem some developers can get away with submitting much larger patches than others. Alexandre explained part of the process he goes through for committing patches:

There's no such thing as special developer vs. other developer, it's more like a linear scale based on trust: the more I trust a developer the easiest it is for him to get his patches committed. The only way to earn trust points is by submitting consistently good patches.

That doesn't mean you can't get stuff in if you aren't trusted, but it means it will require extra scrutiny, which is why it's very important at the beginning to send small patches that are easy to review. Once you have earned enough trust you can get away with being a bit more sloppy (but not too much, or you'll lose trust points again ;-)

There was an idea of developing a metric to measure how long it takes from the time a patch is submitted until it's committed. Alexandre thought one way of doing it would be, The commit logs contain the time of the change and the time of the commit, so you could use that to build a top-10 of the developers with the best patch-to-commit times ;-) Michael Stefaniuc pointed out there might be a problem with doing that since the time of the change could be a lot older than the time the developer submitted the patch. Mike Hearn confirmed even developers with a good track record get patches rejected:

Heh :) Bear in mind that it depends a lot on the patch and what kind of work you're doing. Getting some clearly correct typo fixes in for an obscure DLL is going to be a lot easier even for 'untrusted' developers than, say, implementing SetThreadPriority which touches the core of Wine in a sensitive area and is somewhat controversial.

There's no special privilege for CW employees or SoC students, though we appreciate it may look that way at first glance. I'm a CW employee on and off (more off than on lately due to university) and I get patches rejected all the time <chuckle> :)

The end of thread centered on commenting code. Wine is known for not being heavily commented and there's a few reasons for that. Some of the long-term developers seem to have an aversion to comments because they think the code itself should explain what's going on. Others think there's no need to comment what the code does since MSDN often explains the necessary details. Another argument is that there's no way to define "good" comments versus "poor" ones.

However, over and over and over again we saw comments from people interested in getting involved with Wine development state how difficult it is to understand some of the intricacies of what a piece of code does. Jeremy White succinctly summarized what people really wanted to see commented, I think David hit the nail on the head. I don't need a comment to tell me what the code is doing, I agree that the code itself is more clear. I need a comment to tell me why the @#$ you decided to do that.

Jeremy also mentioned he'd never seen Alexandre strip a comment out or reject a patch because of the comments. Someone suggested comments should be added when a particular bug is fixed and Alexandre explained the context of how that could be done:

I'm not opposed to having bug number in the comments, but it has to be in addition to a proper explanation; the log must be understandable on its own without making reference to an external database.

Finally, here's some random comments culled from the rest of the thread. First, from James Hawkins:

A bigger issue is how we should deal with regressions. Most of the bug reports we get are of the type, "This app used to work, now it doesn't..." and we have to ask the reporter to run a regression test. I know these tests are crucial, but they take a long time and many users don't bother going through that process. Even more integration with the AppDB might help with this process. Ideally we would like to inform the user of a "Last known working release", which would be the Wine release that worked with this app. Looking at a sample AppDB entry, I guess this would be the Testing Results->Wine Version->Runs? field. If the 'regression' keyword is provided for a bug, and the bug is linked with an app in the AppDB, we could provide the "Last known working release" info to the tester, so they know where to start testing.

Kai Blin:

The effort to figure out how to do the patches correctly is pretty high, and you need a lot of frustration tolerance at first. I'm not sure if I would have stayed around if it wasn't for Summer of Code 2005. Once you get past this, and figured out how to write your code so Alexandre will commit it, development is quite fun. I also agree that the whole process improves code quality. It still is hard in to get started. Unfortunately I don't really know how this can be changed.

I think that the effort by some of the more experienced coders to provide feedback to patches already helps a lot.

Detlef Riekenberg:

It was very hard to get my first patch accepted: I needed to learn, how Windows works in this area, how CVS works and what was expected from a fine patch. I read a lot of Documentation (wine-dev-guide, wine-wiki.org, winehq.org, MSDN and the Wine-source), got a lot of hints on wine-devel and finally my first patch was accepted. (Great to be a member of such a large project.)

EnumMonitors (Test + Implementation) needed a long Time:

  • I created, tested and sent a patch
  • No commit, and no comments for my patch for almost two weeks
  • I asked for comments and got one hint from one person.
  • Updating, testing and resending the Patch
  • next week waiting again without a reaction.
  • Asking for comments; one hint from a different person
  • loop again > 5 times
    • I was frustrated that it needed so many loops from the first patch for the tests up to the commit of the last patch for the implementation due to the fact, that I got only one hint after every Update. One hint was changing NO_ERROR to ERROR_SUCCESS. Another example was to split the ANSI-Implementation and the UNICODE-Implementation (together ~11kb) into two Patches.

    Misc comment:

    The AppDB is a great idea, but why is it so poorly integrated in the main page? The same question goes to the Bugtracker and the Wiki where the situation is even worse. On most web pages you have a navigation bar which remains the same as long as you are on the same page. But if you enter the AppDB or the Bugtracker you have the feeling that you are on an entirely new page which only have a link back to the main page and a similar design. If you enter one of the wiki pages the situation is even worse because it does not even have a link to the main page in the navigation bar. Is this a design decision or is it just the lack of time which prevents IMHO proper integration?

    (The short answer is: yes. Tony Lambregts mentioned it was something he'd thought of doing for a while but other things were a higher priority.)

    So how are we doing? Well, overall it seems we're probably not doing too bad. There seems to be pretty good communication and the tools used for development (git, cvs, etc) seem to working for everyone. The biggest conclusion that could be drawn is there's a learning curve for coming up to speed with development. Perhaps some documentation could help with that, but you still need to take time to figure out the code.

    Fixes

    If you read the World of Warcraft AppDB entry, you'll notice it's a very nicely maintained app. It describes exactly how to get the game working with Wine. You'll also notice the instructions are a complete pain in the ass because they involve applying a custom patch to Wine. Nick Law brought it up on wine-devel last week:

    Opening up the debate again on the World of Warcraft ( WoW ) memory patch.

    Some facts about WoW that may explain why the AppDB page is pretty active and the wow patch for wine 0.9.12 was downloaded over 1000 times from the Appdb page during a 4 week period.... Wow has approximately 6 million players that each pay about $90/year for the priviledge of connecting to a WoW server (Realm). Assuming this figure is broadly correct, Blizzard therefore receives $500,000,000/year just from this game in subscriptions. ( This doesn't include the cost of buying the game in the first place ). Perhaps Blizzard would like to employee a programmer fulltime just to work on the wine project to help make Wow run 100% ?.

    Anyway with the popularity of this game in mind, you can see why there is a lot of interest in making this patch a thing of the past, so the thousands of gamers who play this game on wine don't have to keep applying a special patch. I would be grateful for any suggestions as to how we could incorporate this patch so that it is no longer necessary. I know we can't simply include the patch, but there must be some way around this problem ?

    Well, the problem at hand is actually a problem with WoW - it's broken, perhaps intentionally, with regard to how it handles memory addressing. In fact, it's sort of a fluke it works in Windows right now and there's a good chance it won't when Vista comes out in a few months. There's a strong policy within Wine to not accept any patches that are application specific and instead try as much as possible to have bug-for-bug compatibility with Windows. (Other Wine-based products, such as CrossOver Office, don't necessarily follow that policy and as a result you'll often find subtle things that work better.) Mike Hearn replied about the problem:

    This has been discussed previously. It looks likely that to fix this so WoW works out of the box requires extensive and intricate changes to the core of either Wine or the kernel to provide a more accurate match to the NT memory layout model.

    I rate the chances of this happening anytime soon as being low. It's not that people don't care, it's more that there are no developers with the time/motivation/skill hanging around who want to work on it, it seems.

    It'd be better to get the bug in WoW fixed, whatever that is. I do not know how you might contact Blizzard.

    Alternatively there could be (should be!) pre-built versions of Wine that run for all users customized for WoW specifically.

    It was then mentioned that Cedega works around the bug with a similar memory layout hack. Oddly enough, the fact this problem snuck in during a version upgrade shows that WoW doesn't depend on it to function and was probably just a bug that crept in. Tim Kosse replied with some info regarding contacting developers at Blizzard about the issue.

    Build Process WineHQ

    Currently the Wine packages on WineHQ for Fedora are quite out of date. In the news announcements I've mentioned that a newer version is available via Fedora Extras. Apparently this repository is being updated as newer versions become available. Neal Gompa explained:

    I have noticed that since my post about how Fedora packages are inaccessible, you have added the string "Currently official Fedora packages lag behind, but you can get Wine-0.9.10 by running yum install wine from Fedora Extras." Well, that is not totally correct. Usually about a week after Wine Project releases a version, Fedora Extras updates to the newest version! Currently, it is at Wine-0.9.13. I believe it will be a week before Fedora Extras releases Wine-0.9.14 packages... I will reply when Wine packages are updated you that an accurate guage is made of the lag...

    Note: For Wine-0.9.13, and it only took 3 days after Wine official release to release it on Fedora Extras. It is a good idea to assume anywhere from 3-5 days for Wine to be updated in Fedora Extras.

    The links below are to the webview of Fedora Extras:

    Repositories for i386

    Repositories for x86_64

    Note that it is viewing the alphabet group of "W". Scroll down a bit and you will see Wine packages. Please keep download form updated, you make people believe that Wine is not being updated by Fedora Extras, when in fact it is...

    Integration Microsoft

    Mikolaj Zalewski's Summer of Code project will be improving Wine's integration with the Linux desktop. He wrote to wine-devel asking for tips on it:

    As a SoC project I'll try to improve the integration of wine with the Unix shells. My first step will be to implement the freedesktop.org Trash. I've written some code that doesn't add any new features but shows how I want to add it. I'd like to know if this is a good design?

    The main idea is not to hard-code one implementation of things like the Trash into shell32 - not everything is standardized by the freedesktop and even if it would this might not work on other systems like MacOS X. We should allow for many implementations. The correct one is loaded depending on a registry settings (so that a winecfg entry can be added). My implementation uses COM objects as it's standard dlls provides support for such tasks. Currently there is one interface (IWineShellIntegration) that acts as a factory for specialized objects. That could also be implemented using COM Aggregation - when we do that we could use QueryInterface instead of GetIntegrationObejct.

    Some COM objects can run in the address space of the calling process - e.g. the trash can be implemented like that. For others it would be a waist of resources (e.g. there is no need for every process to watch is the file associations have changed) - it's enough to load them only once. The explorer seems to be a good candidate to create such objects. In the attached patch there is one specialized interface - the IWineTrash. The SHELL_DeleteFile[AW] is patched to use it - it shows a different icon if the file can be trashed (these are not the correct icons as wine's shell32 uses a message box instead of a special dialog) and calls the trash method then. Currently there is only one built-in trash that can't trash anything. (note that SHELL_DeleteFile is called in the folders that are decendents of My Computer. If choose delete on a file that is a decendent of the '/', it will be deleted without a warning).

    Ulrich Czekalla replied first:

    I think the general approach is good.

    The way you handle the built in implementation seems odd to me. I think setting the registry key to make the freedesktop.org version as the default would be good enough.

    I'm not convinced we need IWineShellIntegration. I think it would be cleaner to directly create an IWineTrash object.

    Regarding the last point, Mikolaj explained the reasoning behind it:

    If we integrate more closely with the desktop environments we may need to have one central object that will know that e.g. KDE 3.4 uses the freedesktop.org Trash but KDE 3.3 has it's own Trash implementation. If we read the Trash CLSID from the registry such an implementation would require creating proxy classes or hacks in the class factory. Also by storing only one CLSID we don't have a problem which implementation to use if a new kind of objects is introduced.

    Of course when we use COM aggregation instead of a factory pattern we will have all the interfaces visible under one CLSID so we will be able to construct a IWineTrash directly with the main object hidden behind the scene.

    Alexandre wasn't convinced a COM-based approach was necessary, I think using COM for that sort of thing is overkill. Besides, you most likely want to put all of that in the explorer process, and communicate with shell32 using the same protocol that Microsoft is using, like we do already for the system tray.

    There was a little more discussion about using COM and it seems like in the end the idea was abandoned in favor of simpler mechanism.

    WineHQ WineHQ Jeremy Newman cvs

    A few months ago Dan Schwarz mentioned he created an RSS feed for WineHQ:

    I've long wondered why winehq.com does not provide an RSS feed. I've created one using the feed43.com sitescraping tool. Works well and it should be very low impact to your webserver (it only hits the URL at most once every 6 hours and caches the result for subsequent queries)

    Feel free to post this RSS link on the winehq homepage.

    http://feed43.com/winehq.xml

    It would be nice if Wine had it's own RSS feed produced from the individual news files. It probably wouldn't be too difficult and Jeremy Newman probably wouldn't mind adding such a script to produce it to the webserver. In the mean time, Dan's seems to be working pretty well.