Wine Traffic #316 For 11 Jun 

By Brian Vincent

Table Of Contents


This is the 316th issue of the Wine Weekly News publication. Its main goal is to rip apart the washer. 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 243 posts in 362K.

There were 63 different contributors. 40 posted more than once. 40 posted last week too.

The top posters of the week were:

1. GLSL Support

(12 posts) Archive Link: "wined3d: Another GLSL shader status update"

Topics: DirectX

People: Jason GreenMike HearnMicrosoftJason

Lots and lots and lots of work is going on in the DirectX world and we've got some new developers involved. Everything from minor bugfixes to complete rewrites of certain areas are in the works. A lot of the discussion is going on in #winehackers, but some of it trickles to the mailing list for review. This week we're going to take a look at shaders.

Shaders are a graphics concept that allow for extremely complex scenes to be rendered very quickly. They generally come in two flavors: pixel shaders and vertex shaders. At the heart of shaders are complex math operations generally involving things like matrices. Remember all that matrix math from calc III? Me either. On modern graphics cards these math calculations can be performed directly in the specially designed GPU's of the graphics cards rather than using the CPU of the computer. In the end, you get fancy 3D graphics. Shaders are responsible for creating fog effects, creating lighting and shadowing, etc.

Now, on Windows shaders are implemented by taking Direct3D calls and transforming the actions into Microsoft's "High Level Shader Language", or HLSL, that gets passed down to the graphics card. HLSL allows shader "programs" to be created that instruct the graphics processor what to do. On Windows, HLSL gets compiled to machine code by the DirectX libraries and pushed down to the graphics card for execution. That's a lot of overhead for Wine and fortunately it's not necessary.

On Linux, the mechanism to access the hardware of the graphics card is OpenGL. OpenGL 2.0 has more extensive shader support than previous versions and there's been an interest for Wine to be able to take advantage of that support. The OpenGL Shader Language (GLSL) approved by the OpenGL architectural review board and contained in the OpenGL 2.0 spec outlines an advanced shading language based on C. Using GLSL gives developers low-level control of the graphics pipeline similar to HLSL, except the compilation of the GLSL programs gets done within the OpenGL driver.

Wine has had shader support for quite a while, but it's relied on an older, less complete method. This week GLSL support was added by Jason Green in a series of large patches. Jason first posted an update a few weeks ago about the work and included some screenshots:

I'm working on the conversion from DirectX pixel and vertex shaders to GLSL function and have made a good bit of progress this weekend. At the moment, I'm able to run just about every simple vertex shader (version <= 1.4, and a few 2.0's) that I can find which already works on ARB_vertex_program (the current way that Wine handles this). I'm having a bit more trouble with pixel shaders, but I haven't really dug into it yet. Some of the really simple ones work, but I believe I'm missing a step in the texture binding code somewhere.

I've posted a patch to enable this shader generation here:

If you want to try this and help debug things, you'll have to apply the patch (it's against the current git tree as of 2:00 AM EST, May 30th). Plus, you'll need a video card and driver capable of using GLSL (type 'glxinfo' and look for "GL_ARB_shading_language_100") . You'll also have to set a new registry key in your Wine installation (it is case sensitve):

Here are a few comparison screenshots (note, yes, they should be identical ;-):

In theory, once this all works, we'll be able to support shader model 2.0+, which a lot of newer games either require or strongly suggest (aka prettier graphics). Now, there are plenty of other bugs to be worked out in wined3d, so this isn't the holy grail of patches or anything, but it will take us that much closer to supporting new games. Please lend a hand if you're able to. Thanks!

(by the way, many thanks to the entire #winehackers crew for all the help along the way so far, it's been fun)

Then last week another update was given shortly before the patch was committed, Jason described a bit about it:

Well, I've fixed the speed issues with using GLSL (it's now just as fast as ARB shaders for the ones that actually work correctly) and gotten a few other things to work correctly. However, I'm still having issues with certain pixel/vertex shader combinations. Ohsix caught on that it may have to do with sampler limits on graphics cards and how sampling/textures are handled different in GLSL that with ARB. I'm not sure at the moment and could use some help.

is the diff against the most recent git tree. There are still some ugly hacks lying around in there. Note that I've separated out most of the GLSL functions into a new file "glsl_shader.c". Once again, to use GLSL instead of ARB shaders, you'll have to apply this patch, have a graphics card that's capable of GLSL, and add the following case senstive registry key:

(String value)

There was some discussion about the patch and Mike Hearn requested a bit of documentation be added to describe how it all works. Jason did so and you can find an in-depth description of Wine's DirectX shaders ( on the wiki.

