Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Wine Traffic #187 For 12 Sep 2003

By Brian Vincent

Table Of Contents


This is the 187th issue of the Wine Weekly News publication. Its main goal is to watch the snow fly. 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

Mailing List Stats For This Week

We looked at 375 posts in 1108K.

There were 73 different contributors. 51 posted more than once. 26 posted last week too.

The top posters of the week were:

1. News: Wine-20030911, TransGaming Update

6 Sep 2003 - 12 Sep 2003 (2 posts) Archive Link: "News"

Topics: News

People: Alexandre JulliardTransgamingNewsTransGaming

Barely in time for this week's news section, Alexandre released Wine-20030911:

WHAT'S NEW with Wine-20030911: (see ChangeLog for details)

This release has more changes than usual. Alexandre has been hard at work committing lots of changes and reorganizing stuff. As noted above, there's been a lot of changes with the configuration tool. If you're interested in Win32 programming and Wine you might want to check it. There's a good opportunity to get involved with Wine development and help build that tool. As always, you can download the latest source and binaries from SourceForge.

Download. Be happy.

Also this week, TransGaming issued August and September's development status and voting report:

TransGaming's Toronto and Ottawa offices were both hit by the massive power outage that affected about 50 million people in portions of the US and Canada. As late afternoon rolled around, our computers abruptly turned off leaving us increasingly wondering "would the bar down the street have power"? Unfortunately cold beer was not to be found as bars were shut, public transport was crippled, and people and cars filled the streets. We hope that those similarly affected managed to enjoy the forced extra long weekend and did not suffer any major disruptions.

Here are August's top-ranked technology poll items:

Check out the link above for complete details. They also announced their beta testing program available to subscribers.

2. Explorer Clone

6 Sep 2003 (1 post) Archive Link: "Wine fun projects - explorer clone update"

Topics: Utilities

People: Steven EdwardsMartin FuchsReactOS

Wine has never had a good replacement for Windows' Explorer. Steven Edwards announced some work by Martin Fuchs:

I doubt this will ever make it in to WINE as Martin has been using C++ to implement our explorer clone but you might want to have a look at it if you want a explorer clone for WINE.

You will want to get the current source from ReactOS CVS. Martin has made a lot of changes to support both WINE and ReactOS and been working on improving WINEs shell32.

The enhancements to shell32 are needed about as much as Explorer. Hopefully they'll find their way into Wine.

3. Glibc Breakage

10 Sep 2003 (12 posts) Archive Link: "Wine repeated unhandled exptions"

Topics: Build Process

People: Shachar ShemeshRein KlazesMarcus MeissnerOve KaavenAlexandre JulliardOve KåvenRein Klaze

Shachar Shemesh ran into a glibc problem, the type that are really hard to diagnose:

I have just performed an upgrade to my Debian Sid Linux. During the upgrade, libc was replaced. I can now not get Wine to work on the new install.

Previously, I would use Wine without --with-nptl. This no longer works. Wine sigsegv on startup (whether there are parameters or not).

compiling with --with-nptl gets me slightly further. Running wine without parameters produces the help printout. However, when I try to actually run something, this does not work. It doesn't matter what I try to run (whether winelib or Windows). I get a series of "unhandled expection". This happens even for the regedit that is supposed to install my default registry via tools/wineinstall

Any ideas? Anyone?

He added, " It appears that some black magic is destroying the content of a variable between calls. " Rein Klazes seemed to run into the same problem and found an item in Debian's glibc-2.3.2-6 changelog that seemed to be a smoking gun. He downgraded and everything worked again. Shachar wanted to know how he was able to fall back on an older copy without trashing the system. Rein sent some instructions:

If they are not still on your system ( /var/cache/apt/archives/ ) you can download them from a local Debian mirror in pool/main/g/glibc.

Then I did

That worked for Shachar, but didn't solve the real problem. Marcus Meissner got a little closer to the issue, " The newest glibc snapshot causes problems somewhere in pthread_cond_wait or similar. "

