Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #280 For 24 Jun 2005

By Brian Vincent

Table Of Contents


This is the 280th issue of the Wine Weekly News publication. Its main goal is to steal pens off your desk. 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

Mailing List Stats For This Week

We looked at 201 posts in 705K.

There were 81 different contributors. 36 posted more than once. 38 posted last week too.

The top posters of the week were:

1. News: StartCom Linux

18 Jun 2005 - 24 Jun 2005 (1 post) Archive Link: "News"

Topics: News

People: News

Have you ever wished you had a Red Hat based distribution that comes bundled with Wine? StartCom Linux has a MultiMedia Edition that includes Wine. Version 3.0.3 just had an updated version of Wine released and a new version based on StartCom Enterprise 4.0.0 is in the works. They seem to have put some thought into creating a sharp looking and usable desktop system.

2. Binary Registry Ideas

16 Jun 2005 - 21 Jun 2005 (22 posts) Archive Link: "Wine's Registry Format"

Topics: Configuration

People: Francois GougetBrad DeMorrowAlexandre JulliardMartin FuchsJames LiggettShacharEric KohlShachar ShemeshReactOSRob Shearman

Wine's registry implementation has a lot of pros and cons. A big advantage seen by many in the Unix community is the text-based format. Unlike Windows, you can simply open Wine's registry files in your favorite text editor (vim if you're me, or emacs if you're Alexandre). Bug #422 describes one of the drawbacks to this approach:

Currently Wine loads the complete registry into memory at startup. This is relatively ok when the registry is small such as in fake_windows configurations, but when importing the registry fro a Windows partition this can result in the wineserver allocating more than 30MB. This slows down startup times very significantly and wastes memory even if most of it is going to be swapped out.

One of the reasons why Wine puts all the registry into memory on startup is that the current registry file format does not lend itself well to random accesses (especially writes). But there is no fundamental reason why Wine needs to read all the registry on startup. Hence this proposal to:

Brad DeMorrow began a discussion this week about tackling that project:

I've looked into using a Balanced Tree DB from BerkelyDB as a quicker interface to the registry. I think it would be a good solution, but the question is whether or not you want the overhead of another library added to wine. That's why I'm writing here actually - I need to know if it's ok to add this dependancy to wine, or if I should find a different approach.

I know this would cause some chaos in the community - so If this is something that everyone agrees should be done, I'll write a small utility to convert the current ascii registry files into the new format.

Let me know what you think

Alexandre replied first, " Actually the current method is probably the fastest for everything except the initial read. Admittedly it's not very elegant, but it's simple and allows us to store everything in text format. So I'm not at all convinced that using a real database would be worth the trouble."

Brad went into a little more detail and explained more advantages of changing it:

The only reason that the current method is fast is because we're loading the entire registry into memory. As stated in Bugzilla, this is fine for small registries, but the author of the bug has noted wineserver allocated up to 30MB when wine initiates JUST for the registry!

I'm not saying we should abandon the way we edit our registry - because it is very useful to be able to edit it manually with a text editor. . . HOWEVER, I believe we should have a more elegant way that the API accesses the registry. Using a small helper app to sync our plain-text registry files into a db format would let us maintain a human-readable format of our registry, while also reducing the overhead required by the current registry format.

Using BerkeleyDB to access the registry would provide the kind of random-access that we need for such a large amount of information - It would also provide us with a quicker and easier way to search through the registry - so we could finally implement the Find feature in wine's regedit without much effort ( Not that it couldn't be done as is, but things would definitely be easier ).

I'm really not trying to push something that wouldn't help wine if not now, in the near future. A lot of people don't have fast machines with an abundance of memory. 30MB can be a lot of memory for someone with 128MB of RAM.

Several ideas were brought up concerning restructuring the registry, including using XML. Martin Fuchs felt if there was going to be a move to a binary format, then it might be wise to use one that already exists, " The best solution would be to use native Windows registry format. This way you could use real Windows registry files, and can read and update registry piecewise. It's organized like a little file system - or database if you want to see it this way. It's not documented. But you could have a look at the ReactOS implementation, which claimes to be compatible to NT4. "

