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 #304 For 29 Jan 

By Brian Vincent

Table Of Contents


This is the 304th issue of the Wine Weekly News publication. Its main goal is to carpet. 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 174 posts in 332K.

There were 68 different contributors. 39 posted more than once. 43 posted last week too.

The top posters of the week were:

1. WineTools & Wine

(4 posts) Archive Link: "[Fwd: WineTools is in need of some major house cleaning!]"

Topics: Utilities

People: Joachim von ThaddenVitaliy MargolenJuan LangTom Wickline

Debate has been raging for weeks over whether the Winetools project should be listed on Wine's download page.

On the one hand, WineTools is used by a lot of people to get common programs to install. It'll automatically install Internet Explorer and a lot of low-level libraries (DCOM) needed to run it. It offers a very simple way for people to get things running with Wine. The fact that CodeWeaver's has a similar tool, cxsetup, shows that such a thing is valued by users.

Wine developers are arguing that WineTools is doing more harm than good. It's unclear whether which of the additional libraries are needed. WineTools also messes with Wine's default configuration by changing the default overrides for every library to be native Windows ones over Wine's internal ones. That tends to break a lot of things. Furthermore, the WineTools developers don't seem to be easy to get a hold of or responsive to change requests.

As you can imagine, it's a fairly divisive issue. This week Joachim von Thadden, the current WineTools author/maintainer, responded (keep in mind this is in response to a thread that came up over a month ago):

>From Sven Paschukat I was informed about the discussion of removing the WineTools link from the winehq website. I read all remarks made to that hotly discussed topic and I am willing to tell you all a bit about the purpose and history of WineTools as well as I will answer the questions made by Tom Wickline. So this will be a little longish mail and I beg your pardon for that and hope you have enough patience to read it all.

To start from the beginning, I took over the remainings of a project winetools initially started by Frank Hendriksen <frank at> which was somehow orphaned. The very reason I did that was that in autumn 2004 I had to write an article in the well known German computer magazine c't. After fiddling with wine for a long time only to install a stable IE6 or Office, I found that it was so absolute complicated to describe all the steps needed only to install the IE6 (which is much better now) and that also following these steps was very erroneous, that I started to rewrite the winetools script for the readers of this article.

I never meant it to become so famous and wide spread, but the download statistics after only two month showed me that there was a massive demand for such a tool. So this is how it started and it shows very clearly that it was always an installer to make certain important applications easily usable under Linux. It was never meant for testing or developing. It was always meant for the end user being able to use his software.

At the time of the first releases it was almost impossible to install or work with many applications without using native DCOM and/or many of the builtin DLLs that come with the IE6. To find a configuration for as many apps as possible was one of the goals. Not to force users (with very low skills) to have many different wine installations *and* many wine user directories was a second goal. So this is the reason why, until now, everything in WineTools is based on this native M$ software (DCOM, IE6). And believe me, no one would be more happy to wipe this DCOM, IE6 and MSI stuff completely from his harddisk than me!

So as so many programs rely on parts of M$ software (MFC, VB and MDAC are other important examples) and because to install and use this software leads to so many restrictions in the wine usage, I had to pin wine to the emulation of Win98 and also had to massively tamper around with DLLOverrides. The goal was to built up an environment, that can install and use as many Windows programs as possible. This did in no way regard to the fact that it is not very helpful for the wine developers. It was just a practical decision.

>From time to time, Sven Paschukat and me are testing wine versions to figure out, whether we can skip some of the M$ stuff. We have not been very successful with that until now, so this is why there are so many remainings of the first start of the project in the concept. But again: This tool is for the average windows user. And believe me, I tested this with my brothers, who are just normal users. And they never ever got a piece of windows software running with wine without my heavy intervention. With WineTools they just need to click on some buttons and got their software downloaded, installed and configured.

With an amount of many thousand downloads a month, not calculating the distribution inclusions of WineTools, I get almost the same number of direct mails about problems with the software as are coming into the list. And I get massive positive resonance from users who were for a long time trying to get their stuff running with plain wine and are now happy that it just works with WineTools.

I must admit, that there raise problems out of the fact, that the same users are trying to install not WineTools-tested software with the setup of WineTools and coming then to the list. And your are right that this is an undebuggable situation. The only way around that is to smoothly migrate WineTools to more and more builtin features as long as this does not make the programs uninstallable or unusable.

