WWN Issue 322

This is the 322nd issue of the Wine Weekly News publication. Its main goal is to use crutches. 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

The stats below seem a little messed up and were intended to be the stats since 1/1/2007.

This week, 926 posts consumed 1788 K. There were 182 different contributors. 112 (61%) posted more than once. 35 (19%) posted last week too.

The top 5 posters of the week were:

58 posts in 76K by dmitry at codeweavers.com (Dmitry Timoshkov)
47 posts in 48K by julliard at winehq.org (Alexandre Julliard)
34 posts in 39K by rob at codeweavers.com (Robert Shearman)
31 posts in 42K by wine-devel at kievinfo.com (Vitaliy Margolen)
29 posts in 140K by stefandoesinger at gmx.at (Stefan Dösinger)

News: Wine 0.9.31, CrossOver 6.0	Archive
News There's been a lot of news related to Wine in the past five months that hasn't been covered, but I don't think we'll try to catch up on too much of it. Wine development releases have been appearing every two weeks as they have been for the past year. OLE, MSHTML, and Direct3D patches still seem to be dominating wine-patches. There's also been a lot of janitorial work done. Alexandre noted the following changes in Wine 0.9.31 that was released last week: Many Direct3D fixes and performance improvements. Several new comctl32 test cases. IDL compiler improvements. More OLE32 marshalling fixes. Over at CodeWeavers, we saw the CrossOver product have a milestone release last month. CrossOver 6.0, now slightly rebranded as CrossOver Linux and CrossOver Mac , was released on January 9th. CodeWeavers showed off CrossOver Mac at WineConf in the fall and it's a very impressive product. There's a lot of new additions in this version of CrossOver, including the beginnings of support for games. As usual, Jeremy White's announcement to the mailing list was more interesting than the press release . From that announcement: Users of Intel based Mac systems can now seamlessly run many Windows applications on their Mac without needing a Windows license. Supported applications include Outlook, Visio, Project, Quicken, Steam based games such as Half Life 2, and many more. For Linux users, we have added support for Outlook 2003, World of Warcraft, a range of Steam based games such as Half-Life 2, and a number of other applications. Additionally, CrossOver 6 represents another major step forward in the evolution of Wine, so most users will find substantial improvements in the overall compatibility and behavior of CrossOver as compared to version 5. We are looking forward to 2007, as we plan to release a range of improvements to CrossOver, particularly as we get our Mac 'sea legs' underneath ourselves. This will include refinements to many of our supported applications, and will also hopefully include expanded support for many other applications, notably games. As far as Wine development goes, we'll probably start seeing some fresh code appearing soon. Generally CodeWeavers goes through a period of about 6 months leading up to a release and shortly thereafter where a lot of bugfixes appear. After the initial release and initial round of bugfixes there's several months where new features get implemented. We're probably about ready to enter that phase.

News: Wine 0.9.31, CrossOver 6.0

Archive

News

There's been a lot of news related to Wine in the past five months that hasn't been covered, but I don't think we'll try to catch up on too much of it. Wine development releases have been appearing every two weeks as they have been for the past year. OLE, MSHTML, and Direct3D patches still seem to be dominating wine-patches. There's also been a lot of janitorial work done. Alexandre noted the following changes in Wine 0.9.31 that was released last week:

Many Direct3D fixes and performance improvements.
Several new comctl32 test cases.
IDL compiler improvements.
More OLE32 marshalling fixes.

Over at CodeWeavers, we saw the CrossOver product have a milestone release last month. CrossOver 6.0, now slightly rebranded as CrossOver Linux and CrossOver Mac , was released on January 9th. CodeWeavers showed off CrossOver Mac at WineConf in the fall and it's a very impressive product. There's a lot of new additions in this version of CrossOver, including the beginnings of support for games. As usual, Jeremy White's announcement to the mailing list was more interesting than the press release . From that announcement:

Users of Intel based Mac systems can now seamlessly run many Windows applications on their Mac without needing a Windows license. Supported applications include Outlook, Visio, Project, Quicken, Steam based games such as Half Life 2, and many more.

For Linux users, we have added support for Outlook 2003, World of Warcraft, a range of Steam based games such as Half-Life 2, and a number of other applications. Additionally, CrossOver 6 represents another major step forward in the evolution of Wine, so most users will find substantial improvements in the overall compatibility and behavior of CrossOver as compared to version 5.

