Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Sleeping Cousins

Wine Traffic #282 For 8 Jul 2005

By Brian Vincent

Table Of Contents


This is the 282nd issue of the Wine Weekly News publication. Its main goal is to get lost in the woods. 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 339 posts in 1319K.

There were 85 different contributors. 52 posted more than once. 34 posted last week too.

The top posters of the week were:

1. News: StartCom Linux ML 4.0.4

1 Jul 2005 - 8 Jul 2005 (1 post) Archive Link: "News"

Topics: News

People: News

A few weeks ago we mentioned a Red Hat based distribution called StartCom Linux. This week they released a new version of their Multimedia Edition, ML-4.0.4, with a new version of Wine. They've put together their own RPM's, but don't be fooled by the 0.99 version number. What you're actually getting is wine-20050524.

2. DirectX9 Work

12 Jun 2005 - 7 Jul 2005 (20 posts) Archive Link: "DirectX9 Work"

Topics: DirectX

People: Oliver StieberMaxJeremy Whitecvs

Oliver Stieber has been busy submitting DirectX patches to catch up on some of the work he's done over the past six months or so. To give a summary of what's been worked on, here's what Oliver mentioned in his recent patches:


This patch agains winecvs 2005-05-13 adds support for Stateblocks, sampler states and swapchains to wined3d There are a few spelling fixes and tidyups, and a fix for some errors with cubtexture introduced in the interface seperation patch.

With this patch the following demos now run correctly:





This patch adds support for Vertex declarations.

The parsing of vertex declarations has been tidied up, d3d8 declarations are converted into d3d9 declarations so that only one type of declaration need to be managed in the code. Vertex declarations are no longer parsed into FVF's since the fvf doesn't support everything vertex declarations support.

There is a minor issue in that vertex shader constants provided by d3d8 declarations aren't parsed properly yet, but this will be impmeted with vertx shaders.


this patch renames

to the correct

To my knowlage this doesn't fix anything but does enable code with the correct name to compile properly.


This patch adds relay tracing to texture, WINEDEBUG=d3d9 will now display the message 'relay' whenever any member of IDirect3DTexture9 is called.


This patch disables the creation of invalid vertex declarations in d3d9 preventing some applications from crashing.

the patch will be superseded as soon as additions to wined3d make it into cvs.


This patch causses d3d9 to call wined3d for GetDirect3D instead of using the ->direct3D instance, which is no longer valid.


This patch mostly implements swapchains in wined3d.

additionally a couple of minor issues that prevented anything from running have been fixes.

the non-power2 texture check in wined3d/device.c has been changed to ignore rendertargets

direct3d is no longer deleted in d3d9/device.c, because d3d9/device.c no longer holds a reference to a direct3d instance.


This patch tidies up a few texture bugs


This patch adds support for samplers to wined3d, and switches from using d3d9 constants to wined3d constants so that there's no recursive dependencies (and so that d3d8 doesn't need to know about the d3d9 constants)

Also fixed appended a \n onto the end of a trace call in BaseTexture and Resource cleanup.

Note: The code for managing sampler and texture states has been re-written in the current wined3d patch, the new changes don't appear in this patch as other architecture changes are required that are not yet stable.


This patch changes the way caps are sent between d3d9/d3d8 and wined3d to make it easier for wined3d to support additional versions of Direct3D.


This patch implements rendertargets using either textures, swapchains or standalone surfaces.

This patch is only dependand on winecvs but.....

When applying this patch along with the stateblock patch the following lines in wined3d/stateblock.c :


This patch removes the old render target code from d3d9 and replaces the render target calls with relays to wined3d.


This patch against wine-cvs adds support adds support for vertex decalrations to wined3d and d3d9.


This patch makes sure that the OpenGL visual created for a window has a stencil buffer. This is a requirement for stencil buffer support in d3d.


This patch relays all the pixel shader calls from d3d9 to wined3d


This patch check for a NULL vertex declaration being sent to IWineDeviceD3D_SetVertexDeclaration

This patch, combined with the other wined3d and d3d9 patches already sent in is enough to get Pirates working OOTB. Pixelshaders need to be turned on in the registry or you'll have problems with missing textures. Turn on 'disable shaders' in pirates settings, and turn down the detail. (don't worry vertex buffer objects bring the frame rate up to something more desirable).

That sound you hear is Jeremy White furiously applying patches trying to get his copy of Pirates! to run.

3. winecfg Usage Notes

8 Jul 2005 - 10 Jul 2005 (9 posts) Archive Link: "Re: [Wine]june 2005 release and 'registry' ?"

Topics: Configuration

People: Dan SawyerBrian VincentFelix NawothnigMike Hearn

