World Wine News

There's a groklaw article summarizing recent discussion about the impact of the Bilski case on software patents: http://www.groklaw.net/article.php?story=20081102011538422

"The judge says this kind of cloning could be done without infringing Microsoft's copyrights, but how about its patents? Prior to Bilski, one might give one answer. Now, one might give another."

If we thought Wine unlikely to be attacked by Microsoft due to nebulous patent issues and anti-trust implications, it's even less likely now.

Thanks,
Scott Ritchie

So, I was thinking on :

1) Try to join best stuffs of both repos of Huw and Jesse.

2) Add the environment variable DIBENGINE which could have 3 different values (or be missing) :

missing DIBENGINE env var or
DIBENGINE=NONE New dib engine will not be used, back to X11DRV

DIBENGINE=FORWARD Unimplemented stuffs forwarded to X11, the rest using new dib engine code

DIBENGINE=FULL use just dib engine code and shows FIXMEs for
unimplemented stuffs

The first would allow to insert dib engine in main stream without breaking anything, the last would allow to see what's more important to implement. The middle one (FORWARD) would allow to check if something breaks during the transition, and use the developed parts.

3) Stop and wait till it's put on mainstream, so more people could contribute.

The doubt is if it'll be possible the mixed approach, forwarding unimplemented stuffs to X11, but I think so.

Is it an acceptable way to proceed ?

I've already started working on it about 3 months ago and released some functions inside DIB Engine. But now we're thinking about release DIB inside GDI32 as Detlef Riekenberg proposed.

I see it this way (but I could be wrong) :

1) Application uses a DIB format, rendering should be done by DIB driver, conversion is needed only to display it. This is what by now is done with 2 conversions between DIB-X11-DIB formats.

2) Application uses accelerated opengl, for example; it must (afaik) use native format and functions to render it. No need to convert anything.

3) Printer drivers. For ps, they're rendered translating GDI calls into postscript code, for other format the driver should do the rendering. Again, no conversion needed.

So, I don't understand why to have DIB engine INSIDE GDI. Function pointers could handle the correct driver calls depending on DIB (or DDB) format.

