WWN Issue 294

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 www.winehq.org

This week, 341 posts consumed 602 K. There were 81 different contributors. 52 (64%) posted more than once. 42 (51%) posted last week too.

The top 5 posters of the week were:

19 posts in 22K by daniel.r.kegel at gmail.com (Dan Kegel)
17 posts in 17K by infyquest at gmail.com (Vijay Kiran Kamuju)
17 posts in 21K by lionel.ulmer at free.fr (Lionel Ulmer)
14 posts in 15K by wine-devel at kievinfo.com (Vitaliy Margolen)
14 posts in 18K by truiken at gmail.com (James Hawkins)

News: LWN Article	Archive
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 .

News: LWN Article

Archive

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 .

Direct3D 7, version 2	Archive
DirectX 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: DirectDraw is unmodified, and it remains in ddraw.dll. Direct3D7 uses generally the Direct3D9 interface of WineD3D. The only changes made to WineD3D are in WineD3DDeviceImpl_Release and a little change in WineD3DSurface. WineD3D Surfaces can be attached to DDraw Surfaces, and they receive the properties of their parents, including the memory reserved for the surface The D3D7 implementation creates a SwapChain and a RenderTarget from the DirectDrawSurface it's attached to, as well as a DepthStencil WineD3D surface to make WineD3D happy I've made the following changes to WineD3D so far: Make WineD3D handle dxVersion 7, generally with the same code as with dxVersion 7 A new parameter to WineD3DDevice_Create: a pointer, which specifies an existing surface memory. If != NULL is passed, no memory is reserved by WineD3D, and it's not Released on WineD3DSurface_Release When releasing the WineD3DDevice, don't release the parents of the RenderTarget, the DepthStencilBuffer, BackBuffer and FrontBuffer, because ddraw.dll needs its surfaces. Instead, release the WineD3DSurfaces only. The whole thing is far from being usable, 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 they won't need too many changes: Well, I must admit that I don't have a 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 implementation updates the WineD3D surface wherever 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: Add the OpenGL context to the device structure. Make a per-device critical section. Whenever a call is made enter the critical section Then check that the current active context is the same as the context on the device. If not then make the device context active. 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.

Direct3D 7, version 2

Archive

DirectX

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:

DirectDraw is unmodified, and it remains in ddraw.dll.
Direct3D7 uses generally the Direct3D9 interface of WineD3D. The only changes made to WineD3D are in WineD3DDeviceImpl_Release and a little change in WineD3DSurface.
WineD3D Surfaces can be attached to DDraw Surfaces, and they receive the properties of their parents, including the memory reserved for the surface
The D3D7 implementation creates a SwapChain and a RenderTarget from the DirectDrawSurface it's attached to, as well as a DepthStencil WineD3D surface to make WineD3D happy

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

Make WineD3D handle dxVersion 7, generally with the same code as with dxVersion 7
A new parameter to WineD3DDevice_Create: a pointer, which specifies an existing surface memory. If != NULL is passed, no memory is reserved by WineD3D, and it's not Released on WineD3DSurface_Release
When releasing the WineD3DDevice, don't release the parents of the RenderTarget, the DepthStencilBuffer, BackBuffer and FrontBuffer, because ddraw.dll needs its surfaces. Instead, release the WineD3DSurfaces only.

The whole thing is far from being usable, 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 they won't need too many changes:

Well, I must admit that I don't have a 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 implementation updates the WineD3D surface wherever 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:

Add the OpenGL context to the device structure.
Make a per-device critical section.
Whenever a call is made enter the critical section
Then check that the current active context is the same as the context on the device.
If not then make the device context active.

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.

Still Image Architecture	Archive
Graphics 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.

Still Image Architecture

Archive

Graphics

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.

Winelib & Native Apps Archive

Winelib & Native Apps	Archive
Winelib 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 ShellExecute WinExec CreateProcess 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: copied example CreateProcess code from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/creating_processes.asp 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). Created a shell script with that name, e.g. `$ cat > .wine/drive_c/windows/MyChildProcess <<_EOF_ #!/bin/sh xeyes _EOF_ $ chmod 755 .wine/drive_c/windows/MyChildProcess` Compiled the demo app with msvc, ran it with wine, voila! xeyes are following me around on the screen.

Winelib

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

ShellExecute
WinExec
CreateProcess

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:

copied example CreateProcess code from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/creating_processes.asp
Modified it to use an absolute path, e.g.
since it didn't seem to work otherwise (probably a PATH problem).
Created a shell script with that name, e.g.
Compiled the demo app with msvc, ran it with wine, voila! xeyes are following me around on the screen.

Fixing Bugs	Archive
Project Management 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 a 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 jump on the bugs when they are filed 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 choose what to do. Some of us are paid to work on Wine, but for specific tasks. Dan Kegel: Free Software works like this: The programmers scratch their own itches. 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: wait for some programmer to decide he wants to fix it for his own reasons pay a programmer to do it for you. Jeremy White: This page: http://www.codeweavers.com/products/source/ 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: 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. 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. 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 464 bugs resolved this month. Now that doesn't mean there were 464 patches since some were duplicates and some of them couldn't be reproduced. Jonathan Ernst has been heading up the triage and spent a lot of time cleaning things up. 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.

Fixing Bugs

Archive

Project Management

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 a 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 jump on the bugs when they are filed 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 choose what to do. Some of us are paid to work on Wine, but for specific tasks.

Dan Kegel:

Free Software works like this:

The programmers scratch their own itches.

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:

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

Jeremy White:

This page:

http://www.codeweavers.com/products/source/

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:

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.
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.
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 464 bugs resolved this month. Now that doesn't mean there were 464 patches since some were duplicates and some of them couldn't be reproduced. Jonathan Ernst has been heading up the triage and spent a lot of time cleaning things up.

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.

World Wine News