Sven Paschukat suggested to implement a mode for WineTools to install without native components and without that tampering in the registry. This allows automatic installations *and* insight for developers if something goes wrong. We can also add a debugging mode to enable the logging of wines debug channels, to make a mailable report of bugs. Also the other suggested corrections will be looked over and changed if applicable.

If you look through the mailing list you will find, that Sven and me are already giving support on the wine-users mailing list. That we will not and can not maintain a channel should be clear as we are not earning our money by looking at channels. Also the demand by Vitaly to provide rapid fixes to requests on such a channel or the list is something that can be only meant as a joke!!! If Vitaly is a man of independent means it is nice for him but we are a free time project and can only work for WineTools, as the name suggests, in our *free* time. And we have also a family, friends, mistresses and other hobbies...

Well, we also do not like winehq to remove the project's link. As for the support I already wrote a line above about that. Note that there is a massive amount of users using Wine via WineTools. Almost all users coming from Windows are using this software if they like to use their programs. This might lead to more and more end user questions on the list. As a possible solution for that, if you think this gets the upper hand, I would suggest to have a new mailing list wine-winetools and to redirect all users to that one. We will propagate then this list in the readmes and on the WineTools sites. And for sure we will sit on this list like spiders lurking for our prey...

At least I want to thank all wine developers for their absolute fantastic work! In my opinion this is one of the most interesting and most ambitious projects in the community of open source software. And it really works astonishingly good.

Vitaliy Margolen, the most outspoken Wine developer on the subject, echoed the thoughts many others have had regarding WineTools:

The problem with this as I see, is that we as Wine developers creating an environment of one kind. And these "tools" almost totally override that environment.

How often do you guys check if a piece of software can be installed on Wine as-is? Without any additional configuration or native components? The point and click user have to know what they are clicking on, or not be presented with the bad choices. With the way it is _ALL_ new times visiting have an impressions that winetools are the absolute requirement and download and install them.

I can't tell how many times I had to tell the user to vipe their ~/.wine dir and start from scratch _not_ using winetools because what they want to run does not require anything that winetools install.

Also I don't see any post from you or Sven about these problems in the bugzilla. How do we know that there are any problems?

As I mentioned before, every single person visiting download page thinks that winetools are something mandatory. I would really like too see what programs run and don't run with and without winetools. Also please redirect all those users to appDB. We need information there available for everyone to see, not in your e-mail box (no offense).

Winetools has setup environment in a such a way that it is unified! If you're saying that all you did is tinkered with lots of stuff to get few applications to work, this in not good. Wine is not cedega designed to run games and games only. That just proves my point that environment you have setup with winetools is less flexible and more restrictive then Wine itself.

I think it's really silly for Wine trying to be the pure replacement of Windows and yet advertise such a utility that clearly undermines development in number of critical areas.

Juan Lang outlined some ideas that would help WineTools users work with Wine better:

Hm. Felt I needed to offer a counterpoint to Vitaliy's rather enthusiastic response.

I support winetools, though I don't use it myself. Not only as a matter of principle (this is open source we're talking about, and one of the beauties is we don't get to constrain how it's used.) Also because it's in line with the aims of the Wine project: run Windows apps. Wine is nice in that it doesn't require you to have any MS license to run Windows apps, but it can use MS software if you have a licensed copy. So winetools offers folks with MS licenses a relatively easy way to get apps to run.

Still, while that's nice for the users, it's not so nice for us Wine developers, because it's hard to get widespread testing of things we're improving if they're not being widely used.

So, as Vitaliy suggested, it would be nice for us if you guys, who know what problems you encounter running with builtin DLLs, could file bug reports in bugzilla for us. That way at least we have a chance to say, hey, that problem's now fixed, consider using builtin OLE (or whatever) in the next release of winetools.

Now for specifics. For instance, you use native advpack in all cases, but that's seen some more work recently. What bugs do you encounter if you use builtin instead? Same with ole32. Ideally, each of the apps that has a native override should have a bug report associated with it, what goes wrong if you use the builtin version instead.

Also, the default override, "*"="native,builtin" seems wrong. If we don't have a DLL at all, we use a native version of course. I don't think it should be the policy to assume the Wine version isn't up to snuff by default. This could even cause problems, e.g. I don't believe any native version of netapi32.dll will work on Wine, yet you don't specify to use the builtin version.

