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 #265 For 11 Mar 2005

By Brian Vincent

Table Of Contents


This is the 265th issue of the Wine Weekly News publication. Its main goal is to gravitate. 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 265 posts in 1517K.

There were 80 different contributors. 48 posted more than once. 47 posted last week too.

The top posters of the week were:

1. News: Wine 20050305, Linux Gaming

5 Mar 2005 - 11 Mar 2005 (3 posts) Archive Link: "News"

Topics: News

People: Alexandre JulliardJoe BarrSlashdotNewsTransGamingGavriel Statecvs

Wine 20050310 hath been unleashed. Alexandre noted the following changes:

WHAT'S NEW with Wine-20050310: (see ChangeLog for details)

The packaging crew will have binaries available soon, but you can snag the source now.

Slashdot linked to good article at about gaming on Linux. They covered a lot of different aspects of gaming including native ports, gaming with TransGaming's Cedega, and a whole page discussing Wine. They wrapped it all up with an interview with Lucas Smithen of TransGaming. Speaking of which, Cedega 4.3 came out this week. Finally, Gavriel State wrote a column on cross-platform development.

Joe Barr wrote an article for Newforge about running CwGet, some ham radio software, with Wine:

I used an audio cable with a mini-jack at each end to connect my Yaesu FRG-7700 receiver to the Line In port on my SoundBlaster Live! card. Then I found a ham band with some CW activity and started CwGet. I was amazed when I saw the CW being decoded real time, as I heard it, but there it was. Yes, CwGet would work on Linux, thanks to Wine.

Joe included a screenshot to go along with it. I'm not a ham operator, but it looks like the software is useful.

In completely unrelated news, Nobel Prize winning physicist Hans Bethe died last weekend at age 98. I've always loved physics, as well as the history of science in general. Bethe was one of the last links to the old age of physics before relativity and quantum theory. I was sort of sad to see his passing didn't make much news. If you want to hear an excellent discussion of physics, check out Cornell's Quicktime movies of Bethe from 1999.

2. Winecfg & Unixfs

8 Mar 2005 (4 posts) Archive Link: "unixfs"

Topics: Configuration

People: Michael JungAlexandre JulliardMike HearnChris Morgan

The winecfg tool (that someday will be used, we promise) requires a way to access the the complete underlying Unix filesystem. It's a Winelib app, so there's multiple ways of doing this. Michael Jung put together a patch last week, but it wasn't committed. He asked what was wrong with it:

Could you please tell me if you consider the unixfs shell namespace extension, which I've sent to wine-patches last week, a sensible way to go in order to access the unix filesystem from winecfg? I know that there is room for improvements, and I'm working on it. But if you think it is not the right thing to do, I will stop working on it and save some time for other stuff.

Alexandre explained what was going on:

I think the extension itself is perfectly reasonable. The thing I'm not sure about is creating a brand new dll for it, adding Wine-specific dlls should be avoided if possible.

Michael thought of a another way to do it:

Would you consider it more reasonable to implement unixfs as a part of shell32? We would not have to alter the APIs exported by shell32 to do this. Wine's shell32 would just recognize more CLSID's than the original one.

Michael then went ahead and came up with a patch to add the unixfs support to shell32 instead. Alexandre committed the patch the next day as well as one to add support to winecfg to browse the filesystem. So, if you click that Browse button in winecfg, it now comes back with a nice selection window rather than informing you of unimplemented functionality.

Along similar lines, Chris Morgan wondered why we weren't using winecfg yet. The tool is in pretty good shape, it just doesn't actually modify the registry. To make things a little more confusing, the config file isn't installed by default any more so some options appear to be in limbo. Mike Hearn explained what was blocking the move:

Somebody needs to write a patch to migrate the configuration branch across to a new one, disable the pre-existing config file (renaming it?) and then use it.

At least, I think that is what is needed. Alexandre may have other ideas.

3. Drive Management

