World Wine News

All the news that fits, we print.
by Brian Vincent
Issue: 329

XML source
More Issues...

This is the 329th issue of the Wine Weekly News publication. Its main goal is to smile. 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

This week, 172 posts consumed 316 K. There were 67 different contributors. 35 (52%) posted more than once. 35 (52%) posted last week too.

The top 5 posters of the week were:

  1. 13 posts in 37K by stefandoesinger at (Stefan Dösinger)
  2. 10 posts in 10K by dmitry at (Dmitry Timoshkov)
  3. 8 posts in 7K by dank at (Dan Kegel)
  4. 8 posts in 8K by twickline at (Tom Wickline)
  5. 8 posts in 14K by nlaw at (Nick Law)

News: Summer of Code Projects Archive

The big news this week was the announcement of Google's Summer of Code projects. Ten projects were approved for Wine. Even more exciting, each of those 10 projects are really strong candidates. If even half of them get completed we'll have some wonderful new functionality in Wine. Google has continued to expand this program each year. There were nearly 6,200 applicants this summer with over 900 being accepted. Here's the list of Wine projects:

  • Improve sound in wine by Maarten Lankhorst, mentored by Marcus Meissner
  • Improve Wine's rich edit implementation by Matthew Finnicum, mentored by Ulrich Czekalla
  • The DIB Engine by Jessie Laine Allen, mentored by Huw D M Davies
  • Implementing mscoree.dll and Mono-WINE bridge by Bryan DeGrendel, mentored by James Hawkins
  • Tablet PC support in Wine by Carl John Klehm, mentored by Daniel Richard Kegel
  • Beginning of Direct3D10 implementation by András Kovács, mentored by Stefan Dösinger
  • Improve Wine's built-in text editors by Alexander Nicolaysen Sørnes, mentored by Eric Pouech
  • Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine) by Marcel Partap, mentored by Detlef Riekenberg
  • CHM compiler by Miikka Viljanen, mentored by Jacek Caban
  • Improve Wine portability, make Solaris x86/amd64 a first-class supported platform by Albert Lee, mentored by Juan Lang

Kai Blin, who's worked on authentication in Wine for the previous 2 summers, was accepted for a Samba project this year to improve winbindd support. What's interesting about that is Kai has enough experience with Wine to understand what would be needed in Samba for improved support.

A new Wine beta arrived last Friday. Noted changes include:

  • Broken aRts sound driver now removed for good.
  • Many fixes to the Quartz DLL sound support.
  • File I/O performance improvements.
  • The usual assortment of Direct3D fixes.

The 'File I/O' mention lies in some work being done by Alexandre and goes right to the heart of the wineserver. I won't even pretend to understand the changes being made there, but it seems interesting.

Cedega 6.0 & Wine Benchmarks Archive

There's a little topic that doesn't get covered much here. In fact, it's something that doesn't really get covered anywhere and it's probably time to try to set the record straight. We'll start with the Slashdot announcement of TransGaming's Cedega 6.0 which read:

Today TransGaming introduced Cedega 6.0, which is the popular Linux game emulator based upon WINE.

Here's the facts you need to know about Wine & Cedega:

  • Cedega's core is based off the original Wine tree and was forked in 2002. There are several core components that no longer share a similarity with Wine as it exists today.
  • TransGaming has not actively contributed to Wine in about 5 years with the exception of a few patches (less than 5 a year.)

So any time I hear Wine and Cedega in the same sentence I kind of cringe. They're really two different codebases at this point. Why is that? Well, it all goes back to Wine changing its licensing from X11 (BSD-style) to the LGPL about 5 years ago. See WWN issues #115 , #116 , and #117 for more info. So Wine switched its license, TransGaming kept using the old codebase, and now the two have diverged. Except.. TransGaming has realized that some of the stuff created by Wine is necessary and they've imported specific DLLs into their codebase and kept them under the LGPL license. Wine's modular DLL architecture allows that pretty easily.

