Wine Traffic #300 For 2�Dec�2005

By Brian Vincent

Table Of Contents

Introduction

This is the 300th issue of the Wine Weekly News publication. Its main goal is to enjoy 100 inches (250cm) of snow. 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 (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 208 posts in 442K.

There were 85 different contributors. 41 posted more than once. 53 posted last week too.

The top posters of the week were:

1. News: Nothing To See Here.. Move Along

(1 post) Archive Link: "News"

Topics: News

People: WineHQ,�Zack Brown,�News

Wow.. the 300th edition of the Wine Weekly News (aka Wine Traffic.) I really need to get a life, huh? Originally I was planning on putting together a little look back at threads we've covered, but I did that a few weeks ago and published it as WWN #296 (http://www.winehq.com/?issue=296#Beta:%20How%20We%20Got%20Here) to celebrate the beta release. If you didn't see it, check it out for a look back at WWN and Wine.

This is probably a good time to remind everyone you can find this publication in two different places. The content is exactly the same, so you won't see anything in one that isn't in the other. The first location is Zack Brown's Kernel Traffic site under the moniker Wine Traffic (http://www.kerneltraffic.org/wine/latest.html) . You can also find it right on WineHQ as the Wine Weekly News (http://www.winehq.com/?issue=back) . If you read one site and not the other, I'd encourage you to try out the other. Of the two, I can guarantee WineHQ gets updated faster than Wine Traffic since I can publish it there directly.

2. wine.git

�Archive Link: "Git"

Topics: Project Management

People: Alexandre Julliard,�WineHQ,�Mike McCormack,�cvs

posts="1" >

One topic that hasn't appeared on the mailing lists is git. A git repository for Wine and has been set up and some developers have switched over to using it. Is this the direction Wine's source code management will take? Well, it seems quickly on its way to becoming a preferred way to working with Wine. As long as the Git to CVS gateway is working then CVS will remain an option. Therefore, it's probably too early to say where things are headed, but it does seem to be working for everyone's every day use. Alexandre seems to have switched over to it and the commit messages appearing on wine-cvs (http://www.winehq.com/pipermail/wine-cvs/) have changed in format to reflect the git commits.

In lieu of having a real thread to cover, I'll refer you to Mike McCormack's GitWine (http://wiki.winehq.org/GitWine) page on the wiki. He has instructions for getting git up and running.

Interestingly, in a thread this week Alexandre mentioned we now have an even older history of Wine than what's in CVS, " the new git repository on WineHQ contains all the releases I have, going back to 1993. You can browse it at http://source.winehq.org/git, or see the GitWine page on the wiki for instructions on how to download it."

3. Direct3D & WGL

�Archive Link: http://www.winehq.com/pipermail/wine-devel/2005-October/.html

Topics:

People: Aric Cyr,�Oliver Stieber,�Nick Burns

Aric Cyr wrote in to bring up an idea he had asked about a while ago:

A while back I had started to work on, and mostly completed, converting wined3d to using WGL instead of directly accessing glX functions. That was a few months ago, and it was a pretty big change, but not too difficult as WGL and GLX are very similar.

However, my patch is now greatly out of date thanks to the excellent work progressing in wined3d. I was just interested in getting some feedback on whether anyone thinks this is something worth me continuing to pursue, or just drop it?

As I see it, there are a few merits to having wined3d on wgl instead of glx. The biggest one being that all the glX code won't be duplicated in multiple places as it is now (dlls/opengl32 and dlls/wined3d). Along with that comes maintainability and consistency as all glX code would only exist in one place and would be shared by all, applications and wined3d alike. Work-arounds for the various glX revisions (recently discussed glx 1.2, 1.3, etc) would also be localized to a single dll.

Of course, on the down side, we take a hit of one extra layer of indirection by going through WGL. However as WGL/glX functions are rarely called, this should be a minimal of a performance hit.

All in all I think it would be worth while, but I'd still like to hear from others so as not to waste (a lot!) of my time.

Oliver Stieber wrote back:

If wines WGL implementation is fully implemented then it may be a good idea switching to wgl, a wgl implemenatation would also make debugging much easier because wined3d can be run under windows to isolate problems.

Nick Burns also started work on a wgl version of wined3d that I haven't got around to fully merging yet, I can send you the patch.

Aric replied, " Wine's WGL is well implemented, and probably more correct than what is in wined3d currently (well, last time I checked anyways)."

There seemed to be a general consensus among other developers that switching over to using WGL would be a good thing.

4. Linking libGL.so

(15 posts) Archive Link: "opengl support in wine"

Topics: Integration

People: Tomas Carnecky,�,�Mike Hearn,�Mike McCormack,�CodeWeavers

Tomas Carnecky asked for Wine's OpenGL library usage to be changed:

I've had a discussion with someone through this list about wine and libGL.so. It was about wine using dlopen("libGL.so") instead of linking directly with libGL.so.

I still don't understand why the wine developers have made this decision. I'm again at the point where I need to hook OpenGL (glX) functions ahd I have to patch wine again to make it work. There is absolutely no reason not to link with libGL.so directly: Even if you make OpenGL a hard dependency, nothing will break. Just announce it well so that everybody understands the change and make --disable-opengl the default option. Now everyone can get wine and it will work out-of-the-box and those who want opengl can enable it (and the distribution packagers should make sure wine depends on opengl when building the package).

After a little discussion, Tomas described what he was trying to do and what he was trying to avoid:

I want to create fraps for linux. Using XShmGetImage() and friends is too slow. So my first approach was to create a fullscreen opengl app and do glReadPixels(). But this performs very badly when there are two opengl applications running at the same time (fps drops from >100 down to ~10). So my last approach was to call glReadPixels() from the same opengl context (the same opengl application). This is why I need to hook glXSwapBuffers(). Of course I could write a whole libGL.so with all the required functions, rename the real libGL.so to libRealGL.so, dlopen libRealGL.so from my libGL.so and propagate the function calls to the real opengl implementation, then wine would dlopen libGL.so (my library) and I could make whatever I need in glXSwapBuffers(). But this is overkill!

Now what are my options besides modifying the wine source?

Mike Hearn gave a quick answer to the original question, " IIRC this was done so CodeWeavers can ship a GL enabled build. I don't see any reason to change it. Weak linking is usually a good thing. "

Mike McCormack explained the detail behind that:

ddraw.dll uses dlopen on libGL, because there's code in ddraw that can work without libGL being present, and that is needed for some programs (eg. IE6) to run. dlopen'ing means Wine compiled on a machine with libGL can be run on a machine without libGL.

opengl32.dll is directly linked with libGL, since it's not useful without it.

If you're implementing your own shared library, you can probably try dlopen'ing the functions you need from that first, then falling back to dlopening from libGL.

Tomas had a suggestion:

At least you could do:

but later:

eg. use RTLD_NEXT instead of the real libGL handle. This would make it possible to preload my own library but wouldn't change the weak linking. In fact, that's how I've modified my local wine copy, and it worked.

Mike McCormack and Stefan D�singer both suggested he submit a patch for that behavior.

5. Debugging Critical Section Lockups

(4 posts) Archive Link: "Debugging Critical Section lockups"

Topics: Debugging

People: David Hagood,�Robert Shearman,�Rob Shearman

David Hagood ran into a tough problem with an app locking up:

I may have a repeatable case of an error in locking critical sections, so I'd like some pointers as to how to debug this.

The case occurs with the installer for Delorme Street Atlas 5 - on my 2GHz Athlon desktop it runs without a hitch, but on my oooooold slow laptop (how old is it? It's sooooo old, it used PIO for the disk!) the program locks up 100% of the time at startup, with 2 threads trying to take different critical section locks and dying. It looks like the standard deadlock condition: one thread tries to lock A-B-C, the other tries to lock A-C-B, and so they deadlock.

Are there any tricks to identifying who locked what where and in what order?

Rob Shearman had a quick tip for identifying what might be going on, " Unless the installer is using TryEnterCriticalSection, I would expect CPU utilisation to be 0% when deadlocking. Relay logs generally give the best clues in this kind of situation."

David hypothesized:

Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I think) is more along the lines of this:

On fast CPU:

  1. Thread 1 locks resource A, does something, locks B, unlocks B, unlocks A.
  2. Thread 2 locks B, does something, locks A, does something, unlocks C, A.

On slow machine:

  1. Thread 1 locks resource A, does something.
  2. Context switch.
  3. Thread 2 locks B, does something.
  4. Context switch
  5. Thread 1 tries to lock B and blocks.
  6. Context switch.
  7. Thread 2 tries to lock A and blocks.
  8. Deadlock.

In other words, on the fast CPU the deadlock does not happen because thread 1 gets everything done before thread 2 starts. On the slow machine, thread 2 starts while thread 1 is still doing stuff.

Rob outlined the options available, none of which are particularly easy or appealing:

Yep, example of what not to do in concurrent programming. You should make a note of the order in which locks are taken and always take the locks in that order and always release them in the opposite order.

You have several options from here:

  1. File a bug report with the maker of the application.
  2. Find a function that B uses just before it locks that A doesn't use and add a Sleep call. Obviously this kind of fix won't be accepted into Wine.
  3. Do tests to try to find a function that A uses that is much slower on Wine and try to fix it.

6. Installing the Mozilla ActiveX Control

(5 posts) Archive Link: "Does the Windows version of Mozilla need to be installed to use the Mozilla ActiveX plugin?"

Topics: Web/HTML

People: David Hagood,�Aric Cyr,�Jacek Caban

The Mozilla ActiveX control is currently used when an application requires a WebBrowser control to embed OLE documnents, namely HTML, within an application. Ongoing work by Jacek Caban to implement MSHTML.DLL and SHDOCVW.DLL will hopefully obviate the need for it, but that work isn't complete enough yet (although Jacek sent about a bizillion patches last week.) That led David Hagood to ask this week:

Does the Windows version of Mozilla need to be in place for the Mozilla Active X control to work, or is there a way to point the control at my Linux install of Mozilla?

Aric Cyr replied:

Yup, you'll need to install a win32 version of mozilla. There is a decent little Mozilla ActiveX HOWTO at:

(Installing Active X for the new Patchsystem)

Jacek pointed out that was actually incorrect and it was easier, " Mozilla ActiveX Control doesn't need any version of Mozilla. It just uses Gecko (Mozilla's engine), which is provided with it, so you don't have to install anything else."

7. MSVCRT Clashes With LibC

(3 posts) Archive Link: "Latest CVS download opensolaris, AMD 64, build errors"

Topics: Ports

People: David Clack,�Mike McCormack,�Robert Lunnon,�Microsoft

David Clack asked a question this week about a compile problem in MSVCRT, Microsoft's Visual C runtime which is comparable to glibc or libc on other systems:

I'm on OpenSolaris B27, on an AMD 64 system, I'm getting these errors from the build.

I've tried to google a solution for a week but no luck.

Any suggestion to fix would be appreciated.

This problem actually comes up from time to time. Mike McCormack explained the standard workaround:

There's probably an _environ defined in msvcrt and your libc. Have a look through the msvcrt code for the _environ symbol, and try change it to something like MSVCRT_environ. We do that for other symbols in msvcrt that conflict with glibc, so you should be able to find an example to copy.

Bob Lunnon gave a pointer to his Wine-on-Solaris web site:

Did you apply the patches from http://www.blastwave.org/wine (http://www.blastwave.org/wine) ?

8. Installing the Mozilla ActiveX Control

(5 posts) Archive Link: "Does the Windows version of Mozilla need to be installed to use the Mozilla ActiveX plugin?"

Topics: Web/HTML

People: David Hagood,�Aric Cyr,�Jacek Caban

The Mozilla ActiveX control is currently used when an application requires a WebBrowser control to embed OLE documnents, namely HTML, within an application. Ongoing work by Jacek Caban to implement MSHTML.DLL and SHDOCVW.DLL will hopefully obviate the need for it, but that work isn't complete enough yet (although Jacek sent about a bizillion patches last week.) That led David Hagood to ask this week:

Does the Windows version of Mozilla need to be in place for the Mozilla Active X control to work, or is there a way to point the control at my Linux install of Mozilla?

Aric Cyr replied:

Yup, you'll need to install a win32 version of mozilla. There is a decent little Mozilla ActiveX HOWTO at:

(Installing Active X for the new Patchsystem)

Jacek pointed out that was actually incorrect and it was easier, " Mozilla ActiveX Control doesn't need any version of Mozilla. It just uses Gecko (Mozilla's engine), which is provided with it, so you don't have to install anything else."

9. Quake 2 Evolved & Winelib

�Archive Link: "A working winelib application"

Topics: Winelib

People: Toan Nguyen

posts="1" >

It's been a while since we've seen someone mention using Winelib (maybe because there's hardly any documentation?), but this week Toan Nguyen wrote in to mention a working application:

This is to let you know that I'm porting Quake 2 Evolved (Q2E) program to Linux using winelib. It compiles and works beautifully, at least on my PentiumM laptop (I actually link with native linux libjpeg, zlib, openal and dl at the compile time, winelib is used for opengl, winmm and wsock32). The author has allowed my linux commit to the CVS. More information on Q2E can be found at www.quake2evolved.com. The specific discussions about linux Q2E can be found here:

There are two small problems left that I hope the wine developer can test and help. Browsing the save or load games menu is quite sluggish. I don't know why. Also, I don't have an AMD64 system to test this on. If someone here would like to help out, I'm grateful.

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.