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

Re: [PATCH] user32/tests: Test SetUserObjectInformation for invisible winstation.

by Dmitry Timoshkov

Qian Hong <qhong(a)codeweavers.com> wrote: > On Wed, Oct 23, 2013 at 1:51 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > It looks like that these new winstation tests now leave a reference to > > a wineserver object which makes wineserver stay in memory after the tests > > have finished. Please fix. > > Thanks for comment, I noticed this as well, it is an existing Wine bug > discovered by my test, I have a comment regarding this bug in my > [patch 4/6], I'll try to fix Wine rather than my test. So much time has passed but it's still not fixed, wineserver stays forever in memory after 'make test' in user32/tests, this is very annoying. Please either fix it or at least limit the winstation tests to run only in interactive mode. Moreover, plain 'make winstation.ok' doesn't work at all, explorer fails to start. -- Dmitry.

April 23, 2015

Re: [PATCH 2/2] krnl386: Invalid console handles should translate into real handles when creating a new process.

by Alexandre Julliard

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > This patch fixes an issue exposed by the fix in patch 1. The current > mechanism for initializing the DOS handles for a process uses > DuplicateHandle, which converts INVALID_HANDLE_VALUE into a usable > handle (but not 0). Without this fix the Caesar III demo installer > crashes with an unhandled page fault, though it may be more desirable > to allocate new handles than to replicate the behavior we used to have > prior to patch 1. Proper handles would be better, simply open the null device or something like that. -- Alexandre Julliard julliard(a)winehq.org

April 23, 2015

Re: [PATCH 2/5] wined3d: Shadow format flags in wined3d_rendertarget_view.

by Henri Verbeet

On 22 April 2015 at 11:30, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -101,6 +101,7 @@ static void wined3d_rendertarget_view_init(struct wined3d_rendertarget_view *vie > view->parent_ops = parent_ops; > > view->format = wined3d_get_format(gl_info, desc->format_id); > + view->format_flags = resource->format_flags; That's wrong. We won't be able to do much with this until we support ARB_texture_view, but the view format is mostly independent of the resource format, other than that they have to be from the same compatibility class. I guess you'd want something like "view->format_flags = view->format->flags[resource->gl_type];".

April 22, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-22 um 05:30 schrieb Alistair Leslie-Hughes: > + if(*pdwBufferSize < entry->size || *pdwNameLen < namesize) > + { > + *pdwNameLen = namesize + 1; > + *pdwBufferSize = entry->size; > + return DPNERR_BUFFERTOOSMALL; > + } > + > + if((*pdwNameLen && !pwszName) || (*pdwBufferSize && !pvBuffer)) > + return E_POINTER; This check suggests that a NULL pwszName is ok if *pdwNameLen is 0. However, the above check fails in this situation. Depending on how you want this to behave there's either an error in your logic or you have some redundant checks in there. Are you sure *pdwDataType is not set in the BUFFERTOOSMALL case? I mentioned pdwDataType in the last feedback already, please take a bit more care and check if some things I point out apply in a similar way to other places, and re-read the feedback you get after you think you have implemented all the changes to see if there's anything you missed. > + case DPNA_DATATYPE_DWORD: > + *(DWORD*)pvBuffer = entry->data.value ; The extra space in front of the semicolon looks weird. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, 100, NULL, NULL, NULL, &bufflen, &type); > - todo_wine ok(hr == E_POINTER, "got 0x%08x\n", hr); > + ok(hr == DPNERR_INVALIDPOINTER, "got 0x%08x\n", hr); In the code you return E_POINTER. DPNERR_INVALIDPOINTER is defined as E_POINTER, but please try to be consistent. > hr = IDirectPlay8Address_GetComponentByIndex(localaddr, i, NULL, &namelen, NULL, &bufflen, &type); > - todo_wine ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(hr == DPNERR_BUFFERTOOSMALL, "got 0x%08x\n", hr); > + ok(namelen > 0, "namelen length is 0\n"); > + ok(bufflen > 0, "bufflen length is 0\n"); Please check the exact length, not just > 0. Please also check the name string, and the string and lengths in the success case (e.g. if you pass a length > than the necessary size does dpnet change the size?). Also, as pointed out above -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVN25ZAAoJEN0/YqbEcdMwf1cP/jXMXUuyMNzg5JAVG6YMMKgJ yIac4X5zxnmcPrJMjMRKIr2xU3u6ZDki/Kk5/GulDCCd4NQGlDJP0QY9WuuZ9eIN YiAipjXLpO4DPVi6eTRlDIbfCSDfpNJnjSWdDGbjpF/dpUkJOOZzwWvkJKZr598O kZohPT1kwTs12sU3yQyT8N3NGQer+AaWHcfohMW5f0UeZ+whviwjg3CGavrR65mH Q2fWn92mgw8KPTu+zvJ5oBbWQLf24o+lBp/vQ6zeOIA2lxXVLoMfg5q8QRWvKge9 IiPIG8BEOfrTXXSEZSUauif97fdq23JGQJOOGYUyZ+YLg/4Pqj2nWZBOmFM+3gVy E5FgFPT4EdE1vpyn7cnWGufzNtnctTZGOJ4F7AKxdMoBPqXxDEgdjmMFqN0yeTH8 Pm6NGVJP7uR8+wqXApHoGN2S7ceZLuEhMhdGYHbFakx9McPzCEayWMGQ/CIlbjHt YRB5aaxOAk896Fmb+PMuv3G9d4+y4409iLB+/Jrda20VOFfAp1qzNa33R9rhWXN7 sSdCale2KKYwStnzSWAcH4Mn7L+i1B/Dl7Md83HqPumAPfwlSK8VZVeqF0ZVjLaR KlokPcmQnIuS/ia6gPdGVbmAHnpoIIn0CNtgstKBqXkvGUlasXsKhy2ofWkWoaiW lO+hrwausmSORbzMGVaW =fTwv -----END PGP SIGNATURE-----