Under the hood Windows uses Eng* functions in the win2k/winxp driver model (perhaps even Vista, don't know). It is a different architecture than what Wine uses we are close to a win3.1 design. The use of the real win32 functions would offer the possibility of using native printer drivers again (not sure if this is something we really want). Doing stuff the microsoft way might have advantages for properly integrating ddraw and other things. On the other hand it could be a lot of work to get right.

Here's my view on DirectDraw / D3D and the DIB engine. There are two cases. First of all you have plain 'software rendering' in which we do 2d ddraw using GDI and DIB. The use of a DIB engine would save us some roundtrips to X and make color conversion more efficient. Depending on the situation it could boost performance quite a bit.

Second ddraw/d3d apps can use GetDC / ReleaseDC in order to get a HDC which they can use to draw to the ddraw surface. In case of D3D or 'hw accelerated' ddraw (DirectDrawRenderer=opengl) we need to read the image back from the videocard. Then the app works on it using GDI calls which at this point require evil color conversion and roundtrips to X. In the end the image is returned to wined3d and it is uploaded to the card. Various games use this method to draw text. Stefan's idea was to write a opengl dib engine for this. My own idea which matches a bit what Windows does is to use GLX_EXT_texture_from_pixmap which all drivers are starting to support. The idea would be that WineD3D downloads the image from the videocard. The dib engine would render in software to the dib and then GLX_EXT_texture_from_pixmap is used to reupload the corresponding pixmap to the videocard (the pixmap needs to be in the same depth as X). This could be done in different ways. I can imagine that a game uses 8bit (but using opengl we render it at 24bit) and that the dib engine just keeps working at 24bit (it would need to convert all 8bit operations to 24bit), to prevent a lot of depth conversion. Windows also has functionality to improve ddraw and gdi interaction. It works in about the same way. Going this way could make ddraw-gl finally hw accelerated in all areas.

From reading all your mails I get the impression that Etersoft is also doing some work on the DIB engine. What work has Etersoft done on this area? It might be wise to post the code somewhere for review before the wrong direction is taken again and it might prevent code duplication.

Roderick

We have received Huw Davies and Jesse Allen gits with their versions of DIB and continued working on it. But we're planning to change DIB Engine structure in these cases:

1. Releasing DIB Engine functions inside GDI.
2. Releasing interactioin DIB Engine with other drivers (such as X11, PS etc.)

Today we've developed some DIB functions iwithout cnaging DIB driver structure. The main structure of DIB is just an idea and it was not changed yet.

put a testing patch (which introduces Jesse Allen's dib engine in current tree) on bugzilla - Bug 421 page. The engine was tested on autocad (many display problems, but noticeable speedup) and with Excel (quickly, works, display problems in dialogs).

The patch is just for testing purposes and to get some advice on how to proceed.

http://bugs.winehq.org/show_bug.cgi?id=421
Ciao
Max

Hi,

There is a discussion going on over at https://bugs.launchpad.net/ubuntu/+source/wine/+bug/111061 about improving Wine's look and feel to better match the system that it is running on.

The situation is as follows:

== Colour Schemes

Wine supports these by reading the settings from the registry. Winecfg can load a .theme file containing a colour profile and adapt accordingly (saving those settings to the registry).

At the moment, if you need to script this (e.g. when installing Wine) you need to manipulate the registry. It would be helpful if winecfg (or some other helper utility) supported setting the theme file on the command line.

In addition to this, if the user changes the theme used on their system it would not be reflected by Wine.

== Windows Theme Support

Windows theming support is in place to some extent, w.r.t. the XP theming APIs. There are some user32 controls and the window/dialog handlers that don't support theming yet and there are some performance issues that need resolving.

This would be set via the command line used to set the colour scheme since they can be set via the same .theme file. This is limited in that you need an XP theme for each native theme available.

== Native Theme Support

The main thing here is that Wine would monitor the native system for theme changes.

The colours of the native theme would be mapped to the Windows system colours, saved to the registry and then a WM_SYSCOLORCHANGED message would be sent to all open top-level windows so they could update to the new look.

Any metric data would be mapped in a similar way.

As for the theme, an implementation of uxtheme would map the API calls to the native calls. Here, it may be possible to just send a request to redraw everything on each active window. If not, a WM_THEMECHANGED message would need to be sent to all active windows.

The challenge with native theme support is two-fold: (1) it should work on any system - some have Gtk, some Qt and some Cocoa/Carbon, while others (like the *BSDs and OpenSolaris) are likely not to have those engines available; (2) it should not break any Windows application.

Note that as Vista has a different msstyles theming engine (it is a DLL), we could have the msstyles DLL expose the uxtheme API and have uxtheme call msstyles to do the rendering. That way, we could have a gtk.msstyles, qt3.msstyles, qt4.msstyles and an carbon.msstyles that would bind to the corresponding theming engine. If the msstyles DLL does not expose those methods, the uxtheme engine could then fallback to the current XP theme processing.

For Mac theme support that would possibly require Objective-C code to be done properly, that theme could be an external package (possibly in darwine) that would be installed in addition to Wine. The same thing for the Qt engines, allowing them to directly interface with the C++ Qt APIs.

Thoughts? Ideas?

- Reece

Hi,

There are a bunch of uxtheme / control theming bugs which need to be fixed but lets ignore those issues for now.

In the end we need to support a bunch of different theme engines GTK, QT, Cocoa and perhaps later on more. In theory it would be possible to create a different uxtheme backend for each different toolkit. One major issue is the language which each of these toolktis is written in. GTK would be fine as it is C but QT and Cocoa require respectively C++ and Objective C. Alexandre doesn't want such languages in (although he might make an exception for the winecocoa driver if it is really, really needed).

While using a language different than C is a definitive no, I think Alexandre might allow the use of other languages in helper programs. The best way would be to write a separate program (which would have backends for all the needed toolkits) which generates a .msstyles theme (or if Vista uses a newer and better format, lets directly move to that format). The main issue would then be on how to sync themes. I guess that would need to be done at wine startup.

Roderick

FWIW, my opinion is that any deep integration is going to be hard, and that for the moment we should go with something much simpler: simply support mstheme files well, and provide themes that look like the default themes on Ubuntu / OpenSuse / Fedora.

For fun I looked a bit at the format. An msstyles file is just a win32 resource file. It contains various sections each containing strings, colors or bitmaps. Colors are just stored in a text file. Uxtheme parses this text file and loads the colors 1:1 from this section into the registry.

In order to obtain a resource file I used a tool called resource hacker to retrieve one from a GPLed clearlooks theme (most windows theme tools only provide binaries or some usefuless xml files). A msstyles file contains various section which contain the msstyles version (PACKTHEM_VERSION), the different color version of the theme (COLORNAMES). The real info is burried inside 'ini files' which are stored inside the 'TEXTFILES' section of the file (the names of the ini files correspond to FILERESNAMES). Each ini file contains a bunch of sections for buttons, textboxes and all other controls. There's also a generic 'SysMetrics' section which contains some classic properties like ActiveCaption and others. The control specific ones are the most important and they contain the dimensions of lets say a button, where to position text, what DPI to use and more.

Initially my idea was to create a sample .msstyles project but this looks like a huge task as I would need to fill in every attribute of each control. If I would provide an incomplete theme (which might be legal not sure) the current theming code in Wine will fail as it expects theme info to be around.

As everyone is aware of big improvements are needed to the comctl32 theming code and other places which need to draw using themes. For example in case of a button the current drawing code calculates the position for drawing text iself while it should get this info from the theme. The same for other controls.

Roderick

The way to go for Wine theming is to use Windows XP themes. Unfortunately the file format itself is not documented. Based on Wine its uxtheme code (BTW our uxtheme is quite complete) and an analysis of some 'free' XP themes like 'ClearLook' I was able to write my own theme template.

First of all for I want to warn all people who want to write Wine themes. A Windows theme consists of colors, font sizes, bitmaps and dimensions of controls. Windows theme editors use XP themes as a template for creating new themes, so even if you find a 'free' theme it is in the end derived from a Microsoft theme and most of the time Luna. Myself I analyzed the clearlooks and some other free ones just to understand Wine's uxtheme code. If you want to write themes use the uxtheme code as your reference. For instance dlls/uxtheme/stylemap.c shows which properties are allowed on each control. If a property on lets say a button is called 'CONTENTMARGINS' themes useally type 'ContentMargins',

Anyway now to the theme file I created. A theme file is a resource file which contains various sections. They contain the names of the builtin color schemes, font sizes and of course the actual theme data. The theme data itself is stored in ini files. Most themes offer differ font sizes and colors and for each combination there is a ini file.

The theme file I made only consists of a 'SysMetrics' section which contains the 'classic' color names which can also be adjusted from the Control Panel\\Colors registry location. The difference is that in XP Microsoft cleaned up the names, so some of the names have changed. The theme is compiled using mingw because right now winecfg seems to need a real 'MZ' header.

A lot of work is needed especially in comctl32 and also in uxtheme its drawing code to optimize the drawing performance and to properly render themes. For this purpose you should use some free native XP themes and try them to render properly in Wine. The uxtheme drawing code needs to handle margins, locations and positions properly. Right now in case of a button comctl32 is making assumptions about text locations and I don't think that belongs there.

Hopefully some people will step up to create Wine themes and improve utheme and our theme drawing. Myself I envision a 'winetheme.msstyles' which contains some GTK and QT color themes.

Roderick

Hi,

I have my vertex pipeline replacement almost ready to send. Because the fragment pipeline replacement caused a bunch of regressions, I want to give this patch a bit of testing before committing it. I expect slightly more regressions there because the vertex processing stuff is still badly tested, especially lighting.

Can you give the patches a try and see if your game still works? For now the most important part is that the game works without any performance loss or rendering bugs.

This patchset is supposed to address the following issues:

1) Improve performance in applications that are hit hard by drawStridedSlow. I don't know if there are many left, because the vertex buffer fixups really helped here

2) Allow adding features that do not exist in the GL fixed function pipeline(or are not supported by drivers): Vertex blending, tweening, more efficient material tracking, per-vertex point size