Ove Kåven discovered the real cause based on what Rein and Marcus reported:

I've just got a bug report on it (#210300) so I've taken a look. So, this pthread_cond_timedwait.dpatch contains:

Compare with Wine's scheduler/pthread.c:

See the problem?

Hmm, now should I complain to Debian's glibc maintainers, or is this Wine's problem?

Notice how new declarations were added right in the middle of the structure? That's not good when you expect them to be in a defined order. Alexandre felt there wasn't much that could be done on the Wine side, " In a sense it's a Wine problem, since this is an internal structure we are not really supposed to be using. However, I don't think there's any way we can fix the problem on our side, so we are going to need a change in glibc (moving the new function to the end of the structure should work)."

Ove put in a bug report against glibc and within hours it was fixed. Alexandre reported, " The glibc guys have been kind enough to make the change, so this is fixed in the current glibc CVS (and I put in the corresponding change on the Wine side)."

4. Optimization Required

10 Sep 2003 (5 posts) Archive Link: "Compilation errors when compiling without optimizations"

Topics: Build Process

People: Shachar ShemeshAlexandre JulliardEric Pouech

Shachar Shemesh ran into a problem compiling Wine:

When trying to compile Wine without optimizations, the compilation fails. I'm trying clean sources, with the "--with-nptl" flag.