Okay, so the code is different. How about the relationship between the two projects? Despite rumblings that might appear here and there on the mailing list, the relaionship isn't that bad. Really it's more that there isn't a relationship, however there doesn't seem to be animosity between the two groups. The last in-depth communications (public at least) seemed to have been in 2004 when Gav State came to WineConf 2004. At the time he basically pitched a few technical changes for Wine and all of them were shot down. While the two projects were diverging before that, that was probably the event that ensured the two projects would go their own ways.

Okay, so now you know some of the background. Saying that Cedega is based off Wine technicallly isn't incorrect, but it does imply that Cedega has all the new architecture of Wine that's happened in the past half decade.

A benchmark was done and linked from the Slashdot announcement. It led Tom Wickline to comment:

I have been pondering the thoughts of running every benchmark that I have on Wine, Cedega, XP, and CX to see where we stack up in the performance game.

And while doing my daily reading of news sites I came across this posted on /.

Those guys ran 5 game tests and Wine's performance is clearly superior to that of Cedega on benchmarks where Wine was run. They give no details of the Wine configuration, so I can only presume it's a default setup. And since they're *trying* to paint the best picture possible for Cedega, they don't point out that Wine is superior!

    "It is also important to note that there were minimal performance differences between WINE 0.9.32 and Cedega 6.0. Granted there are only five benchmarks in this Cedega 6.0 performance preview, but the level of performance for Cedega does look extremely promising and we will continue to look at Cedega 6.0 and report back in future articles."

Should read : Cedega's performance is currently lagging that of Wine 0.9.32 and with each Wine release Wine's performance and feature set is continuously improving!

I'm open for thoughts and suggestions....

Apparently what's not said in that benchmark though is that all of the games are using OpenGL, not Direct3D, for rendering. Really Direct3D is where Wine and Cedega have completely different codepaths. So both Henri Verbeet and Stefan Dösinger suggested a D3D comparison would be much more useful. On a slightly different note, Stefan mentioned some informal benchmarking he had recently performed himself using just Wine and Linux vs. native Mac OS X:

Though the interesting thing is that I did my own native Linux vs native Mac OS X vs Wine benchmarks with glExcess a few days ago. I got pretty much the opposite result. Granted, my benchmarking code was very primitive, so read the results as +/- 10 fps, and this was on fglrx. But I got remarkable differences between wine and native, with native being up to 2 times faster.

Out of interest I did a quick check on nvidia. The difference is smaller, but there too (990 vs 1100 fps in the first glExcess scene at 640x480). Still a ~10% difference.

I also tested winelib vs PE .exe (with msvc6) and found no difference (That was 990 (winelib) vs 980 (PE)). The small differences could be because of my shitty benchmark code or because of compiler differences.

OpenGL Child Windows Revisited Archive

OpenGL child windows have been broken in Wine for quite a couple of years now. It was broken (some would say 'fixed') when the window management rewrite occurred. There's been some ideas floated about how to fix it, but nothing has really come of it. For more background on this issue, see the OpenGL wiki page. Ulrich Czekalla floated a a patch last October, but it was never included in Wine. Roderick Colenbrander sent a patch this week with a different approach and gave an excellent description of the challenges behind the problem:

This is an updated version of the child window patch from Chris Robinson. I have added some fixes to it which were found by testing it with lots of programs.

Windowed OpenGL

Several options have been discussed over the years for solving the windowed OpenGL issues. The lazy option was to use pixmaps but you would lose hardware acceleration. A better way but similar was the use of pbuffers but still they are poorly supported by most drivers (only Nvidia has decent support).

One of the most attractive solutions is the use of glScissors/glViewport changes. This path works now if you apply Ulrich's latest patch which is in bugzilla (2398). Though for optimal performance you need specific OpenGL extensions. Second a number of standard OpenGL calls require changes and some aren't done yet (glReadPixels and friends) but right now it is one of the best solutions.

