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 #306 For 26 Feb 

By Brian Vincent

Table Of Contents


This is the 306th issue of the Wine Weekly News publication. Its main goal is to sleep on the couch. 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 273 posts in 550K.

There were 94 different contributors. 51 posted more than once. 50 posted last week too.

The top posters of the week were:

1. News: Google & Wine, v0.9.8

(2 posts) Archive Link: "News"

Topics: News

People: Alexandre JulliardCodeWeaversWineHQZack BrownDesktopLinux.comNews broke a story last week that Google will be working with CodeWeavers to get Picasa working under Linux. It was followed by reports in PC Magazine and TechSpot, though they simply the other article. If you haven't used Picasa, I'd recommend downloading it and trying it with Wine. It actually works really well out of the box and it's a great little program. Personally, I still prefer something like EoG for simple image viewing but Picasa really has a lot more features. Given how well it runs with Wine, it's not a stretch that CodeWeavers would consider working on it.

What's not clear is whether this is going to be a Winelib or Wine application. I suspect it's going to be a straight up Windows application with possibly a Winelib library or two for some native integration. For example, one of the features of Picasa is hooking into mail clients. On Linux it would be something that could be done differently with a native library. Otherwise, 99% of the program will be the same. CodeWeavers will likely customize CrossOver Office to sit behind the scenes and do all the Wine magic.

Now, could someone please get them to get Google Earth working?

In other news, Wine 0.9.8 came out. Apparently a fix for Photoshop is in there which seemed to make a lot of people happy. Alexandre noted the following changes:

Go forth and download.

Finally, I'd like to point out that Zack Brown's Kernel Traffic site is on hiatus. While Zack will continue to post these as I write them, there's always a chance his site will go offline. If so, keep in mind that you can continue to find them on WineHQ.

2. D3D8 Changes

(5 posts) Archive Link: "Resubmit D3D8 Surface -> WineD3D"

Topics: DirectX

People: Roderick ColenbranderOliver Stieber

Roderick Colenbrander has picked up the Direct3D flag and continued some work done by Oliver Stieber. The changes at hand involve adapting Wine's Direct3D version 8 code to use the new wined3d layer that Wine's D3D version 9 code uses. There hasn't been a lot of discussion on wine-devel about it, but Roderick's patches have contained some excellent descriptions of the changes going on. If you notice some Direct3D 8 games behaving differently, it's because of this work. I'll just include Roderick's description of each patch to give you a feel for where this is headed.

Patch #1: WineD3D CopyRects

This patch is based on Oliver Stieber his D3D8->WineD3D work and adds the CopyRects method required by D3D8 to WineD3D.

Patch #2: Surfaces

