Wine Traffic Brian Vincent

This is the 288th issue of the Wine Weekly News publication. Its main goal is to sleep in the car. 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
Memory Management

Stefan Dösinger wrote to the list late last week with an odd problem:

I am trying(once again) to get Empire Earth running with wine. After solving a few problems, I've run into a strange access violation crash. It looks like a buffer overrun, followed by a return to an invalid adress.

The crash messages look a little bit different every time, with illegal instructions / access violations or even a Segmentation Fault without starting winedbg at various addreses(Attached file crashes). On very rare occasions, this crash doesn't occur, and the game continues to load and crashes later in some ddraw function. Instead of crashing it complains about a corrupted heap:

    err:heap:HEAP_ValidateInUseArena Heap 0x7fd80000: prev arena 0x7fe01640 is not prev for in-use 0x7fe01cb0

I've looked at a +heap trace, but I couldn't find anything usefull. (See ee-nocrash for a log). I've also attached a normal log without any special debug flags set(ee-normal.log.gz). I've added a few ERR statements for testing in some functions.

So my questions are:

  • Am I right with my suspection that the problems are caused by a incorrect return?
  • How can I get a disassembly of Low-Level Engine.?Deactivate_at_GERasterizer@@UAEJXZ or simmilar functions. I didn't find this symbol.

James Liggett recognized the problem, I've also seen similar problems with related heap functions in WinMM. I'm told that there's something wrong with the heap manager library Wine uses.

Stefan did more detective work and found what seemed to be the source of the problem:

I was lucky with setting a breakpoint in the wine code. The crash happens in the DDraw implementation. The return from Main_DirectDraw_Release(ddraw_main.c:154) leads to a random adress. The call which leads to this is "HeapFree(GetProcessHeap(), 0, This);" in Main_DirectDrawSurface_Destroy, surface_main.c:154. If I comment out this call, Empire Earth continues loading and crashes more or less randomly at some later points.

I've edited the IDirectDrawSurfaceImpl structure and added a 2048 byte block at the beginning and the end. This makes the crashes reliable: With the HeapFree call, the ret jumps to NULL, and without the call Empire Earth crashes little later.

This looks like a really nasty heap corruption to me, and I'm afraid it's beyond my knowledge. Can anyone of the ddraw/d3d people help me?

Lionel Ulmer suggested some debug channels to look at, I think best would a +ddraw,+heap,+relay,+tid,+seh trace to be able to see where the corruption may occur. And it's not because it crashes into DDraw code that it's DDraw responsible for it :-)

Stefan then had an interesting insight, BTW, Empire Earth crashes in exactly the same way in Cedega, where I expect the DirectX implementation to be quite different.

James thought this bug could be hidden deeply in the heap code, such as a buffer overrun. If so, it's likely been there for a long time if Cedega also suffers from it - they branched from Wine over three years ago. More work showed a way to reproduce a problem, though perhaps not the same problem:

This is interesting: Setting the +heap trace flag sets the bad address realiably to 0xaaaaaaaa (without my changes to DDraw). Does this say anything?

Andreas Mohr grepped through the code and pointed out a potentional culprit:

dlls/ntdll/heap.c:#define ARENA_FREE_FILLER 0xaa

I'd guess this is an address in an area that's actually gotten freed.

James thought it was more likely to be an uninitialized value. Stefan poked around more and discovered something that pointed to it being contained within DirectDraw. Lionel Ulmer asked for a +ddraw trace since he thought it could be a reference counting issue. Thus far there's no solution.

Fixes Eric Pouech

Kevin DeKorte reported a problem with Lotus Notes that appeared to be a regression:

Using Wine 20050725 and Lotus Notes 6.51 when I move my mouse to the database tabs or over the replication window the mouse disappears while I move over the tab or replicated databases and then reappears when I leave the list. The databases are highlighted, but having the mouse completely disappear is a little annoying. I don't remember it doing this with 20041202.

I checked this on my XP machine and on that machine the cursor changes from an arrow to a hand pointer. So maybe the cursor just did not load correctly. So can a patch be done that if the cursor being selected is bogus that it stays the arrow pointer.

Apparently it's a known regression filed in Bugzilla under bug #3165 Someone then reported the patch listed with that bug fixed the problem. That touches on something Eric Pouech mentioned at WineConf. Bugzilla contains some bugs with known fixes that haven't made their way into Wine. Kevin wondered about it though, Well the patch does improve the cursor. I can now see it. Although it is only grey. It there any reason why the best cursor selection method always checks for bits == 1. What about color cursors?

Duane Clark also reported success, I don't really understand how the patch fixed things, but... Riven uses a bunch of color cursors (hands pointing various directions). Without the patch, only the standard pointer cursor was generated. This cursor appeared and disappeared normally (the cursor is supposed to disappear while some Quicktime clips are playing, and then reappear). With the patch, the color cursors reappeared and all are correct.

Mike McCormack explained a little behind the patch:

