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 #249 For 19 Nov 2004

By Brian Vincent

Table Of Contents


This is the 249th issue of the Wine Weekly News publication. Its main goal is to get a sugar buzz from candy. 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 180 posts in 817K.

There were 66 different contributors. 37 posted more than once. 25 posted last week too.

The top posters of the week were:

1. News: CrossOver Office 4.0

13 Nov 2004 - 19 Nov 2004 (1 post) Archive Link: "News"

Topics: News

People: CodeweaversCodeWeaverscodeweaversJeremy WhiteAppleNewsTransGaming

The guys over at CodeWeavers have done it again - a new version of CrossOver Office was released this week. This time the version number was bumped up to 4.0 to signify a major release. New applications are now supported which the press release describes:

iTunes, which recently celebrated its 100 millionth music download, allows users to import music in AAC, MP3 or Apple Lossless formats and convert unprotected WMAs to MP3. Users can sync with their iPod, burn CDs, and complete other routine digital jukebox tasks; they can also use Apple's AirPort Express to wirelessly stream music from their computer to a stereo located in any room in their home. Apple's hugely popular iTunes Music Store, accessible from iTunes, currently contains more than 700,000 tracks and 450 independent labels with 30-second previews.

Adobe Framemaker ( is an enterprise-class authoring and publishing solution that combines the simplicity of word processing with the power of XML. Framemaker support under CrossOver will allow Linux users to develop professional-looking documents for both print and the web.

Oracle JInitiator is a Web-based tool for Java-enabled Windows browsers allowing developers and end-users to access Oracle Application Forms. JInitiator is a key enabling technology for deploying Oracle databases via the Web.

A lot of time was spent stabilizing this release to make sure it would work with the various distributions and permutations of them. Nonetheless, CodeWeavers is pretty up front about what this product can and cannot do and Jeremy White cautioned users to be careful installing it in his announcement. Jeremy also pointed to The Real Dirt for what you can expect to find in this release. Slashdot picked up that link and included a quote from it. Because of that, initial comments on Slashdot were filled with naysayers wondering if iTunes even worked at all. Two things happened with the comments though: moderators managed to weed out the pointless ones and CrossOver fans who have actually used the product came to the defense of CodeWeavers. For more info about the newly supported apps, check out CodeWeavers' CrossOver Compatibility Center pages for iTunes and FrameMaker.

In other news, TransGaming is promising support for Half-Life 2 in it's upcoming Cedega 4.2 release.

2. Kernel Integration Problems

12 Nov 2004 (22 posts) Archive Link: "Kernel 2.6.9 - Issue Found"

Topics: Integration

People: Paul RupeJesse AllenEric PouechRoland McGrathMike HearnRoland

Late last week reports began surfacing about problems running Wine with some of the new kernel versions. Paul Rupe was the first to report it, " Has anyone tried Wine with Linux kernel 2.6.9? I'm getting crashes with this version that don't happen when I reboot back to I haven't had much luck debugging it so far, but each time, ps shows a <defunct> wine-preloader process and wineserver still running."

Theories began to circulate that the kernel, glibc, or space aliens were the culprit. On Saturday, Jesse Allen tracked down what had changed and explained:

For the past two weeks I've been tracking an issue that I found with kernels greater than 2.6.8 / and wine. Starting with kernel 2.6.9-rc1, Warcraft III copy protection would not work -- ie please insert disc. I found changes to the cdrom driver in rc1. Reversing them did not work. For a while I was lost to what could have changed. Then I had an idea: search for changes that could affect the way processes run. That led me to reverse changes related to ptrace, and I found a series of patches that break Warcraft III copy protection code.

Patch 1: ptrace single-stepping fix

Patch 2: make single-step into signal delivery stop in handler

The next patch may depend on patch #2 because it is a bug-fix based on 2.

Patch 3: Fix PTRACE_CONT after single-step into signal delivery

Reversing patches 1, 2, and 3 in kernels 2.6.9-rc2 and greater (through 2.6.10-rc1) will allow War3 to work. I tried 1 & 3 without 2, but it failed leading me to believe that 1 & 2 are required. I didn't try 1 & 2 alone because I think reversing 2 would require 3 reversed.

All the patch changes seem to be on ptrace single-stepping. However, there is at least one ptrace single-stepping patch that seems to make no difference at all:

There are other single-stepping patches for different non-i386 architectures but I have no idea on these because I don't run the others. They are meaningless for wine anyways.

Now that I've identified a problem, I'm curious where else it's cropping up. Paul Rupe, could you try reversing these patches to see if this fixes your crashing problem? And how about those people having trouble with debugging?

Then I guess the next step is to find out if this is a wine bug or not. If it's not, then it may be a kernel bug and we should report it to the kernel devs.

Eric Pouech was able to deduce the problem:

This shall harm us...

Basically, when a program is traced by ptrace, and single stepping, the patches allow to also single step in the program's SIGTRAP handler... In Wine case:

To sum up, it's not a wine bug nor a linux bug, it's just a change in linux behavior that breaks wine. Linux's new approach is to say a signal handler is part of the application, and should be traced (in a debugger for example) as a regular function. Wine sees signal handler (at least SIGTRAP, SIGSEGV...) as kernel plugs put in the application (NTDLL) and used to send back information to Wine server. Those two options are not compatible.

IMO, the best option would be to add an option to turn on/off the behavior in ptrace (to allow or not single stepping in signal handlers). Fixing Wine would be doable, but somehow ugly (ie it would mean turning the TF off in Wine server to let our handlers run...)

Mike Hearn set about contacting kernel developers to see what could be done. Apparently Linus got a heads up about it and included a change in 2.6.10-rc2 to address the problem. Another kernel developer who's worked on this issue, Roland McGrath, followed up and mentioned that the change needed to be propagated to a few other parts of the kernel, " Your change hit only one spot of three in arch/i386/kernel/signal.c where PT_PTRACED is now tested and it should be a "is PTRACE_SINGLESTEP in effect?" test. Also the same spots in native and 32-bit emul for x86-64."

Initial testing seemed to confirm that changing just the one spot wasn't enough, at least the original copy protection problem Jesse experiences still existed. Eric thought the patch was headed in the right direction, but even he couldn't tell if it would fix everything. No more changes were made to the signal.c code, so it's unclear what the direction on this is.

3. oprofile & Wine

17 Nov 2004 (2 posts) Archive Link: "profiling GTA4. question about polling"

Topics: Debugging

People: Brian GunlogsonBrian GunlogsdonJason EdmeadesRaphael JunqueiraMark

Profiling has been a topic that's popped up from time to time as being an area Wine needs to tackle. Some of the major architectural issues, such as DLL separation and stabilizing wineserver, have been slowly become reality. What's now evident is there are bottlenecks that could be identified leading to an increase in performance. Brian Gunlogson started a thread this week about just such an issue:

GTA4 (Grand Theft Auto: Vice City) runs on Wine with no additional tinkering! Albeit horribly slow.

A profile of GTA shows that only one D3D function (drawStridedSlow) needs major optimization. According to the oprofile results, polling seems to be the major bottleneck.

(the top of a flat profile generated with oprofile)
samples % image name app name symbol name
2177620 14.0147 wine-preloader drawStridedSlow
1681661 10.8228 vmlinux vmlinux do_pollfd
1025198 6.5980 vmlinux vmlinux pipe_poll
515461 3.3174 vmlinux vmlinux add_wait_queue
423342 2.7245 vmlinux vmlinux poll_freewait
423185 2.7235 vmlinux vmlinux __pollwait
354490 2.2814 vmlinux vmlinux fput
285473 1.8372 vmlinux vmlinux sys_poll

I'd like to optimize this. Any hints?

Raphael Junqueira replied to Brian and mentioned a way for the function to be optimized. Then the discussion turned towards using oprofile and Brian explained how he used it:

Just download the latest CVS from and see the README. I assume you know how to get it compiled and installed :)

