March 2008 - Wine-Devel - list.winehq.org

Redirect http://forums.winehq.org -> http://forum.winehq.org.
by Andrew Riedi March 18, 2008

March 18, 2008

Because many other sites have forums spelled in the plural, such as http://ubuntuforums.org and http://forums.gentoo.org, many users simply assume we will too. I would like to request a redirect from http://fourms.winehq.org to http://forum.winehq.org. Note, even one of own developers made this mistake, which I sent in a fix for at: http://article.gmane.org/gmane.comp.emulators.wine.patches/48512 . -- Andrew Riedi

2 1

Re: msi/tests: Skip the tests if we are unable to identify the user SID. This fixes crashes on Win9x.
by Paul Vriens March 18, 2008

March 18, 2008

Francois Gouget wrote: > --- > dlls/msi/tests/source.c | 50 ++++++++++++++++++++++++++++++++++++++-------- > 1 files changed, 41 insertions(+), 9 deletions(-) > > diff --git a/dlls/msi/tests/source.c b/dlls/msi/tests/source.c > index 49e40c7..5f75159 100644 > --- a/dlls/msi/tests/source.c > +++ b/dlls/msi/tests/source.c > @@ -122,18 +122,22 @@ static void create_test_guid(LPSTR prodcode, LPSTR squashed) > WideCharToMultiByte(CP_ACP, 0, squashedW, -1, squashed, MAX_PATH, NULL, NULL); > } > > -static void get_user_sid(LPSTR *usersid) > +static int get_user_sid(LPSTR *usersid) > { > HANDLE token; > BYTE buf[1024]; > DWORD size; > PTOKEN_USER user; > + BOOL rc; > > - OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &token); > + rc=OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &token); > + if (!rc && GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) > + return 0; > size = sizeof(buf); > GetTokenInformation(token, TokenUser, (void *)buf, size, &size); > user = (PTOKEN_USER)buf; > pConvertSidToStringSidA(user->User.Sid, usersid); > + return 1; > } > > static void check_reg_str(HKEY prodkey, LPCSTR name, LPCSTR expected, BOOL bcase, DWORD line) > @@ -186,7 +190,11 @@ static void test_MsiSourceListGetInfo(void) > } > > create_test_guid(prodcode, prod_squashed); > - get_user_sid(&usersid); > + if (!get_user_sid(&usersid)) > + { > + skip("User SID not available -> skipping MsiSourceListGetInfoA tests\n"); > + return; > + } > Couldn't we just check for pConvertSidToStringSidA like we do in the msi.c tests (line 6039)? -- Cheers, Paul.

1 0

Re: [1/22] WineD3D: Add GL_ATI_fragment_shader
by Alexandre Julliard March 18, 2008

March 18, 2008

Stefan Dösinger <stefan(a)codeweavers.com> writes: > Note that the extension is disabled for now. This allows a bottom-up > contruction of the GL_ATI_fragment_shader replacement pipeline in the > code with separate patches, and activating it at the end when it is at > the same feature level as the existing ARB_texture_env_combine code it > can be enabled at once, thus avoiding additional troubles when running > regression tests. It may avoid trouble, but it also makes regression testing useless, since all problems with this code will point to the patch that enables it. It's not a good idea to add code without making use of it. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: (X11 Series 2/3) Fix handling of non-default visuals
by Alexandre Julliard March 18, 2008

