World Wine News

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 (www.adobe.com) 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.

For the past two weeks I've been tracking an issue that I found with kernels greater than 2.6.8 / 2.6.8.1 and wine. Starting with kernel 2.6.9-rc1, Warcraft III copy protection would not work -- i.e. 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

Included in 2.6.9-rc1
By Davide Libenzi?
http://linux.bkbits.net:8080/linux-2.6/cset_at_1.1803.144.55

This change includes a note that it could break debuggers. Reversing this change would allow War3 to work in rc1, but kernels greater than rc1 would still not work.

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

Included in 2.6.9-rc2
By Roland McGrath
http://linux.bkbits.net:8080/linux-2.6/cset_at_1.1832.59.196

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

Also 2.6.9-rc2
By Roland McGrath
http://linux.bkbits.net:8080/linux-2.6/cset_at_1.1847

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:

http://linux.bkbits.net:8080/linux-2.6/cset_at_1.1803.144.70

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.

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:

• the handler is wine's implementation to send the single step event to wineserver
• our code implies that the handler is not seen from wineserver (basically, that after executing the single step, the debugging event is sent to wineserver)

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 handlers (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 (i.e. it would mean turning the TF off in Wine server to let our handlers run...)

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)

I'd like to optimize this. Any hints?

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

As root:

# opcontrol --start
# opcontrol --reset
'--reset' clears out any old unwanted profiling data
# opcontrol --separate=kernel
'--separate=kernel' Separates output by library and kernel [this is the hardest option to understand].

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

When done:

# opcontrol --dump
'--dump' flushes remaining data to disk
# opreport -l >./myreport.log
Stores the flat profile in a file called myreport.log.

Firstly thanks for the profiling info - it's 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.

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 the dialog to the front.

Still receiving 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.

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, 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'.

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/suppress this behaviour.

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).

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 (at least 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 would be 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.

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. Usually 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 at least our controls aren't using it for theming yet.

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 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.

So, trolling linuxquestions.org 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.