4 Mar 2005 (24 posts) Archive Link: "Drive detection stuff"

Topics: Configuration

People: Mike HearnBoaz HarroshAndreas MohrSteven EdwardsOliver StieberJacek Caban

While we're on the topic drives and setting up drives, Mike Hearn went through and outlined some problems that need to be addressed. If you're looking for a way to get involved with Wine, some of these are good ways:

So, there are 4 obvious problems with our current drive management code:

  1. We add links to the floppy drive. We should blacklist it, as it causes a big delay in the file open dialogs as we poll the drive which sits there spinning its motors naval-gazing. How many people still use floppy disks in 2005 anyway? I'm hoping the answer is "virtually none"

    An alternative solution would be to poll the drives in a non-blocking manner, though I'm not sure this would work for apps which do their own file dialogs like Office.
  2. We don't add any device symlinks. Some programs need these eg d:: -> /dev/cdrom
  3. The artwork in the file pickers sucks ass. Sorry, it does. It's ugly as sin and for some reason the Desktop icon is an arrow, not a desk.

    This doesn't matter when you only have C: and Z: drives. It does matter when you have 2 CD drives, 2 Windows drives, a floppy and a few other drives.

    Fixing this is theoretically easy but for some reason it never gets done. If any of you non-coders are reading this and want to contribute then this would be a good way to start. Good artwork already exists, it's just a case of finding it, converting it to the right format and getting the new bitmaps into CVS.
  4. We don't detect new drives as they are mounted into the system, eg if I start a Windows program and then realize that my work is actually on a USB key, if I plug that key in Nautilus and GTK+ (and probably KDE) apps will detect it and see it, but we won't. Not even if I restart the app! This is bad.

    Fixing this is not, in theory, super hard. When HAL detects a new hotplug device it modifies the fstab file and mounts. If we watch the /etc/fstab file for changes and rerun drive detection therefore we can make this all magically work. Problems are:
    • Who triggers the resync? The wineserver is the obvious choice as there is only 1 per wineprefix but we'd need to integrate FAM support for that
    • How do we broadcast to apps that the drive definitions changed so we can update the UI, flush any caches etc?

Alexandre didn't think device symlinks were necessary and asked if Mike knew of a specific case where they were needed. He said only exotic setups really needed it, and even then it should be possible to fix it. With regard to the last point, Boaz Harrosh briefly explained what Windows does, " There is an API to watch for File System changes. From files (for editors), to folders and drives. The standard Shell control (Used in file dialogs and Explorer) uses this API by default. Also apps that do their own Dialogs like office."

Andi Mohr thought implementing that in Wine was the way to go:

Ah, so this means that the directory change notification mechanism applies to volume notification as well? Or is it still a somewhat separate API?

Nevermind, at least you just told us that this API exists, so we should try to get the hal/hotplug/fam stuff integratedf towards this API.

Steven Edwards also provided some info on how Windows manages the same thing:

I think the umpnpmgr.exe in windows takes care of all of this for the applications and explorer using the APIs you listed. I don't know how we would really fit in the Windows design here.

Oliver Stieber had another link for ideas on how to manage it in Linux, " take a look at how ivman does things." Ivman aims to be a frontend to HAL events.

Jacek Caban had an idea for improving Wine's artwork, " I know two (maybe there are more) projects that have done really nice artwork: xpde ( and KDE xp style ( The main problem is that both have GPL licence, but we could ask authors to let us use them in Wine. Their icons are really cool and I belive Wine would look much better with them."

4. Steam Working

8 Mar 2005 (4 posts) Archive Link: "Let's fix Steam!"

Topics: Fixes

People: Scott RitchieStefan DosingerMicrosoftcvs

Scott Ritchie thought Valve's Steam would be a good app to get working with Wine. Steam acts as a peer to peer client that lets you download and run HalfLife 1 games (HL2 is currently not working with Wine's DirectX implementation.) Scott described the current state:

Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark.

