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 #239 For 10 Sep 2004

By Brian Vincent

Table Of Contents


This is the 239th issue of the Wine Weekly News publication. Its main goal is to play poker. 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 238 posts in 910K.

There were 76 different contributors. 40 posted more than once. 35 posted last week too.

The top posters of the week were:

1. Intro Developers Guide

4 Sep 2004 - 7 Sep 2004 (14 posts) Archive Link: "Wine Developer Cheatsheet, v1"

Topics: Documentation

People: Mike HearnMicrosoft

We had a discussion at Wineconf last winter about what barriers prevent people from helping out with Wine. One of the problems is that it takes some time to come up to speed with how Wine tries to recreate a Windows environment. When things go wrong it's difficult to figure out what happened. Mike Hearn wrote up something this week:

Back in February at WineConf one of the issues (I) raised was that there's a lot of stuff you just have to know in order to hack Wine, and that raises the barrier to entry.

So, I wrote this. If anybody has stuff they think should be added, let me know. If the community likes it, I'll submit it as a patch against the website

I'll reproduce it here just to give everyone a preview:

5 minute intro to Wine development

This is a quick collection of tips and tricks that may be useful for Wine hackers. It's loosely modelled after the hackers guide though I'm afraid this document doesn't feature a comedy build system :)

A great reference is the Wine Developer Guide, which goes into far more depth than this document will, especially about the architecture of Wine and information on the individual components. However, if you want a 5 minute getting started guide, this is it.

Debug logging

The most powerful tool you have to find out why an app breaks on Wine is the logging system. Using it is simple enough, each part of the code (apart from the server) logs to a "debug channel" and each channel has four classes: trace, warn, err and fixme. By default ERR and FIXME messages are displayed, whilst TRACE and WARN are not. To enable them:

There are some channels which are particularly useful:

Basic debugging tips

Implementing Win32

Using the debugger

Winedbg has several useful abilities. The most important are being able to get a backtrace of threads with Win32 and builtin debugging info: usually Windows binaries are stripped so this won't be helpful but it can prove handy when using native DLLs. To get a backtrace use the bt command, to get a backtrace of a particular thread postfix it with the thread id in hex, eg bt 0x9. You can also specify "all" instead of a thread id.

It supports a subset of the gdb commands. The most common ones are all there, for instance you can use info proc and info thread, and then attach to a given process. This is useful for getting a backtrace of deadlocks.

It can also disassemble code. Disassembly isn't something you should be too enthusiastic to use, it often reveals no useful information. However, at times it is the only way to move an investigation forward - for instance, to find out why a program is crashing. Use the disas command to disassemble a piece of code. When working backwards from a particular address try and choose aligned addresses, otherwise you risk starting the disassembly from the middle of an instruction which will produce garbage. If you aren't already familiar with x86 assembly, try using the disassembly feature in gdb on ELF binaries you've compiled yourself so you can get used to what it looks like. The Intel instruction set is vast but very few instructions are used frequently. If you know what to expect, you won't be tripped up by bad disassemblies or anti-disassembly tricks which can corrupt the output.

Firstly, if you do decide to disassemble a program, be aware of what you're doing. Obviously you can't take any code you find there and use it in your own programs. Don't try submitting decompiled code as part of patches, it's been tried before and we know what it looks like. Alexandre will reject any patches that look like they were decompiled or produced from disassembly.

Secondly, understand what you're seeing. Here are some tips:

Common problems

Some bugs are easier to fix than others. Here is a quick list of the more persistant ones so you know what you're getting into:

Various people had comments, but everyone really seemed to like it. Diego Pettenò mentioned he wondered what kind of coding standards were required. In particular, he had submitted a patch a while ago and it was rejected based on the style he used. Mike took a quick look and commented:

A few things that jump out at me (not really reviewed the code itself):

The rest looks fine, I expect it was just the C portability stuff that tripped you up. Please do try again!

2. Transport Layer Security: SSL vs. GnuTLS

2 Sep 2004 - 6 Sep 2004 (12 posts) Archive Link: "Possible fun project/todo list item?"

Topics: Integration

People: Mike HearnSteven Edwards