Also, you direct users to That's fine since this is community support anyway, and it is often the case that winetools knowledgeable people are around (like you guys.) But it would be nicer if you could be clearer about it. Like, that we developers had nothing to do with it, and may be unfriendly to it if we're in a bad mood, or it's a Tuesday :)

It'd also be nice (for us, even though no one actually reads anything these days) if you could be clearer about what it does. That it installs MS components, that it uses these instead of the builtin versions sometimes, that you can change how it does this using winecfg, etc. That'd make it easier for us to help folks that have only used winetools that want support, because often the first question we ask is, what version of wine, and what DLLs are you using?

The last point was addressed by Sven Paschukat by adding a note on Wine's download page later changed by others. There's no easy solution to this issue. On the one hand, Wine needs to become good enough that no external pieces are needed (which is the holy grail of Wine development). On the other, users need an easy way to just get things done until we reach that point.

2. SCSI Tape Drive Support

(9 posts) Archive Link: "TAPE 1/5: add some defines related to tape support"

Topics: Filesystems

People: Hans Leidekker

Hans Leidekker posted a series of patches to allow Wine to talk to SCSI tape drives:

This is the first of 5 patches that implement the Windows tape API on top of the Linux SCSI tape driver (st).

I admit this is probably not the last missing piece that kept people from flocking to Linux and Wine, but I do know that I really enjoyed hacking away on Wine to make my dusty old 2GB DDS 1 SCSI tape unit spin again. Hacking Wine is fun!

In the last patch he described how to get Wine to recognize the tape drive:

There's one missing piece after this patch, which is the association of an NT device name with an appropriate Unix device file. Until Wine learns how to autodetect these you need to do it by hand.

For example, to associate NT tape device \\.\TAPE0 with your Linux SCSI tape device /dev/st0 you need to create this symbolic link:

There was a bit of comments concerning the error codes Hans used and after that the patches did get committed.

3. JACK Audio Driver

(7 posts) Archive Link: "wine and jack => segfault? / wine and OSS not working"

Topics: Multimedia

People: Joachim ForsterEric Pouech

Wine has a lot of audio drivers, but some of them don't get used very often and might not work at all. This week Joachim Förster posted a problem about the low-latency audio server JACK: "

some days ago I sent some mails to the wine-users list. My problem: the JACK output driver of wine does not work => wine segfaults; and the OSS output driver does not work, too. Windows Media Player (used for testing) says, it cannot find the audio hardware.

Since then, nobody on the wine-users list had any idea what could be wrong, so now I am posting this here:

I am new to this list and just wanted to ask a question regarding Wine and JACK:

I'm running JACK as my sound daemon and today I installed Wine (from the APT-Repository). I setup my .wine directory with the help of winetools. So far everything works fine, except sound output (tested with wmplayer and a simple wav file). So I selected "jack" as Audio driver.

But wine segfaults with wmplayer as soon as opening the wav file:

I started qjackctl to see what the JACK says:

So, I assume there was an "connection" established between Wine and JACK?

Does anybody know something about this problem? Tell me if I have to provide more (log/debug) output etc. ...

I am running Ubuntu Breezy (breezy kernel 2.6.12-10-686).

PS: Direct output to ALSA works (with jackd not running).


Eric Pouech asked for a +winmm,+oss,+wave trace to see if he could figure out where the problem was. Joachim did and noted it was " using OSS-output driver and oss2jack" . Eric replied, " oss2jack doesn't provide a proper mixer interface does the attached patch help ?"

Joachim reported it did and noted a few issues:

Yes. Great, thank you very much :-) !

BTW: I had to set "Hardware Acceleration" to "Emulation" (instead of "Full", but did not try other levels) to make mplayer2.exe play all my test wave files _right_.