It should improve things over the original code that was there in cursoricon.c revision 1.9. That code first checked if there was only one cursor, then returned it, but if there was more than on cursor, it would choose one a 1bpp cursor. That scheme would miss out picking a cursor at all if there was two coloured cursors.

The new scheme makes sure that we always start with one cursor and improve over that.

I think the problem is that standard X cannot support coloured cursors. The Xcursor extension appears to, but we don't support that. Any volunteers?

Controls Vitaliy Margolen WineHQ

Jesse Litton ran into a problem using a native commctrl.dll and comctl32.dll:

I'm no longer able to run programs that require the native comctl32 and commctrl DLLs, since updating to today's CVS. Could it be related to these theme patches?

It seems that now, if you override comctl32 for any app (or globally), even WineCfg itself will error out with the error.

    err:thunk:_loadthunk (commctrl.dll, Cctl1632_ThunkData16, comctl32.dll): Unable to load 'commctrl.dll', error 2
    err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting
    err:module:LdrInitializeThunk Main exe initialization for L"c:\\windows\\system32\\winecfg.exe" failed, status c0000142

The native commctrl.dll and comctl32.dll both exist in my windows/system directory - the same versions that always worked before. Overriding commctrl doesn't have any effect on this error.

Andi Mohr wanted to know if Jesse was running either both of the DLL's as native or both as builtin. These DLL's can't be mixed and matched between native and builtin. Jesse replied that both of them were in fact native. Mike McCormack didn't think there was a reason to still use native DLL's:

You shouldn't need to use the native comctl32 any longer. Please update your dll overrides to "comctl32" = "builtin".

Wine's comctl32 implementation is almost complete. If there's bugs with the builtin comctl32 then please help us by reporting them rather than sweeping the problem under the carpet and using the native dll.

Jesse described the specific problem he was running into with DreamWeaver. Mike supplied a patch:

OK, there is a patch that is in CrossOver that has not yet been committed to WineHQ for some reason, that fixes this problem.

Could you please try the attached patch?

I fear that Wine doesn't go forward as much as it should for lack of testing :/

Jesse reported success:

The patch worked great! At least, it appears to work a lot better than before.

There are still some graphical glitches, for example: If you switch server technology between yes and no when defining a site, the combo box doesn't completely reappear... but it's actually useable now!

Vitaliy Margolen jumped in to mention that all Delphi programs are currently broken with themed controls. Frank Richter then posted a patch on Friday with the following ChangeLog, Merge subclass stubs and subclass proc. Having the stub set the window proc to the subclass proc was not a good idea since that breaks subclasses of themed standard controls (e.g. what Delphi does a lot).

Debugging

Saulius Krasuckas wanted to know how to exclude some calls from relay traces:

Using CVS version I get following calls in the output very frequently:

    000b:Call kernel32.97(408b8880) ret=40891d49
    000b:Ret kernel32.97() retval=40428f60 ret=40891d49
    000b:Call kernel32.98(408b8880) ret=40891e27
    000b:Ret kernel32.98() retval=00000000 ret=40891e27

I want to exclude this stuff. Adding "97;98" to HKEY_CURRENT_USER/Software/Wine/debug/RelayExclude string value doesn't help me.

    $ grep -Ir [^0-9]9[78][^0-9] dlls/kernel/*.spec | dlls/kernel/kernel32.spec: 97 stdcall -noname _EnterSysLevel(ptr) | dlls/kernel/kernel32.spec: 98 stdcall -noname _LeaveSysLevel(ptr)

Adding "_EnterSysLevel;_LeaveSysLevel;97;98" does not help either. Suggestions?

Felix Nawothnig suggested:

Try "kernel32.97;kernel32.98".

Saulius reported that worked.

WineHQ Phil Krylov James Hawkins Michael Jung Mike Hearn Gerald Pfeifer Vitaliy Margolen Krzysztof Foltman WineHQ

Tom Wickline is currently updating some web pages on WineHQ:

I am in the process of updating our "Acknowledgement" & "Who's Who" pages and if anyone here wants to be included and your currently not just send me a mail and ask for inclusion.

If you want inclusion on the "Acknowledgement" page let me know what areas you have worked on and you will be added in on my next patch.

If you believe you will be around for some time to come (a year) and want to be included to the "Who's Who" page let me know this as well. For the "Who's Who" I will need a short description of who you are, where you're from, when you started working on wine, and what areas you work on.

You can look at other entries for a good example..

This is what I have thus far for my next update:

  • ADD - Jonathan Ernst (Acknowledgement page)
  • ADD - Krzysztof Foltman (Acknowledgement page)
  • ADD - Phil Krylov (Acknowledgement page)
  • Update - Gerald Pfeifer to (2005)
  • Update - Michael Jung to (2005)
  • Update - James Hawkins to (2005)
  • Update - Vitaliy Margolen to (2005)
  • Update - Mike Hearn to (2005)