James Liggett looked into it and reported, " I have the latest release of ReactOS running on QEMU on my box, so I checked it out. Basically, they're using the same regedit program from Wine, missing find command and all (Which I too feel is a pain in the neck). I looked at the config stuff, and I found what looked like some binary database files for each of the main registry sections. Unfortunately, there's no documentation at all on any of this on their website. If we decide to go this route, we may be in for a hell of a lot of work. But, I do agree with all of your points. I think the current system could use some improvement, especially in the area of searching. Let me know what you think of all this."

Shachar Shemesh expanded on the idea of binary compatibility:

How about an application that carries a binary registry hive around, and uses "LoadHive" to merge it (temporarily) into the registry?

How about deploying Wine in such a way that it uses the existing user profile, user.dat and all? User.dat is a registry file, that goes through load hive.

The way I see the ultimate outcome, Wine should have "Registry providers". These would allow it to use several different registry back ends. The default one would probably be the one used today, but this way we could plug in an SQL back end if needed, as well as a Windows compatible one, if needed.

Brad then went in search of ReactOS' Eric Kohl to ask about the ROS registry implementation. That was pretty much the end of the discussion. It wasn't clear if a binary registry was simply a solution in search of a problem, or if there are real performance concerns that need addressing. Alexandre doesn't seem to be in favor of the idea, though some of the ideas regarding separate applications do sound interesting.

While we were on the topic of the registry, I asked if it would just be possible to add support for importing Windows' .reg files. Rob Shearman felt it would be easy enough to do since the only thing really broken with it right now is the fact NT's Unicode format can't be read in (making .reg files from XP useless.)

3. Exposing the Unix Filesystem

20 Jun 2005 - 23 Jun 2005 (8 posts) Archive Link: "winecfg's registry convience functions"

Topics: Filesystems

People: Michael JungMichal JungMike HearnMicrosoftcvs

Michael Jung, who created the new Unix filesystem shell extension, wanted to know how to go about exposing that to Wine:

I would like to add a checkbox control ("Show host filesystem") to winecfg to allow the user to easily (un-)register the unixfs shell namespace extension. So winecfg would have to query and create/delete the "HKLM\Software\Microsoft\CurrentVersion\Explorer\MyComputer\Namespace\{UNIXFS-CLSID}" key. There are helper functions in winecfg.c to cache registry values for later application, iff the user clicks "Apply" or "Ok". However, those seem to work only for keys rooted at the config key "HKCU\Software\Wine".

My question is: Am I doomed to implement the caching on my own for this key, should I generalize the helper functions, or do you think this configuration option should'nt be in winecfg at all?

Mike Hearn wondered when a user wouldn't want that to be set up. Michael described why it should be configurable:

If you register the extension, you will have the drive letters as well as the unix filesystem, which is somewhat redundant. Thus I thought we might better not register it by default and give the user the choice.

In my opinion, the best way would be to have an option under [shell32] which can be set to show the dos drives, the unix filesystem or both. This could be set globally or in AppDefaults (and since it would be under HKCU per user). This would mean some unixfs specific code in the MyComputer shell folder, but I guess there's no way around this, if we want to be able to hide the drive letters.

Mike had an idea about how all of it could be exposed to the user:

Yeah, I think that would work better for the user. I'm not sure it should be a preference just to enable/disable unixfs as is, but if you can set it as an appdefault and hide the drive letters that'd be good.

One thing we might want to look into is integrating with the GNOME/GTK+ file roots. In the new file picker, it hides the UNIX by default and you have multiple roots like "DVD Drive", "Home", "Desktop", "Apps on SomeServer" and so on. I think that's a much more user-friendly way of doing it than exposing things like /mnt, /usr/, /etc to the user. That would be an additional unixfs feature I guess.

Michael had an idea of how to fit that in:

I think those should be handled by a MyDocuments shell folder, which should work with both shfldr_fs and shfldr_unixfs, whatever the user selected. So we would have multiple instances of the MyDocuments shell folder with different names (like Home, DVD Drive, ...) and different target directories (like /home/foobar or /cdrom), configured with winecfg (or perhaps read from the gnome config).

I found the website , which describes how to create virtual shell folders that link to locations in the filesystem. And then there's the freeware tool "Shell Object Editor", which does this stuff programmatically. I guess if we implement the necessary behaviour in wine, that would be all we need? (And perhaps some code in winecfg to read the gnome configuration and map it to virtual shell folders.)