April 22, 2015

Re: dpnet: Implement IDirectPlay8Address GetComponentByIndex (try 9)

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=12940 Your paranoid android. === w8 (32 bit address) === The test timed out

April 22, 2015

Re: comctl32:TTM_SETTOOLINFO does not change subclassing

by Aric Stewart

On 4/21/15 12:02 PM, Nikolay Sivov wrote: > On 21.04.2015 17:40, Aric Stewart wrote: >> >> Prevents crashes when a subclassed window is unsubclassed and then destroyed. >> >> As per information found at: >> https://support.microsoft.com/en-us/kb/kbview/154122 >> --- >> dlls/comctl32/tooltips.c | 6 +++++- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> >> > > We definitely need a test for that. > You are correct, working on those. -aric

April 21, 2015

Re: comctl32:TTM_SETTOOLINFO does not change subclassing

by Nikolay Sivov

On 21.04.2015 17:40, Aric Stewart wrote: > > Prevents crashes when a subclassed window is unsubclassed and then destroyed. > > As per information found at: > https://support.microsoft.com/en-us/kb/kbview/154122 > --- > dlls/comctl32/tooltips.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > We definitely need a test for that.

April 21, 2015

Re: [PATCH 5/5] ddraw/tests: Port the lighting test to the previous d3d versions.

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=12921 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2488: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2490: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2496: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2527: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2535: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2562: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2582: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2606: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2633: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2650: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2687: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2698: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2725: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2745: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2762: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2789: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2806: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2844: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}.

April 21, 2015

Re: [PATCH 4/5] ddraw/tests: Add more d3d7 lighting tests.

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=12920 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

April 21, 2015

Re: iexplore: Update version to 9.0.8112.16421.

by Hans Leidekker

On Tue, Apr 21, 2015 at 11:25 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Maybe ieframe/mshtml versions should be updated as well? I considered that but they are trailing behind already. It might be better to wait for an application that needs it, so we don't break too much at once.

April 21, 2015