We are looking forward to 2007, as we plan to release a range of improvements to CrossOver, particularly as we get our Mac 'sea legs' underneath ourselves. This will include refinements to many of our supported applications, and will also hopefully include expanded support for many other applications, notably games.

As far as Wine development goes, we'll probably start seeing some fresh code appearing soon. Generally CodeWeavers goes through a period of about 6 months leading up to a release and shortly thereafter where a lot of bugfixes appear. After the initial release and initial round of bugfixes there's several months where new features get implemented. We're probably about ready to enter that phase.

DIB Engine Discussion	Archive
Graphics The DIB Engine has been an item on Wine's tasklist for years. In fact, it's probably the single, largest outstanding task that hasn't been tackled. Part of the reason for that is Wine's graphics subsystem works pretty well in most cases. The motivation to fix the corner cases that the DIB engine would address doesn't seem to exist. Yet, most people agree that a DIB engine would bring large performance benefits. We've covered this topic in depth many times and you can see the wiki page for a description of exactly what the issue is. The short version: we need to be able to draw things within Wine that we're currently relying on the X server to do. Besides just writing the code, there's a huge concern about how to integrate such a beast into Wine without hell breaking loose. Rolf Kalbermatter recently brought up the topic and wanted to get some feedback on it. After a long discussion of what's involved, he posted a summary: This is getting a bit long so if you do not have time, then skip this. I've looked a little more at the issue of a DIB Engine and tried to use the feedback so far to get an idea of what the possible architecture could be. First I took a look at how Windows seems to do it currently (excluding Vista). There GDI32 is mostly a wrapper around win32k.sys and the different GDI APIs call mostly into corresponding NtGdi... functions in win32k.sys. Those functions do the actual handling and call the according driver that is attached to the DC. The interface to the driver is similar to what is done now in Wine although not identical. The modern Windows display driver interface uses sometimes more or less different functions than the old one as used in Wine. A driver can either not implement certain functions, only implement them for its device specific surfaces, or hook certain calls by returning flags inside the driver initialization structure on initialization. Those hook flags tell the GDI engine that the driver wants to be called for DIB surfaces too for particular functions and bit depths. The driver will then be called for according DIB surfaces too and it can decide to do whatever it can do best and for those cases it doesn't know well how to do it, call back into the GDI engine using an according Eng... function. This calling back into the GDI engine for hooked functions is called punting by MS. If the driver didn't provide the actual function it will possibly be simulated by the GDI engine by calling other driver functions and if the driver didn't hook the function or didn't succeed and it is for a DIB surface then the GDI engine itself will call the corresponding Eng... function. GDI32 exports most of those Eng... functions too but they are simply user space wrappers around the win32k.sys entry points for those functions. From a design view it might be interesting to separate the actual GDI engine into a subpart that corresponds with the NtGdi... functions in win32k.sys even though they might stay inside GDI32 for the time being. The actual Eng... functions would be also placed inside that GDI engine and are in fact mostly the long awaited DIB engine. Such an architecture would make reuse of such a GDI32/win32k combo in other projects fairly easy. However this NtGdi API is not documented although it is presumably mostly a mirror of the GDI API. There are lists of what APIs win32k.sys does export and how many parameters each of these functions takes, extracted from the actual win32k.sys file. Even though Windows keeps them in the win32k.sys kernel I think it would be a good idea to keep them all in GDI32 for the time being. If that API is at some time mostly complete and separation into its own DLL or something would be desired, this could be done quite easily. But it is certainly quite a bit tedious to do and would require at least partly some sort of clean room reverse engineering and it's not really necessary for a DIB engine at all at this point. There is a little problem with those Eng.. functions however. They are modeled after the new NT display driver interface that is in so far different that it does use partly different functions and parameters to the old (I assume Win 3.1 display driver) interface used in Wine and this is even more or less all documented in the DDK, although the basic principle between the Windows driver interface and what Wine does is of course mostly the same. Rolf brings up some good points, especially those regarding the newer GDI interfaces that exist in Windows. So while it doesn't seem like Wine is any closer to a DIB engine, at least ideas are floating around.

DIB Engine Discussion

Archive

Graphics

The DIB Engine has been an item on Wine's tasklist for years. In fact, it's probably the single, largest outstanding task that hasn't been tackled. Part of the reason for that is Wine's graphics subsystem works pretty well in most cases. The motivation to fix the corner cases that the DIB engine would address doesn't seem to exist. Yet, most people agree that a DIB engine would bring large performance benefits. We've covered this topic in depth many times and you can see the wiki page for a description of exactly what the issue is. The short version: we need to be able to draw things within Wine that we're currently relying on the X server to do. Besides just writing the code, there's a huge concern about how to integrate such a beast into Wine without hell breaking loose.

