• Broken aRts sound driver now removed for good.
• Many fixes to the Quartz DLL sound support.
• File I/O performance improvements.
• The usual assortment of Direct3D fixes.

Today TransGaming introduced Cedega 6.0, which is the popular Linux game emulator based upon WINE.

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 /.

http://www.phoronix.com/scan.php?page=article&item=681&num=1

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!

"It is also important to note that there were minimal performance differences between WINE 0.9.32 and Cedega 6.0. Granted there are only five benchmarks in this Cedega 6.0 performance preview, but the level of performance for Cedega does look extremely promising and we will continue to look at Cedega 6.0 and report back in future articles."

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....

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.

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.

Windowed OpenGL

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.

OpenGL pixelformats

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 (!).

Summary

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.

Patch

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:

• Blender
• Google Earth
• Google SketchUp
• Lightwave 6 + 9
• MilkShape3D
• Terragen + Terragen2
• VLC OpenGL plugin
• Valve Hammer tool
• Weatherscope
• Q3Radiant

Unfixed programs:

• Truespace 6.5; The program uses OpenGL for its main window and uses some floating win32 toolbars. The child window obscures them, perhaps the SHAPE extension for X can be of help here to cut parts away.

Other broken apps not child window related:

• NWN Model viewer; The program seems to do be using WGL in an illegal way but seems to get away with this without any failures on Windows. I don't know what's going on. It also never worked correctly before when there were X windows. It now behaves the same as before. Using Ulrich's patch it works but that's basically an 'accident'. It isn't because the code is fixed.
• IKEA kitchen planner; The program uses multiple child windows one for a 3D preview which works fine and it uses one for drawing on a grid. When drawing things on the grid, the objects quickly disappear. There's some buffer swapping issue I guess. The same happens without the child window patch and using Ulrich's patch. So the issue is not related to child windows.

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:

1. In winex11.drv:
   -INT X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL lossy)
+HBITMAP X11DRV_LockDIBSection(X11DRV_PDEVICE *physDev, INT req, BOOL force)
   Lossy isn't used anywhere for LockDIBSection anyway. Force means that the function will only lock if the DIB is already in AppMod. The returned bitmap is of course physDev->bitmap->hbitmap.

   Rationale: If you lock the DIB to write on it, it makes sense that the function actually provides you with that DIB.

2. Export LockDIBSection/Unlock to gdi32.

   Adding more exports is not nice but there really is no way around that, right?

3. Move dc->funcs to dc->physDev->funcs. Many changes but mostly mechanical work.

   Rationale: This really belongs there. And I need it. :)

4. Now we write dibdrv.c for now just containing DIBDRV_Install and DIBDRV_Remove. That function will go through the physDev->funcs list and overwrite each function pointer which is actually implemented with DIBDRV_PutPixel(), whatever.

   DIBDRV_Install/DIBDRV_Remove will be called from BITMAP_SelectObject() when we switch from non-DIB to DIB and vice versa.

   Note that we can't use DRIVER_load_driver here because of the wanted "forward to original driver when not implemented".

   For this we will need to extend the "for DIB objects" part in BITMAPOBJ by

   const DC_FUNCTIONS *orig_funcs;
DC_FUNCTIONS local_funcs;
   where orig_funcs to the old physDev->funcs and the new physDev->funcs points to &bmp->local_funcs.

5. In dibdrv.c we get us:
   enum {
   DIBDRV_MIXED, /* Choose driver depending on current AppMod */
DIBDRV_ALWAYS, /* Always use DIBDRV (unless function not implemented) */
DIBDRV_NEVER /* Always use DC driver */

   } DIB_Mode = DIBDRV_MIXED;
   and DIB_Lock(PHYSDEV physDev) / DIB_Unlock(PHYSDEV). Now, here comes the reason we need the HBITMAP from LockDIBSection() and funcs inside PHYSDEV:

   Since we don't have the DC here we have no way of calling LockDIBSection(), forwarding to the original driver if NEVER/MIXED or writing to the actual DIB in case of MIXED/ALWAYS.

6. From this point we can start implementing one function at a time, touching nothing but dibdrv.c.

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.

Comments?

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.

[regarding #2]

No, LockDIBSection is a driver internal detail, gdi32 has no business knowing about this.

[regarding #3]

No it doesn't, physDev is an opaque structure as far as gdi32 is concerned. Data needed by gdi32 belongs in the DC structure.

[regarding #4]

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.

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.

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.

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?

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.

These changes reduce the time needed to load the Audio tab of winecfg from 12 seconds down to 5.

Changelog:

• Load audio drivers in multiple threads, so the length of time the GUI is blocked for is the length of the longest driver load time, rather than the sum of them all.
• Keep audio drivers open until they need to be reloaded, because it can take a very long time to load them multiple times.

A user asked in

http://groups.google.com/group/comp.emulators.ms-windows.wine/msg/06fbfdfb53a28cbd

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:

• http://www.kerneltraffic.org/wine/wn20060428_312_print.html#3
• http://www.winehq.org/pipermail/wine-devel/2005-September/039680.html
• http://kerneltraffic.org/wine/wn20040109_204.html#3

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.

• http://wiki.winehq.org/NamedPipes
• http://wiki.winehq.org/EndPointMapper
• http://wiki.winehq.org/DcomInterfaces

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.

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

commit b22ff8018aca7c365e505f1db7732f7050ae259b
dinput: Remove MsgWaitForMultipleObjects call

(Note: commit --59b also severely slows dinput response, fixed soon after by

commit 685a3e6a6ed623718f640e8906bd44fbca3d8b2c
dinput: Release critical section before warping mouse)

Bug can be alleviated by reverting the original commit until

commit af71538d3343a1cec73e75391a7ebfd5b3ed94ee
dinput: Remove duplicate Keyboard->Poll it is the same as base class

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.

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 ;)

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?

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.