Another way of solving the windowed OpenGL problem is by using X child windows for the OpenGL window. In the end this results in the same as Ulrich's glScissor work but with the advantage that it should work fast on all OpenGL implementations as it doesn't require special extensions. Further it doesn't require the patching of OpenGL calls.

OpenGL pixelformats

Next to the windowed OpenGL issues, there's the pixelformat limitation in Wine. Right now only one pixelformat can be used. Most programs use ChoosePixelFormat using which you can request a pixelformat but the call isn't guaranteed to give you back what you want. For this reason most programs aren't very critical.

These days more and more programs are more critical. They use wglChoosePixelFormatARB which does give you what you want or programs enumerate all pixelformats using DescribePixelFormat and choose what they want.

Anyway the issue is that the single pixelformat isn't enough anymore. A recent report from WoW on Intel drivers is a proof of this. The game didn't like the single format exported by Wine. Another example is the IKEA kitchen planner tool which uses DescribePixelFormat to enumerate all formats. It expects to find a match in a format. Right now it doesn't find any match and calls SetPixelFormat with iPixelFormat=0 (which is invalid).

Like the above two programs there are many other programs with issues due to pixelformats. I believe that perhaps a few of them are fixable (by adding more hacks or by lying to programs). If we had more pixelformats, I think the issues could be fixed. OpenGL child windows would fix this issue as the child doesn't have to use the same pixelformat as its parent (!).


If we would use OpenGL child windows in Wine that would fix most windowed OpenGL issues and second it would allow us to use more pixelformats as a child window doesn't have to use the same pixelformat as its parent.


As mentioned before the patch was mainly made by Chris Robinson and I have added a few fixes to it to make it more compatible. Basically a child window is allocated for a hdc during SetPixelFormat which needs to be called on every hdc before it can be used with OpenGL. That's basically the biggest change to the OpenGL code. For the rest some x11drv calls like SetWindowPos had to be patched in order to move the child window when needed.

Below you can find a list of tested programs and the results. As you can see it works correctly for most of the tested programs. Three of the tested programs don't work correctly of which two are not related to the use of child windows, so overall the result is good.

I'd like to know of more programs that work / don't work and I like feedback on the patch.

Properly working programs:

  • Blender
  • Google Earth
  • Google SketchUp
  • Lightwave 6 + 9
  • MilkShape3D
  • Terragen + Terragen2
  • VLC OpenGL plugin
  • Valve Hammer tool
  • Weatherscope
  • Q3Radiant

Unfixed programs:

  • Truespace 6.5; The program uses OpenGL for its main window and uses some floating win32 toolbars. The child window obscures them, perhaps the SHAPE extension for X can be of help here to cut parts away.

Other broken apps not child window related:

  • NWN Model viewer; The program seems to do be using WGL in an illegal way but seems to get away with this without any failures on Windows. I don't know what's going on. It also never worked correctly before when there were X windows. It now behaves the same as before. Using Ulrich's patch it works but that's basically an 'accident'. It isn't because the code is fixed.
  • IKEA kitchen planner; The program uses multiple child windows one for a 3D preview which works fine and it uses one for drawing on a grid. When drawing things on the grid, the objects quickly disappear. There's some buffer swapping issue I guess. The same happens without the child window patch and using Ulrich's patch. So the issue is not related to child windows.

With a little luck we'll see a solution soon. This is one of those meta-bugs keeping an entire class of applications from working.

DIB Engine Ideas Archive

Felix Nawothnig posted some ideas for how a DIB engine could get off the ground:

Okay, I've spent the last days looking into this matter and I'd like to suggest a way to get it started. So. This is the plan:

  1. In winex11.drv:
      -INT X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL lossy)
      +HBITMAP X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL force)
    Lossy isn't used anywhere for LockDIBSection anyway. Force means that the function will only lock if the DIB is already in AppMod. The returned bitmap is of course physDev->bitmap->hbitmap.

    Rationale: If you lock the DIB to write on it, it makes sense that the function actually provides you with that DIB.

  2. Export LockDIBSection/Unlock to gdi32.

    Adding more exports is not nice but there really is no way around that, right?

  3. Move dc->funcs to dc->physDev->funcs. Many changes but mostly mechanical work.

    Rationale: This really belongs there. And I need it. :)

  4. Now we write dibdrv.c for now just containing DIBDRV_Install and DIBDRV_Remove. That function will go through the physDev->funcs list and overwrite each function pointer which is actually implemented with DIBDRV_PutPixel(), whatever.

    DIBDRV_Install/DIBDRV_Remove will be called from BITMAP_SelectObject() when we switch from non-DIB to DIB and vice versa.

    Note that we can't use DRIVER_load_driver here because of the wanted "forward to original driver when not implemented".

    For this we will need to extend the "for DIB objects" part in BITMAPOBJ by

      const DC_FUNCTIONS *orig_funcs;
      DC_FUNCTIONS local_funcs;
    where orig_funcs to the old physDev->funcs and the new physDev->funcs points to &bmp->local_funcs.

  5. In dibdrv.c we get us:
      enum {
        DIBDRV_MIXED, /* Choose driver depending on current AppMod */
        DIBDRV_ALWAYS, /* Always use DIBDRV (unless function not implemented) */
        DIBDRV_NEVER /* Always use DC driver */
      } DIB_Mode = DIBDRV_MIXED;
    and DIB_Lock(PHYSDEV physDev) / DIB_Unlock(PHYSDEV). Now, here comes the reason we need the HBITMAP from LockDIBSection() and funcs inside PHYSDEV:

    Since we don't have the DC here we have no way of calling LockDIBSection(), forwarding to the original driver if NEVER/MIXED or writing to the actual DIB in case of MIXED/ALWAYS.

  6. From this point we can start implementing one function at a time, touching nothing but dibdrv.c.

So far so good. I did all those steps (except 3., I hacked around that in my local tree) in a clean way and it works nice (for 6. I implemented SetPixel() and tried that with a test-app).

I attached patches for the steps 1 2 and 4 so you can see where this is going.


Then Felix noticed someone had been accepted for Google's Summer of Code to work on this very project. That someone is Jesse Allen and he replied:

Honestly there have been attempts before to start the DIB engine and I've seen them already. I don't think it will affect what I do, as nothing has really been accepted yet. But I suggest you find out who my mentor is and show it to him first. See if what you have done can somehow be worked into the mentoring process (hopefully it's good enough :D). I think it's early enough to work it out.

Alexandre then replied and commented on some specific points that Felix proposed:

[regarding #2]

No, LockDIBSection is a driver internal detail, gdi32 has no business knowing about this.

[regarding #3]

No it doesn't, physDev is an opaque structure as far as gdi32 is concerned. Data needed by gdi32 belongs in the DC structure.

[regarding #4]

You certainly don't want to store the full function table in the BITMAPOBJ, it will be the same for all bitmaps. All you need is one function table for the DIB driver and one for the normal graphics driver. Forwarding to the graphics driver can be done privately in the DIB driver, gdi32 doesn't need to know about it. And you probably want a separate physDev pointer for it, you'll need to maintain state for DIBs too.

Felix then replied to Alexandre's points to clarify what he'd meant.

Rolf Kalbermatter replied regarding #1 above:

I had actually a bit of a different idea but didn't get around to trying it yet. I was thinking about adding an extra value to the DIB section sync state such as DIB_Status_Conf. With this X11DRV_DIB_Coerce would decide based on a configuration setting if it should do DIB_Status_GdiMod (DIBDRV_NEVER in point 5.), DIB_Status_AppMod (DIBDRV_ALWAYS), or DIB_Status_AppMod if the DIB is already in DIB_Status_AppMod (DIBDRV_MIXED). The return value would someow indicate to that driver function if it should just simply return with a failure leaving the rest to GDI32 to deal with or do for the time being the actual work as it does now.

On driver failure (or nonexistent driver function) GDI32 would invoke the corresponding DIBDRV function for non-meta DCs. A nonexistent driver function would still work thanks to the exception handling for DIBs being accessed in application mode, although it is not the preferred way to deal with this until the DIB engine is fully functional (and the DIB handling could then be consequently removed from x11drv entirely).

This would reduce the modifications to x11drv to a minimum and also GDI32 wouldn't need much change at all. Adding a new DIBDRV function would be a change in GDI32 to add the DIBDRV call on failure of the driver function and then switching the DIB_Status value in that driver function to DIB_Status_Conf instead of DIB_Status_GdiMod.

Regardless of whether any of this is the appropriate plan of attack, it's exciting to see that 3 different people are interested in this.

Removing Audio Drivers Archive

Audio in Wine has been receiving more attention lately. Maarten Lankhorst has plans to do a lot of work in this area and he's starting by doing a bit of Spring cleaning. First on the chopping block was the winearts driver:

As far as I can tell, it has been disabled for at least 4 months, and I didn't hear anyone about it, so it seems like a good idea to remove winearts, if anybody feels like reviving it, it would be easy to do so by reverting this commit, but KDE itself is moving away from arts, so I don't see a point in keeping this broken, disabled audio backend.

That patch went through. Next up he wanted to remove a few of the other slightly obscure drivers:

There are 5 different audio drivers for linux, I think this is a bit overkill, so I propose to remove the esd and nas drivers, I don't think anyone uses esd, especially that since for that task alsa can be used now since dmix addon.

I'm not sure what nas is for, but it seems to be 'network audio system', I haven't seen any use for it, except that it causes a 30 seconds slowdown at showing 'audio' tab in winecfg. I don't think anyone uses it.

For esd I think it's best to remove it, for nas I'm also for removal, but I'll settle for removing it from the winecfg list same way as winearts was disabled for a while.

What are your thoughts about this?

Vit Hrachovy raised his hand to mention he was using esd. Francois Gouget raised a good point about NAS:

NAS is used to get sound on X terminals. It would be interesting to get input from the LTSP and thin-client crowd before concluding it can be removed.

Other discussion seemed wary of removing working drivers. With regards to speeding up winecfg, Damjan Jovanovic supplied a patch to help with that:

These changes reduce the time needed to load the Audio tab of winecfg from 12 seconds down to 5.


  • Load audio drivers in multiple threads, so the length of time the GUI is blocked for is the length of the longest driver load time, rather than the sum of them all.
  • Keep audio drivers open until they need to be reloaded, because it can take a very long time to load them multiple times.

NT Named Pipes Archive

Dan Kegel forwarded a question from the c.e.m.w. (aka newsgroup asking about NT named pipes support (not the same as Unix named pipes):

A user asked in

whether Wine could communicate with remote machines via named pipes yet (he needs it to talk with an SQLServer box).

I know Alexandre's been poking around in that area, but I think he's working on local networking, not remote. I also know Kai Blin had looked at this, but I don't know where he left it.

Can someone summarize the current state and plan, if any?

Here are some past discussions on the topic:

Kai Blin, who's delved into this area, replied:

I distinctly remember Juan asking me to poke Samba's Steve French about this for last year's SambaXP conference. Steve seemed happy to add some hooks to his cifs module fur us, but I think no one came up with anything specific.

I'll be going to SambaXP again this year to show off our use of ntlm_auth to have outlook authenticate to an exchange server. Right before SambaXP starts, the Samba team will meet at SerNet for a "developer day", I'm going to be there for that, too. If we can come up with a hard list of requirements, I can look into getting this up to speed a little bit.

Now, we've been at this topic before, but as far as I can recall, we never really made much progress on this. Named pipes, as well as user handling and some parts of netapi32.dll scream for a closer interaction with Samba. As discussed before, the LGPL vs. GPL licensing is an issue, but maybe we can work around that by interfacing with winbindd to get the stuff we need.

A quick search through our wiki shows me that Juan put up three pages about this when we discussed this last time.

If we can flesh those out in the next week or two, I'll have some more substantial things to take with me to SambaXP to discuss this. I think the wiki will be ideal to collect this.

DInput Bug Archive

Martin Traverse came up with a patch to fix a mouse handling problem that was recently introduced:

I have done a bisection on bug #7640, mouse jitter in Halo which rendered the game unplayable. I have a patch which fixes the problem on my Gentoo system against wine-0.9.35.

Bug is introduced by

    commit b22ff8018aca7c365e505f1db7732f7050ae259b
    dinput: Remove MsgWaitForMultipleObjects call

(Note: commit --59b also severely slows dinput response, fixed soon after by

    commit 685a3e6a6ed623718f640e8906bd44fbca3d8b2c
    dinput: Release critical section before warping mouse)

Bug can be alleviated by reverting the original commit until

    commit af71538d3343a1cec73e75391a7ebfd5b3ed94ee
    dinput: Remove duplicate Keyboard->Poll it is the same as base class

I put back the specialised version of Poll with MsgWaitForMultipleObjects, which fixed the problem, and have sent a patch. It was only necessary to alter Poll, not GetDeviceState. This is the first time I've sent in a patch, obviously I'm not familiar with the code so I'd be grateful for any comments.

Vitaliy Margolen disagreed with the patch and explained why it was wrong:

You patch is not correct for one simple reason - it "fixes" mouse by changing keyboard code. I have removed some code like that from dinput while cleaning it up. It had way too many hacks - leftover from some wholesale changes by TG. Of course none of their patches stated exactly what they did and why.

To fix the problem, you first need to find the reason why the code Wine has doesn't work. And how the code you're adding will fix the problem. Then you need to make some tests to check/verify what's going on.

Running a small test program (attached) with native dinput shows that it does not call MsgWaitForMultipleObjects in kbd->Poll at all (look at +relay channel). You can experiment with this program a bit more to see what dinput is doing and how ;)

Windows/Linux Shared Objects Archive

A request that comes up from time to time is to take a Windows library and be able to reuse it as a Linux shared object. Phil Lodwick asked this week about it:

My googling skills are letting me down today. I believe I have seen several people requesting to do the same and answers indicating it is possible. However, after several hours of reading email archives from 2000-2007 are am officially confused :-(

I have successfully ported an application using winelib. However, what I really want to do is port a DLL to an SO which I can use natively from a Linux application.

I believe this is something that can be done with winemaker/winebuild etc if I just get the recipe right -- correct?

Stefan Dösinger explained the problem with that and why a lot of people overlook why it's so hard to do that:

I'm not the DLL expert, but I think you're missing something here.

The problem is that your windows dll will most likely use the windows APIs (otherwise, don't use wine at all). The windows APIs depend on some other things, like a few memory management constraints, the windows registry, and most likely other things too. So you can't lift the Wine core dlls outside of the environment wine sets up.

Applications and DLLs ported using winelib are native Linux .so files. So you can try to link them in, but you'll get unresolved symbols which in the long run will end up somewhere in and And I think both of them depend on the environment wineloader sets up.

So the options you have are doing a real port of the dll if it does not depend on the win32 api too much (so ditch wine), or put the whole app into wine (do a full winelib port of the application), or to write some proxy winelib app and talk to the DLL using ipc like sockets, pipes, shared memory, etc.

For that reason, it's recommended that a whole application gets built as a Winelib app. Phil didn't want to do that in this case because he wanted to provide a library for other developers.

All Kernel Cousin issues and summaries are copyright their original authors, and distributed under the terms of the
GNU General Public License, version 2.0.