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

Re: [PATCH 2/5] ddraw/tests: Rewrite offscreen_test().
by Marvin Feb. 5, 2016

Feb. 5, 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=20224 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 1/5] ddraw/tests: Rewrite yv12_test().
by Marvin Feb. 5, 2016

Feb. 5, 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=20223 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2545: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw2) === ddraw2.c:2360: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw1) === ddraw1.c:2209: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}. === w1064 (32 bit ddraw7) === ddraw7.c:2275: Test failed: Expected {0, 0, 512, 384}, got {0, 0, 1024, 768}.

1 0

Re: [PATCH 1/7] wined3d: Move internal format queries to separate function.
by Henri Verbeet Feb. 5, 2016

Feb. 5, 2016

On 5 February 2016 at 15:08, Józef Kucia <jkucia(a)codeweavers.com> wrote: > adapter->fragment_pipe->get_caps(gl_info, &fragment_caps); > adapter->shader_backend->shader_get_caps(gl_info, &shader_caps); > srgb_write = (fragment_caps.wined3d_caps & WINED3D_FRAGMENT_CAP_SRGB_WRITE) > && (shader_caps.wined3d_caps & WINED3D_SHADER_CAP_SRGB_WRITE); > It seems wasteful to do this for each format.

1 0

Re: [PATCH] usp10: Implement fOverrideDirection
by Marvin Feb. 5, 2016

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

1 0

Re: [2/2] shell32/tests: Fix okShell() so it takes all logging options into account.
by Marvin Feb. 5, 2016

Feb. 5, 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=20213 Your paranoid android. === w1064 (32 bit shlexec) === shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 === w1064 (64 bit shlexec) === shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32 shlexec.c:2443: Test failed: failed: rc=29 err=2 shlexec.c:2441: Test failed: ShlexecVar expected 'Present', but key not found or empty shlexec.c:2443: Test failed: failed: rc=29 err=32

1 0

Re: uxtheme: test and fix CloseThemeData with invalid handle value
by Alexandre Julliard Feb. 5, 2016

Feb. 5, 2016

Piet Jankbal <xerox.xerox2000x(a)gmail.com> writes: > Hi, this fixes https://bugs.winehq.org/show_bug.cgi?id=29862 > > signed off: Louis Lenders Please add a Signed-off-by header in the correct format. Also why are you sending this under a different name? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: Add test MultiByteToWideChar for code page is 936. (try 2)
by Alexandre Julliard Feb. 5, 2016

Feb. 5, 2016

Changhui LIU <chliu027028(a)gmail.com> writes: > + BOOL vistaOrLater = FALSE; > + OSVERSIONINFOA osvi; > + > + memset(&osvi, 0, sizeof(osvi)); > + osvi.dwOSVersionInfoSize = sizeof(osvi); > + GetVersionExA(&osvi); > + vistaOrLater = (osvi.dwMajorVersion > 5); Please don't do version checks in tests. You can mark the old behavior as broken if necessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [v5 PATCH 1/2] gdiplus: Implement GdipSetPenTransform
by Marvin Feb. 5, 2016

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

2 1

Re: [v5 PATCH 2/2] gdiplus: Implement GdipResetPenTransform
by Marvin Feb. 5, 2016

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

1 0

Re: [v5 PATCH 2/2] gdiplus: Implement GdipResetPenTransform
by Marvin Feb. 5, 2016

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

1 0

Re: [v5 PATCH 1/2] gdiplus: Implement GdipSetPenTransform
by Marvin Feb. 5, 2016

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

1 0

Re: [PATCH] dwrite/tests: Remove failing test line, we have skips for this now
by Marvin Feb. 5, 2016

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

1 0

Re: [v4 PATCH 2/3] gdiplus: Implement GdipSetPenTransform
by Vincent Povirk Feb. 4, 2016

Feb. 4, 2016

Why did you remove the TRACE from this function?

1 0

Re: [PATCH 3/6] wined3d: Add support for separate sRGB formats.
by Henri Verbeet Feb. 4, 2016

Feb. 4, 2016