Mike went and looked into how GTK+ gets those locations for its file picker and found the code responsible:

The relevant function is here:

It's gtk_file_system_gnome_vfs_list_volumes. Doesn't look too hard to dlopen libgnomevfs and fetch the right list. Harder part is integrating that with the shell32 VFS and getting things like icons right etc.

4. Finding and Using Fonts

20 Jun 2005 - 21 Jun 2005 (15 posts) Archive Link: "Re: Change Name of Wine Marlett Font"

Topics: Fonts

People: Huw DaviesRobert ShearmanAlexandre JulliardRob Shearman

Wine's documentation concerning fonts leaves a lot to be desired. Fortunately most of the system is extremely simple to use once you figure it out and then it Just Works. Rob Shearman posted a patch to rename the font "Wine Marlett" to just "Marlett". Huw Davies wondered why that was needed, " The font replacement mechanism should make this unnecessary. Why doesn't that work in this case?"

Rob explained the problem he ran into, " It enumerates the fonts, but Marlett isn't enumerated, only "Wine Marlett." I tried adding a value in the FontSubstitutes and Fonts registry keys and the problem was the same. You can test this very easily using notepad's Edit->Font dialog. Steam only started working when Marlett was listed as a font in there."

A way to do that already exists in Wine and Huw gave an example of how to use it (including the new registry paths set up only days before by Alexandre):

Yup, that's the fonts substitutes mechanism which is different from the replacements one<g> See LoadReplaceList in gdi/freetype.c

You need something like this:

Rob reported that worked, but Alexandre raised the point that it required users to have their registry configured properly. Huw explained, " It would be nice to have the Windows fonts overload the Wine ones if they're present, which is what the current scheme does. Now, for TrueType fonts we could set the version low enough such that the Windows fonts would win, but there's no version associated with a .fon font so we couldn't use that trick there. "

Alexandre thought that could be worked around with a different method, " Can't this be based on the font path, using the first font we find in the path? Then we just have to make sure the Windows dir is searched first. "

Huw didn't think that method was foolproof either:

That would work if the Wine fonts end up in the Windows dir, but aren't they likely to get installed into somewhere under /usr/share/fonts ?

Also, I like the versioning thing, it lets me have the ms webfonts under /usr/share/fonts and have /win/winnt/fonts in my fontconfig path. This way, if my Windows partition has a newer version of Arial than the ms webfonts I get to use that, rather than it being on a first come first serve basis.

Can't we just add the Replacement keys to wine.inf and be done with it?

Alexandre thought Wine should behave in a sane matter regardless of the registry entries created by wine.inf. With regards to font versioning, Wine would of course follow that method. For fonts without versions they would be used on a "first found" basis.

5. ALSA Initialization Changes

13 Jun 2005 - 15 Jun 2005 (9 posts) Archive Link: "Alsa initialization change"

Topics: Multimedia

People: Jeremy WhiteKevin KoltzauUnknown

Jeremy White started off a thread about trying to fix Wine's ALSA sound driver:

Attached is a fairly sizable patch that revamps the way Alsa initialization is done. With this patch, Wine now does the following: scan all cards given by Alsa (not brute force 0-5), respect alsa defaults and environment variable overrides, probe to see if a reported Alsa device is useful (e.g. strip my Modem from the list of reported sound cards), and provide a mechanism for an end user to explicitly configure Wine to use Alsa.

The default configuration values should 'just work' in most cases, but the following registry values are permitted to provide finer control:

I'd appreciate anyone passionately interested in Alsa (Kevin? Robert?) taking the time to try this patch.

I've tried to 'do no harm', but this is a material enough change that I'm not yet comfortable submitting it to wine-patches.

fwiw, there is a (fairly thin) thread on the alsa dev lists regerading this here:

Kevin Koltzau tried it out and found a problem:

In ALSA_TestDeviceForWine, the call to snd_pcm_open blocks if I have any applications currently using my sound card, and does not complete until all other apps accessing alsa close, effectively freezing wine mixing is not supported on my card, so only one application can open hw at a time, all others will block on snd_pcm_open it does, however, work with

Sound card is standard AC'97 that comes with nForce4

Jeremy and Kevin then exchanged some emails to track down the problem and finally figured out it had to do with the way the sound device was being opened. Kevin explained how his device was configured:

The sound card is in use by the dmix/dsnoop plugin. my "default" device is actually a chain of plugins, a striped down version of my .asoundrc is (let me know if you want my full config)

so default goes through asym, which joins dsnoop and dmix, which then actually access my hardware.

This is a pretty common config for cards that do not support hardware mixing, IMO.

Kevin ran a test program that Jeremy came up with and it seemed to finally nail down the remaining issues. The patch made it in later in the week.

6. WineD3D Fun Project

21 Jun 2005 - 22 Jun 2005 (3 posts) Archive Link: "wine d3d fun projects."

Topics: DirectX

People: Oliver StieberScott Ritchie

Oliver Stieber has been back at work on Wine's DirectX. A bunch of large patches appeared this week and made their way into CVS. (Hooray!) At a glance it looks like the patches are laying the groundwork for larger additions. Oliver had an idea this week for a project someone could tackle that might prove to be interesting:

I have another 'fun' and useful project to add to the list.

It should be fairly to make wined3d (or d3d8) use the wgl (windows opengl) instead of glx. (just search for glx commands and replace then with the wgl equivalents)

Doing so would enable Wine's d3d to run on windows in place of the windows driver and without the rest of Wine which would greatly help in debugging.

It would also allow wined3d to use the wgl implementation in Wine.

Scott Ritchie wondered if something like that had been done at a driver level once before:

Didn't one of the video card makers experiment with something like this at one point, translating all Direct3d calls into OpenGL and just writing OpenGL-optimized drivers (or perhaps vice-versa)?

Oliver knew of an example that worked the opposite way, " Matrox had the Matrox icd, which 'translated' OpenGL calls into DirectX calls."

7. Cross-compiling Winelib Apps

23 Jun 2005 (2 posts) Archive Link: "Cross-compiling with winelib"

Topics: Winelib

People: Eric FriasAlexandre Julliard

Eric Frias wanted to add some cross-compiling support to Winelib but needed some advice on how to approach it:

We're working on setting up an environment to cross-compile a winelib application (initially from x86 linux to sparc solaris). To do this, we need a cross-compiling version of winebuild which will generate the assembly code for the target architecture instead of the build architecture.

I see two basic ways we can accomplish this. We could either use autoconf's --target flag to specify the target architecture, and then replace all of the "#ifdef __sparc__" statements in winebuild with "#ifdef __target_arch_sparc". I came across an autoconf macro ( that would generate the appropriate defines.

The other way we could approach the problem is to modify winebuild to always generate assembly code for all of the architectures, pushing the #ifdefs down into the .spec.c file.

I'm inclined to stick with the first option, since it looks like less work and less chance of introducing errors, but I wanted to run it by the list before starting work. Would a patch like this be accepted into wine? Do you know of any other gotchas we should be aware of?

Alexandre suggested an idea similar to the second approach:

I think the right way is to get rid of the #ifdefs, but not by pushing them into the .spec.c file but my making the target a run-time option. I've been meaning to do this for a while now, I was just waiting for someone to actually need that feature ;-)

8. Wine + Subversion + SVK

19 Jun 2005 (1 post) Archive Link: "Using SVK and Subversion to manage distributed branches to Wine CVS"

Topics: Project Management

People: Troy Rollo

Troy Rollo has been working with SVK over the past few weeks. I've been meaning to post something about this, but thus far all of the work has appeared only on the Wiki. Troy explained how to get started:

Over the past few weeks I have been experimenting with SVK and Subversion managing a handful of branches to Wine CVS, and it appears to be working well. The system is based on a "central" Subversion repository that mirrors the Wine CVS tree without any modifications (publicly readable at svn:// and is kept up to date within a day or so.

Branches are stored in separate Subversion repositories.

I am finding this very convenient. If you have converted from CVS to Subversion on other projects, you are probably aware of the huge difference it makes. Adding SVK on top of Subversion is another giant leap when you have distributed development. In the case of Wine, however, with the CVS repository being read-only except to Alexandre, the difference between read-only CVS and the combination of Subversion and SVK is even more dramatic (I would compare it to the difference between chiselling documents into stone tablets and using a word processor).

For anybody who is interested in moving their own Wine development to Subversion and SVK, there is a page on the Wiki describing what to do at







Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.