As root:

Profiling is on, run the application to profile and do not do anything else.

When done:

Jason Edmeades outlined the current direction of Direct3D:

Firstly thanks for the profiling info - its something I have been waiting to try when I get through the d3d9 changes. We have always known that routine was bad (hence the name 'slow'!) but that confirms it.

Re the splitting into wined3d - You asked "Is this a tedious task or does it require knowledge of the codebase?"... It's a bit of both. I am taking it slower because I am trying to ensure the patches get committed so I don't end up reworking things, and I only have limited time so I don't want to waste it.

At the moment I am 'stuck' trying to get a particular patch in, which will dictate the future direction of lots of other patches, so it is important we get it right. Once that's done, I really hope to make a lot of progress relatively quickly, and once I get beyond a certain point, feel free to hack away. I hate the fact I am holding anyone back!

Please do take Raphael's test patch and try again - I would be interested to know if it makes a significant difference (which I do believe it should).

I would be very interested in any other profiling results, and if you feel like improving things in the code please go for it. One thing I always fancied doing was to profile the 3dMark2001SE utility, and see how close to windows performance we can get and identify the bottlenecks.

4. iTunes Issues

16 Nov 2004 - 17 Nov 2004 (4 posts) Archive Link: "[Discuss] iTunes in 4.0"