March 18, 2008

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> writes: > @@ -144,7 +170,7 @@ BOOL X11DRV_CreateDC( HDC hdc, X11DRV_PDEVICE **pdev, LPCWSTR driver, LPCWSTR de > else > { > physDev->bitmap = NULL; > - physDev->drawable = root_window; > + physDev->drawable = template_window; > physDev->depth = screen_depth; > physDev->drawable_rect = virtual_screen_rect; > SetRect( &physDev->dc_rect, 0, 0, virtual_screen_rect.right - virtual_screen_rect.left, This won't work, a screen DC has to be able to paint on the root window. I'm afraid that supporting different depths properly is pretty complicated. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: 1/6 WineD3D: CheckDeviceFormat rewrite
by Stefan Dösinger March 18, 2008

March 18, 2008

Am Montag, 17. März 2008 20:22:58 schrieb Roderick Colenbrander: > Hi, > > This patch puts legacy bump mapping in its own function. Battlefield 1942 is broken for me after these patches, apparently because D3DFMT_R8G8B8 is enabled again. As far as I can see this is due to the early if(!Usage) return in the texture resource check, the code never reaches the if condition that disables R8G8B8. Is this early return needed at all? It seems confusing to me and is only going to cause breakage similarly to the old code. The old code enabled R8G8B8 for d3d7, but I think you can remove that and keep the format disabled altogether. As far as I can see Windows does not support it in ddraw either, and enabling it for d3d7 but not d3d8 wouldn't make sense. By the way, I noticed(a bit late) that the patches from yesterday broke depth stencil selection for me. These patches fix this problem again, but I'm afraid it will cause some issues for regression testing.

2 3

Proposal for debugging improvement
by tony.wasserka＠freenet.de March 18, 2008

March 18, 2008

Hi, When I was trying to find out how the native d3dx9_36.dll handles ID3DXRenderToSurface->BeginScene() with WINEDEBUG="+d3d9,heap" I had the problem that I had to find out what functions are called within the dll and what functions are called by the d3d9 functions (and thus are irrelevant for d3dx9). For example this is what I got for BeginScene: (fixmes were disabled) > trace:d3d9:IDirect3DSurface9Impl_GetDesc (0xc3b428) Relay > trace:d3d9:IDirect3DDevice9Impl_CreateDepthStencilSurface Relay > trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x1264c8) Relay > trace:heap:RtlAllocateHeap (0x110000,0000000a,0000001c): returning 0xc3b450 > trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x1264c8) : w(256) h(256) fmt(0) surf@(nil) > trace:heap:RtlAllocateHeap (0x110000,0000000a,00000114): returning 0x1b81e0 > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 4 > trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x1264c8) : Created surface 0xc3b450 > trace:d3d9:IDirect3DDevice9Impl_BeginStateBlock (0x1264c8) Relay > trace:heap:RtlAllocateHeap (0x110000,0000000a,0000c994): returning 0xd1df30 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000006a0): returning 0xc3b820 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000001a8): returning 0xa7b7e8 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000006b0): returning 0x1b8300 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000001ac): returning 0xd2a8d0 > trace:heap:RtlAllocateHeap (0x110000,00000002,000001ac): returning 0xc3bec8 > trace:heap:RtlAllocateHeap (0x110000,00000002,000001a8): returning 0xa7b998 > trace:d3d9:IDirect3DDevice9Impl_SetViewport (0x1264c8)0xc3b384 Relay > trace:d3d9:IDirect3DDevice9Impl_EndStateBlock (0x1264c8) Relay > trace:heap:RtlAllocateHeap (0x110000,0000000a,00000010): returning 0xd1dec8 > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 5 > trace:d3d9:IDirect3DDevice9Impl_EndStateBlock (0x1264c8)Returning 0xd1dec8 0xd1df30 > trace:d3d9:IDirect3DStateBlock9Impl_Capture (0xd1dec8) Relay > trace:d3d9:IDirect3DDevice9Impl_GetRenderTarget (0x1264c8) Relay > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d20) > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 6 > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d20) : AddRef from 0 > trace:d3d9:IDirect3DDevice9Impl_GetDepthStencilSurface (0x1264c8) Relay > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d48) > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 7 > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d48) : AddRef from 0 > trace:d3d9:IDirect3DDevice9Impl_SetRenderTarget (0x1264c8) Relay > trace:heap:RtlFreeHeap (0x110000,00000002,0x178110): returning TRUE > trace:d3d9:IDirect3DDevice9Impl_SetDepthStencilSurface (0x1264c8) Relay > trace:d3d9:IDirect3DDevice9Impl_SetViewport (0x1264c8)0xc3b384 Relay > trace:d3d9:IDirect3DDevice9Impl_BeginScene (0x1264c8) Relay > trace:d3d9:IDirect3DSurface9Impl_AddRef (0xc3b428) > trace:d3d9:IDirect3DSurface9Impl_AddRef (0xc3b428) : Forwarding to 0xa7b6e8 > trace:d3d9:IDirect3DTexture9Impl_AddRef (0xa7b6e8) : AddRef from 2 > trace:heap:RtlAllocateHeap (0x110000,00000002,0000001d): returning 0xc3b478 However, after distinguishing the direct and the indirect function calls, I would've found an output like this much better: > trace:d3d9:IDirect3DSurface9Impl_GetDesc (0xc3b428) Relay > trace:d3d9:IDirect3DDevice9Impl_CreateDepthStencilSurface Relay > trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x1264c8) Relay > trace:heap:RtlAllocateHeap (0x110000,0000000a,0000001c): returning 0xc3b450 > trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x1264c8) : w(256) h(256) fmt(0) surf@(nil) > trace:heap:RtlAllocateHeap (0x110000,0000000a,00000114): returning 0x1b81e0 > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 4 > trace:d3d9:IDirect3DDevice9Impl_CreateSurface (0x1264c8) : Created surface 0xc3b450 > trace:d3d9:IDirect3DDevice9Impl_BeginStateBlock (0x1264c8) Relay > trace:heap:RtlAllocateHeap (0x110000,0000000a,0000c994): returning 0xd1df30 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000006a0): returning 0xc3b820 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000001a8): returning 0xa7b7e8 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000006b0): returning 0x1b8300 > trace:heap:RtlAllocateHeap (0x110000,0000000a,000001ac): returning 0xd2a8d0 > trace:heap:RtlAllocateHeap (0x110000,00000002,000001ac): returning 0xc3bec8 > trace:heap:RtlAllocateHeap (0x110000,00000002,000001a8): returning 0xa7b998 > trace:d3d9:IDirect3DDevice9Impl_SetViewport (0x1264c8)0xc3b384 Relay > trace:d3d9:IDirect3DDevice9Impl_EndStateBlock (0x1264c8) Relay > trace:heap:RtlAllocateHeap (0x110000,0000000a,00000010): returning 0xd1dec8 > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 5 > trace:d3d9:IDirect3DDevice9Impl_EndStateBlock (0x1264c8)Returning 0xd1dec8 0xd1df30 > trace:d3d9:IDirect3DStateBlock9Impl_Capture (0xd1dec8) Relay > trace:d3d9:IDirect3DDevice9Impl_GetRenderTarget (0x1264c8) Relay > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d20) > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 6 > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d20) : AddRef from 0 > trace:d3d9:IDirect3DDevice9Impl_GetRenderTarget (0x1264c8) Finished > trace:d3d9:IDirect3DDevice9Impl_GetDepthStencilSurface (0x1264c8) Relay > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d48) > trace:d3d9:IDirect3DDevice9Impl_AddRef (0x1264c8) : AddRef from 7 > trace:d3d9:IDirect3DSurface9Impl_AddRef (0x177d48) : AddRef from 0 > trace:d3d9:IDirect3DDevice9Impl_SetRenderTarget (0x1264c8) Relay > trace:heap:RtlFreeHeap (0x110000,00000002,0x178110): returning TRUE > trace:d3d9:IDirect3DDevice9Impl_SetDepthStencilSurface (0x1264c8) Relay > trace:d3d9:IDirect3DDevice9Impl_SetViewport (0x1264c8)0xc3b384 Relay > trace:d3d9:IDirect3DDevice9Impl_BeginScene (0x1264c8) Relay > trace:d3d9:IDirect3DSurface9Impl_AddRef (0xc3b428) > trace:d3d9:IDirect3DSurface9Impl_AddRef (0xc3b428) : Forwarding to 0xa7b6e8 > trace:d3d9:IDirect3DTexture9Impl_AddRef (0xa7b6e8) : AddRef from 2 > trace:heap:RtlAllocateHeap (0x110000,00000002,0000001d): returning 0xc3b478 I have to admit that I have yet no real idea if this distinction is correct, but I hope it makes clear what I want to approach. All traces that have been made inside of a nested function call are written a bit more right, so that one can easily see that it hasn't been called directly by an application. A suggestion for how to realize this system would be to 1) add a variable that counts how much right a debug output should be 2) modify the debug macros TRACE, FIXME, etc... in such a way that they recognize this variable 3) replace all TRACE("(%p): relayn", This) calls, which are usually at the beginning of a function, with a new macro, let's say NEWTRACE, which does exactly the same but also increments our tab (or space) counter by one. 4) make sure that there's also an ENDTRACE macro at the end of each function that decrements the counter again. At least I would find this idea very useful, so feel free to leave a comment about either the thing itself or my implementation idea of it. Best regards, Tony PS: I know that there would be several workarounds that would help me in this case, but I'd like this proposal to get into the official tree if others like it, too. PPS: We could also add a WINEDEBUG option that filters out any indirect function calls from e.g. the 4th level to make things more overviewable, however, it's just another idea, too ;-)