Rolf Kalbermatter recently brought up the topic and wanted to get some feedback on it. After a long discussion of what's involved, he posted a summary:

This is getting a bit long so if you do not have time, then skip this.

I've looked a little more at the issue of a DIB Engine and tried to use the feedback so far to get an idea of what the possible architecture could be.

First I took a look at how Windows seems to do it currently (excluding Vista). There GDI32 is mostly a wrapper around win32k.sys and the different GDI APIs call mostly into corresponding NtGdi... functions in win32k.sys.

Those functions do the actual handling and call the according driver that is attached to the DC. The interface to the driver is similar to what is done now in Wine although not identical. The modern Windows display driver interface uses sometimes more or less different functions than the old one as used in Wine.

A driver can either not implement certain functions, only implement them for its device specific surfaces, or hook certain calls by returning flags inside the driver initialization structure on initialization. Those hook flags tell the GDI engine that the driver wants to be called for DIB surfaces too for particular functions and bit depths. The driver will then be called for according DIB surfaces too and it can decide to do whatever it can do best and for those cases it doesn't know well how to do it, call back into the GDI engine using an according Eng... function. This calling back into the GDI engine for hooked functions is called punting by MS.

If the driver didn't provide the actual function it will possibly be simulated by the GDI engine by calling other driver functions and if the driver didn't hook the function or didn't succeed and it is for a DIB surface then the GDI engine itself will call the corresponding Eng... function. GDI32 exports most of those Eng... functions too but they are simply user space wrappers around the win32k.sys entry points for those functions.

From a design view it might be interesting to separate the actual GDI engine into a subpart that corresponds with the NtGdi... functions in win32k.sys even though they might stay inside GDI32 for the time being. The actual Eng... functions would be also placed inside that GDI engine and are in fact mostly the long awaited DIB engine. Such an architecture would make reuse of such a GDI32/win32k combo in other projects fairly easy. However this NtGdi API is not documented although it is presumably mostly a mirror of the GDI API. There are lists of what APIs win32k.sys does export and how many parameters each of these functions takes, extracted from the actual win32k.sys file. Even though Windows keeps them in the win32k.sys kernel I think it would be a good idea to keep them all in GDI32 for the time being. If that API is at some time mostly complete and separation into its own DLL or something would be desired, this could be done quite easily. But it is certainly quite a bit tedious to do and would require at least partly some sort of clean room reverse engineering and it's not really necessary for a DIB engine at all at this point.

There is a little problem with those Eng.. functions however. They are modeled after the new NT display driver interface that is in so far different that it does use partly different functions and parameters to the old (I assume Win 3.1 display driver) interface used in Wine and this is even more or less all documented in the DDK, although the basic principle between the Windows driver interface and what Wine does is of course mostly the same.

Rolf brings up some good points, especially those regarding the newer GDI interfaces that exist in Windows. So while it doesn't seem like Wine is any closer to a DIB engine, at least ideas are floating around.

Summer of Code 2007	Archive
Summer of Code 2007 Google's Summer of Code is back. This year things are kicking off a little earlier so there's some time to come up to speed with regards to each project. Tom Wickline announced it on wine-devel: I see Google is going to do their summer of code again this year :-) They plan to start accepting applications in March, so now would be the time for us to propose new projects and review the ones we have already listed on the Wiki for interested applicants? As well as line up mentors for the accepted applicants? https://wiki.winehq.org/SummerOfCode http://google-code-updates.blogspot.com/2007/02/speaking-of-summer.html Many of the projects on the wiki are still available to be worked on. There's also about a bazillion other things you could take a stab at.

Summer of Code 2007

Archive

Summer of Code 2007

Google's Summer of Code is back. This year things are kicking off a little earlier so there's some time to come up to speed with regards to each project. Tom Wickline announced it on wine-devel:

I see Google is going to do their summer of code again this year :-) They plan to start accepting applications in March, so now would be the time for us to propose new projects and review the ones we have already listed on the Wiki for interested applicants? As well as line up mentors for the accepted applicants?

Many of the projects on the wiki are still available to be worked on. There's also about a bazillion other things you could take a stab at.

