May 2011 - Wine-Devel - list.winehq.org

Re: infosoft/tests: COM cleanup in infosoft.c.

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 http://testbot.winehq.org/JobDetails.pl?Key=11350 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed

May 31, 2011

Re: comctl32/tests: Using unsigned constants to remove sign comparison warning.

by Marko Nikolic

David Laight wrote: > On Fri, May 27, 2011 at 10:09:04PM +0400, Nikolay Sivov wrote: >> On Fri, May 27, 2011 at 5:16 PM, Marko Nikolic <grkoma(a)gmail.com> wrote: >> > --- >> > ?dlls/comctl32/tests/treeview.c | ? ?6 +++--- >> > ?1 files changed, 3 insertions(+), 3 deletions(-) >> > >> > diff --git a/dlls/comctl32/tests/treeview.c >> > b/dlls/comctl32/tests/treeview.c index 5fd26a0..b1eb85e 100644 >> > --- a/dlls/comctl32/tests/treeview.c >> > +++ b/dlls/comctl32/tests/treeview.c >> > @@ -634,7 +634,7 @@ static void test_get_set_bkcolor(void) >> > >> > ? ? /* If the value is -1, the control is using the system color for >> > the background color. */ ? ? crColor = (COLORREF)SendMessage( hTree, >> > TVM_GETBKCOLOR, 0, 0 ); - ? ?ok(crColor == -1, "Default background >> > color reported as 0x%.8x\n", crColor); + ? ?ok(crColor == 0xffffffff, >> > "Default background color reported as 0x%.8x\n", crColor); >> > >> >> ~0 looks better here imo. > > Rather ~0u > The 0xffffffff should be 0xffffffffu > > David > You are right, thanks, I'll update the patch. Marko

May 31, 2011

Re: Added unbound sampler test for pixel shaders.

by Stefan Dösinger

On Tuesday 31 May 2011 17:48:14 Sean Sube wrote: > + static const DWORD ps_code[] = > + { > + 0xFFFF0200, 0x0200001F, 0x90000000, 0xA00F0800, > + 0x0200001F, 0x80000000, 0xB00F0000, 0x03000042, > + 0x800F0000, 0xB0E40000, 0xA0E40000, 0x02000001, > + 0x800F0800, 0x80E40000, 0x0000FFFF, > + }; Please write the assembler code into comments, this makes the test easier to read. > + hr = IDirect3DDevice9_GetPixelShader(device, &old_ps); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_GetPixelShader failed, hr %#x.\n", hr); The individual tests should unset the pixel shader, if old_ps is not NULL here that's a bug. > + color = getPixelColorFromSurface(rt, 32, 32); > + ok(color == 0xFF000000, "Color is %#x.\n", color); My understanding is that the test currently fails, so you should mark it as todo: todo_wine ok(...); > + hr = IDirect3DDevice9_CreatePixelShader(device, ps_code, &ps); > + ok(SUCCEEDED(hr), "IDirect3DDevice9_CreatePixelShader failed, hr %#x. \n", hr); Your test must check is PS 2.0 shaders are supported. We already have a pixel shader >= 2.0 supported block in the START_TEST(visual) function, please call your test function inside it. (e.g. after dp2add_ps_test)

May 31, 2011

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus().

by Adam Martinson

On 05/31/2011 12:02 PM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> +/* Check the current process and all ancestors. Some apps run sub-processes that >> + * have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but the parent process doesn't. >> + * (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6). >> + * If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */ > How do the processes running in separate address spaces have anything to do > with that? > Hmm, didn't consider that. Maybe this is only needed if the processes share one

May 31, 2011

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx().

by Adam Martinson

On 05/31/2011 12:09 PM, Dmitry Timoshkov wrote: > Adam Martinson<amartinson(a)codeweavers.com> wrote: > >> + if (osver.dwMajorVersion>= 5) > That's a wrong check for win9x. > It's not, it's a check for win2k and later, the stuff in that block isn't done for win9x.

May 31, 2011

Re: [1/3] kernel32/heap: Emulate Win9x if appropriate in GlobalMemoryStatusEx().

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > + if (osver.dwMajorVersion >= 5) That's a wrong check for win9x. -- Dmitry.

May 31, 2011

Re: [2/3] kernel32/heap: Fix some hacks in GlobalMemoryStatus().

by Dmitry Timoshkov

