- wine-devel - winehq.org

Re: [PATCH 1/5] usp10: Resolve BNs and explicit formatting characters to the preceding level in resolveResolved().
by Marvin 18 May '16

18 May '16

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=23083 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1433: Test failed: 0: uJustification incorrect (0) usp10.c:1433: Test failed: 1: uJustification incorrect (0) usp10.c:1433: Test failed: 2: uJustification incorrect (0) usp10.c:1433: Test failed: 3: uJustification incorrect (0) usp10.c:1433: Test failed: 4: uJustification incorrect (0) usp10.c:1433: Test failed: 5: uJustification incorrect (0) usp10.c:1433: Test failed: 6: uJustification incorrect (0) usp10.c:1433: Test failed: 7: uJustification incorrect (0) usp10.c:1433: Test failed: 8: uJustification incorrect (0) usp10.c:1433: Test failed: 9: uJustification incorrect (0) usp10.c:1449: Test failed: 3: uJustification incorrect (0) usp10.c:1449: Test failed: 5: fDiacritic incorrect (1) usp10.c:1449: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1449: Test failed: 15: fDiacritic incorrect (1) usp10.c:1449: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1433: Test failed: 0: uJustification incorrect (0) usp10.c:1433: Test failed: 1: uJustification incorrect (0) usp10.c:1433: Test failed: 2: uJustification incorrect (0) usp10.c:1433: Test failed: 3: uJustification incorrect (0) usp10.c:1433: Test failed: 4: uJustification incorrect (0) usp10.c:1433: Test failed: 5: uJustification incorrect (0) usp10.c:1433: Test failed: 6: uJustification incorrect (0) usp10.c:1433: Test failed: 7: uJustification incorrect (0) usp10.c:1433: Test failed: 8: uJustification incorrect (0) usp10.c:1433: Test failed: 9: uJustification incorrect (0) usp10.c:1449: Test failed: 3: uJustification incorrect (0) usp10.c:1449: Test failed: 5: fDiacritic incorrect (1) usp10.c:1449: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1449: Test failed: 15: fDiacritic incorrect (1) usp10.c:1449: Test failed: 15: fZeroWidth incorrect (1)

2 1

Re: [PATCH 3/6] wininet: Use compose_request_url in INTERNET_OPTION_URL implementation.
by Marvin 18 May '16

18 May '16

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=23082 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] msvcr120/tests: Add critical section test.(resend)
by Piotr Caban 18 May '16

18 May '16

Hi, On 05/18/16 15:25, YongHao Hu wrote: > +#if _MSVCR_VER >= 110 _MSVCR_VER is not defined in tests. (I didn't look on rest of the patch yet) Thanks, Piotr

1 0

Re: [PATCH] msvcr120/tests: Add critical section test.(resend)
by Marvin 18 May '16

18 May '16

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=23080 Your paranoid android. === w2008s64 (64 bit msvcr120) === Found no trace of the test summary line or of a crash

1 0

Re: [PATCH] user32/scroll: Move GetDCEx to stop DC leak
by Alexandre Julliard 18 May '16

18 May '16

Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> writes: > @@ -920,9 +919,12 @@ static void SCROLL_HandleScrollEvent( HWND hwnd, INT nBar, UINT msg, POINT pt) > break; > > default: > + WARN("unsupported msg %s\n", SPY_GetMsgName(msg,hwnd)); > return; /* Should never happen */ > } > > + hdc = GetDCEx( hwnd, 0, DCX_CACHE | ((nBar == SB_CTL) ? 0 : DCX_WINDOW)); The function is only called for the messages it supports, so there's no need to add handling for other cases. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ddraw/tests: Fix a typo in an ok() call
by Marvin 18 May '16

18 May '16

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=23075 Your paranoid android. === w864 (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 === 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

1 0

Re: [PATCH] oleaut32 todo: formatting 0 with "000#"
by Marvin 18 May '16

18 May '16

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=23070 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] msxml3/tests: Simplify refcount checks
by Marvin 17 May '16

17 May '16

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=23060 Your paranoid android. === w1064 (32 bit httpreq) === httpreq.c:1628: Test failed: got 0x80070057, expected 0x00000000 === w1064 (64 bit httpreq) === httpreq.c:1628: Test failed: got 0x80070057, expected 0x00000000

1 0

Re: [PATCH v2 3/6] ddraw: Forbid creating flippable cubemaps.
by Henri Verbeet 17 May '16

17 May '16