On 4 February 2016 at 01:17, Józef Kucia <jkucia(a)codeweavers.com> wrote: > - factory->wined3d = wined3d_create(0); > + factory->wined3d = wined3d_create(WINED3D_SEPARATE_SRGB_FORMATS); In some ways I like this, although I wonder if it wouldn't make more sense to handle this in terms of a flag to enable support for SRGB_READ/SRGB_WRITE. I.e., when WINED3D_SAMP_SRGB_TEXTURE and WINED3D_RS_SRGBWRITEENABLE are supported, WINED3DFMT_R8G8B8A8_UNORM and WINED3DFMT_R8G8B8A8_UNORM_SRGB would effectively be the same, while when they aren't you'd get the d3d10+ behaviour. > @@ -5993,7 +5994,7 @@ HRESULT wined3d_init(struct wined3d *wined3d, DWORD flags) > return WINED3D_OK; > } > > - if (!wined3d_adapter_init(&wined3d->adapters[0], 0)) > + if (!wined3d_adapter_init(&wined3d->adapters[0], wined3d, 0)) I'm not a huge fan of this, although I could probably live with it. I guess it's mostly to get at wined3d->flags during format initialization, in which case it may be sufficient to just pass the flags to wined3d_adapter_init(). > diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c > index 1904dd1..718aa18 100644 > --- a/dlls/wined3d/utils.c > +++ b/dlls/wined3d/utils.c > @@ -58,8 +58,11 @@ static const struct wined3d_format_channels formats[] = > {WINED3DFMT_DXT4, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_DXT5, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC1_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC1_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC2_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC2_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_BC3_UNORM, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > + {WINED3DFMT_BC3_UNORM_SRGB, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_MULTI2_ARGB8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_G8R8_G8B8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, > {WINED3DFMT_R8G8_B8G8, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0}, One thought I have about this is that we could just store the channel sizes and shifts for the typeless formats, and then have the typed formats copy the information from there, perhaps instead of the format_base_flags[] table we have now. So you'd have something like this: {WINED3DFMT_R8G8B8A8_UNORM, WINED3DFMT_R8G8B8A8_TYPELESS, UNORM, UNORM, UNORM, UNORM} {WINED3DFMT_R8G8B8A8_UNORM_SRGB, WINED3DFMT_R8G8B8A8_TYPELESS, UNORM, UNORM, UNORM, UNORM} {WINED3DFMT_R8G8B8A8_SNORM, WINED3DFMT_R8G8B8A8_TYPELESS, SNORM, SNORM, SNORM, SNORM} {WINED3DFMT_R8G8B8A8_UINT, WINED3DFMT_R8G8B8A8_TYPELESS, UINT, UINT, UINT, UINT} {WINED3DFMT_R8G8B8A8_SINT, WINED3DFMT_R8G8B8A8_TYPELESS, SINT, SINT, SINT, SINT} > @@ -2237,7 +2255,7 @@ static void query_internal_format(struct wined3d_adapter *adapter, > format_clear_flag(format, WINED3DFMT_FLAG_SRGB_WRITE); > > if (!gl_info->supported[ARB_DEPTH_TEXTURE] > - && texture_info->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)) > + && !!texture_info && texture_info->flags & (WINED3DFMT_FLAG_DEPTH | WINED3DFMT_FLAG_STENCIL)) The "!!" before texture_info seems unnecessary. > +static inline BOOL should_use_separate_srgb_gl_texture(const struct wined3d_context *context) That's a fairly long function name. Not that I have a better suggestion though. > +{ > + return !context->gl_info->supported[EXT_TEXTURE_SRGB_DECODE] > + && !(context->swapchain->device->wined3d->flags & WINED3D_SEPARATE_SRGB_FORMATS); > +} The number of pointer dereferences in here is scary. :) (Yeah, I know, there are other places that are just as bad.) Maybe it makes sense to store a copy of the flags in struct d3d_info?

2 1

Re: kernel32: Add test MultiByteToWideChar for code page is 936.
by Alexandre Julliard Feb. 4, 2016

Feb. 4, 2016

