Table Of Contents
|1.||(1 post)||News: LWN Article|
|2.||(3 posts)||Direct3D 7, version 2|
|3.||(3 posts)||Still Image Architecture|
|4.||(3 posts)||Winelib & Native Apps|
|5.||(29 posts)||Fixing Bugs|
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 (http://www.winehq.org)
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"
LWN published an article last week titled, Wine to Reach A Major Milestone (http://lwn.net/Articles/153546/) . 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 (http://www.tuxmagazine.com/node/1000155) .
2. Direct3D 7, version 2
(3 posts) Archive Link: "D3D7 -> WineD3D, 2nd attempt"
People: Stefan Dosinger, Lionel Ulmer, Oliver 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 (http://www.winehq.com/?issue=291#WineD3D%20and%20DirectX7) 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"
People: Damjan Jovanovic, Mike McCormack, Microsoft
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"
People: Craig MacLeod, Kuba Ober, Dan 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:
CreateProcess( NULL, TEXT("c:\\windows\\MyChildProcess"), ...
$ cat > .wine/drive_c/windows/MyChildProcess <<_EOF_
$ chmod 755 .wine/drive_c/windows/MyChildProcess
5. Fixing Bugs
(29 posts) Archive Link: "Reality check"
Topics: Project Management
People: John Smith, Dimitrie Paun, Marcus Meissner, Dan Kegel, Jeremy White, Robert Reif, Vitaliy Margolen, codeweavers, Krzysztof Foltman, Ivan Leo Puoti, Christian Costa, Dimi Paun, Luis Lenders, Raphael 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:
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.
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.
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:
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:
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 kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.