What's interesting, however, is that Steam works perfectly in Crossover 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine.

This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :)

So, where do we go about this? The installer demonstrating the error can be downloaded easily from

Stefan Dösinger downloaded it and reported success:

I downloaded steam, ran it with wine(cvs from 3/6/2005) and it WORKED without doing anything special.

Wine just told me that it has to download the mozilla active X control and crashed because of a missing dll(MSVCR70.dll). I'll get this dll and do some more testing.

Stefan wrote back several hours later and described his progress:

Steam runs indeed nice with wine. I don't know why it works all over the sudden, but it works ;-)

These are the problems I found:

5. Winebuild Changes

6 Mar 2005 - 7 Mar 2005 (2 posts) Archive Link: "winebuild changes"

Topics: Build Process

People: Dimitrie PaunDimi Paun

Dimi Paun figured out a way to solve a problem that popped up this week, but asked for comments on the changes:

Ivan found that on Windows .exe's can export functions, just like DLLs. He needs this for his work on ntoskrnl.exe.

To support this, we need a bit of an interface change to winebuild. I've put together a simple patch to see if you are OK with such a change. If so, I'll finish it, and modify winegcc accordingly.

So, thing will change as follows:

to build an .exe with arbitrary exports, we would do:

Alexandre looked over it and approved of the idea.

6. Wine Patch to Work With Valgrind

9 Mar 2005 (1 post) Archive Link: "Wine & Valgrind 2.2.0"

Topics: Memory Management

People: Robert ShearmanRob Shearmancvs

For anyone wanting to find memory problems, Rob Shearman posted a patch to make Wine work with Valgrind 2.2.0:

I notice there has been interest from developers wanting to run valgrind with wine. I have been doing this successfully with the attached patch applied. Note that there are some false positives from the thread start routines caused by a bug in valgrind. Apparantly this is fixed in the latest cvs, but I have not tried it. I find the --tool=memcheck option the most useful, which can be used for finding the source of memory corruption.

7. Wine's Server Protocol

8 Mar 2005 - 10 Mar 2005 (8 posts) Archive Link: "server/protocol.def documentation"

Topics: Architecture

People: James HawkinsAlexandre JulliardJuan LangMike HearnMike McCormack

James Hawkins needed some help to understand wineserver:

I now understand the purpose of SERVER_START_REQ et al, but now I'm in server/protocol.def and I'm trying to add a protocol definition for load_key. load_key is implemented in server/registry.c, but is not in server/protocol.def so, if I'm correct, I can't make a call to load_key from ntdll yet. I am trying to add load_key to protocol.def, but I don't know the semantics of this file. Is there any documentation available for this topic, or does anyone have any information that could be added to the docs?

Mike Hearn asked James what problems he was running into. James replied:

I guess it's not so much that I can't understand it when I read through the code and read the comments, but that we should document this so whoever needs to work with the server next won't have to take time to read through the necessary files to understand it. There's also a big possibility that I'm not understanding this correctly. Some things that would be nice to see in documentation are:

The biggest question I have right now (because I understand minimally the points listed) is why api in protocol.def have different parameters than their reg counterparts and even ntdll api.

What I'm getting at is that these things are an integral part of wine, and there isn't any documentation for it. If someone would be willing to write documentation for this topic, then wine and its developers would definitely benefit.

Mike McCormack pointed out that comments tend to bitrot and including them can lead to outdated information. Alexandre explained, " protocol.def itself is the documentation of the protocol, there is no need for more. It's pretty much self-explaining anyway, and people who can't figure it out by reading the code have no business messing around with the server protocol. Consider it as the entrance exam for server hacking ;-)"

Juan Lang thought it might be worth giving a pointer to protocol.def, " Okay, fair enough. I think what's missing, though, is a dev guide entry on where this thing is, and (briefly) how to extend it. But since experienced wine hackers seem to figure this out anyway, there may be no need."







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.