Wine Traffic Brian Vincent

This is the 226th issue of the Wine Weekly News publication. Its main goal is to grill. 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 eweek eWeek Jeremy White News

Jeremy White appeared on The Linux Show this week. Unfortunately I don't know of any archive links to the show, so you may want to catch this week's show before it disappears. Along with that, eWeek reviewed CrossOver Office 3.0. It's postive, though it lacks much in the way of detail (I get the distinct impression the author installed it and only ran it once.)

Other than that, there's not much going on. Alexandre is on vacation and everyone else seems to be taking a break accordingly.

Shachar Shemesh asked for help tracking down what appears to be a kernel bug:

Mike M told me on IRC that this matter has come up before, but I have not been able to find it in the archives. It seems Wine has been generating lots of zombie processes when it's not 100% cleanly killed. I have also seen the system hold a socket created from a wine process in "ESTABLISHED" state, when no process is registered as the socket's owner.

According to Alexandre according to Mike, this is a kernel bug. Well, it most certainly is. Theoretically, there is nothing a user space process can do to cause zombies to stay around after their parent has exit, or keep sockets open after their controlling process has quit. As wine is a user space only process, this must be a kernel bug. No way around it.

However, it happened to me both on RedHat 9 with 2.4.something (NPTL back ported), with both RH9's original kernel, and their most up to date one. It also happened on Debian Sid's almost-vanilla kernel 2.6.6. It happened with LD_ASSUME_KERNEL=2.4.1 making wine choose the standard threading mode, as well as without, choosing nptl. The zombies are sometimes called wine-pthread/wine-kthread, and sometimes wine-preloader. In short, I think this is a long standing Linux kernel bug, and Linus helps those who help themselves. I will also not be surprised if it was triggered by a wine bug.

So the question is this. Is there anyone on this list who knows how to submit this as a question to lkml?

Shachar mentioned he had a tainted kernel due to Nvidia drivers. Rob Shearman confirmed he experienced the same thing though, I've experienced the same thing on a perfectly clean kernel (I think 2.6.5-mm1), but I assumed it was because we were messing around with signals. If I can reproduce the problem I will report it, although Mike McCormack seems to have had quite a bit of contact already with the kernel folks

Mike McCormack wrote in with a few more details, The problem seems to be a kernel bug. It's been round since 2.6.0... in my experience it only seems to happen when you terminate a wine process using ^C or when the program crashes tries to start the debugger, fails, then you press ^C

From there more reports trickled in with the same issue. Kernels with this problem included an untainted 2.6.5 and an "untainted" RedHat 2.4.20-8. Shachar thought that offered a bit of insight into the problem, if I am guessing correctly, this problem has something to do with NPTL, which means it was only there in the 2.4 kernel to begin with because of a RedHat patch. However, as the problem DOES happen on vanilla 2.6 kernel, this will not be a problem to reconstruct.

Fixes

Killing a Wine process may not be as straight forward as you'd think. Mike Hearn gave a pointer to anyone experiencing this problem:

Sometimes it is convenient to do a "killall -9 wine-pthread" to kill Wine for whatever reason. This no longer works:

    $ ps ax | grep wine-pthread | grep -v grep 10425 pts/4 S 0:00 /opt/wine/bin/wine-pthread notepad.exe

    $ killall wine-pthread
    wine-pthread: no process killed
    $ killall wine-preloader
    $

Huh? WTF is going on here? Well, it seems that "ps" and "killall" look at different places to get the process name, so despite the fact that it appears as wine-pthread in the process list, you must use the name wine-preloader in order to send it signals from the command line.

There are reasons for this, which will hopefully become clear when I submit my docs on the Wine init process. For now, you have been warned.

Fixes

This topic comes up from time to time, although it's been a while since we've seen it. Raghavan Gurumurthy asked, If i want to do some special handling inside my Windows executable when running in Wine environment, what is the best way to do this?

Mike Hearn gave the preferred answer, if you are trying to work around a Wine bug a better approach is just to fix it.

Bill Medland had the other answer - how to actually detect a Wine environment, Unless things have changed, I think the normal suggestion is to look for the HKLM/Software/Wine registry key

Josh Walker thought working around deficiencies might lead to problems later if Wine needed to change the registry layout for compatibility reasons. Raghavan explained that their intentions were simply to ensure they were able to provide the best compatibility possible on Linux:

The purpose of my question was to make sure that wherever we are doing changes to the product code to work-around limitations in Wine, we are doing so only when running on Wine. And, before you (or anyone else) send further flame mail, note that we are submitting fixes to Wine as and when we run into them and have a solution.

We are not trying to limit the product in anyway on Linux - if any, we are trying to make sure that the end-user experience for our product when running on Linux is as painless and seamless as possible.

Chris Morgan thought it might be a good opportunity to identify areas of Wine that need work, I'd be curious as to what kinds of things you are trying to work around. It would be interesting to see in which cases bugs were worked around vs. fixed and which areas were the biggest problems.

Testing

Chris Morgan updated the Winrash tool used to run Wine's test suite and asked for people to please register:

Just released a new version of winrash. I'm sending this email because after asking people who are running Winrash to send an email to the list or myself , I didn't receive any emails. This isn't usually a problem except when there is an issue with Winrash. I get error reports that have the IDs people put in but no way to contact them.

So I added a field in the installer for a contact email. This will be sent along with the clientID when an error report is generated by winrash.

In case anyone is curious the web archive for the error reports is here:

I'd like to ask that anyone who installed winrash please run the installer again so they can enter a valid contact email. If you are one of those people wondering why your results aren't found at

this will help both of us by letting me get a hold of you ;-)

The one change I should mention is the addition of proxy support in the 0008 release. There are a handful of people running behind proxies, I can tell by squid html in what should be the script part of the error reports. This version of the client *should* fix things for you. Thanks to Florian Steinel for the code change.

Here is the SF link to the latest client:

Thanks to anyone running the testing suite and for the feedback on winrash changes, I appreciate it.

In case you missed the original announcement about the automatic testing facility (see issue #224), Winrash is a service you can run on Windows to help validate the accuracy of Wine's tests. So if you've got a spare PC laying around, give it a shot. It's bandwidth requirements are minimal - a full Wine test suite is only about 650k. Even if you only boot into Windows occasionally it can provide useful results.

Fixes Rob Shearman

Erich Hoover couldn't get the Blizzard Updater to run, I haven't been able to get the blizzard updater to run on recent versions of wine (I've downloaded from CVS to make sure there isn't a fix). I'm not sure if this is something wrong with my setup or a bug with wine (i recently reinstalled my system with Fedora Core 2 and am no-longer running the same version of wine). I'm executing programs with "setarch i386 wine <appname>" but the blizzard updater seems hosed (though Diablo II and Warcraft III run fine). It appears that the updater doesn't launch correctly

Rob Shearman asked for some more info so that he could debug it. Saulius Krasuckas sort of recognized the problem; it appeared to affect a few other programs. He gave a bit of a background on it:

AFAICS this case may be related to already known issue [1].

The bug is still present in the CVS. If it's the same bug I urge to reverse this patch [2] (if compiling by yourself) or just use Wine version prior to the date "2004/04/19 23:02:35". For me reversing [2] patch worked out fine.

Rob then created a patch and asked if it fixed the problem. Both Saulius and Erich reported success.