We sort of discussed this topic back in July (WWN issue #230), but Mike Hearn brought it up again. It seems OpenSSL using OpenSSL in Wine's crypto code leaves something to be desired. If you follow the link above, Steven Edwards raises some points about licensing. This week Mike Hearn brought up some technical problems and thought it might be something to add to the Fun Projects list:

The OpenSSL library we use in wininet/netconnection.c is a very unstable library, with somewhat odd licensing as well. By unstable I'm talking about the interfaces it exports: unfortunately they break backwards compatibility very frequently with the result that a build of Wine compiled on one system may bail out when using SSL on another, as the soname/abi of OpenSSL it's looking for has changed *yet again*.

This also means that some distros deliberately ship older versions and just backport security fixes, as upgrading OpenSSL to newer versions is quite painful. Fedora at least does this.

If anybody is looking for work to do then, addressing this problem may be useful. Probably the best way forward is to talk to the GnuTLS people ( and see if you can get written confirmation from them that they have a strong commitment to binary compatibility (at least, more than OpenSSL does). It also seems to be a fairly stable project: the new maintainer is more focussed on portability enhancements and a slow release cycle than making huge changes to the code.

If so, it might be worth porting wininet over to GnuTLS, or alternatively, rather than remove the OpenSSL code just add code to use GnuTLS and then fall back to OpenSSL if it cannot be found (or vice-versa).

One interesting thing about GnuTLS is that it has some OpenSSL compatibility code, but from a look at their website it seems that this is GPLd. Maybe we could get an exemption from them.

The downside is that while OpenSSL is frequently going to not be found as it's the wrong version, GnuTLS is also not widely installed by default so it might not get us much in the short term.

The good news is that Gaim packages are often built against it, so in any modern distro that packages Gaim (which is a very popular chat client) in its repositories, there's a good chance GnuTLS is packaged as well.

Steven suggested a different library, " A better solution is to use the Mozilla Network Security Services (NSS). NSS is everywhere mozilla is and is much more mature."

Mike disagreed:

Yes, that's another approach. Gaim did this though and then implemented support for GnuTLS as well, because having a chat program depend on a web browser was a bit odd and people were prone to go "Ooh look, a new Mozilla is out! rpm -e mozilla, tar xzvf mozilla-1.7.tar.gz" and such, and then their IM client mysteriously no longer connects to MSN.

I think it's better to depend on an actual library, as opposed to a component of another application. Maybe if Mozilla split it out into a separate project with separate releases, packaging etc, it might be better. Maybe they already have ...

A couple people corrected Mike by mentioning NSS was already available as a separate package. Vincent Béron pointed out that even so it would be necessary to have the development headers installed in order to compile with it.

3. FreeBSD Breakage - IPX Packets

9 Sep 2004 (3 posts) Archive Link: "dlls/winsock/socket breakage"

Topics: Ports

People: Gerald PfeiferRoderick Colenbrander

Roderick Colenbrander posted a large patch that changed the behavior of IPX networking. It seemed to be fine for Linux, but Gerald Pfeifer reported a problem with FreeBSD:

The following change

breaks FreeBSD 4.10 quite a bit:

Concerning the error in socket.c, line 1120, SOL_IPX is not defined on FreeBSD 4.10, but there is a constant SOL_SOCKET which is supposed to be passed as the second parameter of getsockopt with the following description: "To manipulate options at the socket level, level is specified as SOL_SOCKET". Would that do the job?

Concerning the error in socket.c, line 1123, struct sockaddr_ipx looks as follows on FreeBSD 4.10:

Finally, I could not find anything remotely similiar to IPX_TYPE.

I hope this will allow you to fix this breakage? (To check for FreeBSD, you can use #ifdef __FreeBSD_...)

Roderick wasn't sure what the solution was, " The problem is like this. In case of the ipx protocol you can select different ipx types of ipx packets. On linux there's an entry in the sockaddr_ipx struct in which you can change and further you can change it at the ipx socket level using that SOL_IPX stuff. I wasn't aware that this stuff doesn't exist on freebsd. Unfortunately I don't have any freebsd experience, so I don't know about the way to do it on your OS. I will try to find a solution, if none can be found I'm affraight we need some #ifdef stuff."

He took a closer look and reported:

I made some more progress with the fix but I'm not fully sure how it works. I checked the freebsd source code to figure out how it works. Compared to the linux source the code was very complicated as in linux there's a special ipx setsockopt option and so on. We have to pass SO_DEFAULT_HEADERS to setsockopt with as option SOPT_GET/SOPT_SET when we want go get/set the packet type. The structure to use is "struct ipx".

Perhaps you can try to build a fix as I don't have access to any FreeBSD box and can't test the patch. Note that in the function ws2_send we don't need to retrieve the ipx packet type as that won't be needed for freebsd as the linux/freebsd ipx sockaddr structure is different.

This issue was published before a solution was found.

4. Fix for Broken Delphi Menus

7 Sep 2004 - 8 Sep 2004 (10 posts) Archive Link: "Revised menu patch"

Topics: Fixes

People: Michael KaufmanDmitry TimoshkovUwe BonnesMike HearnAlexandre JulliardUlrich Czekalla

Michael Kaufman posted a patch to fix some menuing problems in Delphi applications:

My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior. We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out.

I've also added more bugfixes to the patch: Now WINE supports the (very rare) case where a menu is assigned to multiple windows. To test this, I'll attach a program which displays two windows using the same menu. The windows are from different window classes in order to test if WINE sends the ownerdraw messages to the correct window.

Dmitry Timoshkov disagreed with disabling a test case:

That's a very bad idea, then you need to comment out half of the test cases in Wine. The tests show *the real* behaviour, it doesn't really matter whether it's documented or not, it's known that MSDN has lots of misleading and missing information.

it has a good chance that the bug will be never fixed at all. A commented out test does not differ from a not existent one, and has zero chance to be revived.

First I'd suggest to add another test to the set of existing menu tests. Next, a fake fix is not going to help as all previous attempts didn't, especially when a proper way to fix the problem is known.

Michael thought adding the patch was justified:

How do you define the "real behavior" ? The behavior of Windows XP? Have you checked that Windows 2003 still passes this test? You can't be sure. There's no real behavior in this case.

I promise that I'll remember you to reactivate this testcase. If we don't modify DestroyMenu NOW, there's also a good chance that this bug will never be fixed. Remember, a lot of Delphi applications don't work because of this bug which is simple to fix and breaks only one single testcase. Is is really more important that WINE passes this test but fails on Delphi apps again and again? What will the users of WINE think?

To fix it properly, we have to move the menu code to WineServer. When will this happen? In a year? In two years? Never? Until then, many Delphi apps won't work. For me, this is not acceptable.


Uwe Bonnes suggested adding another test for the behavior Michael was fixing:

can we perhaps create a test case, that mimics the Delphi behaviour and succeeds on WinXX but fails on Wine? Then the behaviour is well documented and there is less reason to not fix it while breaking another test.

There are other things that seem (on the first glance) " not acceptable" to me, when problems I try to pinpoint are not solved. But hey, we are an open project, and as long as nobody pays for the Delphi fix, nobody has a "right" on a fix. We have to work together to get it right...

With regard to that last point, Mike Hearn then explained a little about Alexandre's process of accepting a patch:

When this sort of thing happens, it boils down to a judgement call on the part of Alexandre. He has to decide:

Now sometimes Alexandre does allow in incorrect fixes because the cost is low and the benefit is high, or because he knows a correct fix is a long time away (maybe never). Most of our DCOM code falls into this category :)

In this case, he has to decide:

This is all part of figuring out the cost and the benefit. In this case, I have no idea what he will think. Alexandre does tend to be conservative - ie dropping patches he isn't sure about rather than accept them and hoping for the best.

Wine has been around for a very long time, and correctness is very important simply because if you don't consider it, nearly every fix you make will break something else and you end up going round and round in mad circles constantly moving but never getting nearer to the goal of 100% compatibility.

Even given a large and growing test suite, huge numbers of testers, a conservative maintainer and so on, Wine still suffers a high rate of regressions.

Now, I don't know anything about the menu code, so I'm not going to comment on whether the patch should go in or not. I think given how popular Delphi is for writing apps the cost of not including it is quite high but if the fix is clearly going to cause problems then we have no choice but to wait for Ulrichs menu->wineserver patch.

So hopefully you understand better the factors that go into these decisions. I know what you must be thinking, I've been there before with things like the system tray patch which is still not committed because it extends incorrect code rather than rewrites it but eventually you realise that in the long term it's for the best.

Mike alluded to some work that Ulrich Czekalla has done that changes how menus are handled. Alexandre felt that work was the proper direction and it was the only way to handle the sitation, " There have been a number of similar hacks done in the menu code already, but they all had to be removed because they broke too many things; I have no reason to believe your proposed fix will be any different. The issue is a fundamental problem with the way menus are implemented, and it can't simply be hacked around, it has to be fixed right."

Michael then happened to stumble upon a much simpler fix:

The fix is as simple as updating the menu bar's hWnd member every time the user clicks on a menu bar. This is even necessary if the menu is displayed in multiple windows, so it's not a "Delphi-only" fix.

My patch is here:

It's a one-liner, but thus far Alexandre hasn't committed it.







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.