Topics: Codeweavers

People: Tony RicciottiJeremy WhiteMike HearnCodeWeaverscodeweaversAppleNewsCodeweavers

Almost every thread covered in the Wine Weekly News comes from the wine-devel mailing list. Once in a while something pops up on another list that's pertinent enough to cover here though. Over on CodeWeavers' mailing list there was some discussion about the performance of iTunes. The details of the problems encountered really center on Wine. Tony Ricciotti started off a thread by describing his experiences:

It appears that the installation of iTunes completes properly, but cxoffice reports a failure of the install.

The menus in iTunes disappear as you roll the mouse over them.

When adding files to the library, the dialog box that is up showing the progress of the import is supposed to be an application modal box, which, should stop you from bringing the iTunes app to the forefront but you can, requiring an ALT+TAB to bring it the dialog to the front.

Still receiving the the error about the CD/DVD burning driver not being installed properly. I know it is not supported, but there must be some way to fool it. lolol

Performance overall is GREATLY improved, however, songs skip a little when playing in iTunes and the wineserver is sucking up ~95% of my P4 3.2G processor. Unacceptable IMO. :)

Still need to test the iPod syncing.

Regarding the CPU usage, Jeremy White explained some workarounds:

Yup; this one stinks. This happens on 2.6.x kernels, primarily. iTunes is a highly threaded application, and has some strange mechanics in how it delivers sound to the audio system (and Wine's audio system is imperfect, at best).

You can improve the situation in several ways; the faqs on Quicktime sound settings can help (set Quicktime sound output to waveOut and to the sound frequency supported by your sound card, which might be 48khz). Also, the mini player seems less affected (although it's still not great).

Finally, and this is no answer, but iTunes suffers from skipping on Windows too; if you move windows around in Windows you can get it to skip. Candidly, I think the problem is that Apple doesn't use a large enough buffer for the music output, and has an overly complex architecture that is vulnerable to timing changes (Linux timing is different than that of Windows, to my dismay).

Mike and Alexandre and I worked on this all through the weekend and could not get to the bottom of it; Mike and Alexandre are continuing on in the hope that we can have a fix.

But, frankly, we felt that this release had been delayed far too many times and that it was good enough to ship and call it 'bronze'.

Mike Hearn gave a more in-depth explanation of the problem:

It has strange mechanics in a lot of things, to be quite honest it appears Apple seriously bodged the Windows port which limits how well it'll run on CrossOver (can't be more catholic than the pope ...)

I took a brief look at the 100% CPU thing but didn't come to anything conclusive: basically the problem is that iTunes spams the wineserver with apparently pointless message traffic. I don't know if it does the same on Windows but if so it'd explain the ~10% cpu usage you see on the real thing. Unfortunately on Wine sending an inter-thread message is a bit more expensive than on Windows, multiplied by bazillions of times per second and you get 100% cpu usage.

The so-called "QTGenerateNullEvents" message sounds awfully like some kind of scheduling hack inside iTunes or QuickTime to me ... it's intermittent as well, I've seen iTunes playing audio from the music store as opposed to the library but not doing this. So possibly there's something we can do to fix/supress this behaviour.

It appears that work is progressing in this area and some preliminary patches are being tested that fix it.

5. Changing Wine's Look and Feel

30 Oct 2004 - 16 Nov 2004 (16 posts) Archive Link: "Default System Colors"

People: William Poetra Yoga HRoderick ColenbranderKevin KoltzauWilliam Poetra

William Poetra Yoga Hadisoeseno has come up with some patches to make Wine look nicer and it led him to ask this week:

The last time I submitted a patch to change the default system colors from win95 to winxp (classic), it wasn't merged. I think this was because I didn't discuss it here.

So now, should we change the default system colors for WINE, from win95 to winxp (classic)? I really think it looks a lot better with the new colors, as the win95 colors are too dull (MS certainly must have done a lot of research into this).

William came up with a lot of new stuff, including a patch to do a gradient through the title bar. Several folks expressed approval of the changes. Roderick Colenbrander thought it could be taken a step further:

Now that I have thought about it a while longer perhaps it is the right idea to already start using uxtheme. If I remember correctly uxtheme is already usable the only problem is that we don't use it to actually modify the look of wine widgets. Kevin Koltzau, the original uxtheme author, made the dll able to parse original windows xp themes and further he used it to theme his own app with it (atleast the color part). It might be a good idea to stick to the old wine colors and add a winelook uxtheme option. When the option is enabled we use uxtheme to parse a theme file and it will then adjust the colors. The theme file will be then of the same type as the files used on windows, so you could even use windows themes. After this a gtk/qt backend could be added to uxtheme.

Roderick went on to explain more about how uxtheme works:

Some time ago I looked into uxtheme a bit and it roughly works like this. The dll itself is responsible for loading theme files. After a theme is loaded it can for example be used to load a bitmap and draw as for example the background of a window or it can change the color of controls.

Uxtheme can be used in two ways. Useally all theming is done by windows itself. To do the theming microsoft ships a new version of the user and common dialog dlls which use uxtheme to do the theming. In the other case you can call uxtheme yourself and then you can decide yourself what you want to theme.

Not sure if I said it all correctly. Likely Kevin Koltzau knows it a bit better as he is working on uxtheme. Not sure what the current status of the dll is but atleast our controls aren't using it for theming yet.

The big issue with using uxtheme seems to center on Wine's controls not implementing it. Kevin replied and described how some apps use uxtheme:

Under Windows XP, the only way for an application to be themed is if it has a manifest in its resources requesting comctl 6.0. If an app was written for Win95 it will always draw with the old style as it has no manifest. However, the color scheme of the theme will still be applied to all applications

It is possible to add a a manifest for an existing application without modifying the executable by placing a <app>.exe.manifest file in the same directory as the application executables, but your mileage may vary on this approach.

A theme-aware application can call the IsThemeActive and IsAppThemed to determine if a theme is active, and if the current application is themed. XP has a user-configurable blacklist to prevent applications from being themed, even if they are theme-aware..hence the two API calls.

The final decision on changing Wine's look and feel will be up to Alexandre. Since he's been gone all week it looks like the resolution of this thread is in a holding pattern.

6. Usability Problems

19 Nov 2004 (1 post) Archive Link: "Problem roundup"

People: Mike Hearn

Mike Hearn pointed out:

So, trolling reveals the following top 3 problems users are having with Wine currently:

  1. The RH9 RPMs are apparently being compiled with epoll support linked in. This is causing user pain. We should really be using dlsym here, why are we not again?
  2. Our bestest bestest friends over at InstallShield Corp have released a new version of their elegant and simple product, which refuses to start with builtin DCOM.
  3. Some people still seem to be getting the "C:\\Windows\\System does not exist" message.

7. Lack of CVS Commits

18 Nov 2004 - 19 Nov 2004 (3 posts) Archive Link: "CVS updates?"

Topics: Project Management

People: Mike HearnAlexandre Julliard

Christian Britz wondered why there haven't been any CVS commits for over a week. Unlike many projects, Wine only has one person who makes commits to CVS: Alexandre Julliard. If there haven't been CVS commits for a while it usually means Alexandre is doing something. In this case, Mike Hearn explained, " Alexandre has moved back to Switzerland and there's no ADSL at the place he's staying. Once he gets a fast net connection set up he'll be committing. Hopefully he has more luck with this than I did!"

Alexandre pointed out that maybe it's not a bad thing for him to be away for a while, " Getting DSL shouldn't be too hard, but I have to find a place to live first, which isn't trivial out here... So yes, updates are going to be a bit painful over the next couple of weeks. The good news is that it's all part of an evil plan to prevent Jer from getting in touch with me so that I can concentrate on the wm [ed note: window manager] work for a while <g> "







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.