- wine-devel - winehq.org

Re: comctl32: Fix a typo in comment
by Huw Davies 19 May '16

19 May '16

On Thu, May 19, 2016 at 11:42:11AM +0300, Andrey Gusev wrote: > diff --git a/dlls/comctl32/trackbar.c b/dlls/comctl32/trackbar.c > index 8c99ad0..ba4cec3 100644 > --- a/dlls/comctl32/trackbar.c > +++ b/dlls/comctl32/trackbar.c > @@ -920,7 +920,7 @@ TRACKBAR_Refresh (TRACKBAR_INFO *infoPtr, HDC hdcDst) > > GetClientRect (infoPtr->hwndSelf, &rcClient); > > - /* try to render offscreen, if we fail, carrry onscreen */ > + /* try to render offscreen, if we fail, carry onscreen */ > hdc = CreateCompatibleDC(hdcDst); > if (hdc) { > hOffScreenBmp = CreateCompatibleBitmap(hdcDst, rcClient.right, rcClient.bottom); Apart from the fact that this comment still doesn't make sense (it should probably have an additional 'on'), I'm not sure why we have this fallback in the first place. If the dc or bitmap creation fails then we've probably got bigger problems. I'd suggest just returning early in those cases (with the appropriate cleanup). Huw.

1 0

Re: user32: Fix a typo in a comment
by Ken Thomases 18 May '16

18 May '16

On May 18, 2016, at 2:46 PM, Frédéric Delanoy <frederic.delanoy(a)gmail.com> wrote: > > Signed-off-by: Frédéric Delanoy <frederic.delanoy(a)gmail.com> > --- > dlls/user32/combo.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/user32/combo.c b/dlls/user32/combo.c > index c9b969f..143d992 100644 > --- a/dlls/user32/combo.c > +++ b/dlls/user32/combo.c > @@ -416,7 +416,7 @@ static void CBCalcPlacement( > > /* > * In the case of a dropdown, the popup listbox is offset to the right. > - * so, we want to make sure it's flush with the right side of the > + * so, we want to make sure it's flushed with the right side of the > * combobox > */ > if( CB_GETTYPE(lphc) == CBS_DROPDOWN ) The original is actually correct English. "Flush" is an adjective meaning aligned. Cheers, Ken

1 0

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

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