The failure (so far, I'm still trying to figure these things out) are when compiling ntdll and the wine executable itself. Both cases, the problem is that same. The linker complains that "InterlockedCompareExchange" cannot be found. Adding kernel32 to the IMPORTS Makefile at dlls/ntdll and miscemu/wine seem to solve these problems, but I'm somewhat worried, and would like to get a second opinion before I submit a patch about this.

Alexandre jokingly pointed out the obvious solution:

Don't do it then <g>

That's a temporary problem because dll separation is not finished. It will be fixed soon, in the meantime just make sure to compile at least ntdll with optimization.

Eric Pouech told Shachar his solution wasn't right and elaborated on the DLL separation problem, " either ensure that the inline version of the Interlocked* are always used, or copy the source (from kernel32) of the non-inlined version of the Interlocked* functions in ntdll. That'll do for the moment."

5. Input Events and DGA Problems

7 Sep 2003 (2 posts) Archive Link: "DGA input events dropped"

Topics: Graphics

People: Thomas MooreOve KaavenOve KåvenLionel Ulmer

There have been problems with Wine using the XFree86 DGA extension. DGA (really DGA2), the Direct Graphics Architecture, is a 2D graphics API that allows the CPU direct access to the framebuffer memory. This topic came up over a year and half ago, but I didn't cover it then. Lionel Ulmer originally diagnosed problems with DGA2 and event handling. Thomas Moore went through a similar process and mailed in a patch:

For a very long time now, enabling DGA causes mouse/keyboard events to be ignored. There have been a few threads on this issue in the past, and it seems nobody is willing to actually fix this problem (even though some have submitted patches to fix it, nothing has ever made it into CVS). Why is this? Overall, the problem seems to be related to the use of separate per-thread X display handles, along with a global (separate) "GDI" display. At first I tried just making the first thread's display the "global" display, but since that didn't work, and I don't have the patience to figure out why this dichotomy exists, here's a simple patch which at least works for a few games I tried (but still has mouse problems with a few other games I've tried - there was a mouse fix on an earlier thread(1) on this subject, but it doesn't work -- perhaps it has something to do with the fact that DGA only returns relative mouse movement, and non-DGA returns absolute movement). On the other hand, you could just at least make your default behavior and sample config not enable DGA.

Ove Kåven explained why it was wrong and what the correct solution should do (and why it's a lot harder):

all those patches are based on having gdi_display receive events. It should not. Consequently, DGA should be initialized using a per-thread display so that events arrive on a per-thread display. Originally I had thought that the DGA driver could create a separate thread and use its thread display, but it may not be strictly necessary, given that DirectDraw needs a cooperative window, and windows are per-thread objects, so the thread that owns the cooperative window could also own the DGA display. If we also assume that this thread calls SetMode, it's probably okay to just use the current thread_display() instead of gdi_display. But I suppose it's probably still safer to let DGA create its own thread, though somewhat more involved (you may have to use XSendEvent or some kind of wineserver stuff to forward keyboard and mouse events to the thread that owns the cooperative window). Besides, a separate thread would allow the DGA code to handle its own events, instead of scattering DGA special cases around the rest of the x11drv event-handling code.

6. Locating Font Paths

7 Sep 2003 (2 posts) Archive Link: "Using fontconfig"

Topics: Configuration

People: Mike HearnHuw Davies

Mike Hearn has been putting a lot of work into Wine's configuration lately - namely the work on winecfg. He asked a question along those lines:

It'd be nice to use fontconfig in future to locate font installation paths. There is a simple API:

which should let us use a small part of it, even if we don't use all of it. It means we don't need to make the user manually configure font paths.

Does anybody know how hard this would be?

Huw Davies, Wine's font guru, has already done the work, " I've done this for CrossOver 2.1 and hopefully we'll merge it into winehq soon. Rather than a directory by directory approach, I'm walking the entire font list and using any TrueType fonts that I come across."

7. OpenSSL Support

9 Sep 2003 - 10 Sep 2003 (6 posts) Archive Link: "adding structures to headers"

Topics: Fixes

People: Geoff Thorpe

Geoff Thorpe stubbed out some functions that let him install and use OpenSSL:

I don't have or use any windows installation or compilers, but as a wine user and openssl developer I was curious anyway about how well win32 versions of openssl programs and libraries would function under wine. It turns out that the PRNG polling touches on some system monitoring functions for additional sources of entropy, and these were generating some exceptions.

So this just adds two stub functions that cause openssl to work (the error values returned from these two stub functions prevent the oodles of other functions from being used). This should help not only openssl programs (and scripts that use them), but also any win32 programs that depend on openssl DLLs.

PS: the types added with NetStatisticsGet are not used, but will be needed if the stub is later implemented. The structure definitions in both patches were taken from msdn's online API reference - so don't commit if this is a violation of any legal fineprint.

PS2: I could have added stubs for the other Heap32<foo> functions too, but after doing the first one (and learning a little about the ntdll/kernel build) everything worked. Should I send stubs for the rest too?

Geoff had a question about adding headers that Dimi fielded. Then he included a little more detail on exactly what his patch fixed:

Now, can you tell me if the code seems ok to you? :-) It's my first submission to wine-patches and I note that it hasn't as yet elicited any response, either as a rejection or a commit. FWIW: I was using the prebuilt openssl installer for version 0.9.7b from:

This installer appears to run well under wine. My changes were sufficient to get "wine /path/to/openssl/bin/openssl.exe -- speed rsa1024" working, and although the timing mechanisms for benchmarking don't appear to work properly (another problem for another time), it is nonetheless doing crypto operations satisfactorily. As these routines include assembly optimisations and there being a somewhat clunky win32 compilation system behind it (long story), this was a useful test from my point of view.

But anyway, the point was to get the libs and crypto executing, and I suspect those two stub functions would be enough now for any applications using openssl libraries under wine.

8. Alpha/SGI Development for Wine and ReactOS

11 Sep 2003 (1 post) Archive Link: "ReactOS and WINE development on AlphaAXP and others"

Topics: Ports

People: Steven EdwardsReactOS

Steven Edwards extended a generous offer for developers interested in porting Wine:

HP has recently extended the loan I requested on this alpha pws500 workstation for another year. If anyone is interested in working on porting WINE or ReactOS to the alpha email me privatly and I can setup a account for you on the system.

I have another system a friend has let me borrow for at least a few months if anyone is interested in doing some porting work on it. Its a SGI Indigo 2 IMPACT 10000. I still need to load linux on it and get it up on the network though it will be a few weeks before anyone can use it if they are interested in starting a MIPS port







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.