July 2006 - Wine-Devel - list.winehq.org

Call for volunteer: dwarf2 testing
by Eric Pouech July 1, 2006

July 1, 2006

As you may have seen, there's now some support for the dwarf2 debug format (instead of stabs) in the Wine tree I'd like to get some feedback on the overall feedback on how it behaves. To do so, you need to reconfigure Wine with something like CFLAGS="$CFLAGS -gdwarf-2" ./configure and then make clean; make (so that all modules are recompiled with proper format) Normal debugging should be available with winedbg. If something goes wrong, please indicate: - console messages - error items - steps that led to it - version of gcc used TIA

3 4

Re: Any chances to get some feedback on latests mswsock patch?
by Juan Lang July 1, 2006

July 1, 2006

Hi Lukasz, you probably didn't notice that most patches didn't get through this week. There were several other rather large series sent, in addition to the usual traffic. My guess is Alexandre only had time for the easy ones this week. Your patches looked pretty good. The only suggestion I'd make with the documentation patch is not to say things that aren't true yet. The notes about the implementation won't be correct until the implementation patch is applied, and you shouldn't count on that. In particular, - * TODO - * This function is currently implemented as a stub.perhaps leave this as-is.. + * BUGS + * lpOverlapped->OffsetHigh is not supported. + * limited to ULONG files size (see above) + * doesn't support TF_REUSE_SOCKET + * doesn't support async IO. Note: some of it is simulated via lpOverlapped. and omit this until the implemenation patch. Cheers, --Juan

1 0

WRT failed to Build
by Detlef Riekenberg July 1, 2006

July 1, 2006

Hi. The cross-compiled WRT failed since 17. May. The native WRT failed even longer. And Ideas? -- By By ... ... Detlef

2 3

Wine 0.9.16 and ddraw issues
by Alexander Nicolaysen Sørnes July 1, 2006

July 1, 2006

Greetings, I maintain several ddraw apps in the Application Database. While most of the problems introduced by Wine 0.9.16 have been fixed, some still remain. Command & Conquer and C&C: Red Alert When exiting the game, a messagebox displays: 'Unregonized Direct Draw result code: 1' A demo of Red Alert is available here: http://appdb.winehq.org/appview.php?versionId=4026 These two games, along with 'Warlords IIII: Darklords Rising' also have a strange SMP problem. In earlier Wine versions, these games would stop redrawing at some point. This also happens in Wine 0.9.16, but sometimes an error message is displayed instead, and then Wine receives a page fault. Emperor: Battle for Dune This game requires native d3drm.dll, which does not work anymore. Problems with this file was mentioned on this list a few days ago. Heroes of Might and Magic IV This game now displays a File menu when run in full-screen, which it is only supposed to do when run in a window. If I change the game's resolution, the menu disappears, but if I change it back to the resolution it had when it was started, the File menu is displayed again. Because of this menu, the game window is moved downwards, so the bottom part of the game is not displayed. Warcraft II Battle.net Edition The title screen is no longer displayed; it shows a black screen instead. This also happens with some of the campaign intro screens. The rest of the game seems to work as before. The new ddraw code fixes redrawing problems in at least a dozen games, and makes some of them faster, so it was a very good thing! :) Regards, Alexander N. Sørnes

3 4

Any chances to get some feedback on latests mswsock patch?
by Łukasz Chróst July 1, 2006

July 1, 2006

Especially i'd like to know why it hasn't been accepted. It would be nice to have some starting point in the tree, as i've much more done but can't send it anyway. :/ It would be a lot of work to cut the patches into smaller parts at some point. Especially with no feedback... -- thanks, Łukasz Chróst

1 0

Re: Win64 patch 3/5 (winedbg)
by Eric Pouech July 1, 2006

July 1, 2006

Ge van Geldorp wrote: >diff --git a/programs/winedbg/stack.c b/programs/winedbg/stack.c >index b976117..c2dec5f 100644 >--- a/programs/winedbg/stack.c >+++ b/programs/winedbg/stack.c >@@ -127,9 +127,14 @@ BOOL stack_get_current_symbol(SYMBOL_INF > static BOOL CALLBACK stack_read_mem(HANDLE hProc, DWORD addr, > PVOID buffer, DWORD size, PDWORD written) > { >+ SIZE_T sz; >+ BOOL ret; >+ > struct dbg_process* pcs = dbg_get_process_h(hProc); > if (!pcs) return FALSE; >- return pcs->process_io->read(hProc, (const void*)addr, buffer, size, written); >+ ret = pcs->process_io->read(hProc, (const void*)addr, buffer, size, &sz); >+ if (written != NULL) *written = sz; >+ return ret; > } > > /****************************************************************** > > this one is questionnable. Now that we have stackwalk64 implemented (I'm not saying it works flawlessly on 64bit machines), it may be more interesting here to use the 64 bit version of the call back A+

2 2

DDRAW: Releasing attached surfaces
by Krzysztof Benkowski July 1, 2006

July 1, 2006

Hello, In the latest version of wine (0.9.16) there is a regression which makes Dune 2000 crash. After some debugging i found that the problem lays in IDirectDrawSurfaceImpl_Release method. The game (Dune 2000) shows that the assumption that all attached surfaces should be destroyed regardless of their refcount is wrong. What causes the crash in few words: - first Dune 2000 creates a surface with a backbuffer - then it gets the backbuffer interface by GetAttachedSurface method (refcount for the backbuffer is incremented) - it releases the frontbuffer (the backbuffer is destroyed even though its refcount is higher than frontbuffer's) - creates new frontbuffer and an offscreen plain - when one starts a mission the game tries to use the old backbuffer (which is then destroyed) and causes a page fault So my fix is rather quick and thus i'm not quite sure if it's correct. That's because the game works with it but when it quits it leaves the backbuffer not released. I don't know if it's the game's fault or the fix has to be done some other way. I've done it this way: --- surface.c 26 Jun 2006 12:15:20 -0000 1.6 +++ surface.c 29 Jun 2006 14:09:59 -0000 @@ -377,7 +377,7 @@ IDirectDrawSurfaceImpl_Release(IDirectDr while( (surf = This->next_complex) ) { This->next_complex = surf->next_complex; /* Unchain it from the complex listing */ - IDirectDrawSurfaceImpl_Destroy(surf); /* Destroy it */ + IDirectDrawSurfaceImpl_Release(surf); /* Release it */ } If you (Stefan probably) need more info about the bug i can provide some logs Krzysiek

4 5