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

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

May 14, 2016

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 May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 May 13, 2016

May 13, 2016

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 May 12, 2016

May 12, 2016

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 May 12, 2016

May 12, 2016

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 May 12, 2016

May 12, 2016

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 May 12, 2016

May 12, 2016

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 May 11, 2016

May 11, 2016

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 May 11, 2016

May 11, 2016

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 May 11, 2016

May 11, 2016

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 May 11, 2016

May 11, 2016

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 May 11, 2016

May 11, 2016

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 May 11, 2016

May 11, 2016

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 May 10, 2016

May 10, 2016

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 May 10, 2016

May 10, 2016

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 May 10, 2016

May 10, 2016

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 May 10, 2016

May 10, 2016

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 May 10, 2016

May 10, 2016

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 May 10, 2016

May 10, 2016

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 May 9, 2016

May 9, 2016

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