This is the 329th issue of the Wine Weekly News publication. Its main goal is to smile. 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, 172 posts consumed 316 K. There were 67 different contributors. 35 (52%) posted more than once. 35 (52%) posted last week too.
The top 5 posters of the week were:
|News: Summer of Code Projects||Archive|
The big news this week was the announcement of Google's Summer of Code projects. Ten projects were approved for Wine. Even more exciting, each of those 10 projects are really strong candidates. If even half of them get completed we'll have some wonderful new functionality in Wine. Google has continued to expand this program each year. There were nearly 6,200 applicants this summer with over 900 being accepted. Here's the list of Wine projects:
Kai Blin, who's worked on authentication in Wine for the previous 2 summers, was accepted for a Samba project this year to improve winbindd support. What's interesting about that is Kai has enough experience with Wine to understand what would be needed in Samba for improved support.
A new Wine beta arrived last Friday. Noted changes include:
The 'File I/O' mention lies in some work being done by Alexandre and goes right to the heart of the wineserver. I won't even pretend to understand the changes being made there, but it seems interesting.
|Cedega 6.0 & Wine Benchmarks||Archive|
There's a little topic that doesn't get covered much here. In fact, it's something that doesn't really get covered anywhere and it's probably time to try to set the record straight. We'll start with the Slashdot announcement of TransGaming's Cedega 6.0 which read:
Today TransGaming introduced Cedega 6.0, which is the popular Linux game emulator based upon WINE.
Here's the facts you need to know about Wine & Cedega:
So any time I hear Wine and Cedega in the same sentence I kind of cringe. They're really two different codebases at this point. Why is that? Well, it all goes back to Wine changing its licensing from X11 (BSD-style) to the LGPL about 5 years ago. See WWN issues #115 , #116 , and #117 for more info. So Wine switched its license, TransGaming kept using the old codebase, and now the two have diverged. Except.. TransGaming has realized that some of the stuff created by Wine is necessary and they've imported specific DLLs into their codebase and kept them under the LGPL license. Wine's modular DLL architecture allows that pretty easily.
Okay, so the code is different. How about the relationship between the two projects? Despite rumblings that might appear here and there on the mailing list, the relaionship isn't that bad. Really it's more that there isn't a relationship, however there doesn't seem to be animosity between the two groups. The last in-depth communications (public at least) seemed to have been in 2004 when Gav State came to WineConf 2004. At the time he basically pitched a few technical changes for Wine and all of them were shot down. While the two projects were diverging before that, that was probably the event that ensured the two projects would go their own ways.
Okay, so now you know some of the background. Saying that Cedega is based off Wine technicallly isn't incorrect, but it does imply that Cedega has all the new architecture of Wine that's happened in the past half decade.
A benchmark was done and linked from the Slashdot announcement. It led Tom Wickline to comment:
I have been pondering the thoughts of running every benchmark that I have on Wine, Cedega, XP, and CX to see where we stack up in the performance game.
And while doing my daily reading of news sites I came across this posted on /.
Those guys ran 5 game tests and Wine's performance is clearly superior to that of Cedega on benchmarks where Wine was run. They give no details of the Wine configuration, so I can only presume it's a default setup. And since they're *trying* to paint the best picture possible for Cedega, they don't point out that Wine is superior!
Should read : Cedega's performance is currently lagging that of Wine 0.9.32 and with each Wine release Wine's performance and feature set is continuously improving!
I'm open for thoughts and suggestions....
Apparently what's not said in that benchmark though is that all of the games are using OpenGL, not Direct3D, for rendering. Really Direct3D is where Wine and Cedega have completely different codepaths. So both Henri Verbeet and Stefan Dösinger suggested a D3D comparison would be much more useful. On a slightly different note, Stefan mentioned some informal benchmarking he had recently performed himself using just Wine and Linux vs. native Mac OS X:
Though the interesting thing is that I did my own native Linux vs native Mac OS X vs Wine benchmarks with glExcess a few days ago. I got pretty much the opposite result. Granted, my benchmarking code was very primitive, so read the results as +/- 10 fps, and this was on fglrx. But I got remarkable differences between wine and native, with native being up to 2 times faster.
Out of interest I did a quick check on nvidia. The difference is smaller, but there too (990 vs 1100 fps in the first glExcess scene at 640x480). Still a ~10% difference.
I also tested winelib vs PE .exe (with msvc6) and found no difference (That was 990 (winelib) vs 980 (PE)). The small differences could be because of my shitty benchmark code or because of compiler differences.
|OpenGL Child Windows Revisited||Archive|
OpenGL child windows have been broken in Wine for quite a couple of years now. It was broken (some would say 'fixed') when the window management rewrite occurred. There's been some ideas floated about how to fix it, but nothing has really come of it. For more background on this issue, see the OpenGL wiki page. Ulrich Czekalla floated a a patch last October, but it was never included in Wine. Roderick Colenbrander sent a patch this week with a different approach and gave an excellent description of the challenges behind the problem:
This is an updated version of the child window patch from Chris Robinson. I have added some fixes to it which were found by testing it with lots of programs.
Several options have been discussed over the years for solving the windowed OpenGL issues. The lazy option was to use pixmaps but you would lose hardware acceleration. A better way but similar was the use of pbuffers but still they are poorly supported by most drivers (only Nvidia has decent support).
One of the most attractive solutions is the use of glScissors/glViewport changes. This path works now if you apply Ulrich's latest patch which is in bugzilla (2398). Though for optimal performance you need specific OpenGL extensions. Second a number of standard OpenGL calls require changes and some aren't done yet (glReadPixels and friends) but right now it is one of the best solutions.
Another way of solving the windowed OpenGL problem is by using X child windows for the OpenGL window. In the end this results in the same as Ulrich's glScissor work but with the advantage that it should work fast on all OpenGL implementations as it doesn't require special extensions. Further it doesn't require the patching of OpenGL calls.
Next to the windowed OpenGL issues, there's the pixelformat limitation in Wine. Right now only one pixelformat can be used. Most programs use ChoosePixelFormat using which you can request a pixelformat but the call isn't guaranteed to give you back what you want. For this reason most programs aren't very critical.
These days more and more programs are more critical. They use wglChoosePixelFormatARB which does give you what you want or programs enumerate all pixelformats using DescribePixelFormat and choose what they want.
Anyway the issue is that the single pixelformat isn't enough anymore. A recent report from WoW on Intel drivers is a proof of this. The game didn't like the single format exported by Wine. Another example is the IKEA kitchen planner tool which uses DescribePixelFormat to enumerate all formats. It expects to find a match in a format. Right now it doesn't find any match and calls SetPixelFormat with iPixelFormat=0 (which is invalid).
Like the above two programs there are many other programs with issues due to pixelformats. I believe that perhaps a few of them are fixable (by adding more hacks or by lying to programs). If we had more pixelformats, I think the issues could be fixed. OpenGL child windows would fix this issue as the child doesn't have to use the same pixelformat as its parent (!).
If we would use OpenGL child windows in Wine that would fix most windowed OpenGL issues and second it would allow us to use more pixelformats as a child window doesn't have to use the same pixelformat as its parent.
As mentioned before the patch was mainly made by Chris Robinson and I have added a few fixes to it to make it more compatible. Basically a child window is allocated for a hdc during SetPixelFormat which needs to be called on every hdc before it can be used with OpenGL. That's basically the biggest change to the OpenGL code. For the rest some x11drv calls like SetWindowPos had to be patched in order to move the child window when needed.
Below you can find a list of tested programs and the results. As you can see it works correctly for most of the tested programs. Three of the tested programs don't work correctly of which two are not related to the use of child windows, so overall the result is good.
I'd like to know of more programs that work / don't work and I like feedback on the patch.
Properly working programs:
Other broken apps not child window related:
With a little luck we'll see a solution soon. This is one of those meta-bugs keeping an entire class of applications from working.
|DIB Engine Ideas||Archive|
Felix Nawothnig posted some ideas for how a DIB engine could get off the ground:
Okay, I've spent the last days looking into this matter and I'd like to suggest a way to get it started. So. This is the plan:
So far so good. I did all those steps (except 3., I hacked around that in my local tree) in a clean way and it works nice (for 6. I implemented SetPixel() and tried that with a test-app).
I attached patches for the steps 1 2 and 4 so you can see where this is going.
Then Felix noticed someone had been accepted for Google's Summer of Code to work on this very project. That someone is Jesse Allen and he replied:
Honestly there have been attempts before to start the DIB engine and I've seen them already. I don't think it will affect what I do, as nothing has really been accepted yet. But I suggest you find out who my mentor is and show it to him first. See if what you have done can somehow be worked into the mentoring process (hopefully it's good enough :D). I think it's early enough to work it out.
Alexandre then replied and commented on some specific points that Felix proposed:
No, LockDIBSection is a driver internal detail, gdi32 has no business knowing about this.
No it doesn't, physDev is an opaque structure as far as gdi32 is concerned. Data needed by gdi32 belongs in the DC structure.
You certainly don't want to store the full function table in the BITMAPOBJ, it will be the same for all bitmaps. All you need is one function table for the DIB driver and one for the normal graphics driver. Forwarding to the graphics driver can be done privately in the DIB driver, gdi32 doesn't need to know about it. And you probably want a separate physDev pointer for it, you'll need to maintain state for DIBs too.
Felix then replied to Alexandre's points to clarify what he'd meant.
Rolf Kalbermatter replied regarding #1 above:
I had actually a bit of a different idea but didn't get around to trying it yet. I was thinking about adding an extra value to the DIB section sync state such as DIB_Status_Conf. With this X11DRV_DIB_Coerce would decide based on a configuration setting if it should do DIB_Status_GdiMod (DIBDRV_NEVER in point 5.), DIB_Status_AppMod (DIBDRV_ALWAYS), or DIB_Status_AppMod if the DIB is already in DIB_Status_AppMod (DIBDRV_MIXED). The return value would someow indicate to that driver function if it should just simply return with a failure leaving the rest to GDI32 to deal with or do for the time being the actual work as it does now.
On driver failure (or nonexistent driver function) GDI32 would invoke the corresponding DIBDRV function for non-meta DCs. A nonexistent driver function would still work thanks to the exception handling for DIBs being accessed in application mode, although it is not the preferred way to deal with this until the DIB engine is fully functional (and the DIB handling could then be consequently removed from x11drv entirely).
This would reduce the modifications to x11drv to a minimum and also GDI32 wouldn't need much change at all. Adding a new DIBDRV function would be a change in GDI32 to add the DIBDRV call on failure of the driver function and then switching the DIB_Status value in that driver function to DIB_Status_Conf instead of DIB_Status_GdiMod.
Regardless of whether any of this is the appropriate plan of attack, it's exciting to see that 3 different people are interested in this.
|Removing Audio Drivers||Archive|
Audio in Wine has been receiving more attention lately. Maarten Lankhorst has plans to do a lot of work in this area and he's starting by doing a bit of Spring cleaning. First on the chopping block was the winearts driver:
As far as I can tell, it has been disabled for at least 4 months, and I didn't hear anyone about it, so it seems like a good idea to remove winearts, if anybody feels like reviving it, it would be easy to do so by reverting this commit, but KDE itself is moving away from arts, so I don't see a point in keeping this broken, disabled audio backend.
That patch went through. Next up he wanted to remove a few of the other slightly obscure drivers:
There are 5 different audio drivers for linux, I think this is a bit overkill, so I propose to remove the esd and nas drivers, I don't think anyone uses esd, especially that since for that task alsa can be used now since dmix addon.
I'm not sure what nas is for, but it seems to be 'network audio system', I haven't seen any use for it, except that it causes a 30 seconds slowdown at showing 'audio' tab in winecfg. I don't think anyone uses it.
For esd I think it's best to remove it, for nas I'm also for removal, but I'll settle for removing it from the winecfg list same way as winearts was disabled for a while.
What are your thoughts about this?
Vit Hrachovy raised his hand to mention he was using esd. Francois Gouget raised a good point about NAS:
NAS is used to get sound on X terminals. It would be interesting to get input from the LTSP and thin-client crowd before concluding it can be removed.
Other discussion seemed wary of removing working drivers. With regards to speeding up winecfg, Damjan Jovanovic supplied a patch to help with that:
These changes reduce the time needed to load the Audio tab of winecfg from 12 seconds down to 5.
|NT Named Pipes||Archive|
Dan Kegel forwarded a question from the c.e.m.w. (aka comp.emulators.ms-window.wine) newsgroup asking about NT named pipes support (not the same as Unix named pipes):
A user asked in
I know Alexandre's been poking around in that area, but I think he's working on local networking, not remote. I also know Kai Blin had looked at this, but I don't know where he left it.
Can someone summarize the current state and plan, if any?
Here are some past discussions on the topic:
Kai Blin, who's delved into this area, replied:
I distinctly remember Juan asking me to poke Samba's Steve French about this for last year's SambaXP conference. Steve seemed happy to add some hooks to his cifs module fur us, but I think no one came up with anything specific.
I'll be going to SambaXP again this year to show off our use of ntlm_auth to have outlook authenticate to an exchange server. Right before SambaXP starts, the Samba team will meet at SerNet for a "developer day", I'm going to be there for that, too. If we can come up with a hard list of requirements, I can look into getting this up to speed a little bit.
Now, we've been at this topic before, but as far as I can recall, we never really made much progress on this. Named pipes, as well as user handling and some parts of netapi32.dll scream for a closer interaction with Samba. As discussed before, the LGPL vs. GPL licensing is an issue, but maybe we can work around that by interfacing with winbindd to get the stuff we need.
A quick search through our wiki shows me that Juan put up three pages about this when we discussed this last time.
If we can flesh those out in the next week or two, I'll have some more substantial things to take with me to SambaXP to discuss this. I think the wiki will be ideal to collect this.
Martin Traverse came up with a patch to fix a mouse handling problem that was recently introduced:
I have done a bisection on bug #7640, mouse jitter in Halo which rendered the game unplayable. I have a patch which fixes the problem on my Gentoo system against wine-0.9.35.
Bug is introduced by
(Note: commit --59b also severely slows dinput response, fixed soon after by
Bug can be alleviated by reverting the original commit until
I put back the specialised version of Poll with MsgWaitForMultipleObjects, which fixed the problem, and have sent a patch. It was only necessary to alter Poll, not GetDeviceState. This is the first time I've sent in a patch, obviously I'm not familiar with the code so I'd be grateful for any comments.
Vitaliy Margolen disagreed with the patch and explained why it was wrong:
You patch is not correct for one simple reason - it "fixes" mouse by changing keyboard code. I have removed some code like that from dinput while cleaning it up. It had way too many hacks - leftover from some wholesale changes by TG. Of course none of their patches stated exactly what they did and why.
To fix the problem, you first need to find the reason why the code Wine has doesn't work. And how the code you're adding will fix the problem. Then you need to make some tests to check/verify what's going on.
Running a small test program (attached) with native dinput shows that it does not call MsgWaitForMultipleObjects in kbd->Poll at all (look at +relay channel). You can experiment with this program a bit more to see what dinput is doing and how ;)
|Windows/Linux Shared Objects||Archive|
A request that comes up from time to time is to take a Windows library and be able to reuse it as a Linux shared object. Phil Lodwick asked this week about it:
My googling skills are letting me down today. I believe I have seen several people requesting to do the same and answers indicating it is possible. However, after several hours of reading email archives from 2000-2007 are am officially confused :-(
I have successfully ported an application using winelib. However, what I really want to do is port a DLL to an SO which I can use natively from a Linux application.
I believe this is something that can be done with winemaker/winebuild etc if I just get the recipe right -- correct?
Stefan Dösinger explained the problem with that and why a lot of people overlook why it's so hard to do that:
I'm not the DLL expert, but I think you're missing something here.
The problem is that your windows dll will most likely use the windows APIs (otherwise, don't use wine at all). The windows APIs depend on some other things, like a few memory management constraints, the windows registry, and most likely other things too. So you can't lift the Wine core dlls outside of the environment wine sets up.
Applications and DLLs ported using winelib are native Linux .so files. So you can try to link them in, but you'll get unresolved symbols which in the long run will end up somewhere in ntdll.dll.so and libwine.so. And I think both of them depend on the environment wineloader sets up.
So the options you have are doing a real port of the dll if it does not depend on the win32 api too much (so ditch wine), or put the whole app into wine (do a full winelib port of the application), or to write some proxy winelib app and talk to the DLL using ipc like sockets, pipes, shared memory, etc.
For that reason, it's recommended that a whole application gets built as a Winelib app. Phil didn't want to do that in this case because he wanted to provide a library for other developers.
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License, version 2.0.