2. OpenAL Audio Driver

(15 posts) Archive Link: "Feedback requested on an OpenAL audio driver patch"

Topics: Multimedia

People: OpenALNick BurnsEric PouechRobert Reif

Wine's audio has scrutinized lately. There's a lot of issues with getting sound to Just Work with Wine, not the least of which is communicating properly to the underlying hardware. There's also some fragmentation going on with Wine's audio. Rather than having one audio driver that works properly, we have five drivers subtly (and even not so subtly) broken. On top of that, other platforms require other implementations.

This week Nick Burns posted a patch for an OpenAL audio driver. In case you're not familiar with it, and I wasn't till the patch appeared, OpenAL is, " a cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications." As you can imagine, there was a bit of skepticism regarding the patch. On the one hand, it's great to see people jumping into Wine development and as such there was a fair amount of feedback and tips given regarding the patch. On the other hand, it adds one more driver to a framework badly needing attention in other areas. Nick seems to be aiming for support of MacOS X since another patch touched on that area. In that regard, it's nice to see even more work being done for that platform.

From Nick's original post:

I have started work on an openal driver for wine... So far I have playback and recording working (with minor issues) (for some reason the DSound HEL is unhappy with my driver)

OpenAL seems to have enough functionality to do the job.

Are there any problems with using OpenAL for such a purpose?

The reason for using OpenAL is for platforms that dont have alsa/oss/esd/... support For one it gives a chance to test audio on windows for example -- and on mac osx (although the winecoreaudio driver is making great progress).

Eric Pouech, who's done a lot of low-level work on audio, replied:

Planning to use OpenAL for portability reasons is a bad idea IMO:

Nick addressed each of those issues:

OpenAL 1.1 supports recording... (1.0 does not have recording so that is a problem yes.) My driver handles this atm -- it checks for recording capabilities and supports accordingly.

The OpenAL api is rather simple: for playback you make buffers and queue them then poll them (to find out when they are done.) There are some extensions that cut out copies/support eax/. I have not looked at 'em yet. (support 2d and 3d audio) For recording (1.1 only): start capturing -- poll (get data -- if there) -- stop recording.

The dsound mapping stuff I want to understand better (are there any docs for this?) I am sure we can layer it on OpenAL (hopefully good.)

PortAudio looks like a good choice as well -- afaict -- but I dont have any experience with it (not that I had any openal exp when i started that driver)

Nick then posted a patch, got a lot of feedback, and reposted his work again. With the second round patch he announced some changes:

I finally figured out my dsound HEL problem (was making too many buffers) -- now I wait and only use a few buffers.

It seemed to work well for GTA3, Tribes2 and FlatOut (requires a binary patch to run) (dsound) -- and for SndRec32 (win/wout) Games and ...App... tested under Mac OSX x86 -- Mac Book Pro.

Remove the disable 'OPENAL_DISABLE_IN' to test wavein. (Forced off due to some issues of my OpenAL framework (I could only record at 44k -- could not figure out how to force 44k only for wavein) -- others may have better luck)

So here is my patch -- It adds it to winecfg, the, And it adds the new files (the actual driver why not)

I would like any feedback ppl out there may have.

With those changes it led Robert Reif to ask how well Wine's regression tests worked when run in interactive mode. Nick didn't know there was an interactive mode to the tests and after running them he reported, " So I ran dsound_test and winmm_test (interactive mode?) on the command line There are some failures -- but no crashing Some games like Carmageddon2 are unhappy with openal atm."

Will another driver get added? The jury is out. Thus far the patch hasn't made it in.

3. Fedora Packages Update

(4 posts) Archive Link: "Broken FC5 packages - stay clear."

Topics: Packaging

People: Andreas BierfertMike HearnVitaliy Margolencvs