I used the c:/Windows/Media/*.wav files. And the strange thing was, that mplayer2.exe (with "Full") played some of them right and others wrong (= sounds like sampling freq. (transformation) issue).

Eric submitted another patch to wine-patches later to address the issue.

4. Overriding Executables With Winecfg

(4 posts) Archive Link: "wine 0.9.6 segfaults (was: Re: wine 0.9.5 - segmentation fault with some apps)"

Topics: Configuration

People: Ulisses de Sousa PennaMike McCormackStefan Dosinger

Winecfg now sets overrides for DLL's allowing you to you to choose native Windows DLL's over Wine's own builtin ones. Sometimes it's also necessary to override an executable as well. Ulisses de Sousa Penna ran into that problem this week:

I have posted a comment at

The problem seems to be with the name of the executable: "user.exe" (sounds crazy, but it was I could realize after some tests).

Mike McCormack explained why and a possible workaround:

That's quite possible. user.exe is a 16 bit part of user32.dll, and Wine treats it in a special way.

You might be able to add a dll override entry in winecfg like this:

Ulisses found other folks had run into the same problem, but didn't understand Mike's solution:

In fact there are a little more with same problem: start.exe and sound.dll (as reported in bugs 3950, 4351 and 4311)

However "winecfg" does not allow me to input free form strings (at least I try and could not find a way). It does only allow me to navigate throught the file system and choose the application. And the "Libraries" tab, in winecfg, it is only for DLL's - I guess! (Am I wrong?) The only solution I tried is using "vi" to edit ~/.wine/user.reg but I think I made a mistake because wien still segfaults.

Here is the KEY I have put:

I have also tried a variation of it .... but it still segfaults when calling "wine user.exe":

Stefan Dösinger explained Winecfg does in fact work:

No, it can be used for .exes too, you only have to specify the full name(e.g. "user.exe" for user.exe compared to "oleaut" for oleaut.dll)

I often use it for dplaysvr.exe, so it works

5. Hook Problems

(8 posts) Archive Link: "Global hooks problems (WH_MOUSE_LL)"

People: Vitaliy MargolenRolf KalbermatterAlexandre Julliard

Windows has a concept of hooks that allow an application to monitor the system for various events that might occur. For example, you can use the WH_MOUSE hook to intercept mouse messages before they're normally processed. Vitaliy Margolen noticed a problem last week with Wine's implementation:

Trying to track down the problem with our DInput implementation I found some interesting stuff - our global hooks don't work correctly because hook callbacks are never called if event is generated in the different thread. I don't think this is a revelation to number of people who knew that before. But how do we fix it?

Here is what I dug up so far:

  1. Installing global hook we setting it as WINEVENT_INCONTEXT while msdn and tests indicate that it qualifies as WINEVENT_OUTOFCONTEXT instead. Unless of course we don't want to call post_win_event in step 5 and go to step 6 instead.
  2. All HW mouse messages start here: From looking at it I assume that all the HW mouse hooks should be handled by HOOK_CallHooks function. This is because there are no code related to hooks in send_message server call.
  3. First thing that HOOK_CallHooks does is calling HOOK_IsHooked with checks only current thread for installed hooks. So this is first place that is wrong. Let's comment that check out for now. I think we need to move that check farther down, after the call to server.
  4. We call start_hook_chain to start hook callback chain. There we call get_first_valid_hook on local and then global if no local hooks exist. But there again we check for the hook callback thread being local (which is again not the case for global hooks). This is problem #2.
  5. Now we have post_win_event of but right before it we hitting an assert so this is not the right way?
  6. Say we returned with success and back to HOOK_CallHooks that now tries to call MSG_SendInternalMessageTimeout. Which for some reason fails to deliver message to our global hook.

So my question is to anyone who knows. What is the proper way to deliver these messages to global hooks that are in a different thread/process?

Rolf Kalbermatter added to it:

Just an observation I did in a Windows program running under WinXP. Not sure if this is related somehow but it seems quite like the opposite of what you describe here although with windows message hooks.

I had a program that was hooking window messages for a particular window. When using SendMessage from the same thread as in which the Windows message loop was running (doesn't make much sense of course but it was just for testing purposes) I could not receive any events above WM_USER, lower events did seem to get received properly though. When placing SendMessage in a different thread the events did come through.

Not exactly sure yet what this is all about but message handling and especially hooking in Windows for sure can be a tricky business.

Alexandre replied and outlined what was going on:

That's because the new win event code changed the meaning of the thread field, and the low-level hooks haven't been updated for it. Try something like this.

Vitaliy reported it worked:

It does work thank you. The only question I have : does that cover WINEVENT_OUTOFCONTEXT hooks too?

I'm working on a test to test hooks. Hopefully there will be a way to test it.

And it looks like we will have to rethink our DInput - the game still doesn't work. It seems that the thread which acquired mouse doesn't have a message loop.

Regarding Vitaliy's question about WINEEVENT_OUTOFCONTEXT hooks, Alexandre asked if he knew they were broken. Vitaliy replied that he was just asking.







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.