January 2007 - Wine-devel - list.winehq.org

Re: [PATCH 1/3] [Msvcrt]: reset a signal to DFL after it's been used
by Alexandre Julliard 02 Jan '07

02 Jan '07

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > @@ -455,13 +456,13 @@ static LONG WINAPI msvcrt_exception_filt > case EXCEPTION_FLT_OVERFLOW: > case EXCEPTION_FLT_STACK_CHECK: > case EXCEPTION_FLT_UNDERFLOW: > - if (sighandlers[MSVCRT_SIGFPE]) > + if ((handler =3D sighandlers[MSVCRT_SIGFPE]) !=3D MSVCRT_SIG_DFL= > ) > { > - if (sighandlers[MSVCRT_SIGFPE] !=3D MSVCRT_SIG_IGN) > + sighandlers[MSVCRT_SIGSEGV] =3D MSVCRT_SIG_DFL; > + if (handler !=3D MSVCRT_SIG_IGN) You have to check for SIG_IGN first, the handler should not be reset in that case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray [2]: transparent icons: let systray window responsible for background
by Kirill K. Smirnov 02 Jan '07

02 Jan '07

> "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > > @@ -366,6 +366,7 @@ static void systray_dock_window( Display > > > > wine_tsx11_lock(); > > XSendEvent( display, systray_window, False, NoEventMask, &ev ); > > + XSetWindowBackgroundPixmap(display, data->whole_window, ParentRelative); > > wine_tsx11_unlock(); > > This won't really do what you want. You have to set the window shape > if you want the background to be properly transparent. Now I understand, that the problem is more hard than I think before. 1) The code I sent is the solution... unless the application change icon. In this case new icon is painted over and produces a mixture. 2) If I set window shape to 'AND' bitmap of icon (do I correctly understand you?) then what to do with full transparent icons? E.g. some applications (qip) flashes the icons by changing the icon with full transparent icon and back. a) Will window with NULL shape be created? b) if a) is true, then when I click on null icon will I get any events? For some time I wonder, why kde icons looks good even when they are changing??? The answer is kde applications use KSystemTray directly without XEMBED. xmule to achieve the same goal, removes the icon from systray and adds new one (as I understand it, I may wrong). Shall we use the same mechanism? Any other suggestion?

2 1

World of Warcraft Progress
by darckness 02 Jan '07

02 Jan '07

Ahoy! First off, I'd like to say happy 2007! Hope you all did some good celebrating. I know I did ;) Anyway, I've been doing some testing on World of Warcraft, and I noticed some things of interest (Latest wine version from cvs/git, no patches applied). First off, the D3D (DX9) runs MUCH better (faster and more smoothly) than the OGL mode. Big kudos to you guys; last time I played, the D3D mode was completely unusable because there was no D3D support in wine. Very impressive. The OGL performance isn't bad by any means, but it isn't great either. I was running some traces as I played, but nothing in particular seemed to be the culprit in terms of choppiness, so it's possible that it could just be my system. I'll write back soon when I have more conclusive evidence. Additionally, OGL mode crashes any time I attempt to change a video setting, something that does not happen in D3D mode. The load time (both startup and between zones/etc) is at least 10x faster than it used to be. I know that Blizzard has been working on this a bit, but based on what I've seen on systems running Windows, the load time reduction seems largely due to improvements in wine. I guess my only real complaint at this point, since the D3D mode woks so well, is that the X cursor still shows up in the game window along with the game cursor. I vaguely recall having this problem a long long time ago in OGL mode, but I can't remember exactly what caused it or how it was fixed. Anyone have a better memory than I do? That's pretty much the state of WoW at the moment. Comments/Questions/Solutions?

3 2

Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
by Ivan Gyurdiev 02 Jan '07

02 Jan '07

Louis. Lenders wrote: > Hi, is there anything wrong with this patch? If so, could you please > tell me what. Thx > > */"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk>/* wrote: > > Hi, this patch should fix failing tests in d3d9, like you see for > example here: > http://test.winehq.org/data/200612231000/ > > Appearently the tests in stateblock.c didn't need to be modified, > as they create the device with flag D3DDEVTYPE_NULLREF; these > tests do not fail anywhere. > > thanks for some advice from stringfellow > ------------------------------------------------------------------------ > So why not fallback to REF or NULLREF type of device everywhere else if HAL is unavailable? Do those tests need HAL support in the first place?

2 1

Re: Resend: d3d9: fix failing tests on windows, when no 3d hardware acceleration is available
by Alexandre Julliard 02 Jan '07

02 Jan '07

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > Hi, is there anything wrong with this patch? If so, could you please tell me what. Thx I fixed it up, but next time please try to respect the indentation style of the existing file. We don't have any place that uses a strange style like this: > + if(FAILED(hr)) > + { > + trace("could not create device, IDirect3D9_CreateDevice returned %#x\n", hr); > + goto cleanup; > + } -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: systray [2]: transparent icons: let systray window responsible for background
by Alexandre Julliard 02 Jan '07

02 Jan '07

"Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > @@ -366,6 +366,7 @@ static void systray_dock_window( Display > > wine_tsx11_lock(); > XSendEvent( display, systray_window, False, NoEventMask, &ev ); > + XSetWindowBackgroundPixmap(display, data->whole_window, ParentRelative); > wine_tsx11_unlock(); This won't really do what you want. You have to set the window shape if you want the background to be properly transparent. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/opengl32/wgl.c: minor dealloc fix
by Stefan Dösinger 02 Jan '07

02 Jan '07

Am 01.01.2007 um 11:03 schrieb Nick Burns: > There can be a problem where the detach is hit before > internal_gl_extensions is allocated and it tries to free NULL and > dies... > > This just checks for the allocation before freeing -- very minor > > - Nick HeapFree(GetProcessHeap(), 0, NULL) is supposed to be a nop, so the check is not needed.

4 5

Re: [9/16] WineD3D: Move decoding the vertex declaration to the device
by Ivan Gyurdiev 02 Jan '07

02 Jan '07

+ if (stateblock->wineD3DDevice->vs_selected_mode != SHADER_NONE && stateblock->vertexShader && + ((IWineD3DVertexShaderImpl *)stateblock->vertexShader)->baseShader.function != NULL) + memcpy(&stateblock->wineD3DDevice->strided_streams, stateblock->wineD3DDevice->up_strided, sizeof(stateblock->wineD3DDevice->strided_streams)); + primitiveDeclarationConvertToStridedData((IWineD3DDevice *) stateblock->wineD3DDevice, useVertexShaderFunction, + &stateblock->wineD3DDevice->strided_streams, &stateblock->wineD3DDevice->streamFixedUp); My eyes hurt - can we *please* store the device in a local variable. Also, I am not sure how we got to the point where this many upward references to the device from the stateblock are necessary - there has to be something wrong with that: a stateblock captures the state of a device, so why is it referring back to its parent device and looking up state there? This type of thing was introduced into the shader code as well, and IIRC it was wrong there too. Also, all this transient data from the drawprim codepath moved into the device - can you explain again why that's necessary, does it really need to persist after the drawprim call?

2 1

Re: wininet: ensure null check before dereference
by James Hawkins 02 Jan '07

02 Jan '07

On 1/1/07, Jeff Latimer <lats(a)yless4u.com.au> wrote: > Coverity cid: 367 Do the null check before the dereference. Given that > this is an simple internal function, do we need to check for null pointers? > Generally we don't check for NULL params in internal functions. -- James Hawkins

1 0

Re: dbghelp: Search for .gnu_debuglink file
by Eric Pouech 02 Jan '07

02 Jan '07

Frank Richter a écrit : > The .gnu_debuglink section contains only a bare filename, however, the > debug file can be in a number of locations. These are stated in the > GDB manual and are now searched when a .gnu_debuglink is encountered. Frank, a couple of remarks: - there are memory leaks in the code (moduleDir can be leaked, as well as the newly found pathname) - for the code to still be readable, I'd rather but in a single function all the processing required, ie. do it the same way as for the other debug information: if the .gnu_debuglink section is found, map it, and then let this new function handle the lot A+

1 0