Wine Traffic Brian Vincent

This is the 279th issue of the Wine Weekly News publication. Its main goal is to trench. 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 News

There's a great article over on Advogato about Financing Volunteer Free Software Projects. Wine happens to be mentioned, but it isn't the focus of the article. For anyone involved with a large free software project, especially one where some development gets paid for, it has lot of really good points. It discusses some of the dangers of infusing paid development into a project and gives some ideas for how to manage that process. A few years ago Wine seemed to be heading toward some of the pitfalls mentioned, but changing Wine's license from BSD-style to LGPL may have prevented that. The number of patches steadily increased after switching to LGPL (after descreasing previous to that.) Now we're seeing between 4x and 5x as many as we did in late 2001 and early 2002. The effect of licensing could easily fill its own article, but it isn't mentioned in this one.

Configuration Juan Lang

Yesterday a two-line CVS commit message to winecfg signaled a major shift for Wine:

Fixed registry paths to edit the real config, and removed the startup warning message.

Alexandre has spent the week focusing on Wine's configuration and some major changes have happened. The commit above allows the winecfg program to actually edit the registry. That's right, after about two years of sporadic development, winecfg is seeing the light of day. It's not a particularly large program, nor does it configure every possible setting in Wine. However it does provide a nice front end. For everything else you can use Wine's regedit. In fact, regedit will now write to the Wine branch of the registry as well.

You might be wondering about the config file though. Well, we're in an odd situation where the config code is still in place. If you make changes in the config file they may be reflected in the registry. However, if you make changes in the registry they definitely won't be reflected in the config file. Changes to the config file may or may not actually get reflected by the app running. This is sort of the warning to make sure you're ready for the config file to go away.

Along similar lines, Alexandre is moving registry keys. Currently you'll find Wine's settings in HKLM,Software->Wine->Wine and things are moving to just HKLM,Software->Wine or into HKEY_USER,username->Wine. There's likely to be some growing pains as a result of all this. Just as I was finishing this issue, Juan Lang pointed out that currently the Windows version could only be set in the config file.

Documentation

As we noted above, it looks like the June 30th date of ditching the config file is pretty realistic. There's a few obstacles in the path and Alexandre spent some time tackling them. First, he moved some of the registry keys to other locations in the registry. Then he went through and got rid of some old options that were fairly useless. One of the big issues that people have voiced is that the registry is not a self-documenting entity. That's long been a problem on Windows as well and there's no way to document within the registry what each of the keys and values do. The existing config file contains comments describing each option, so switching all the config options into the registry has the potential to lose information. To work around that, Alexandre began going through and adding comments to the code like:

+ /* @@ Wine registry key: HKCU\Software\Wine\DirectSound */

In that instance, the DirectSound keys don't have any options in the winecfg program, so this comment in the code is about the easiest way to find all of the keys related to it. It's easily grep'able, so keys will turn up easily. One problem with it is the values and their data are left undocumented. Dimi and Alexandre had a discussion about it this week. Dimi wondered why a configuration change seemed different than the others, Hmm, these don't seem to have the magic comments, is this intentional?

That's when Alexandre described the process, They do, the magic comment is on the RegOpenKey above. I'm only adding comments for registry keys, not for every possible value under them.

Dimi thought the values were important as well, but Alexandre felt it was a separate documentation matter, The goal of the comments is to allow to find the relevant pieces of code; once you get there it's fairly easy to determine the values being used. Detailed information about the values and their contents should go in the documentation, the comments are only here to make it easier to check that the documentation is up to date.

After thinking about it, Dimi thought similar magic comments could be added for values as well, Yeah, agreed. But it would be so much easier to keep the docs up-to-date if we can simply grep for the values. I'm not suggesting that you do the work, but if you think we can mark them somehow for easy grepping, we can add it as a Janitorial task.

Alexandre didn't think that was realistic though, It's not the extra work, it's that I'm not convinced we want to add a lot of noise in the source for that. I don't think we can realistically hope to build the documentation only by grepping, we need to check the source anyway.