Last week we mentioned updated Wine packages were appearing on Fedora Extras ( . This week Vitaliy Margolen warned everyone not use them since someone on irc appeared to have a broken package. That was news to Andreas Bierfert, who until now hasn't said anything about building the packages:

Be sure it is compiled with everything that FC/FE{3,4,5,devel} can support. The only thing is that some stuff is split out into subpackages and if users want that support they need to install it. Take a look at debian for example. Fedora Extras wine layout is basically the same. For the X driver... that should work out of the box so I suspect that the user has a different problem. In any way direct FE wine users to to file bug against wine. This way I can easily track such bugs and decide if they should be filed against wine or if it really is a packaging but.

If you look in the package repository, you'll see there are 11 packages for Wine. A big chunk of that is to split out the various audio drivers, but there are packages that put TWAIN and LDAP support in separate packages. It led Mike Hearn to question why it was done:

We had this problem with Debian, where people didn't install the "utils" package and apps broke mysteriously. Unless you have a lot of experience of Wine debugging you cannot detect this easily ... please, there's no reason to split this stuff up as Wine will load everything in a failsafe fashion so there is no need to mark the package as depending on a million things.

Out of interest what are the 11 packages?

Andreas explained:

Well from a wine perspective I see that this makes sense, but if you take a look at all the dependencies it is another story... installing wine is one thing... ending up with zillion dependencies is a whole different story for lots of people where e.g. bandwidth is still a problem or which rather want to have a slim system. I as a packager sit between the chairs and in this case I see why splitting up wine made sense in debian and why it made sense for Fedora Extras as well. The question is what to split and what to leave in. The stuff that has been split from just having one 'wine' package is stuff that made sense and in ways interacts best with what Fedora Core ships with the distro. Sure there are improvements to be made and suggestions are always welcome :) but doing it the way it is done now made lots of people happy (and gave me positive feedback).

[the packages are:]

These are the 10 packages which are relevant for a 'normal' user where wine and wine-tools are the major ones. They are build from the wine sources (without winemp3). Then there is:

These two are more or less only interesting for packagers/developers etc.

For more details take a look here:

And of course build from the wine-docs sources is the wine-docs rpm:

4. AppDB Update

(65 posts) Archive Link: "How are we doing?"

Topics: WineHQ, Status Updates

People: Tony LambregtsChris MorganJonathan ErnstWineHQJeremy Newman

As part of a discussion about how well regressions are being tackled, Tony Lambregts gave his thoughts regarding, an update on how the AppDB is doing, and ideas for how people could help:

Since I have Administrated both the AppDB and Bugzilla for quite a while I would say that this is about even with regressions keeping pace with improvements. What seems to be improving is the rate at which the regressions are caught and fixed.

Catching regressions early is critical to fixing them and the faster release cycle helps but only if the user upgrades in a timely fashion.

Some programs have been Rock Solid for years (eg: SimCity 3000) while others are are not. Myst worked for years and then fell victim the Windows Management rewrite and I have just recently been able to run it again but it is still very unstable.

Overall I am seeing a lot more activity in bugzilla since we went to 0.9.0 as I am sure most of you are aware:

Some may call it a flood but over all I think this has been a good thing. The real downside to this is that it takes a lot more of my time to go through each email and see if I can assist and that the proper bug links are in place.

Going to winecfg has made the product more user friendly but we are still seem to be a long way away from "It Just Works" in a lot of cases.

In the interm I believe the AppDB has helped a lot. I think that the work that we have put into it has paid off fairly well to a point. So far we have added:

Lots of thanks to Chris Morgan and Jonathan Ernst and everyone else that submited patches to get it to its current state.

However there are a number of things that are needed still.

5. Anonymous Patches

(5 posts) Archive Link: "notepad patches (search/replace, etc)"

Topics: Patches

People: Andreas MohrChristoph FrickAlexandre JulliardCodeweavers

This week a serious of patches appeared all at once from Anoni Moose. That's quite interesting because it shows someone took a lot of time to work on Wine and then wait to submit all the work at once... under an anonymous name. Andi Mohr was thankful for the patches but asked:

I can't help but say that your parents must have been giving you a rather "funny" name...

Or, IOW, do we have any guidelines about "Anoni Moose" submissions to our project? Are they ok, not ok, ok? Loves me, loves me not, ...

Anyway, thanks for a very nice collection of patches!

That led Christoph Frick to ask, " What is the difference between anonymous submissions, that we can spot and which we don't? Maybe you are a fake ;)"

Andi replied:

Darn, I knew fully well that exactly this objection would arise... ;)

Me, I've been created as an IRC bot happily typing away for about a decade without anyone noticing...

Oh, that's not true in fact, people do know that I'm real, since someone has been showing up at Codeweavers and various wineconfs pretending to be me ;)

So I guess it's fully a non-issue after all since the internet is a completely anonymous space anyway and patches can only be judged by their quality, not by their origin. Sorry for the noise!

Alexandre did weigh in on the situation:

Of course there's no real difference, but collaboration is based on trust, and it's hard to trust people who don't even want to give out their name. Obviously you can give me a false name, but I'll figure it out eventually, and then trust you even less than an anonymous submitter so there's really no point in trying to cheat.

If you have good reasons for wanting to remain anonymous, please discuss it with me in private and we can arrange something; but otherwise please use your real name.







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.