Adam Martinson <amartinson(a)codeweavers.com> wrote: > +/* Check the current process and all ancestors. Some apps run sub-processes that > + * have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set, but the parent process doesn't. > + * (eg, Dragon NaturallySpeaking 7 setup runs Install Shield 6). > + * If any don't have IMAGE_FILE_LARGE_ADDRESS_AWARE, return FALSE. */ How do the processes running in separate address spaces have anything to do with that? -- Dmitry.

May 31, 2011

Re: [4/5] ddraw: Extend the lifetime of the IDirect3D7::EnumDevices strings beyond function scope.

by Andrew Nguyen

On 05/31/2011 10:47 AM, Stefan Dösinger wrote: > Does the enum_device_entry structure have to be in ddraw_private.h? I > think you can just declare it in ddraw.c because it is used only there. No, I simply defined the structure there to be consistent with the role of the unused structure definitions I removed earlier. I can certainly move the definition to ddraw.c.

May 31, 2011

Re: [4/5] ddraw: Extend the lifetime of the IDirect3D7::EnumDevices strings beyond function scope.

by Stefan Dösinger

Does the enum_device_entry structure have to be in ddraw_private.h? I think you can just declare it in ddraw.c because it is used only there. At some point we'll want to get rid of the ddraw device type strings and call wined3d_get_adapter_identifier - but that needs more work and some more tests. Am 31.05.2011 um 12:50 schrieb Andrew Nguyen: > --- > dlls/ddraw/ddraw.c | 43 +++++++++++++------ > dlls/ddraw/ddraw_private.h | 8 ++++ > dlls/ddraw/tests/d3d.c | 98 ++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 136 insertions(+), 13 deletions(-) > > > <0004-ddraw-Extend-the-lifetime-of-the-EnumDevices-strings-b.txt>

May 31, 2011

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 31.05.2011 um 12:50 schrieb Alexandre Julliard: > I mean using D3DPOOL in wined3d, not by including the d3d9 headers, but > by defining it when necessary, i.e. if neither d3d8types.h nor > d3d9types.h have been included already. This would lead to a mixture of WINED3D* and D3D* types. But that could be addressed with a #define WINED3DPOOL D3DPOOL if D3DPOOL is available and declaring the num if D3DPOOL is not available. There are types like D3DRENDERSTATETYPE that aren't clear subsets/supersets. For example d3d8 has D3DRS_ZBIAS while d3d9 has D3DRS_DEPTHBIAS, and ZBIAS was removed. I guess that's something we should discuss with Henri once he is back. I don't like the idea just yet because we can't check if the d3d8, d3d9 and wined3d types are the same. With the switch statement without a default case we get a compiler warning if the wined3d type changes and the compiler optimizes the switch statement and no-op function away(At least the last time I checked). -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJN5QCKAAoJEN0/YqbEcdMwELoQAIGzt1Pz8xDjTl0872+Eo4ul eTTopbvjUf1b44p0SSQBk8ypwP8FXn1K72wQxk0XcQBr5LOsX8T3i2gDKOwjfMtS YQ4OoEep0+LYdz69bsPydnFE3PNnT8Uhj8v4Di2udfnv5pXp16Ay9y45XfyzFbCY C5Zho8U4V43yWXpyiNF7o1wbSg82Bvkr9YsZJ9e2r1mTmHMKyJfdsjc5kUyDR9el u51Zad53xv99rLa8qmh6lXerbHeGXGTuBv5hMlv0eCWHQyrLvPh0aUvboke83UyE QbM9WME91WhcPlm1VEvA6grP+XZrb20Ib6XINSk804hMZNZlH3r20+kv/3owd2RN IqUxv5KgqR7st1GCOdhzeHo5CorR0JwmNIu68bOO+vJ5fS+b56MORNJ9AO/T+tKN e5pIoUdA2frwqj+/O/pZTpPTvLm+1GjR7/Zp7Dbc4hzqkxmqBRDFsyooBP9ijKzm 9odh6xTI+Al3rUaGxs4mpzAqnWEHGU6IkWPRHcJ3eNtAPRdrahjRCffLH3mT98W0 KsW8CreW2dUBwV/Qreio5jWoSApoEm/k2C/GzaNvhXWCzs0oKcLx7gO6T6uwGowD /76Me1KxRygrmntZprWN5iDEs6+PAsF3Cc6CI1MeNj3a3MYxRqLwj+yuGhjatOgu GuLlEila6eHSAAMoHMx0 =w8v0 -----END PGP SIGNATURE-----

May 31, 2011