Dimi thought it would be worth trying though:

Well, it's not a matter of building the docs only by grepping, that wouldn't be feasible. But _checking_ if anything has been added or deleted can be done easily. And that would be the important trigger for someone to go in and update the documentation.

Remember that I've tried already to document all the options (we even have a web page for it at http://winehq.org/site/status_options) but it was close to impossible to keep it up-to-date. Just knowing if anything changed would really be invaluable.

As for adding much noise, if we have that many options, we have a lot more problems than the 1-line comments for each of them :)

Alexandre didn't think it was fool-proof enough, Yes, but it doesn't really help if the comments are not up to date. I'd prefer to make sure it's dead easy to update the doc directly rather than ask people to maintain comments and then have to come back and sync with the doc. That may mean putting the doc directly in the source, or having a wiki page than everybody can update, I don't know; but I think we should be able to find a better mechanism than these magic comments.

It was sort of left there. There was no clear method would be self-documenting and for now we'll rely on Wine's docs to provide the user-facing information on configuration options.

WineHQ WineHQ

Last week we posted a to-do list for the AppDB (see WWN #278). The to-do list was out of date about as soon as we published it. The AppDB guys got together and put together a really nice list with a lot of projects people could tackle. One of the topics that came up was searching. Chris Morgan added the ability last week to do 'fuzzy' searching to improve the matches. Someone then had a great idea for searching and posted it to Bugzilla and Chris came up with a patch to implement it:

Improve search results by seeing if any of the search words match a vendor name or a vendor url. If so we should return all of the vendors applications in our search results.

After implementing it Chris realized it was one of those obvious changes that just needed someone to think of it. For example, a lot of people might just stick in the keyword "Borland" and before this change it wouldn't turn up anything.

For a complete update on the AppDB to-do list, head over to the wiki and look at http://wiki.winehq.org/AppdbInfo.

DirectX Rob Shearman

Last week (WWN issue #278) we mentioned a patch submitted by Christian Costa that statically links FFMpeg. No one really liked the fact it has to be statically linked, but apparently the ffmpeg developers require it because of version problems. Alexandre asked for the library to be dlopen'ed and Christian explained:

Well, it was meant to link with the static library only however I admit my configure check is not that good. The FFMpeg build the static lib by default and it's not likely you find a shared version lying somewhere when building Wine.

Marcus Meissner wondered if separate DLL's could be build to access FFMpeg and then dropped in to provide the functionality. It would sort of turn it into more of a packaging issue:

What I think of is putting all codecs that can benefit from libavcodec into a wine-quartz-avcoded.rpm which contains one (1) q_avcodec.dll which can register all these filters.

So just 1 add-on RPM to install additionaly.

Since this can be provided by external contributors a distributor would not have to worry about libavcoded related problems.

Rob Shearman explained a problem with that:

At the moment, most of the filters depend on a set of files that are implementation of base types like pins and media format enumerators. I think the long term goal is to move these into a libwinestrmbase, but at the moment it is not easy to take a filter from quartz and put it into another dll / library.

Ideally, I don't think we want to link to libavcodec at all. We should import code for as many filters as native implements, without stepping on patented territory. That way, apps that specifically ask for CLSID_CMpegAudioCodec, for example, will get exactly what they want.

Christian explained that importing FFMpeg code would make Wine's build dependencies more complicated:

How would you benefit from an ffmpeg update in a seamless manner?

Note that some months ago, I did a version of the wrapper that directly uses source files in the makefile but I realized that taking benefit of acceleration (i386, mmx, sse, etc...) would require merging a lot of things from ffmpeg build to Wine's one. No to mention that I was not sure that ffmpeg sources would be accepted again in Wine tree. That's why I switched back to use the library.
Multimedia

Maarten Lankhorst has been hard at work getting MSN Messenger to run. For more details on that effort, see WWN issues #274, #275, and #276. He posted another patch this week that implemented more functionality. Messenger 6.2 is now closer to working with builtin DLL's. Maarten described how to get it running, but it doesn't sound like it's for the faint of heart:

MSN Messenger 6.2 (!!) seems to run fairly well with only builtin dll's, from what I can tell the only real thing missing is CreateTextServices in riched20.dll, SSL support and urlmon's obtainuseragent (or something), webcams will work without any additional native dll now, if my patch for msvfw32 gets committed.

I don't know much about SSL, but currently it works fine by just disabling it. For urlmon's obtainuseragent you should just write a patch so it returns a value, but something like this seems to be enough:

    +WCHAR Agent[] = { 'B', 'r', 'o', 'w', 's', 'e', 'r', 0 };
    +
    /**************************************************************************
    * ObtainUserAgentString (URLMON.@)
    */
    @@ -279,6 +281,10 @@ HRESULT WINAPI ObtainUserAgentString(DWO
        if(dwOption) {              ERR("dwOption: %ld, must be zero\n", dwOption);     }
    +
    +    if (sizeof(Agent)/sizeof(WCHAR) < *cbSize)
    +        *cbSize = sizeof(Agent)/sizeof(WCHAR);
    +    lstrcpynW((WCHAR *)pcszUAOut, Agent, *cbSize);

Disabling SSL can be done by changing a line in dlls/wininet/netconnection.c, but if someone wants to write ssl you should go right ahead:

    void NETCON_init(WININET_NETCONNECTION *connection, BOOL useSSL)
    {
    -    connection->useSSL = useSSL;
    +    connection->useSSL = /*useSSL*/0;

It will not run fully, you have to disable msn today before signing in, and you are required to download the mozilla activeX control.

Standard wine uses windows version win98 for msnmsgr, but I found out that that is 1 of the worst possible choices, it seems that win2k behaves exactly the same for the user, but works a *LOT* faster, personally I prefer to use win20 and builtin unicows (have to override in config), because else smilies appear to be invisible.

What I miss however, is the icon in the system tray, while this works fine under KDE it really *HURTS* not to have it in gnome.

I currently use the following native dll's: msvcp60.dll/RTC{DLL,RES,RTP}.dll

The above 4 aren't really interesting, as they are required by the mozilla activeX control, and not worth implementing. I can't remember wether it was installed by mozilla activeX, but I believe it was.

What is more interesting is that there is now only 1 file needed for msn 6.2 to work builtin (MSN+ works perfectly too): riched20.dll

I'll try playing around a bit with CreateTextServices and see how far I will come, it seems to be tricky, I can't find any useful information about it.

I am not sure about MSN 7.0, but I can tell already that would require a lot more effort.
Utilities

Oliver Stieber wrote in to mention a utility he wrote:

Quite a while ago I mentioned that I had a plugin for KDE so that the correct icons for windows applications (and the icons in dlls) are displayed in the file explorer.

A few people seemed interested so I've put the plugin up on KDE apps.

Oliver also began submitting DirectX 9 changes this week. The initial patches have already made their way into the Wine tree, hopefully preparing for the massive DirectX 9 patches.

Project Management Dimi Paun

I posted the following on Tuesday:

A few weeks ago Ivan asked me about getting him a VMWare Workstation license. I contacted VMWare and they graciously donated 5 licenses to Wine. I thought that was pretty generous of them.

I contacted some people off-list about it, so now Ivan, Jacek, Hannu, and James all have a copy of VMWare. That means we have 1 more license up for grabs. It's open to anyone. However, I'd like to make sure you'll use it. If you don't have a track record of contributing patches to Wine you're not likely to get it. Likewise, if you don't think you'd use it then please don't ask for it just to have it. Having said that, by all means contact me if you think it would help you out. A lot of Wine developers have been using it for a while and it's a useful tool.

Thanks again to VMWare for supporting a free software project!

The extra license went to Dimi Paun. Muchos gracias to all the folks at VMWare.