On 13 May 2016 at 13:55, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + if (desc->ddsCaps.dwCaps2 & DDSCAPS2_CUBEMAP) > + { > + WARN("Tried to create a flippable cubemap.\n"); > + HeapFree(GetProcessHeap(), 0, texture); > + return DDERR_INVALIDPARAMS; > + } > + > if (desc->ddsCaps.dwCaps & DDSCAPS_TEXTURE) > { > FIXME("Flippable textures not implemented.\n"); > @@ -5748,6 +5755,8 @@ HRESULT ddraw_surface_create(struct ddraw *ddraw, const DDSURFACEDESC2 *surface_ > { > WARN("Tried to specify a back buffer count for a non-flippable surface.\n"); > HeapFree(GetProcessHeap(), 0, texture); > + if (desc->ddsCaps.dwCaps2 & DDSCAPS2_CUBEMAP) > + return DDERR_INVALIDPARAMS; > return DDERR_INVALIDCAPS; > } I suppose it ends up being more or less the same thing, but to me this looks like DDSD_BACKBUFFERCOUNT being disallowed for cubemaps rather than DDSCAPS_FLIP.

1 0

Re: [PATCH] kernel32/nls: Added SSHORTESTDAYNAME* entries
by Henri Verbeet 17 May '16

17 May '16

> diff --git a/dlls/kernel32/nls/urd.nls b/dlls/kernel32/nls/urd.nls > index 65b57f7..9ce5689 100644 > --- a/dlls/kernel32/nls/urd.nls > +++ b/dlls/kernel32/nls/urd.nls > @@ -134,6 +134,13 @@ STRINGTABLE LANGUAGE LANG_URDU, SUBLANG_URDU_PAKISTAN > LOCALE_SPOSITIVESIGN "" > LOCALE_SSCRIPTS "Arab;" > LOCALE_SSHORTDATE "dd/MM/yyyy" > + LOCALE_SSHORTESTDAYNAME1 "پ" > + LOCALE_SSHORTESTDAYNAME2 "م" > + LOCALE_SSHORTESTDAYNAME3 "ب" > + LOCALE_SSHORTESTDAYNAME4 "ج" > + LOCALE_SSHORTESTDAYNAME5 "ج" I'm no expert on Urdu, but it seems suspicious to have the same abbreviation for two different days.

2 1

Re: [PATCH 2/2] include: Use inline functions for common RECT helpers.
by Alexandre Julliard 17 May '16

17 May '16

Michael Stefaniuc <mstefani(a)redhat.de> writes: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/user32/tests/uitools.c | 1 + > dlls/user32/uitools.c | 1 + > include/winuser.h | 38 +++++++++++++++++++++++++++++++++++--- > 3 files changed, 37 insertions(+), 3 deletions(-) Not really your fault, but this is causing some warnings here: gcc -m32 -c -o device.o device.c -I. -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer -Werror -g -O2 -fno-diagnostics-show-caret device.c: In function ‘device_clear_render_targets’: device.c:393:9: error: ‘ds_rect.bottom’ may be used uninitialized in this function [-Werror=maybe-uninitialized] device.c:393:9: error: ‘ds_rect.right’ may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1: all warnings being treated as errors make: *** [device.o] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 1

Re: [PATCH] winex11: Send SC_KEYMENU on managed windows.
by Marvin 17 May '16

17 May '16

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=23042 Your paranoid android. === wvistau64 (32 bit msg) === msg.c:11039: Test failed: expected PeekMessage to return FALSE, got 1 === w864 (32 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different === w1064 (32 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:7440: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a === w1064 (64 bit msg) === msg.c:6484: Test failed: Update region shouldn't be empty msg.c:6718: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6720: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:6490: Test failed: Regions are different msg.c:7440: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH 11/11] wininet: Added test of cookies with long URL.
by Marvin 16 May '16

16 May '16

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=23039 Your paranoid android. === w1064 (32 bit internet) === internet.c:1092: Test failed: expected ret == 0, got 87 === w1064 (64 bit internet) === internet.c:1092: Test failed: expected ret == 0, got 87

1 0

Re: [PATCH 02/11] wininet: Fixed handing NULL buffer in InternetReadFileExW.
by Marvin 16 May '16

16 May '16

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=23038 Your paranoid android. === w864 (64 bit http) === http.c:5241: Test failed: HttpSendRequest failed: 8

1 0

Re: [PATCH 01/11] wininet: Fixed internet tests on win10.
by Marvin 16 May '16

16 May '16

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=23037 Your paranoid android. === w1064 (32 bit internet) === internet.c:1074: Test failed: expected ret == 0, got 87 === w1064 (64 bit internet) === internet.c:1074: Test failed: expected ret == 0, got 87

1 0

Re: [PATCH 6/7] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v3)
by Stefan Dösinger 16 May '16

16 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-13 um 22:21 schrieb Aaryaman Vasishta: > static HRESULT WINAPI d3drm_texture1_InitFromFile(IDirect3DRMTexture *iface, const char *filename) > { > - FIXME("iface %p, filename %s stub!\n", iface, debugstr_a(filename)); > + struct d3drm_texture *texture = impl_from_IDirect3DRMTexture(iface); > + D3DRMIMAGE *image; > + HRESULT hr; > > - return E_NOTIMPL; > + TRACE("iface %p, filename %s.\n", iface, debugstr_a(filename)); > + > + if (texture->image) > + { > + /* d3drm intentionally leaks a reference IDirect3DRM if texture is already initialized. */ > + IDirect3DRM_AddRef(texture->d3drm); > + return D3DRMERR_BADOBJECT; > + } > + if (FAILED(hr = d3drm_texture_load(texture, filename, FALSE, &image))) > + return hr; > + > + hr = IDirect3DRMTexture3_InitFromImage(&texture->IDirect3DRMTexture3_iface, image); I think you forgot to remove the extra check here :-) . (https://www.winehq.org/pipermail/wine-devel/2016-May/113212.html) > - IDirect3DRM_AddRef(texture->d3drm); > + if (texture->d3drm) > + IDirect3DRM_AddRef(texture->d3drm); This if check looks like it is an accidental leftover from before you reordered patch 1 too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXOiCxAAoJEN0/YqbEcdMwpSkP/ifqzhJnNWI0ZRqMQa9/rOUg MgbEJEGLC2xFFWwGWHL3biuf+ibZOkmmAPBUznU9+E70ekzegvvRGquc2HTHP0y+ 43PXR5A9TXFoOEDvkIiYF6KGiTyEoC2K3N3KzMabm5Iz8ReDLqvF4MmwlggTBsWQ RS1hbDgP4KKSGRECJFKmI3F0WJk52T2TtPjVXmHrYLYgSKQ8QmCj0BSCGBLFlqWF uQtH6sM/dI4w6LiqjG83JAlt7VmKZ5hrWJIY7IakF7vZLIOwni4x9+CJyh9b6dc6 gAY27wojqiBtk7x8weQXG2o3kToCL0+dpHTcLNKuJy80tPZa5QVTmXNF5B+Eqtjf 7u3ZWOOEKGdVKKDaztnoEtxlXHfZDn4ST+2pdUhbOW9X5gcxxSQWyour9FnD/fGj i/OkgvM4gszu1RwcZlpbUY8CkyboOJyziVSUxt7cnW2gHDXY0FwhQMvfpHoPSxiq +UmsuTFwopoJzK30kh4kwmJSkBGtackb2nA0i34tb69ixIAfQy55cqYTgozEzclh +2T/wa5q2DhOlHBScjPlUu46j3AqI8B0mtfrLuURB2UWzxKOZpZYtVsTLErVSFqT 745Z+bPbYWGETBJYx+BVxFE4bpGpwqJTI5IH/jITDv4qmNxoLgHKeYnxU9dwayhx PcvR3vpmTKw/C2N84u+n =3f/e -----END PGP SIGNATURE-----

2 1

Re: [PATCH 4/7] d3drm: Implement IDirect3DRM*_CreateTexture. (v6)
by Stefan Dösinger 16 May '16

16 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-13 um 22:21 schrieb Aaryaman Vasishta: > - *texture = &object->IDirect3DRMTexture3_iface; > + if (FAILED(IDirect3DRMTexture3_InitFromImage(*texture, image))) > + { > + IDirect3DRMTexture3_Release(*texture); > + return D3DRMERR_BADVALUE; > + } This will leave a non-NULL pointer stored in *texture, which is most likely wrong. Please extend your tests to check for this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXOgmWAAoJEN0/YqbEcdMw4PQP/1Ri28V/xXTb90aSLvHLi3QQ 47cGk1M2C9/z3bj9kZUKfYGADCJVgdf52bcFQUb4yBBEkxtY2RrAYMAY2218l0PB QcNpkFhVEnauRII4CsoLShByEtKLfLo6sqflABUKoBfK9BELjz4QpDEUiMvyKHXk vRtesZBK16VaFnwbpQekFb233/sID9oCLitNzIXJ6ntNLEvGYCgfWmaT9VdXNGvv zvnQfWh8ayXbJGulUclNectDqA2ww+vRxHmC5dkgAVGHsfxOp1dY3Z45b6CNPksE iyxn6A3mAVgy6hhjbm8AjgN/8agkvwDRhL2774ZdemBCL1FAq39kFobSNju4evAx YH6r8bFiN1y3814hxMe74Zk2oXJsCN4ZL5ZxOOabJHdWHCxTDWU8yikordtlfdF2 q1Va/GVi9aKLXiWhfNjusP5bG/DY8hK14dRe570eWP2U9fKbDaFLc8iVhwxZRs0N 3EJddB286uvLjAGEbGEe5iSPTuTKCER0L/8rRTliczYt5rJeX+2955bTZu3ek5Uu XjmOzBP5374IiBDai1dhHX2EwTD3UxisN2olDUfFGee8DkDjzowKt5hFBYVT7x8j hDU7rkRKht2loO7vKEqX+uM9twplIWVIIcQWY2ZXT7gZ8x07bCqVa8eHhKy63cGp J1YMc8wPUUENq+iVYZ1W =sm0l -----END PGP SIGNATURE-----

2 1

Re: [PATCH 1/7] d3drm: Use CreateObject in IDirect3DRM*::LoadTexture.
by Stefan Dösinger 16 May '16

16 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 2016-05-13 um 22:21 schrieb Aaryaman Vasishta: > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM_CreateObject(iface, &CLSID_CDirect3DRMTexture, NULL, &IID_IDirect3DRMTexture, (void **)texture))) This line is fairly long and could profit from a line break IMHO. > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (FAILED(hr = IDirect3DRM2_CreateObject(iface, &CLSID_CDirect3DRMTexture, NULL, &IID_IDirect3DRMTexture2, (void **)texture))) I think here you could already put the 2 -> 3 thunk from patch 7. It's a minor issue though. Overall I'd say wait if Henri has any other comments before resending. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXOh4hAAoJEN0/YqbEcdMwjeMP+wRn3MLnrgMlB85ZfafutK3g wml22BVCwzHvHjbPKFhqbrPUIjS4z/PcZ133djjS6dysL2sBfMK4zxKKqVDRp+0V RRphWDVQehg6dpfaSBEWcEqLvy5eUXbQlGQ9eWGT40++OVZQ/C5rmIDmPt1/pX/H f2vnjCIKhGaiDS7M29fnakQckr3sjGuQAJXJuAJqyUHyPo4Edu340UJQweLCOIXX kDXTAJM0ep17xln5FD8RDjukRc1SRg3P+/PzM1PsED0St/talBFdN16DnfNwzOWO XbE+wlTQnMxeu2ycY5gyTdFxWUq/lqCYL6Z0KYTwBUHIqryz0K2XPnb1fGZUTuKk B+XsxtOJYkcvJEoStUuEQSwsTEGipuOStj+fSFEoYnOHBqZWl6midQGWrU6Xyd39 TlOFMew6IldjQBgbfEbu9dSGr3xPi4jD5dPfThdTZFTMOmD++K2APKGmhVmc5bon QOJ+M6uJJQvnyCqnik63uNQcX5UlBf5Guq1op2K6Zbm3V1neipVBQj8+8mUr7weV HQDccTIyzErBJuEdSDoCuw4womh+UGcFbusWpRjP5lRaa57X9poZO58Ofw61f/HZ Tqm9bbnuVjwk4hLa8z5wVbd2bQAytkK0ISFP9bnmGIVk8SZIwuU471pqunF6UMsF Yl/jFc8sJKIeRAe+bGq2 =LMsi -----END PGP SIGNATURE-----

1 0

Re: [PATCH] qedit: Don't require SampleGrabber to be playing to call callback
by Marvin 16 May '16

16 May '16

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=23019 Your paranoid android. === w2008s64 (32 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 00401A5F === w2008s64 (64 bit mediadet) === mediadet.c:148: Test failed: CoCreateInstance failed: 80040154 mediadet: unhandled exception c0000005 at 0000000000401995

2 1

Re: kernel32/tests: Fix a typo in comment
by Marvin 16 May '16

16 May '16

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=23020 Your paranoid android. === w864 (64 bit process) === process.c:1192: Test failed: expected 1, got 0 process.c:1195: Test failed: Child process termination process.c:1199: Test failed: Toolhelp:cntUsage expected 0, but got 1 process.c:1200: Test failed: Toolhelp:th32DefaultHeapID expected 0, but got 1 process.c:1201: Test failed: Toolhelp:th32ModuleID expected 0, but got 1 process.c:1202: Test failed: Toolhelp:th32ParentProcessID expected 280, but got 0 process.c:1204: Test failed: Toolhelp:dwFlags expected 0, but got 1

1 0

Rebased command stream patches
by Stefan Dösinger 15 May '16

15 May '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, In the past weeks I have rebased my command stream patches on top of Henri's recent texture restructuring work. They can be found as usual on https://github.com/stefand/wine/ (git repo URL is https://github.com/stefand/wine.git). They are essentially the same state as the last ones, just rebased, and thus the surface and volume handling code is quite a bit changed. The new patches do a better, but not perfect, job at keeping the tests working during the rework. The tests pass with CSMT enabled, except for a d3d10/11 test. I will hopefully investigate this in the next days and push an updated version. Performance seems to be generally unchanged. That's a good sign I guess. I tested a number of games, but I am sure there are some regressions compared to the last CSMT version. I probably will not do another rebase of this magnitude. Keeping up with the ongoing d3d work requires a lot of time, and I'd rather spend the time I have available for hacking on Wine on smaller tasks that I have a better chance of completing and upstreaming. Though if you run into problems I am interested in getting feedback. I just don't promise that I'll reply or fix anything :-) . Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXOMITAAoJEN0/YqbEcdMwmfwP/j0VXX+0YnFsZCG/u7Bt5Dth LLpbYrUeWcGnS9ddHppdb9VkU0sbrqnXo6j/PA/tXMdli2CFHsC8/DFoPi/A4dKE 5kLDagUE6CPsFOxjmCXdgvdb7yqK2EToz/0sBGJEHXl2tN/B+/yPpIGUfHz5prWb KE1M4w065Wxe39opuV3EkYKk1rFT4wrLUKaH7iBl2rVN4hqvZ4rxS2wFFLFlZk9S E6CR3SDC/HhGZU4ZPpdkMWk3pYi/YDDg1yRESd7PJZNHSVRAo7wgQu4KkQM2aGnG onqmpN6Prw06MKjixSdVF4jcQcPeYiY1dYVB61IslbR9Y7FRSmrxsGnrY51sqTCi pGITgl9loktSbA+hxouMa4xhaz80v6iVvpRkjR1vqnOGZxBRJUC9U9eqRAbdzoZs KhujuEVR74DQ54U5dZbX6+Z682WbPPPqdFMXZrRt0eR3y1TfOhC38Zky3ri7X7/p BleoWUQ4Hut4LK/Td0hhxxkPvfjOGvm6Jm+JPZO4+JnBVZl13WyWat1OOSSOrM2u jcZ7IPkBqeVFu7G1j3YCMoc0hQfa5nPzoHIcbb6DSKythILKSdBZ79KnKzlprvOy pc9EtJFlmSvFi/JiBSJTJuHeUyA9mokmkYtrBsEvh3KBXU/zHtRCLI7qlDpj9yZb +GAQ6tGuZmoUlW0VIwrN =pE16 -----END PGP SIGNATURE-----

1 0

Re: ddraw/tests: A spelling fix for a d3d ok() message.
by Marvin 15 May '16

15 May '16

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=23014 Your paranoid android. === 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

1 0

Re: [PATCH] kernel32: Set C3_KASHIDA only for kashida character
by Marvin 15 May '16

15 May '16

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=23006 Your paranoid android. === w1064 (32 bit locale) === locale.c:2367: Test failed: LCMapStringEx should fail with bad locale name locale.c:2368: Test failed: unexpected error code -559038737 locale.c:2459: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4189: Test failed: IsValidLocaleName should have failed locale.c:4191: Test failed: IsValidLocaleName should have failed locale.c:4556: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4558: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2367: Test failed: LCMapStringEx should fail with bad locale name locale.c:2368: Test failed: unexpected error code -559038737 locale.c:2459: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4189: Test failed: IsValidLocaleName should have failed locale.c:4191: Test failed: IsValidLocaleName should have failed locale.c:4556: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4558: Test failed: For id 7, Expected IVC, got ''

2 1

Re: [PATCH] kernel32: Handle NULL locale name in IsValidLocaleName()
by Austin English 15 May '16

15 May '16

On May 15, 2016 2:30 AM, "Nikolay Sivov" <nsivov(a)codeweavers.com> wrote: > > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/kernel32/locale.c | 3 +++ > dlls/kernel32/tests/locale.c | 2 ++ > 2 files changed, 5 insertions(+) > > diff --git a/dlls/kernel32/locale.c b/dlls/kernel32/locale.c > index a69e76f..636187f 100644 > --- a/dlls/kernel32/locale.c > +++ b/dlls/kernel32/locale.c > @@ -2656,6 +2656,9 @@ BOOL WINAPI IsValidLocaleName( LPCWSTR locale ) > { > struct locale_name locale_name; > > + if (!locale) > + return FALSE; > + > /* string parsing */ > parse_locale_name( locale, &locale_name ); > > diff --git a/dlls/kernel32/tests/locale.c b/dlls/kernel32/tests/locale.c > index 20f52d2..70944a2 100644 > --- a/dlls/kernel32/tests/locale.c > +++ b/dlls/kernel32/tests/locale.c > @@ -4179,6 +4179,8 @@ static void test_IsValidLocaleName(void) > ok(!ret, "IsValidLocaleName should have failed\n"); > ret = pIsValidLocaleName(LOCALE_NAME_INVARIANT); > ok(ret, "IsValidLocaleName failed\n"); > + ret = pIsValidLocaleName(NULL); > + ok(!ret, "IsValidLocaleName should have failed\n"); > } > > static void test_CompareStringOrdinal(void) > -- > 2.8.1 Hi Nikolay, I'm just curious what application this fixes? Or was this something you found while writing tests for something else?

2 1

Re: [PATCH] kernel32: Handle NULL locale name in IsValidLocaleName()
by Marvin 15 May '16

15 May '16

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=23005 Your paranoid android. === w1064 (32 bit locale) === locale.c:2367: Test failed: LCMapStringEx should fail with bad locale name locale.c:2368: Test failed: unexpected error code -559038737 locale.c:2459: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4177: Test failed: IsValidLocaleName should have failed locale.c:4179: Test failed: IsValidLocaleName should have failed locale.c:4546: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4548: Test failed: For id 7, Expected IVC, got '' === w1064 (64 bit locale) === locale.c:2367: Test failed: LCMapStringEx should fail with bad locale name locale.c:2368: Test failed: unexpected error code -559038737 locale.c:2459: Test failed: Expected lcid == 0, got got 00001000, error -559038737 locale.c:4177: Test failed: IsValidLocaleName should have failed locale.c:4179: Test failed: IsValidLocaleName should have failed locale.c:4546: Test failed: For id 7, expected ret == 4, got 1, error 87 locale.c:4548: Test failed: For id 7, Expected IVC, got ''

1 0

Re: [4/5] imm32/tests: Add tests for life cycle of default IME window. (try 2)
by Alexandre Julliard 14 May '16

14 May '16

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 2: > Mark Vista's behaviour as broken and add visible window tests. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/tests/imm32.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 59 insertions(+) It fails here: ../../../tools/runtest -q -P wine -T ../../.. -M imm32.dll -p imm32_test.exe.so imm32 && touch imm32.ok imm32.c:895: Test failed: Expected IME window existence imm32.c:895: Test failed: Expected IME window existence make: *** [imm32.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/5] wininet: Fixed internet tests on win10.
by Marvin 13 May '16

13 May '16

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=22984 Your paranoid android. === wxppro (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w2003std (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === wvistau64 (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w2008s64 (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w7u (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w7pro64 (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w8 (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w864 (32 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === wvistau64 (64 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w2008s64 (64 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w7pro64 (64 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87 === w864 (64 bit internet) === internet.c:1063: Test failed: expected ret == 0, got 234 internet.c:1076: Test failed: expected ret == 0, got 87

2 1

Re: [PATCH 2/5] wininet: Fixed http tests on win10.
by Marvin 13 May '16

13 May '16

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=22983 Your paranoid android. === wxppro (32 bit http) === http.c:1593: Test failed: HttpSendRequest failed: 12029 http.c:1597: Test failed: InternetQueryOptionA(INTERNET_OPTION_DATAFILE_NAME) failed: 12028 http.c:1600: Test failed: InternetLockRequestFile returned: 0(2) http.c:1601: Test failed: lock == NULL http.c:1604: Test failed: InternetLockRequestFile returned: 0(2) http: unhandled exception c0000005 at 3D955BDA

1 0

Re: [PATCH 1/5] wininet: Updated winehq.org cert info.
by Marvin 13 May '16

13 May '16

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=22982 Your paranoid android. === w1064 (32 bit http) === http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1762: Test failed: Expected 2, got 4 http.c:1763: Test failed: Expected CRLF, got ' http.c:2413: Test failed: count was wrong http.c:2414: Test failed: http data wrong, got: Garbage: Header http.c:3077: Test failed: HttpAddRequestHeaders succeeded http.c:3078: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3083: Test failed: code = 200, expected 400 http.c:3083: Test failed: unexpected status code 200, expected 400 http.c:3083: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w1064 (64 bit http) === http.c:6030: http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1762: Test failed: Expected 2, got 4 http.c:1763: Test failed: Expected CRLF, got ' http.c:2413: Test failed: count was wrong http.c:2414: Test failed: http data wrong, got: Garbage: Header http.c:3077: Test failed: HttpAddRequestHeaders succeeded http.c:3078: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3083: Test failed: code = 200, expected 400 http.c:3083: Test failed: unexpected status code 200, expected 400 http.c:3083: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: [PATCH 5/6] d3drm: Partially implement IDirect3DRMTexture*::InitFromFile. (v2 resend)
by Henri Verbeet 13 May '16

13 May '16

On 11 May 2016 at 21:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -47,7 +48,7 @@ static inline struct d3drm_texture *impl_from_IDirect3DRMTexture3(IDirect3DRMTex > void d3drm_texture_destroy(struct d3drm_texture *texture) > { > d3drm_object_cleanup((IDirect3DRMObject*)&texture->IDirect3DRMTexture3_iface, &texture->obj); > - if (texture->image) > + if (texture->image && texture->d3drm) > IDirect3DRM_Release(texture->d3drm); I guess this and the similar change in d3drm_texture3_InitFromImage() are because LoadTexture() still uses d3drm_texture_create(). Is there any reason you can't make the changes to LoadTexture() before this patch? (Or even as the first patch in the series, for that matter?) > +static void CDECL destroy_image_callback(IDirect3DRMObject *obj, void *arg) > +{ > + struct d3drm_texture *texture = arg; > + HeapFree(GetProcessHeap(), 0, texture->image->buffer1); > + HeapFree(GetProcessHeap(), 0, texture->image); > +} I suppose it doesn't matter much, but passing the image would be sufficient. > + if (bpl * h > UINT_MAX) > + { > + hr = D3DRMERR_BADALLOC; > + goto cleanup; > + } Did you test this does what you think it does? > + if (image) > + { > + if (image->buffer1) > + HeapFree(GetProcessHeap(), 0, image->buffer1); > + HeapFree(GetProcessHeap(), 0, image); > + } HeapFree() handles NULL pointers fine. I.e.: if (image) HeapFree(GetProcessHeap(), 0, image->buffer1); HeapFree(GetProcessHeap(), 0, image); > static HRESULT WINAPI d3drm_texture1_InitFromFile(IDirect3DRMTexture *iface, const char *filename) > { > - FIXME("iface %p, filename %s stub!\n", iface, debugstr_a(filename)); > + struct d3drm_texture *texture = impl_from_IDirect3DRMTexture(iface); > + D3DRMIMAGE *image; > + HRESULT hr; > > - return E_NOTIMPL; > + TRACE("iface %p, filename %s.\n", iface, debugstr_a(filename)); > + > + if (texture->image) > + { > + /* d3drm intentionally leaks a reference IDirect3DRM if texture is already initialized. */ > + IDirect3DRM_AddRef(texture->d3drm); > + return D3DRMERR_BADOBJECT; > + } > + if (FAILED(hr = d3drm_texture_load(texture, filename, FALSE, &image))) > + return hr; > + > + hr = IDirect3DRMTexture3_InitFromImage(&texture->IDirect3DRMTexture3_iface, image); > + > + return hr; > } This looks a bit awkward. Why do you need the "if (texture->image)" block? InitFromImage() should leak the d3drm reference fine on its own.

2 4

Re: [PATCH 3/6] d3drm: Implement IDirect3DRM*_CreateTexture. (v5)
by Henri Verbeet 13 May '16

13 May '16

On 11 May 2016 at 21:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > + if (FAILED(hr = IDirect3DRMTexture3_InitFromImage(*texture, image))) > + { > + IDirect3DRMTexture3_Release(*texture); > + return D3DRMERR_BADVALUE; > + } You're not using the value of "hr", so the assignment is redundant.

2 1

Re: [PATCH v2 4/6] ddraw/tests: Test creating flippable cubemaps.
by Marvin 13 May '16

13 May '16

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=22978 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}.

1 0

Re: [PATCH 1/6] d3drm: Introduce d3drm_texture_destroy helper (v3).
by Henri Verbeet 13 May '16

13 May '16

On 11 May 2016 at 21:19, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > +void d3drm_texture_destroy(struct d3drm_texture *texture) This should be static. I.e.: +static void d3drm_texture_destroy(struct d3drm_texture *texture) Adding static prevents the function from being available outside of texture.c. (See also http://port70.net/~nsz/c/c89/c89-draft.html#3.1.2.2 for the details, although "The C Programming Language" by Kernighan & Ritchie makes for better reading.) Applies to d3drm_validate_image() as well.

1 0

Re: mciavi32: Propely handle Heap[Re]Alloc failure (resend)
by Kirill Smirnov 12 May '16

12 May '16

On 12.05.2016 22:39, Andrew Eikum wrote: > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > > Thanks. Just wondering, does this fix an issue in an application, or > you just happened to notice it? > > Andrew Just playing with clang static analyzer, nothing more :-) Unlike other patches in the series of clang-spotted, this one looked a little bit deeper than just "dereference of NULL pointer". That's why I did not stamped it with "spotted by clang" mark. -- Kirill

1 0

[PATCH] Use todo_wine_if() in tests.
by Hugh McMaster 12 May '16

12 May '16

On Thursday, 12 May 2016, 04:55:54 CDT, Jacek Caban wrote: >Commit message should specify the module. > >Other than that: Signed-off-by: Jacek Caban <jacek at codeweavers.com> It's not clear which patch you're signing off on. They both have the same subject line. Hadrien (CC'd) also needs to add a Signed-Off-by line to his patches.

1 0

Re: dbghelp: add EnumerateLoadedModulesEx/EnumerateLoadedModulesExW stubs
by Nikolay Sivov 12 May '16

12 May '16

On 12.05.2016 0:32, Austin English wrote: > For https://bugs.winehq.org/show_bug.cgi?id=40614 > > @ stdcall EnumerateLoadedModules(long ptr ptr) > @ stdcall EnumerateLoadedModules64(long ptr ptr) > -@ stub EnumerateLoadedModulesEx > -@ stub EnumerateLoadedModulesExW > +@ stdcall EnumerateLoadedModulesEx(ptr ptr ptr) > +@ stdcall EnumerateLoadedModulesExW(ptr ptr ptr) For historical reasons first argument is usually made 'long', not that it matters. > +BOOL WINAPI EnumerateLoadedModulesExW(HANDLE process, > + PENUMLOADED_MODULES_CALLBACK64 callback, > + void *context) This prototype is wrong. Are those calls any different from EnumerateLoadedModulesW64/EnumerateLoadedModules64? It looks like we could simply forward to existing calls. Also please update headers.

1 0

Re: [PATCH] Use todo_wine_if() in tests.
by Jacek Caban 12 May '16

12 May '16

Commit message should specify the module. Other than that: Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>

1 0

Re: [PATCH 3/6] d3drm: Implement IDirect3DRM*_CreateTexture. (v4)
by Henri Verbeet 11 May '16

11 May '16

On 11 May 2016 at 16:43, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -1152,15 +1156,21 @@ static HRESULT WINAPI d3drm3_CreateAnimationSet(IDirect3DRM3 *iface, IDirect3DRM > static HRESULT WINAPI d3drm3_CreateTexture(IDirect3DRM3 *iface, > D3DRMIMAGE *image, IDirect3DRMTexture3 **texture) > { > - struct d3drm_texture *object; > HRESULT hr; > > - FIXME("iface %p, image %p, texture %p partial stub.\n", iface, image, texture); > + TRACE("iface %p, image %p, texture %p.\n", iface, image, texture); > > - if (FAILED(hr = d3drm_texture_create(&object))) > + if (!d3drm_validate_image(image)) > + return D3DRMERR_BADVALUE; Why do you need the d3drm_validate_image() call? Purely for the error code?

2 5

Re: [PATCH 2/6] d3drm: Implement IDirect3DRMTexture{2-3}_InitFromImage. (v4)
by Henri Verbeet 11 May '16

11 May '16

On 11 May 2016 at 16:43, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > @@ -46,10 +46,27 @@ static inline struct d3drm_texture *impl_from_IDirect3DRMTexture3(IDirect3DRMTex > > void d3drm_texture_destroy(struct d3drm_texture *texture) > { > + if (texture->image) > + IDirect3DRM_Release(texture->d3drm); > d3drm_object_cleanup((IDirect3DRMObject*)&texture->IDirect3DRMTexture3_iface, &texture->obj); It's somewhat hypothetical, but it seems safer to release the IDirect3DRM interface after the d3drm_object_cleanup() call, in case there are callbacks that (implicitly) depend on the Direct3DRM object still existing. (E.g., is it possible to call IDirect3DRMObject2::GetDirect3DRM() on textures?) > HeapFree(GetProcessHeap(), 0, texture); > } > > +BOOL d3drm_validate_image(D3DRMIMAGE *image) > +{ > + if (!image > + || !image->red_mask > + || !image->green_mask > + || !image->blue_mask > + || !image->buffer1 > + || !(image->rgb || (image->palette && image->palette_size))) > + { > + return FALSE; > + } > + > + return TRUE; > +} Like d3drm_texture_destroy(), you're not using this outside texture.c.

2 1

Re: [PATCH 1/6] d3drm: Introduce d3drm_texture_destroy helper (v2).
by Henri Verbeet 11 May '16

11 May '16

On 11 May 2016 at 16:43, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > +void d3drm_texture_destroy(struct d3drm_texture *texture) > +{ > + d3drm_object_cleanup((IDirect3DRMObject*)&texture->IDirect3DRMTexture3_iface, &texture->obj); > + HeapFree(GetProcessHeap(), 0, texture); > +} You're not using d3drm_texture_destroy() outside texture.c, so you don't need the declaration in d3drm_private.h, and this should just be static.

2 1

Re: [PATCH] wined3d: Add missing WINED3DUSAGE flags to debug_d3dusage
by Henri Verbeet 11 May '16

11 May '16

On 11 May 2016 at 08:15, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > --- > dlls/wined3d/utils.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c > index e2e3ec9..69c5b3b 100644 > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -3572,9 +3572,23 @@ const char *debug_d3dusage(DWORD usage) > WINED3DUSAGE_TO_STR(WINED3DUSAGE_NPATCHES); > WINED3DUSAGE_TO_STR(WINED3DUSAGE_DYNAMIC); > WINED3DUSAGE_TO_STR(WINED3DUSAGE_AUTOGENMIPMAP); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_RESTRICTED_CONTENT); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_RESTRICT_SHARED_RESOURCE_DRIVER); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_RESTRICT_SHARED_RESOURCE); > WINED3DUSAGE_TO_STR(WINED3DUSAGE_DMAP); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTAPI); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_LEGACY_CUBEMAP); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_TEXTURE); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_OWNDC); > WINED3DUSAGE_TO_STR(WINED3DUSAGE_STATICDECL); > WINED3DUSAGE_TO_STR(WINED3DUSAGE_OVERLAY); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_LEGACYBUMPMAP); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_FILTER); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_POSTPIXELSHADER_BLENDING); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_SRGBREAD); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_SRGBWRITE); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_VERTEXTEXTURE); > + WINED3DUSAGE_TO_STR(WINED3DUSAGE_QUERY_WRAPANDMIP); > #undef WINED3DUSAGE_TO_STR > if (usage) FIXME("Unrecognized usage flag(s) %#x\n", usage); > That's better, but now buf[] is too small to contain all the flags, and debug_d3dusagequery() is redundant.

1 0

Re: [PATCH] d3d11/test: Test for ID3D11InfoQueue interface
by Henri Verbeet 11 May '16

11 May '16

On 11 May 2016 at 08:15, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > @@ -6795,7 +6802,8 @@ static void test_getdc(void) > START_TEST(d3d11) > { > test_create_device(); > - test_device_interfaces(); > + test_device_interfaces(0); > + test_device_interfaces(D3D11_CREATE_DEVICE_DEBUG); I think it makes more sense to just handle this inside test_device_interfaces(). Note that d3d10 has an equivalent interface.

1 0

Re: [PATCH] Use todo_wine_if() in tests.
by Marvin 11 May '16

11 May '16

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=22950 Your paranoid android. === w8 (32 bit capture) === capture.c:181: Test failed: Position 1015 expected 0 capture.c:231: Test failed: Position 2167 expected 1463 capture.c:262: Test failed: Position 2167 expected 1463 capture.c:324: Test failed: Position 3255 gap 1344 capture.c:348: Test failed: Position 4343 expected 3703 capture.c:373: Test failed: Position 4791 expected 4151 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:262: Test failed: Position 2167 expected 1527 capture.c:324: Test failed: Position 3127 gap 1152 capture.c:328: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:348: Test failed: Position 4215 expected 3575 capture.c:349: Test failed: flags 1 capture.c:373: Test failed: Position 5303 expected 4023 capture.c:374: Test failed: flags 1 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1143 expected 0 capture.c:231: Test failed: Position 2167 expected 1591 capture.c:262: Test failed: Position 2167 expected 1591 capture.c:324: Test failed: Position 4215 gap 2176 capture.c:328: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:348: Test failed: Position 5303 expected 4663 capture.c:349: Test failed: flags 1 capture.c:373: Test failed: Position 6391 expected 5111 capture.c:374: Test failed: flags 1 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1143 expected 0 capture.c:231: Test failed: Position 2167 expected 1591 capture.c:262: Test failed: Position 2167 expected 1591 capture.c:324: Test failed: Position 4215 gap 2176 capture.c:328: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:348: Test failed: Position 5303 expected 4663 capture.c:349: Test failed: flags 1 capture.c:373: Test failed: Position 7287 expected 5111 capture.c:374: Test failed: flags 1

1 0

Re: fusion: Clear all memory for the pathname in test_assembly_name_props_line.
by André Hentschel 10 May '16

10 May '16

Am 08.05.2016 um 22:09 schrieb Gerald Pfeifer: > str is declared WCHAR str[MAX_PATH], so we need to account for > the size of WCHAR when clearing memory. > > Gerald > > Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> > --- > dlls/fusion/tests/asmname.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/fusion/tests/asmname.c b/dlls/fusion/tests/asmname.c > index e415c3a9..8962630 100644 > --- a/dlls/fusion/tests/asmname.c > +++ b/dlls/fusion/tests/asmname.c > @@ -358,7 +358,7 @@ static void test_assembly_name_props_line(IAssemblyName *name, > to_widechar(expect, vals[i].val); > > size = MAX_PATH; > - ZeroMemory(str, MAX_PATH); > + ZeroMemory(str, MAX_PATH*sizeof(WCHAR)); why not sizeof(str)?

1 0

Re: [v2] riched20: Properly clear all of a buffer of type WCHAR. WCHAR.
by Huw Davies 10 May '16

10 May '16

On 10 May 2016, at 12:53, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > > Per Huw's preference (when I offered an alternate approach), this now > properly clears this buffer (which is of type WCHAR, so MAX_BUF_LEN > fell short). > > Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> > --- > dlls/riched20/tests/editor.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/riched20/tests/editor.c b/dlls/riched20/tests/editor.c > index ae9c0a5..3678b95 100644 > --- a/dlls/riched20/tests/editor.c > +++ b/dlls/riched20/tests/editor.c > @@ -3822,7 +3822,7 @@ static void test_EM_SETTEXTEX(void) > getText.flags = GT_DEFAULT; > getText.lpDefaultChar = NULL; > getText.lpUsedDefChar = NULL; > - memset(buf, 0, MAX_BUF_LEN); > + memset(buf, 0, sizeof buf); > SendMessageA(hwndRichEdit, EM_GETTEXTEX, (WPARAM)&getText, (LPARAM)buf); > ok(lstrcmpW(buf, TestItem2) == 0, > "EM_GETTEXTEX results not what was set by EM_SETTEXTEX\n”); I’d prefer "sizeof(buf)", since that’s what’s used further down this function (and in most other places in Wine for that matter). Huw. > @@ -3837,7 +3837,7 @@ static void test_EM_SETTEXTEX(void) > getText.flags = GT_USECRLF; /* <-- asking for CR -> CRLF conversion */ > getText.lpDefaultChar = NULL; > getText.lpUsedDefChar = NULL; > - memset(buf, 0, MAX_BUF_LEN); > + memset(buf, 0, sizeof buf); > SendMessageA(hwndRichEdit, EM_GETTEXTEX, (WPARAM)&getText, (LPARAM)buf); > ok(lstrcmpW(buf, TestItem1) == 0, > "EM_GETTEXTEX results not what was set by EM_SETTEXTEX\n"); > -- > 2.8.1

1 0

Re: [5/5] imm32, user32: Create and destroy the default IME window implicitly. (try 2)
by Aric Stewart 10 May '16

10 May '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> On 5/8/16 6:25 AM, Akihiro Sagawa wrote: > Fix bug 34056. > Try 2: > - Another approach to maintain default IME windows --- no more using hooks. > - Add an internal API to imm32 as thread_data is still there. > - User32 keeps reference counter in TEB block and call the new API > when creating/destroying a window. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 34 ++++++++++++++++++++++++++-------- > dlls/imm32/imm32.spec | 1 + > dlls/imm32/tests/imm32.c | 4 ++-- > dlls/user32/misc.c | 4 +++- > dlls/user32/user_private.h | 2 ++ > dlls/user32/win.c | 40 ++++++++++++++++++++++++++++++++++++++++ > 6 files changed, 74 insertions(+), 11 deletions(-) > > > >

1 0

Re: [4/5] imm32/tests: Add tests for life cycle of default IME window. (try 2)
by Aric Stewart 10 May '16

10 May '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> On 5/8/16 6:25 AM, Akihiro Sagawa wrote: > Try 2: > Mark Vista's behaviour as broken and add visible window tests. > > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/tests/imm32.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 59 insertions(+) > > > >

1 0

Re: [3/5] imm32: Use wine_dbgstr_rect() and wine_dbgstr_point() in traces.
by Aric Stewart 10 May '16

10 May '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> On 5/8/16 6:25 AM, Akihiro Sagawa wrote: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) > > > >

1 0

Re: [2/5] imm32: Avoid null pointer dereference in trace.
by Aric Stewart 10 May '16

10 May '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> On 5/8/16 6:25 AM, Akihiro Sagawa wrote: > Signed-off-by: Akihiro Sagawa <sagawa.aki(a)gmail.com> > --- > dlls/imm32/imm.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > > >

1 0

Re: ddraw/tests: Fix a typo in ok() message (v2)
by Marvin 09 May '16

09 May '16

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=22928 Your paranoid android. === w864 (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 === 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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel