wine-devel July 2006

wine-devel@winehq.org

142 participants
297 discussions

Call for volunteer: dwarf2 testing
by Eric Pouech 01 Jul '06

01 Jul '06

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 01 Jul '06

01 Jul '06

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 01 Jul '06

01 Jul '06

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 01 Jul '06

01 Jul '06

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 01 Jul '06

01 Jul '06

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 01 Jul '06

01 Jul '06

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 01 Jul '06

01 Jul '06

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2006