Changhui LIU <chliu027028(a)gmail.com> writes: > +static void test_cp936_to_widechar(void) > +{ > + int count = 0; > + int count2 = 0; > + WCHAR wide_buf[4]; > + unsigned char buf[] = {0xbf, 0xb4, 0xc7}; > + > + count = MultiByteToWideChar(936, 0, (char*)&buf[0], sizeof(buf), NULL, 0); > + ok(count > 0, "returned %d (expected > '0')\n", count); > + > + count2 = MultiByteToWideChar(936, 0, (char*)&buf[0], sizeof(buf), wide_buf, count); > + todo_wine ok(count2 > 0, "returned %d (expected > '0')\n", count2); > + > + todo_wine ok(count == count2, "expected twice call result is same\n"); That test could be more strict, I expect that there's a defined behavior, not just > 0. Comparing with the results from MB_ERR_INVALID_CHARS would also be interesting. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: hhctrl.ocx: Store window position in registry so that it's persistent between runs.
by Jacek Caban Feb. 4, 2016

Feb. 4, 2016

On 02/04/16 13:05, Jacek Caban wrote: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/hhctrl.ocx/help.c | 71 > +++++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 68 insertions(+), 3 deletions(-) Please ignore this patch. It's not the right fix. Jacek

1 0

Re: [PATCH] include: Add IColumnsInfo interface (resend)
by Nikolay Sivov Feb. 4, 2016

Feb. 4, 2016

On 04.02.2016 12:31, Alistair Leslie-Hughes wrote: > +[ > + object, > + uuid(0c733a11-2a1c-11ce-ade5-00aa0044773d), > + pointer_default(unique) > +] > +interface IColumnsInfo : IUnknown > +{ > + [local] > + HRESULT GetColumnInfo([in, out] DBORDINAL *columns,[out, size_is(*columns)] DBCOLUMNINFO **colinfo, > + [out] OLECHAR *stringsbuffer); > + > + [call_as(GetColumnInfo)] > + HRESULT RemoteGetColumnInfo([in, out] DBORDINAL *columns, [out, size_is((ULONG)*columns)] DBCOLUMNINFO **col_info, > + [out, size_is((ULONG)*columns)] DBBYTEOFFSET **name_offsets, > + [out, size_is((ULONG)*columns)] DBBYTEOFFSET **columnid_offsets, > + [in, out] DBLENGTH *string_len, [in, out, unique, size_is((ULONG)*string_len)] OLECHAR **stringsbuffer, > + [out] IErrorInfo **error); > + ULONG in SDK comes from DBORDINAL being ULONGLONG vs ULONG depending on bitness, I agree we probably don't have to duplicate that, and can always use cast. In any case size_is attribute is used in a wrong way, and at least one method prototype does not match SDK.

1 0

Re: [PATCH] usp10: Correct math punctuation handling in itemization
by Marvin Feb. 3, 2016

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

2 1

Re: [v3 PATCH 2/3] gdiplus: Implement GdipSetPenTransform
by Vincent Povirk Feb. 3, 2016

Feb. 3, 2016

I think we should keep the FIXME on this one until we use the transform in rendering, maybe change it to semi-stub.

1 0

Re: [PATCH 1/6] d3d11: Implement d3d11_device_CheckMultisampleQualityLevels().
by Henri Verbeet Feb. 3, 2016

Feb. 3, 2016

On 29 January 2016 at 00:51, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > + if (sample_count > 32) > + return E_FAIL; I think that's D3D11_MAX_MULTISAMPLE_SAMPLE_COUNT. > + if (sample_count > 16) > + { > + FIXME("sample_count %u not handled yet.\n", sample_count); > + return S_OK; > + } I think that belongs in wined3d_check_device_multisample_type(). > + hr = wined3d_device_check_multisample_quality_levels(device->wined3d_device, > + wined3dformat_from_dxgi_format(format), sample_count, quality_level_count); > + if (hr == WINED3DERR_INVALIDCALL) > + return E_INVALIDARG; > + if (hr == WINED3DERR_NOTAVAILABLE) > + return S_OK; This is fine, but the d3d10+ API probably makes more sense in the long run. I.e., eventually we'd want to handle the difference in d3d8/9 instead. > +HRESULT CDECL wined3d_device_check_multisample_quality_levels(const struct wined3d_device *device, > + enum wined3d_format_id format_id, enum wined3d_multisample_type multisample_type, > + DWORD *quality_level_count) I don't think we really want to introduce a new entry point for this. I guess the issue is that we can't get at the wined3d object that created the device from inside d3d11, but I think it would be preferable to do something about that instead. It seems likely that CheckFeatureSupport() and CheckFormatSupport() would run into this as well.

2 1

Re: [5/5] webservices: Implement WsWriteStartCData and WsWriteEndCData.
by Marvin Feb. 3, 2016

Feb. 3, 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=20164 Your paranoid android. === build (build) === Make failed

1 0

Re: [PATCH v5] user32: Add MOUSEHOOKSTRUCTEX to improve mouse wheel support
by Alex Henrie Feb. 3, 2016

Feb. 3, 2016

+typedef struct +{ + struct { /* MOUSEHOOKSTRUCT */ + POINT pt; + HWND hwnd; + UINT wHitTestCode; + ULONG_PTR dwExtraInfo; + } DUMMYSTRUCTNAME; + DWORD mouseData; +} MOUSEHOOKSTRUCTEX, *PMOUSEHOOKSTRUCTEX, *LPMOUSEHOOKSTRUCTEX; Other than the excessive indentation in "DWORD mouseData", this patch looks good, and the user32 tests still pass on my machine. -Alex

1 0

Re: [PATCH 6/6] ddraw: Replace wined3d_surface_preload() with wined3d_texture_preload().
by Henri Verbeet Feb. 1, 2016

Feb. 1, 2016

On 31 January 2016 at 11:22, Riccardo Bortolato <rikyz619(a)gmail.com> wrote: > Also removed wined3d_surface_preload as it's now unused > > Signed-off-by: Riccardo Bortolato <rikyz619(a)gmail.com> > --- > dlls/ddraw/device.c | 2 +- > dlls/wined3d/surface.c | 13 ------------- > dlls/wined3d/wined3d.spec | 1 - > include/wine/wined3d.h | 1 - > 4 files changed, 1 insertion(+), 16 deletions(-) > You may have noticed that I started working on this myself instead, and this patch is practically a duplicate of 118671.

2 3

Re: [PATCH 5/5] dwrite: Remove some redundant includes
by Marvin Feb. 1, 2016

Feb. 1, 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=20128 Your paranoid android. === wvistau64 (32 bit layout) === Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)

1 0

Re: [v3] msvcrt: handle of thread created by _beginthread should not be closed on thread detach.
by Piotr Caban Feb. 1, 2016

Feb. 1, 2016

Hi, On 02/01/16 12:00, Paul Gofman wrote: > + /* _beginthreadex: handle is not closed on _endthread */ > + hThread = (HANDLE)_beginthreadex(NULL,0, test_thread_func_ex, NULL, 0, NULL); > + ok(hThread != INVALID_HANDLE_VALUE, "_beginthreadex failed (%d)\n", errno); _beginthreadex returns 0 in case of error (not INVALID_HANDLE_VALUE). Except of it the patch looks good for me. Thanks, Piotr

1 0

Re: [v2] msvcrt: handle of thread created by _beginthread should not be closed on thread detach.
by Piotr Caban Feb. 1, 2016

Feb. 1, 2016

Hi Paul, On 01/31/16 22:58, Paul Gofman wrote: > + /* _beginthread: handle is not closed on ExitProcess and _endthreadex */ > + hThread = (HANDLE)_beginthread(test_thread_func, 0, (void*)0); > + Sleep(150); > + ret = WaitForSingleObject(hThread, INFINITE); > + ok(ret == WAIT_FAILED, "ret = %d\n", ret); This test may fail if for some reason thread has not finished during 150ms sleep. You can workaround this issue following way: hThread = (HANDLE)_beginthread(test_thread_func, 0, (void*)0); ok(hThread != INVALID_HANDLE_VALUE, "_beginthread failed (%d)\n", errno); WaitForSingleObject(hThread, INFINITE); ret = CloseHandle(hThread); ok(!ret, "ret = %d\n", ret); > @@ -69,6 +69,9 @@ static DWORD CALLBACK _beginthread_trampoline(LPVOID arg) > MSVCRT_free(arg); > > local_trampoline.start_address(local_trampoline.arglist); > + > + CloseHandle(data->handle); > + data->handle = NULL; According to MSDN _endthread should be called here. Because it's documented I think we should implement it in similar way. > @@ -136,8 +139,18 @@ MSVCRT_uintptr_t CDECL _beginthreadex( > */ > void CDECL _endthread(void) > { > + thread_data_t *tls; > + > TRACE("(void)\n"); > > + tls = TlsGetValue(msvcrt_tls_index); > + if (tls && tls->handle) You should check for INVALID_HANDLE_VALUE instead of NULL here. It's doesn't really matter but for sake of consistency tls->handle should be set to INVALID_HANDLE_VALUE after close. Thanks, Piotr

2 1

Re: [PATCH] server: Implement serial port read interval timeouts.
by Alexandre Julliard Feb. 1, 2016

Feb. 1, 2016

Alex Henrie <alexhenrie24(a)gmail.com> writes: > Fixes https://bugs.winehq.org/show_bug.cgi?id=39875 > > There is a test program attached to the bug report. > > Version 3 has all the logic in serial.c, even though this required > adding a getter in async.c and another getter in fd.c. The first > interval timeout no longer trashes subsequent interval timeouts or > the total timeout, and absolute timeouts are used exclusively. You should be able to do this without adding all the extra getter functions. I'd suggest something along these lines (completely untested): diff --git a/server/serial.c b/server/serial.c index 164a4b1fe717..04b517dd347e 100644 --- a/server/serial.c +++ b/server/serial.c @@ -62,12 +62,15 @@ static void serial_destroy(struct object *obj); static enum server_fd_type serial_get_fd_type( struct fd *fd ); static void serial_queue_async( struct fd *fd, const async_data_t *data, int type, int count ); +static void serial_reselect_async( struct fd *fd, struct async_queue *queue ); struct serial { struct object obj; struct fd *fd; + struct timeout_user *read_timer; + /* timeout values */ unsigned int readinterval; unsigned int readconst; @@ -115,7 +118,7 @@ static const struct fd_ops serial_fd_ops = no_fd_flush, /* flush */ default_fd_ioctl, /* ioctl */ serial_queue_async, /* queue_async */ - default_fd_reselect_async, /* reselect_async */ + serial_reselect_async, /* reselect_async */ default_fd_cancel_async /* cancel_async */ }; @@ -134,6 +137,7 @@ struct object *create_serial( struct fd *fd ) if (!(serial = alloc_object( &serial_ops ))) return NULL; + serial->read_timer = NULL; serial->readinterval = 0; serial->readmult = 0; serial->readconst = 0; @@ -157,6 +161,7 @@ static struct fd *serial_get_fd( struct object *obj ) static void serial_destroy( struct object *obj) { struct serial *serial = (struct serial *)obj; + if (serial->read_timer) remove_timeout_user( serial->read_timer ); release_object( serial->fd ); } @@ -203,6 +208,34 @@ static void serial_queue_async( struct fd *fd, const async_data_t *data, int typ } } +static void serial_read_timeout( void *arg ) +{ + struct serial *serial = arg; + + serial->read_timer = NULL; + fd_async_wake_up( serial->fd, ASYNC_TYPE_READ, STATUS_TIMEOUT ); +} + +static void serial_reselect_async( struct fd *fd, struct async_queue *queue ) +{ + struct serial *serial = get_fd_user( fd ); + + if (serial->read_timer) + { + if (!(default_fd_get_poll_events( fd ) & POLLIN)) + { + remove_timeout_user( serial->read_timer ); + serial->read_timer = NULL; + } + } + else if (!serial->read_timer && serial->readinterval && (default_fd_get_poll_events( fd ) & POLLIN)) + { + serial->read_timer = add_timeout_user( (timeout_t)serial->readinterval * -10000, + serial_read_timeout, serial ); + } + default_fd_reselect_async( fd, queue ); +} + DECL_HANDLER(get_serial_info) { struct serial *serial; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/3] user32: A window may be notified with WM_CAPTURECHANGED about itself gaining mouse capture if SetCapture() i
by Marvin Feb. 1, 2016

Feb. 1, 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=20123 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different === w1064 (64 bit msg) === msg.c:7246: Test failed: destroy child on thread exit: 3: the msg sequence is not complete: expected 0000 - actual 001a

1 0

Re: [PATCH] user32: Allow WM_CAPTURECHANGED indicating SetCapture() parameter
by Ken Thomases Feb. 1, 2016

Feb. 1, 2016

On Jan 31, 2016, at 7:18 PM, Christopher Thielen <cthielen(a)gmail.com> wrote: > > A window may be notified with WM_CAPTURECHANGED about itself > gaining mouse capture if it calls SetCapture() twice. > > Tested on Windows XP and Fedora Workstation 22. > > Revised to simplify based on wine-devel feedback. > Revised to address any side-effects of new WM_CAPTURECHANGED > messages. The changes to comctl32 should be in a separate patch. In general, changes to different DLLs should be in separate patches unless it can't be avoided. The comctl32 patch should come before the change to when WM_CAPTURECHANGED is sent so that things aren't broken part-way through the patch series. You might also put the button.c changes in a separate patch, too. > case WM_CAPTURECHANGED: > - return TOOLBAR_CaptureChanged(infoPtr); > + if(hwnd != lParam) > + { > + return TOOLBAR_CaptureChanged(infoPtr); > + } > + else > + { > + return 0; > + } The second return can be hoisted out of the else since the true branch can't fall through. Also, you can reverse the logic, so the code can look like: case WM_CAPTURECHANGED: if(hwnd == lParam) return 0; return TOOLBAR_CaptureChanged(infoPtr); I think that's clearer and also a smaller diff. Same for the other files. Cheers, Ken

2 1

Re: [PATCH] user32: Allow WM_CAPTURECHANGED indicating SetCapture() parameter
by Marvin Feb. 1, 2016

Feb. 1, 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=20122 Your paranoid android. === w1064 (32 bit msg) === msg.c:6290: Test failed: Update region shouldn't be empty msg.c:6524: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6526: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different msg.c:6296: Test failed: Regions are different

1 0