3) Make the way towards OpenGL 3 forward compatibility mode

So far (1) should already go some way with these patches. There are no new features added yet, and opengl 3 needs the same stuff implemented with GLSL and further work, but this is a necessary start.

Once these patches are in, I'll turn to fine-tuning things. The rhw handling can be done better(maybe), and vertex buffer loading can be made much cheaper if the pipeline replacement is in use and opengl supports native 16 bit vertex attributes. This should get old card compatibility costs off our backs when we're running on a modern GPU without sacrificing backward compatibility.

Howdy Wine Users!

The Wine developers are currently faced with 4329 open bugs in Bugzilla. While most of these are valid bugs, many haven't been checked on in months, and may already be fixed. If you've got time and bandwidth to kill, please help us by verifying these bugs. There are currently 643 bugs with downloads that haven't been checked on in 3 months (see bugzilla ).

If you're an moderately experienced Wine user and already have a Bugzilla login, please test these bugs in 1.1.10 or newer Wine and leave a note in the bug with its current status. Be sure to test in a clean WINEPREFIX (.wine folder)!

Hi guys,

I can finally report success on the first ever win64 program running on wine. The program was a textbook classic, but to make it work gcc had to be changed a lot. This was done by Kai Tietz, who has put a lot of effort in the task of making gcc accept the calling convention.

There are still a lot of things which should be done before this will be able to get into mainline though.

My repository is at http://repo.or.cz/w/wine/wine64.git , but in order to actually get it working you need gcc checked out from subversion with some experimental patches. They are expected to get merged soon, so until then it is not recommended to even try. :)

There are a bunch of things in my tree which are not merged with mainline. A few of them are hacks (disabling SEGV handling for example).

There are also some changes which should be accepted, but still need some work. For example wineserver, AJ wants something with regards to fd handling, but I didn't find him clear on what exactly. va_list also is incompatible, and should be replaced with ms_va_list where appropiate.

Once again, thanks to Kai Tietz for making this possible.

Cheers,
Maarten.