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.

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.

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

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?

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.

At least you could do:

glHandle = dlopen("libGL.so", ...)

but later:

glXSwapBuffers_Ptr = dlsym(RTLD_NEXT, "glXSwapBuffers");

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.

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?

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.

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.

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?

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

http://gentoo-wiki.com/HOWTO_Install_and_update_World_Of_Warcraft_with_wine

(Installing Active X for the new Patchsystem)

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.

(ed. note: output shortened)
ld: fatal: symbol `_environ' is multiply-defined: (file /usr/lib/crt1.o type=OBJT; file data.o type=OBJT);
ld: fatal: File processing errors. No output written to msvcrt.dll.so

Any suggestion to fix would be appreciated.

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.

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

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?

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

http://gentoo-wiki.com/HOWTO_Install_and_update_World_Of_Warcraft_with_wine

(Installing Active X for the new Patchsystem)

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:

• http://www.quake2evolved.com/blurforum/showthread.php?s=4d42894a75fed08e372d74cff9a849cf&threadid=2038
• http://www.quake2evolved.com/blurforum/showthread.php?s=4d42894a75fed08e372d74cff9a849cf&threadid=2043

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.