2 1

Re: 6/6 WineD3D: CheckDeviceFormat rewrite
by Alexandre Julliard March 18, 2008

March 18, 2008

"Roderick Colenbrander" <thunderbird2k(a)gmx.net> writes: > This patch removes some code which isn't needed anymore. All of this is now handled inside the resource type checks. It doesn't work here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:2555: Test failed: quad 1 has color 00000000, expected 0x00FFFF00 visual.c:2559: Test failed: quad 3 has color 00000000, expected 0x0000FF00 visual.c:2642: Test failed: quad 1 has color 00000000, expected 0x00FF0000 visual.c:2649: Test failed: quad 4 has color 00000000, expected 0x0033cc00 wine: Unhandled page fault on write access to 0x05594884 at address 0x601cdcb6 (thread 0036), starting debugger... -- Alexandre Julliard julliard(a)winehq.org

1 0

wined3d: Check with "&& FALSE"
by Paul Vriens March 18, 2008

March 18, 2008

Hi, In the past we had some occurrences of comparisons with NULL flags. I had this check run again today and it came back with: ./dlls/wined3d/arb_program_shader.c:316: if(max_constantsF + extra_constants_needed + 1 < GL_LIMITS(pshader_constantsF) && FALSE) { Is this line correct? Doesn't this alway return FALSE? -- Cheers, Paul.

3 5

Re: user32: Add test_CreateIconFromResourceEx().
by Dmitry Timoshkov March 18, 2008

March 18, 2008

"Andrew Riedi" <andrewriedi(a)gmail.com> wrote: > changelog: user32: Add test_CreateIconFromResourceEx(). What this patch is supposed to test? Just that CreateIconFromResourceEx returns a valid icon handle? What about the resulting icon contents? What about cases when CreateIconFromResourceEx should fail? -- Dmitry.

2 2

Google Summer of Code 2008 is on!
by Maarten Lankhorst March 18, 2008

March 18, 2008

Hi all, Wine has been officially accepted as mentoring organisation for 2008!!!!!!!! Just thought I'd share. I hope this will be the best summer of code for wine yet! Cheers, Maarten.

1 1