WineHQ

World Wine News

All the news that fits, we print.

02/26/2007
by Brian Vincent
Issue: 323

XML source
More Issues...

This is the 323rd issue of the Wine Weekly News publication. Its main goal is to have the same great taste, now with real mailing list stats. 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, 152 posts consumed 471 K. There were 57 different contributors. 28 (49%) posted more than once. 45 (78%) posted last week too.

The top 5 posters of the week were:

  1. 16 posts in 133K by stefan at codeweavers.com (Stefan Dösinger
  2. 15 posts in 13K by hverbeet at gmail.com (H. Verbeet)
  3. 11 posts in 21K by rob at codeweavers.com (Robert Shearman)
  4. 10 posts in 9K by wine-devel at kievinfo.com (Vitaliy Margolen)
  5. 7 posts in 15K by patrol at sinus.cz (Pavel Troller)

News: Short Article Archive
News

There's short editorial on LinuxWorld (Network World?) by Scott Bradner about running Windows apps on non-Windows platforms titled, Obeying Microsoft: Is Wine the way? . Virtualization and Wine are mentioned but Scott summarizes with:

The Wine approach seems to me the ideal way to support nonnative software on your platform of choice. Because Microsoft is making the main alternative too expensive, I expect to see wider use of this approach in the future.


Direct3D Breakage in 0.9.31 Archive
DirectX

Wine's bi-weekly snapshots are exactly that - snapshots of the git repository. There's no extra care given toward a release, no regression testing done (other than the usual process of running the regression test suite), and certainly no applications checked for compatibility. Pavel Troller warned gamers last week to stay away from release 0.9.31:

I've tried 0.9.31 and it seems that there is a regression in at least two games:

  • Fallout Tactics (BOS.exe): Shows a dialog stating
      "C:\dev\phoenix\display\win32\win32_window.cpp(873): **fatal error**: Could not create display buffers"
    and then another one about abnormal termination of the program and quits.
  • Steam based games, mainly HL2: During game load, the screen goes black. Moving the cursor causes sound effects as it hovers across the menus and buttons, so the program runs, but nothing can be seen.

Both those games are known to work with wine at about a half between .29 and .30. I tried it with basic .31 as well as with today's git update. Are those regressions known and is it a work in progress, or should I make a bisecting session to find the problem ?

Regarding the issue affecting Steam games, Stefan Dösinger was aware of it:

This regression is known, and it should be fixed already. It was caused by my patch which made wined3d return an error if an unsupported query is created, like windows does. Wine does not support event queries, but many apps expect them to be supported. I have sent another patch (committed already) that re-enables the fake event queries.

Stefan wasn't aware of the other issue and asked Pavel to do a bisect to find the patch that caused the problem. Pavel did and found it was a patch that contained fixes for fullscreen windows. He also ran a trace using some debug channels which Stefan diagnosed:

This here seems strange. If you compare that to the good log you'll see that IWineD3DDeviceImpl_Init3D was left way too early. As there is no ERR about a possible reason for the abort I think that somewhere an exception is thrown, caught by the game which terminates afterwards.

You can do the following:

  • Run the game in winedbg and see if it catches the execption and gives a backtrace and crash position
  • Add some extra traces (or ERRs) to Init3D and its subfunctions to catch the last line that is executed successfully.

Pavel did a lot more testing and eventually narrowed the issue down to some calls to SetWindowPos() . The consensus seemed to be that the problem didn't actually lie with that function, but with the parameters passed to it or some such event. Thus far it doesn't appear there's a solution other than a hack by Pavel to simply comment out the SetWindowPos() calls.


Screenshots Archive
DirectX

Everyone likes eye candy. Someone named Mirek posted a link to some screenshots of Wine showing off the latest work on Direct3D:

Hi, i would like to say "Thanks for your work!" to all wine developers. In the past months there was really big progress in implementation of Direct3D in wine (that part is most important for me) and other parts such as Dinput, so I would like to introduce you to some more sreenshots from the latest Direct3D applications. I will try to post them on the official wine website.

To run the third benchmark in 3DMark 2005 I used the wined3d_3dmark05.diff.txt patch (from H. Verbeet) To run Call of Duty 2 I used cod2.diff patch (my latest modification of a patch against current CVS)

All screenshots are from today CVS 20.02.2007 without patch "[9/10] WineD3D: Use VBOs for index buffers" which caused some regressions.


Message Spy Viewer Archive
Debugging

Felix Nawothnig announced to everyone he'd developed a little tool to parse Wine's debugging output for spying on messages being passed in a program and display it in a treeview manner:

I just figured I never told anyone (did I?) - a while ago I wrote a Ruby/GTK2 tool to parse +message logs (along with other channels mixed in) and display them in a treeview - makes debugging message related problems much easier. I suppose others wrote similar scripts for their own use - but maybe someone will find it useful nevertheless:

Use like:

    $ WINEDEBUG="+message" wine foo.exe 2>log
    $ ruby spy.rb log


Theming Performance Archive
Controls

Andrew Barr wanted to know about using themes in Wine:

I would like to use the XP ClearLooks theme that is available to make Wine apps blend in with my GNOME desktop. However, it seems that using themes in Wine makes it rather slow. Is this a known problem, is there a workaround of some kind, a registry setting or a patch, or is it best just not to use themes with Wine right now? I am running Wine 0.9.31.

According to a Google search, there seem to be scattered reports of this problem but no diagnosis or solution.

Frank Richter recommended not using them at all:

The comctl32 controls all do theming "natively". The subclassing is done only for controls residing in user32 (the motivation was to avoid copying and pasting all the control implementations from user32 to comctl32, as Microsoft supposedly did).

With regard to speed: themes usually use alpha-blending extensively; however, the speed of Wine's AlphaBlend() can almost be measured in geological terms; so at least part of the performance problem can be found there.

Dmitry Timoshkov referred to WWN #267 for a discussion of theming as it was being implemented.


Winetest Executable Archive
Testing

There's been a problem with automatically generated builds of winetest for the past few months. Paul Vriens announced that it was working again:

as of today there's a new winetest executable available at the usual place:

There is however an issue with the generated reports. It looks like this is introduced when the 'skip' thingy was added to the test infrastructure. I'm currently going through the perl scripts but have no fix yet. Most likely we have to patch the 'dissect' script

He later posted a patch to the script he mentioned. Feri Wagner thought it looked good, but mentioned, Looks good. The already submitted report files could be moved from the data dir back into the queue on the web server as http://cvs.winehq.org/cvsweb/tools/winetest/README tries to explain. (The original directories can be removed afterwards.)


WineConf '07 $$$ Archive
WineConf 2007

There's been active discussion on the wineconf mailing list for WineConf 2007. For those of you not keeping track, it appears there's 3 possible locations on the table: Utrecht, Netherlands; Zurich, Switzerland; and Bratislava, Slovakia. Anyway, something closer to Wine development lies with funding. As a project we've searched for few funds but thankfully always received enough for the things we've needed. Tom Wickline thought it might be time to step up and actively seek some donations. He summarized a discussion that took place on the wineconf mailing list and asked developers what they thought of it:

On February 14th I made a suggestion on the wine-conf mailing list that we should have an annual Fund Raiser to help raise funds for our annual Conference.

Jeremy replied with his thoughts/suggestions and some background info on how the WPF funds have helped in the past.

From this, I cobbled together an extremely rough Donations page.. Keep in mind this is still very much a work in progress and the language within it needs major revisions.

The current discussion is now on whether or not a $1,000 donation is sufficient for a front page listing for one year since our search rank is so high.

Dan suggested that we join adsense, and I replied that I had already suggested this in the past.

At this point there are many undecided questions about the original suggestion of us having a fund raiser, as well as if we should join adsense.

If you have a opinion on this subject we would like (even suggest) that you air it at this time before decisions are made.

Questions:

Should we have a annual fundraiser to help with conference expenses? Thus far the consensus is Yes.

What is a realistic goal? I believe $10,000 is very doable.

What amount should we receive for a front page listing 'gold sponsor'? Is $10,000 to much or too small an amount? If we decide on $10,000 the goal should be revised to about $25,000

Should the Wine project join the adsense network? With our high google page rank we are practically guaranteed to rake in a mint :D

The idea was met with deafening silence. Usually that's a bad thing, but in the Wine community it generally implies a general agreement. No one is afraid to voice their opinion if they disagree, so it seems most people don't mind Tom's suggestion.


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.