April 2016 - Wine-Devel - list.winehq.org

Re: riched20: Use SetRect instead of open coding it.

by Michael Stefaniuc

On 04/18/2016 01:31 PM, Huw Davies wrote: > On 18 Apr 2016, at 09:11, Michael Stefaniuc <mstefani(a)redhat.de> wrote: >> --- a/dlls/riched20/paint.c >> +++ b/dlls/riched20/paint.c >> @@ -617,10 +617,8 @@ static void ME_DrawParaDecoration(ME_Context* c, ME_Paragraph* para, int y, RECT >> MoveToEx(c->hDC, c->pt.x, y + bounds->top, NULL); >> LineTo(c->hDC, c->pt.x, y + para->nHeight - bounds->bottom); >> if (border_details[idx].dble) { >> - rc.left = c->pt.x + 1; >> - rc.right = rc.left + border_width; >> - rc.top = y + bounds->top; >> - rc.bottom = y + para->nHeight - bounds->bottom; >> + SetRect(&rc, c->pt.x + 1, y + bounds->top, rc.left + border_width, >> + y + para->nHeight - bounds->bottom); > > > This is using rc.left uninitialised. Thanks Huw for catching this! I have amended my coccinelle script to generate compile failures in those cases. There were two more of those in my patch. How do you prefer to handle this cases? Still use SetRect() or leave them open coded? thanks bye michael

April 18, 2016

Re: riched20: Use SetRect instead of open coding it.

by Huw Davies

On 18 Apr 2016, at 09:11, Michael Stefaniuc <mstefani(a)redhat.de> wrote: > --- a/dlls/riched20/paint.c > +++ b/dlls/riched20/paint.c > @@ -617,10 +617,8 @@ static void ME_DrawParaDecoration(ME_Context* c, ME_Paragraph* para, int y, RECT > MoveToEx(c->hDC, c->pt.x, y + bounds->top, NULL); > LineTo(c->hDC, c->pt.x, y + para->nHeight - bounds->bottom); > if (border_details[idx].dble) { > - rc.left = c->pt.x + 1; > - rc.right = rc.left + border_width; > - rc.top = y + bounds->top; > - rc.bottom = y + para->nHeight - bounds->bottom; > + SetRect(&rc, c->pt.x + 1, y + bounds->top, rc.left + border_width, > + y + para->nHeight - bounds->bottom); This is using rc.left uninitialised. Huw.

April 18, 2016

Re: ntdll: Ignore invalid exit_frame when exiting thread.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > On 18.04.2016 12:27, Alexandre Julliard wrote: >> Sebastian Lackner <sebastian(a)fds-team.de> writes: >> >>> Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >>> --- >>> >>> When applications switch to a custom stack, exit_frame is not necessarily >>> valid anymore. >> >> How does it become invalid? Does the app unmap the previous stack? > > Yes, MSYS2/Cygwin will switch to its own stack and deallocate the old one. > This patch alone is not sufficient because there are still a couple of other > references to the old stack (like the debug_info struct in start_thread). > > If preferred, this issue can also be solved differently by calculting exit_frame > dynamically based on StackBase (after a couple of other bugs are fixed). > Disadvantage is that if applications mess around with StackBase, I'm not sure if > we should trust that the new stack is set up properly. The reason for exit_frame is to prevent pthread_exit from trying to unwind the stack. I'm wondering how that will work if it was deallocated. Did you look into this? Does pthread detect that we are on a different stack? And doesn't pthread also put its own structures on the stack? -- Alexandre Julliard julliard(a)winehq.org

April 18, 2016

Re: [PATCH 1/2] d3drm: Implement IDirect3DRM*::CreateObject.

by Henri Verbeet

On 17 April 2016 at 22:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -1054,10 +1058,50 @@ static ULONG WINAPI d3drm3_Release(IDirect3DRM3 *iface) > static HRESULT WINAPI d3drm3_CreateObject(IDirect3DRM3 *iface, > REFCLSID clsid, IUnknown *outer, REFIID iid, void **out) > { > - FIXME("iface %p, clsid %s, outer %p, iid %s, out %p stub!\n", > + void *object_struct; ... > + if (IsEqualGUID(clsid, &CLSID_CDirect3DRMTexture)) > + { > + if (FAILED(hr = d3drm_texture_create((struct d3drm_texture **)&object_struct))) > + { > + *out = NULL; > + return hr; > + } > + object = (IUnknown *)&((struct d3drm_texture *)object_struct)->IDirect3DRMTexture3_iface; > + } Why do you need "object_struct"?

April 18, 2016

Re: ntdll: Ignore invalid exit_frame when exiting thread.

by Sebastian Lackner

On 18.04.2016 12:27, Alexandre Julliard wrote: > Sebastian Lackner <sebastian(a)fds-team.de> writes: > >> Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> >> --- >> >> When applications switch to a custom stack, exit_frame is not necessarily >> valid anymore. > > How does it become invalid? Does the app unmap the previous stack? > Yes, MSYS2/Cygwin will switch to its own stack and deallocate the old one. This patch alone is not sufficient because there are still a couple of other references to the old stack (like the debug_info struct in start_thread). If preferred, this issue can also be solved differently by calculting exit_frame dynamically based on StackBase (after a couple of other bugs are fixed). Disadvantage is that if applications mess around with StackBase, I'm not sure if we should trust that the new stack is set up properly.

April 18, 2016

Re: ntdll: Ignore invalid exit_frame when exiting thread.

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > > When applications switch to a custom stack, exit_frame is not necessarily > valid anymore. How does it become invalid? Does the app unmap the previous stack? -- Alexandre Julliard julliard(a)winehq.org

April 18, 2016

Re: user32/tests: Use SetRect instead of open coding it.

by Michael Stefaniuc

On 04/18/2016 10:50 AM, Marvin wrote: > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=22284 > > Your paranoid android. > > > === w8 (32 bit sysparams) === > sysparams.c:2485: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2496: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 > > === w864 (32 bit sysparams) === > sysparams.c:2485: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out > sysparams.c:2496: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 Unrelated as even a whitespace diff produces them: https://testbot.winehq.org/JobDetails.pl?Key=22288 bye michael

April 18, 2016

Re: wbemprox/tests: Add initial tests for ASSOCIATORS query.

by Sebastian Lackner

On 18.04.2016 09:11, Hans Leidekker wrote: > On Sun, 2016-04-17 at 21:03 +0200, Sebastian Lackner wrote: >> +static void test_associators( IWbemServices *services ) >> +{ >> + static const WCHAR query1[] = >> + {'A','S','S','O','C','I','A','T','O','R','S',' ','O','F',' ','{','W','i','n','3','2','_', >> + 'v','L','o','g','i','c','a','l','D','i','s','k','.', 'D','e','v','i','c','e','I','D','=','"','C',':','"','}',0}; > > Should that be 'Win32_LogicalDisk'? > > Looks indeed like a typo, thanks. I've sent a fixed version.

April 18, 2016

Re: user32/tests: Use SetRect instead of open coding it.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=22284 Your paranoid android. === w8 (32 bit sysparams) === sysparams.c:2485: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2496: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1 === w864 (32 bit sysparams) === sysparams.c:2485: Test failed: Waiting for the WM_DISPLAYCHANGE message timed out sysparams.c:2496: Test failed: Set bpp 32, but WM_DISPLAYCHANGE reported bpp -1

April 18, 2016

Re: ddraw [v3]: Move ComputeSphereVisibility tests to ddraw7

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=22283 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (64 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit d3d) === d3d.c:2326: Test failed: Unexpected destination texture level pixels; 2031 differences at 0 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 518 differences at 1 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 138 differences at 2 level d3d.c:2326: Test failed: Unexpected destination texture level pixels; 46 differences at 3 level d3d.c:2510: Test failed: Unexpected destination texture level pixels; 257 differences d3d.c:2657: Test failed: Unexpected destination texture level pixels; 256 differences at 2 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 64 differences at 3 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 16 differences at 4 level d3d.c:2657: Test failed: Unexpected destination texture level pixels; 4 differences at 5 level

April 18, 2016