GNOME & Freedesktop Menus	Archive
Integration David Saez Padros did some work on getting Wine working better with the freedesktop.org specs: I saw your post at https://wiki.winehq.org/GnomeMenusIntegration and i made some freedesktop compliant files which: add a global Wine menu item in the Aplications menu (seen by all users) with WineFile and WineMine, which also merge all user specific wine installed programs. add a global menu item for winecfg in System -> Preferences (seen by all users) I also have what should be added to installation so .exe files are executed with wine when double-clicked (tested in ubuntu) How could i submit those files ?? I cannot find anything related to this in the bugzilla :( Mike Hearn briefly described what to do: Sounds great! To submit those files, you need to make a patch ... git can do this but I don't remember the exact command to use (depends on your setup also). Or you can do it the old fashioned way using diff directly. Feel free to ask if you'd like more guidance with this. Once you have a patch, email it to wine-patches at winehq.org so Alexandre and the others can review it, suggest improvements etc. Good luck! This work builds on the foundation laid by Vitaliy Margolen in November for using the Freedesktop standard to create Wine's menu structure.

GNOME & Freedesktop Menus

Archive

Integration

David Saez Padros did some work on getting Wine working better with the freedesktop.org specs:

I saw your post at https://wiki.winehq.org/GnomeMenusIntegration and i made some freedesktop compliant files which:

add a global Wine menu item in the Aplications menu (seen by all users) with WineFile and WineMine, which also merge all user specific wine installed programs.
add a global menu item for winecfg in System -> Preferences (seen by all users)

I also have what should be added to installation so .exe files are executed with wine when double-clicked (tested in ubuntu)