This is the first part of a 1700 line patch (based on Oliver Stieber's d3d8 work) which moves big portions of the D3D8 surface code over to WineD3D.

It moves the d3d8 surface structure over to wined3d. As moving all code over in one step to wined3d is not a good idea the old d3d8 code had to be made compatible with the new structure. This change required me to import some structures from the wined3d_private.h header untill the move is over (the wined3d header can't be included by d3d8 as it conflicts with d3d8_private.h). Further some pieces of surface code were moved over to wined3d.

Patch #3: Textures

This patch (based on Oliver Stieber's d3d8 code) moves d3d8's texturing code over to WineD3D. The patch adds new datatypes, replaces a few texture creation calls with wined3d code and updates code to work with the new datatypes. Unfortunately the patch is quite big because there's one texture base type of which all other texture types are instances.

Patch #4: Capabilities

Both our d3d8 and wined3d dlls contain a routine which detects the capabilities of the videocard as advertised by the OpenGL driver. Right now varies parts of D3D8 have been moved over to WineD3D. Varies pieces of the code ported to WineD3D use these capabilites. Right now D3D8 contains a list with capabilities but doesn't share it with WineD3D. Because of this some pieces of code failed for instance wined3d's surface code for each I posted a workaround last week.

This patch moves the capability detection code over to WineD3D and lets the few existing parts which need the capabiliteis use the WineD3D capability structure (gl_info). This info structure contains next to 'flags' inidicating certain features also all GL/GLX functions pointers. Because D3D8 moves over to the wined3d gl_info structure all the gl prototypes in d3dcore_gl.h were unneeded and removed.

Patch #5: Everything Else

The past few weeks I have trying to split Oliver Stieber's d3d8 patches in small pieces. The patches I sent so far me oved big parts of the surface, texture and capability detection code over to wined3d (roughly 1/3th of the total patch) These parts could safely be moved as they didn't depend on much other d3d8/wined3d functionality. The remaining texture, shader, primitive drawing code depends on stateblocks and swapchains which haven't been ported over yet. If I would move over for instance the remaining texture code the stateblock/swapchain code needs to moved too. The current d3d8 shader code would need to be made compatible with the wined3d stateblocks (which isn't possible becaue various datatypes in the stateblock changed; the wined3d stateblock uses incompatible wined3d datatypes which the shader code doesn't understand)

Other parts of the d3d8 code have similar issues, so they all depend on the stateblock/swapchain code. The only option is to move all this code at once. I talked with H. Verbeet and others and they thought that separating is nearly impossible too. (splitting would create too many new bugs and not everything is moveable)

The patch which I attached to this email removes the remaning d3d8 code over to WineD3D. (based on Oliver Stieber's code) The file d3d8.patch.bz2 makes changes to the current d3d8 code and also makes a few changes to wined3d in order to let wined3d create various objects for d3d8. The other two files need to be added to the d3d8 directory and replace the current shader code. As you will notice in the various d3d8 files aren't used anymore a next patch will clean up the d3d8_private.h file and remove the unneeded .c files.

That's a lot of changes! Roderick has more issues to sort out, but patches continue to roll in.

3. Current State of Lotus Notes

(1 post) Archive Link: "wine-0.9.8 and Lotus Notes 6.5.1"

Topics: Status Updates

People: Rainer DorschCodeWeavers

Lotus Notes is a popular application that folks like to run with Wine. It's worked well for years and CodeWeavers supports it in CrossOver Office. >From time to time regressions happen, but it seems to be one application where we hear about such things. Rainer Dorsch dropped a note this week to let everyone know how well things are working with the latest release:

Just wanted to report my wine experience with Lotus Notes 6.5.1: I've run Lotus Notes with wine for a long time. What I notice with wine-0.9.8 (though this was present in a few releases before but not in all releases):

4. --rpath

(6 posts) Archive Link: "Alexandre Julliard : configure: Use --rpath if supported when building binaries to point to"

Topics: Build Process

People: Alexandre JulliardVitaly Lipatov

Being able to relocate a Wine installation has been on the to-do list for a long time. It would be nice to just move the entire /usr/local/lib/wine and associated programs without breaking anything. Well, apparently this week that fix finally made it in. Alexandre committed a change with the following note:

configure: Use --rpath if supported when building binaries to point to the relative location of the wine libraries.

That prompted Vitaly Lipatov of the ALT Linux team to ask for another option, " We need a --disable-rpath option in configure for rpath disable. Rpaths is not useful when WINE building for distribution. Will I add --disable-rpath of there is a better suggestion? "

Alexandre wanted to know why it wouldn't be useful and Vitaly answered:

It is only useful when we run wine from the source tree.

There is no need for rpath if libwine is placed in a standard place such as /usr/lib

I got follow broken requires when build rpm package:

/usr/bin/../lib/ /usr/bin/../lib/

Alexandre explained a workaround:

It sounds like rpm needs a good whack on the head if it is unable to cope with this. Anyway, you could always build with make LDEXERPATH="".

That worked for Vitaly.

5. Updated

(1 post) Archive Link: " 0.2"

Topics: Utilities

People: Christian Lachner

Want an easy way to download and compile Wine from the git repository? Christian Lachner updated his script:

I decided to make this release a bit more complete than the other ones i did before. Bugfree (i hope ;)) and with readme. current version is 0.2.

This is the readme's content:


getwinegit is a script which was designed to download/update, compile and install the current wine-git-source-tree.


Usage: /usr/bin/ -<mode>



Just copy wherever you want, make it executable and create a softlink at /usr/bin. Then (or before) configure the script by editing the variables in the head with your favourite editor. (minimum is to set ENABLE="yes")


0.2 first stable release.


Tell me what you need and i will implement it... maybe :D

You can find the script attached to his announcement email.

6. Fixing Memory Layout Issues

(7 posts) Archive Link: "Possibly crazy idea to deal with memory layout problems once and for all"

Topics: Memory Management

People: Troy RolloDan KegelMike McCormack

Troy Rollo ran into a problem with Wine and memory management. He thought of a crazy way to deal with it and asked for some input:

I have been looking at a problem that has arisen in recent versions, particularly when using some D3D games, in which the virtual address space above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you get an out of memory condition, even though you still have well over a gigabyte free (even in a contiguous block!). This has led to some people using the attached hack (first attachment) to get their D3D games to work.

After considering a lot of approaches to this problem that did not seem to get anywhere productive, it seemed that the only way to resolve it would be to get in between the application and any libraries, and the kernel. The solution I came up with is somewhat rude, but if we assume that any libraries that Wine uses only call mmap() and associated calls via the C library, then it may well do the trick, plus make it possible to implement other virtual memory APIs more effectively (and in a couple of cases eliminate calls to wineserver).

If wine_preloader were extended to have its own implementation of all the friends of mmap(), and to have its own implementation of the dynamic linker, then in principle it could make sure only its mmap (and not the C library's) is called. An even more aggressive approach might be to load the C library and stick jumps into its mmap that redirect to the preloader's versions. The preloader's mmap would keep track of mappings on its own and when it receives an mmap with a start address of "NULL", decides on its own what base address to use.

Dan Kegel didn't think it was enough:

You can override mmap() in wine by just changing all the places it's called. (Having control over the source is a wonderful thing.) But if you want mmap to behave truly differently, you'd probably need to change the kernel.

I seem to recall somebody was working on a linux kernel module for wine that just dealt with program loading, but I can't recall who. Perhaps he'll surface and comment on this.

Mike McCormack followed up Dan's email with:

You can do that easily after glibc has loaded, but you won't know where glibc itself was loaded into the address space.

I discussed something like what Troy proposed with Vitaliy on IRC, but with the preloader looking up and overriding the mmap/munmap symbols in glibc. That would hopefully give Wine control over most mmaps and munmaps, possible save us from having to reserve memory in the preloader, and allow more control of the address space.

It has a few problems though. Firstly, we'd miss mmaps done with system calls. Secondly, we'd have to make assumptions about what areas of memory the kernel would let us map, and what areas of memory were already used in the address map.

I had a go at creating a kernel based PE loader for Linux 2.6 by forward porting parts of David Howell's Wine kernel module. It currently compiles, but that's about all.

Haven't had much time to spend on it lately, because I've been busy with work.

7. Sponsored Development

(3 posts) Archive Link: "Guitar Rig 2 in Linux/Wine"

People: Michael Ost

Michael Ost with Muse Research asked if anyone was interested in doing some development:

We are interested in getting the new Guitar Rig 2 USB foot controller supported in Linux/Wine. It's described here:

I assume from looking at it, that a USB driver would be required and then perhaps some Wine tweaks to let the plugin open the USB driver.

Anyone interested in taking this on? We are hoping to do this as a trade --- like you do this work and get a Receptor and/or some VST plugins for your time.

BTW, we also have a job opening, posted here:

Michael then replied a few days later to let everyone know someone was going to work on it:

A guy from the linux-audio developers mailing list named Brian Sturk replied and is interested in doing the work. He should be fine with the linux driver side, but pointers in the Wine part of the project might be useful.

For now, I am assuming that the work would be open source and integrated into linux and wine in the normal way. I believe the company will be cooperative.

One interesting thing here is that more work might be done to support USB devices.







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.