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 #294 For 14 Oct 2005

By Brian Vincent

Table Of Contents


This is the 294th issue of the Wine Weekly News publication. Its main goal is to enjoy stable talus. 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 341 posts in 602K.

There were 81 different contributors. 52 posted more than once. 42 posted last week too.

The top posters of the week were:

1. News: LWN Article

(1 post) Archive Link: "News"

Topics: News

People: News

LWN published an article last week titled, Wine to Reach A Major Milestone. It discusses Wine's pending beta release and some of the work that's gone into it. If you're a frequent reader of WWN, there probably won't be any surprises in there. (Disclaimer: I wrote it.)

A pretty slick online magazine called TUX ran two articles on Linux in their latest issue. You'll need to register to get access to it, but it's an interesting twist on online media. It reads more like a read magazine rather than a normal, newsfeed style website. Both articles concern gaming with the cover of the issue #7 saying, You CAN Play Windows Games on Linux.

2. Direct3D 7, version 2

(3 posts) Archive Link: "D3D7 -> WineD3D, 2nd attempt"

Topics: DirectX

People: Stefan DosingerLionel UlmerOliver Stieber

Stefan Dösinger has been spending some time on Wine's DirectX 7 implementation. You might remember that there's been some discussion to gradually share the Direct3D libraries being developed for DirectX 9 (see WWN #291 for details.) Stefan's initial work seems to have progressed:

I am trying again to Implement Direct3D 7 using WineD3D, and I've made some progress. The D3D7 Device implementation seems to initialize correctly, with the correct surfaces.

My solution looks like this:

I've made the following changes to WineD3D so far:

The whole thing is far from being useable, if anyone is interested in the code, I can send it, but be warned, it's quite a mess at the moment. My plan is to get some games running, and then I'll send small and clean patches for CVS commit and upload a big patch somewhere for prior testing.

Lionel Ulmer wanted to know, " How do you handle the 'special' case Blits (between surface and texture, between surfaces, ...) ?"

Stefan hopes there won't need to many changes:

Well, I must admit that I don't have an totally detailed plan, but the DDraw surface and the WineD3D surface share the same memory area. So those Blits will be handled by the original DirectDraw surface implementation in any case, and if a WineD3D surface is attached, the DDraw surface implemenation updates the WineD3D surface whereever it might be necessary. I hope that I can avoid extra memcpy()s

I don't know if there might occur any problems if DGA is used, and I can't test it because DDraw DGA fails on my system for some reason.

From there the discussion delved into a lot of details. Stefan ran into a problem with apps that required multithreaded support for 3D rendering. Wine's wined3d library is not threadsafe and games requiring that won't work. However, most games don't require multithreaded rendering so it's not an issue. Oliver Stieber gave a quick outline of what would need to be done to correct that problem:

It fairly easy to make things thread safe and support multiple devices per thread, very roughly you have to:

I wanted to finish state management before making things threadsafe and support multiple devices per thread.

Another problem Stefan ran into was finding any docs on D3D7.

3. Still Image Architecture

(3 posts) Archive Link: "STI on wine: progress + help"

Topics: Graphics

People: Damjan JovanovicMike McCormackMicrosoft

A surprising amount of time has been spent fixing bugs in Wine over the past few weeks. That hasn't stopped some folks from continuing new development though. Damjan Jovanovic has been working on an implementation of Microsoft's Still Image Architecture (STI). The interfaces provided by STI allow for acquiring still images from different devices. It sits at a higher level than something like TWAIN, and in turn could use TWAIN to pull images from a scanner. However, it could also be used to get images from a digital camera, etc. One of the advantages to STI lies in its ability to manage devices that "push" data rather than requiring apps to pull from them. Therefore that requires some kernel support. Damjan described his initial work:

I've been working on an STI implementation for wine, and recently I made some progress.

At present I've got a basic STI.DLL and I've made a Linux kernel module replacement of USBSCAN.SYS on Windows. I've only changed CreateFile() and NtDeviceIoControl(). When CreateFile() gets a devicepath "\\.\USBSCAN..." it opens the kernel module's device file using open(), and sends the file descriptor to the wine server using wine_server_fd_to_handle(). NtDeviceIoControl() checks the IOCTL code to see whether it is a scanner code, and if so, does an ioctl() call.

The problem seems to be that after running for a couple of seconds, all the file system calls like ioctl() start failing with EBADF (bad file descriptor). Is there something other than wine_server_fd_to_handle() I have to do? The scanning application I am testing uses multiple threads and several processes.

Mike McCormack recognized the Wine problem:

Once you register the handle with wine_server_fd_to_handle(), you need to use wine_server_handle_to_fd() to access it again.

If you're already doing that, you may have a handle leak and be running out of file descriptors. You need to make sure to close the handle you receive from wine_server_handle_to_fd(), as the returned value is a dup'd unix file handle.

Damjan reported that did it:

You were right, I wasn't calling wine_server_release_fd(), so wine was hitting the maximum number of open files limit. I fixed it, AND IT SCANS!!!

Thank you Mike, you made my day. I'll be submitting patch in the next few weeks.

4. Winelib & Native Apps

(3 posts) Archive Link: "How Do I launch a Native Linux application from Within Wine"

Topics: Winelib

People: Craig MacLeodKuba OberDan Kegel

Craig MacLeod wanted to know how to launch a native Linux app from within a Winelib program:

I have a Windows application and I wish to run a native linux application from within it. The main Win32 API calls for running another apllication are

I have tried calling a native linux program with these (nautilus) and it consistently fails. Do I need a fully specified path (nautilus is in the search path mind you)?

It either does nothing or hangs Wine when I try calling these applications. I assume Wine is running the application as if it is a Windows app and failing.

Kuba Ober gave a quick pointer, " I'd say that you're free to use a linux syscall to do whatever you want, including forking the process and exec'ing the linux program. That's the beauty of wine. You have win32 *and* linux APIs available at the same time. "

Dan Kegel followed up with an example:

I just tried it, and it works.

Here's what I did:

  1. copied example CreateProcess code from
  2. Modified it to use an absolute path, e.g.
      CreateProcess( NULL, TEXT("c:\\windows\\MyChildProcess"), ...
    since it didn't seem to work otherwise (probably a PATH problem).
  3. Created a shell script with that name, e.g.
      $ cat > .wine/drive_c/windows/MyChildProcess <<_EOF_
      $ chmod 755 .wine/drive_c/windows/MyChildProcess
  4. Compiled the demo app with msvc, ran it with wine, voila! xeyes are following me around on the screen.

5. Fixing Bugs

(29 posts) Archive Link: "Reality check"

Topics: Project Management

People: John SmithDimitrie PaunMarcus MeissnerDan KegelJeremy WhiteRobert ReifVitaliy MargolencodeweaversKrzysztof FoltmanIvan Leo PuotiChristian CostaDimi PaunLuis LendersRaphael Junqueira

How do you get a bunch of people who work on free software as a hobby to fix bugs? Well, it's difficult. It's especially difficult if you have a small group of people and everyone only wants to work on the latest features. Fortunately Wine has more developers than most projects and some of them are paid to work on Wine. It seems money is a good incentive for bugfixing. Despite that, Wine is a massive project and regressions are common. John Smith wrote to wine-devel to illustrate that point:

There was a discussion here about 2 months ago, where I asked for a way to embed WINE config strings into Win32 executable (for example, as string resources). I was told that it is better to fix the problem rather than to create workarounds, and that fixing bugs is trivial and takes at most 2-3 days as soon as it is reproducible.

I didn't argue much then but made a little experiment to prove my point. The point is the following: THE MOST DIFFICULT THING IN GETTING BUG FIXED IS TO GET SOMEBODY WORK ON IT. The same applies both to commercial environments and to open source ones equally. Experiment illustrates it very well:

I've found an application that experiences the problem with sympthoms which are very similar to ours, can be installed in 5 minutes and the problem can be reproduced in 3 clicks. And I've opened a bug in WINE's bugzilla: #3270 (another one #3269 was opened for another incompatibility). Result is the following: IN 6 WEEKS NOBODY EVEN TOOK A LOOK AT BOTH THOSE BUGS.

Welcome to the real world

Ouch. It immediately provoked a long discussion that at times almost delved into a flamewar. Here's some random snippets of conversation that ensued:

Dimi Paun:

Unfortunately, Wine is very incomplete in the sense that you don't have to look far to find lots of bugs. Because of this, we don't usually have the same sense of urgency as other projects to fix them -- there is an infinite stream of them just around the corner.

Not an excuse -- I'm just trying to explain why we don't just on the bugs when they are filled in Bugzilla. Now that we have 0.9 on the way (hopefully followed by 1.0), this attitude seems to be changing.

Marcus Meissner:

Yes, we welcome you to the wonderful world of OpenSource.

Please understand that a lot of us are not being paid ... and so just chose what to do. Some of us are paid to work on Wine, but for specific tasks.

Dan Kegel:

Free Software works like this:

That's it! Users who have an itch not shared by any programmer have no right to complain. Don't look a gift horse in the mouth, as they say. If you *really* want a bug fixed, and no programmer is willing to fix it for free, and you can't fix it yourself, you have two choices:

  1. wait for some programmer to decide he wants to fix it for his own reasons
  2. pay a programmer to do it for you.

Jeremy White:

This page:

takes two clicks to get to from our home page, and has all of our public source code, including Wine.

We also have a company policy that prefers that all the work we do on Wine is publicly submitted to wine-devel first, before we commit to our own tree.

I have found that, on many open source projects, it is possible to get help from a developer. It takes an enormous amount of effort, a great deal of politeness, and some luck. But most open source developers are actually quite giving. The keys, imho, are:

  1. Do your homework

    Read the FAQs. Read the ML archives. Actually try the various alternatives suggested. Research the technical issues at hand. Learn enough so you know what you're talking about.

    Do that first.

  2. Make it easy

    Developers find a nice bug report, with easy to follow instructions to reproduce, and nice easy access to the software to be quite nice.

  3. Ask nicely

    If you want someone to work for you, for free, you have to recognize that they are giving you a gift - a gift of their time.

    If you can't hold that in mind when you ask, then you're not asking right.

John wrote back in response to the many emails on wine-devel:

In fact, I don't care about those bugs at all. Once again (for the 3rd time, BTW): I just tried to make Wine a little bit more compatible with 3rd-party applications (by supporting a way for Win programmers to specify WINE config parameters within executable). I was told that it doesn't make sense, as 'bugs are usually fixed within 2-3 days', which I had serious doubts about (it just doesn't work that way), so I've made a little experiment. I was right, you guys were wrong, and now you're trying to blame me? I don't really think that after all that heated conversation somebody is going to consider my original proposal, but frankly I don't care about WIne anymore - I definitely don't like this 'pay me' attitude (rather than normal 'sorry, we didn't have time to fix it yet' attitude).

A quick look in Bugzilla shows 58 bugs closed this month. In addition, a bunch of bugfixes have come in related to Wine 0.9. A lot of those came from Wine's non-paid developers, including Vijay Kiran Kamuju, Vitaliy Margolen, Krzysztof Foltman, Luis Lenders, Raphael Junqueira, Ivan Leo Puoti, Robert Reif, Peter Berg Larsen, and Christian Costa.

Could things get better? Of course. However, for unpaid developers spending their free time working on things it gets difficult. As Dimi pointed out, there always seems to be an infinite supply of bugs that can only be fixed in a finite amount of time. Things get prioritized based on how interesting it is to fix or whether someone has the knowledge to work on it.







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.