How could i submit those files ?? I cannot find anything related to this in the bugzilla :(

Mike Hearn briefly described what to do:

Sounds great! To submit those files, you need to make a patch ... git can do this but I don't remember the exact command to use (depends on your setup also). Or you can do it the old fashioned way using diff directly. Feel free to ask if you'd like more guidance with this.

Once you have a patch, email it to wine-patches at winehq.org so Alexandre and the others can review it, suggest improvements etc. Good luck!

This work builds on the foundation laid by Vitaliy Margolen in November for using the Freedesktop standard to create Wine's menu structure.

Direct3D Screenshots	Archive
DirectX To say Direct3D has seen a lot of work over the past few months would be an understatement. Stefan Dösinger and others have been pouring patches in by the truckload. After another round of patches, someone commented: Wow, great work!!!!! 3DMark 2006 with fbo looks really coool!! And some Nvidia SDK demos are completely fixed! Following up on that, there were some screenshots posted: Yes, but after accepting this error message i can select some test and run the benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 and GT2 tests are almost perfect, but very slow (fbo is slower than backbuffer, so I am not using it in other applications), you should also disable post processing (very very slow) in 3DMark. Here are some screenshots with latest wine and latest Stefan patches: http://62.240.181.87/Mirek/3DMark2006/ Neil Skrypuch mentioned that 3DMark is rather fussy and might take some coaxing to get to run, 3DMark 05 and 06 are quite picky about caps, there's a few that are slightly off and it refuses to run Henri Verbeet then provided a patch that may help with it.

Direct3D Screenshots

Archive

DirectX

To say Direct3D has seen a lot of work over the past few months would be an understatement. Stefan Dösinger and others have been pouring patches in by the truckload. After another round of patches, someone commented:

Wow, great work!!!!! 3DMark 2006 with fbo looks really coool!! And some Nvidia SDK demos are completely fixed!

Following up on that, there were some screenshots posted:

Yes, but after accepting this error message i can select some test and run the benchmark, i have full version v102. I can't run any PS3 HDR test, GT1 and GT2 tests are almost perfect, but very slow (fbo is slower than backbuffer, so I am not using it in other applications), you should also disable post processing (very very slow) in 3DMark. Here are some screenshots with latest wine and latest Stefan patches:

http://62.240.181.87/Mirek/3DMark2006/

Neil Skrypuch mentioned that 3DMark is rather fussy and might take some coaxing to get to run, 3DMark 05 and 06 are quite picky about caps, there's a few that are slightly off and it refuses to run

Henri Verbeet then provided a patch that may help with it.

Toolbar Regression Archive

Toolbar Regression	Archive
Controls Common controls aren't something you hear a lot about in Wine any more. Sure, there's patches here and there, but for the most part development has moved on. Common controls are responsible for all of the control mechanisms you see in a Windows program: scrollbars, toolbars, listviews, etc. Pavel Troller reported a regression that occurred recently: I just found a regression in comctl32 and bisected it successfully. The following commit `369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit commit 369749dcb2ba12ce8481503543afd18ad99805d1 Author: Dmitry Timoshkov <dmitry at codeweavers.com^gt; Date: Mon Feb 12 16:47:56 2007 +0800 comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code. :040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M dlls` causes IDA Pro to show black squares instead of its toolbar icons. Apparently this regression is causing problems in other programs too. Dmitry was aware of the problem and referred him to bug #7405 .

Controls

Common controls aren't something you hear a lot about in Wine any more. Sure, there's patches here and there, but for the most part development has moved on. Common controls are responsible for all of the control mechanisms you see in a Windows program: scrollbars, toolbars, listviews, etc. Pavel Troller reported a regression that occurred recently:

I just found a regression in comctl32 and bisected it successfully. The following commit


369749dcb2ba12ce8481503543afd18ad99805d1 is first bad commit

commit 369749dcb2ba12ce8481503543afd18ad99805d1

Author: Dmitry Timoshkov <dmitry at codeweavers.com^gt;

Date:   Mon Feb 12 16:47:56 2007 +0800



    comctl32: Make ImageList_Read and ImageList_Write compatible with each other, simplify the code.



:040000 040000 7a8b282d58c6a6111ad0995eb8d47cbfbc8cadb0 afca21972669e3d013eef8de59556675a0bc798b M      dlls

causes IDA Pro to show black squares instead of its toolbar icons.

Apparently this regression is causing problems in other programs too. Dmitry was aware of the problem and referred him to bug #7405 .

RHEL 3 RPM's	Archive
Packaging What's the most thankless job when it comes to Wine? Packaging and maintaining packages would be pretty high on the list. Thanks to Andreas Bierfert, Marcus Meissner, Ivan Leo Puoti, Adam Schreiber, Scott Ritchie, Gerald Pfeifer, Kris Moore, and Robert Lunnon, Wine has excellent coverage with up to date packages. Bill Medland still had a question though: I'm looking to see if there are rpms being built for Red Hat Enterprise Linux 3 these days. I see that the Red Hat rpms nowadays are for fc. but they aren't suitable for RHEL3 The download page says that the RedHat/Fedora area is for RedHat 8,9 and Fedora, but I don't see any RedHat 8 or 9 there. Are they not there or am I looking in the wrong place? Lei Zhang then spoke up and mentioned that although the RPMs aren't listed on Wine's Download page, he maintains them: I build RPMs for RHEL 3, give them a try: http://linux.ucla.edu/~leiz/software/wine/rpms.php

RHEL 3 RPM's

Archive

Packaging

What's the most thankless job when it comes to Wine? Packaging and maintaining packages would be pretty high on the list. Thanks to Andreas Bierfert, Marcus Meissner, Ivan Leo Puoti, Adam Schreiber, Scott Ritchie, Gerald Pfeifer, Kris Moore, and Robert Lunnon, Wine has excellent coverage with up to date packages. Bill Medland still had a question though:

I'm looking to see if there are rpms being built for Red Hat Enterprise Linux 3 these days. I see that the Red Hat rpms nowadays are for fc. but they aren't suitable for RHEL3 The download page says that the RedHat/Fedora area is for RedHat 8,9 and Fedora, but I don't see any RedHat 8 or 9 there. Are they not there or am I looking in the wrong place?

Lei Zhang then spoke up and mentioned that although the RPMs aren't listed on Wine's Download page, he maintains them:

I build RPMs for RHEL 3, give them a try:

http://linux.ucla.edu/~leiz/software/wine/rpms.php

IE Developers Toolbar	Archive
Web/HTML Darryl Dixon was pleased that the IE Developers Toolbar is now working with Wine: Just a brief to let you know that it looks like Microsoft is finally taking compatibility seriously ;) - the new Beta 3 version of the IE Developers Toolbar (link ) improves on the previous Beta release by installing and working correctly with wine 0.9.30 with an IE6 'ies4linux' install. In the previous Beta, the 'View DOM' button did not work in wine 0.9.30 - this new version fixes that and adds lots of enhancements. I don't know if this is useful to many here, but it sure is for me, so I thought I'd share. Nice to see Microsoft improving their software to work better with Wine for once (even though I'm sure it's unintentional ;).

World Wine News