Dan Sawyer wanted to know how to manage DLL overrides now that we don't have a config file:

The release notes state config file control has been moved to the registry and that winecfg is active. winecfg does not seem to recognize dll overrides. Has anyone else seen this? If so were you able to work around it?

I agreed it wasn't really easy to figure out and described how it works:

What may not be obvious is the "Applications" tab in winecfg is tied to the other tabs. We should probably add a sentence in the description of that tab to briefly explain it links to other ones (inc. "Graphics"). In fact, I'm procrastinating, so maybe I'll just try to submit a patch for that.

So if you want to change systemwide overrides:

  1. Select "Default Settings" in the Applications tab.
  2. Then move to the "Libraries" tab and enter the name of the DLL in "New override" box, such as "msi.dll" and click on "Add".
  3. "Edit" the load order as necessary in the box below.

If you want to change the override for one application, "Add" the new application in the "Applications" tab, select it on that tab, and then move to "Libraries" to create an override. If you update to the latest CVS you'll see a different Libraries tab than what was in wine-20050628 and it follows what I described above. The layout is different in wine-20050628, but it's essentially the same concept.

Felix Nawothnig thought the design of winecfg could be better:

The current design is totally braindead from a usability standpoint:

I'll submit a preliminary patch (introducing the not yet configurable DSound settings) showing how I think this should be done later today.

The discussion moved over to IRC and Mike Hearn wrote a summary of that on wine-devel:

Felix and I talked this stuff over on IRC, I think we came to some understanding on where winecfg is going and why it's designed the way it is.

For everybody: generally, we should resist the temptation to do yet more UI overhauls. Yes, the linked tabs thing is not ideal. It's more an artifact of the Property Sheet control than anything else. However, a few things which are less ideal are:

  1. Treeviews: tried, didn't work very well. Treeviews have generally poor usability anyway
  2. Tri-state checkboxes: not really clear what the third state means, but for now it may be a quick fix
  3. Opening up new windows for each app: hard to implement in the code.

A much better way forward is simply to fix the damn bugs that winecfg settings invariably exist to work around :)

Eg, even "Windows Version" will hopefully be fixed sometime later this year (?) by switching us to 2K/XP mode by default and by nailing the last DCOM problems. Desktop mode will eventually (I hope) become the "winedesktop" program that was done years ago, I'm not sure what AJ plans are here though.

Eventually nobody should have to use winecfg for anything. Let's spend our time fixing the bugs and increasing automation rather than arguing about the best way to represent a list of hacks in the UI :)

Alexandre replied to mention the Windows version should change soon, sometime before Wine 0.9 (we're shooting for September 30th.) With regards to the winedesktop program, it's going to become part of the as-yet unseen Explorer process that Alexandre is currently working on.

4. Printers and Network Folders

7 Jul 2005 - 8 Jul 2005 (3 posts) Archive Link: "Re: shell32: Printers folder"

People: Huw DaviesDetlef Riekenberg

Huw Davies submitted a patch a while ago to add a special Printers folder to Wine to match the folder of the same name on Windows. It was never committed and this week Detlef Riekenberg wanted to know why. Huw explained the problem:

I think Alexandre didn't want every special folder to have its own implementation. Mike also has a network neighbourhood folder that has the same problems. Basically, a lot of the shell folder code needs to be tidied up with all of these special folder integrated into it.

Detlef replied:

I See, but I don't see any comment from Alexandre. We need even more Window-handling in shell32.dll See my stub for Printers_RegisterWindowW. (Printer Properties)

Together with the other special Folders we have a big Part of explorer.exe ready.

5. Compressor for Cabinet.DLL

6 Jul 2005 (3 posts) Archive Link: "cabinet.dll dev. - Using external compression libraries"

Topics: Integration

People: Gerold WucherpfennigSteven EdwardsDan Kegelcvs

Gerold Wucherpfennig wanted to know how to go about adding some external code to cabinet.dll:

I'd like to use an LGPL licensed LZX compressor for the compression part of cabinet.dll. What's the best way to accomplish this?

  1. copy and pasting the code as required.
  2. dynamically loading an elf library at runtime
  3. do configure checks at ./configure and link statically
  4. do the same and link dynamically
  5. checkin a windows-version of this LZX compressor to wine cvs and use that at runtime.

Web site:

Steven Edwards voted for checking in the Windows version of the compressor and explained, " If its not too big I would rather go this route to make it less trouble to share the dll with ROS. "

Dan Kegel agreed including it with the Wine source was the way to go, " I had a look at the source for this compressor. It's pretty small. I recommend unpacking lzxcomp.tar.gz right into dlls/cabinet and simply using the source files completely unchanged if possible."







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.