November 2015 - Wine-devel - list.winehq.org

Re: shell32: Improved IDataObject::QueryGetData implementation
by Marvin 24 Nov '15

24 Nov '15

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=18490 Your paranoid android. === w1064 (32 bit shlfolder) === shlfolder.c:1578: Test failed: IShellFolder_GetDisplayNameOf(NULL) failed! hr = 80070057

2 1

Re: [PATCH] add test on host value of InternetConnectW
by Marvin 24 Nov '15

24 Nov '15

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=18485 Your paranoid android. === w2003std (32 bit http) === http.c:5896: Test failed: HttpQueryInfoA failed 12019 http.c:5897: Test failed: header missing === w1064 (32 bit http) === http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 http.c:1773: Test failed: Expected 2, got 4 http.c:1774: Test failed: Expected CRLF, got ' http.c:2408: Test failed: count was wrong http.c:2409: Test failed: http data wrong, got: Garbage: Header http.c:3072: Test failed: HttpAddRequestHeaders succeeded http.c:3073: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: code = 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:3078: Test failed: unexpected status code 200, expected 400 http.c:534: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

1 0

Re: [PATCH] add test on host value of InternetConnectW
by Nikolay Sivov 24 Nov '15

24 Nov '15

On 24.11.2015 16:02, Hao Peng wrote: > Add a test on giving host value of InternetConnectionW. > > Some App fill host param with port number when calling InternetConnectionW. it will still operate successfull on system brove windows 2000. > > I tested to connect to [www.winehq.org] but I got GetLastError with 2 on WinXP and Win2003, other systems were fine. > (See https://testbot.winehq.org/JobDetails.pl?Key=18484) > All fine when I tested to connecting to [www.bing.com] > (https://testbot.winehq.org/JobDetails.pl?Key=18482) > And I didn't get what happened. > > I plan to send a patch to fix this later. > > Any comments are welcome. > > Signed-off-by: Hao Peng <penghao(a)linuxdeepin.com> > --- > dlls/wininet/tests/http.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > + connect = InternetConnectA(session, "www.bing.com:21", INTERNET_DEFAULT_HTTPS_PORT, NULL, NULL, > + INTERNET_SERVICE_HTTP, 0, 0); > + ok(connect != NULL, "InternetConnect failed\n"); I think we prefer winehq.org as test url domain. > + SetLastError(0xdeadbeef); > + ret = HttpSendRequestA(request, NULL, 0, NULL, 0); > + error = GetLastError(); > + ok(ret || broken(!ret /* win2000 */), "HttpSendRequest failed\n"); > + ok(error == 0 || broken(error == ERROR_INTERNET_NAME_NOT_RESOLVED /* win2000 */), "got %u\n", error); Windows 2000 is not in a base set of tested versions anymore, you can probably drop special handling for it. > I plan to send a patch to fix this later. What this patch will fix? I don't see any todos or other ways to skip in your test patch.

1 0

Re: [PATCH 1/6 v2] msxml3/tests: Run IXMLDOMNode::get_text whitespace tests on other msxml versions
by Nikolay Sivov 24 Nov '15

24 Nov '15

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>

1 0

Re: [2/4] comctl32: Accept touchscreen-related messages in monthcal test.
by Nikolay Sivov 24 Nov '15

24 Nov '15

Maybe it's better to filter them? If they are sent internally by default procedure it's not an appropriate place to test for them, and as long as we only want to fix comctl32 tests I think it's easier to filter. And please add a comment directly in test code about system configuration it applies to.

1 0

Re: [1/4] comctl32: Accept touchscreen-related messages in button test.
by Nikolay Sivov 24 Nov '15

24 Nov '15

BM_GETSTATE doesn't use message parameters, so I don't think it makes sense to test them. Otherwise it's fine, if it fixes real failures.

1 0

Re: [PATCH 1/2] d3d11: Make blend_factor optional in d3d11_immediate_context_OMSetBlendState(). (try 2)
by Henri Verbeet 24 Nov '15

24 Nov '15

On 23 November 2015 at 11:14, Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> wrote: > static void STDMETHODCALLTYPE d3d11_immediate_context_OMSetBlendState(ID3D11DeviceContext *iface, > - ID3D11BlendState *blend_state, const FLOAT blend_factor[4], UINT sample_mask) > + ID3D11BlendState *blend_state, const FLOAT arg_blend_factor[4], UINT sample_mask) > { > struct d3d_device *device = device_from_immediate_ID3D11DeviceContext(iface); > + static const FLOAT default_blend_factor[4] = {1.0f, 1.0f, 1.0f, 1.0f}; Please just use "float". (Yeah, there are a couple of other places in d3d11 that use "FLOAT", but it's silly.) > + const FLOAT *blend_factor; ... > + blend_factor = arg_blend_factor ? arg_blend_factor : default_blend_factor; You don't need this. You can just do: if (!blend_factor) blend_factor = default_blend_factor;

1 0

Re: d3d8: Accept CURSOR_SUPPRESSED as cursor flags.
by Henri Verbeet 24 Nov '15

24 Nov '15

Please send patches inline. (I.e., use git send-email.) On 23 November 2015 at 22:36, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Subject: [PATCH] d3d8: Accept CURSOR_SUPPRESSED as cursor flags. This is not wrong, but please use "d3d8/tests: " as prefix if you're not touching the dll itself. > - ok(info.flags & CURSOR_SHOWING, "The gdi cursor is hidden (%08x)\n", info.flags); > + ok((info.flags & CURSOR_SHOWING) != 0 || info.flags == CURSOR_SUPPRESSED, > + "The gdi cursor is hidden (%08x)\n", info.flags); Why introduce the redundant comparison with 0? Anyway, the test should probably be something like "ok(info.flags & (CURSOR_SHOWING | CURSOR_SUPPRESSED), ...);" or perhaps just "ok(info.flags, ...);". The test is really just about showing that the cursor isn't hidden, and not so much about the exact combination of flags. Line continuations should use double indentation. There's an equivalent test for d3d9 in dlls/d3d9/tests/device.c, I'd expect that to have the same issue.

1 0

Re: [PATCH] user32: Allow WM_CAPTURECHANGE indicating SetCapture() parameter.
by Marvin 23 Nov '15

23 Nov '15

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=18463 Your paranoid android. === w1064 (32 bit msg) === msg.c:6094: Test failed: Update region shouldn't be empty msg.c:6328: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6330: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6100: Test failed: Regions are different msg.c:6100: Test failed: Regions are different msg.c:6100: Test failed: Regions are different

1 0

gcc doesn't love us anymore
by Daniel Santos 23 Nov '15

23 Nov '15

I was tuning some of my code looking by at the disassembly and I noticed a disturbing thing -- my NtReleaseSemaphore had a really ugly epilogue and prologue! 000000007bc9d150 <NtReleaseSemaphore> push %rdi 000000007bc9d151 <NtReleaseSemaphore+0x1> push %rsi 000000007bc9d152 <NtReleaseSemaphore+0x2> mov %rcx,%r9 000000007bc9d155 <NtReleaseSemaphore+0x5> push %rbx 000000007bc9d156 <NtReleaseSemaphore+0x6> mov $0x8,%ecx 000000007bc9d15b <NtReleaseSemaphore+0xb> mov %r8,%rbx 000000007bc9d15e <NtReleaseSemaphore+0xe> sub $0x150,%rsp 000000007bc9d165 <NtReleaseSemaphore+0x15> mov %fs:0x28,%rax 000000007bc9d16e <NtReleaseSemaphore+0x1e> mov %rax,0xa8(%rsp) 000000007bc9d176 <NtReleaseSemaphore+0x26> xor %eax,%eax 000000007bc9d178 <NtReleaseSemaphore+0x28> mov %rsp,%rdi 000000007bc9d17b <NtReleaseSemaphore+0x2b> movl $0x0,0x40(%rsp) 000000007bc9d183 <NtReleaseSemaphore+0x33> movaps %xmm6,0xb0(%rsp) 000000007bc9d18b <NtReleaseSemaphore+0x3b> movaps %xmm7,0xc0(%rsp) 000000007bc9d193 <NtReleaseSemaphore+0x43> movaps %xmm8,0xd0(%rsp) 000000007bc9d19c <NtReleaseSemaphore+0x4c> movaps %xmm9,0xe0(%rsp) 000000007bc9d1a5 <NtReleaseSemaphore+0x55> movaps %xmm10,0xf0(%rsp) 000000007bc9d1ae <NtReleaseSemaphore+0x5e> movaps %xmm11,0x100(%rsp) 000000007bc9d1b7 <NtReleaseSemaphore+0x67> movaps %xmm12,0x110(%rsp) 000000007bc9d1c0 <NtReleaseSemaphore+0x70> movaps %xmm13,0x120(%rsp) 000000007bc9d1c9 <NtReleaseSemaphore+0x79> movaps %xmm14,0x130(%rsp) 000000007bc9d1d2 <NtReleaseSemaphore+0x82> movaps %xmm15,0x140(%rsp) (55 bytes of actual work) 000000007bc9d227 <NtReleaseSemaphore+0xd7> movaps 0xb0(%rsp),%xmm6 000000007bc9d22f <NtReleaseSemaphore+0xdf> movaps 0xc0(%rsp),%xmm7 000000007bc9d237 <NtReleaseSemaphore+0xe7> movaps 0xd0(%rsp),%xmm8 000000007bc9d240 <NtReleaseSemaphore+0xf0> movaps 0xe0(%rsp),%xmm9 000000007bc9d249 <NtReleaseSemaphore+0xf9> movaps 0xf0(%rsp),%xmm10 000000007bc9d252 <NtReleaseSemaphore+0x102> movaps 0x100(%rsp),%xmm11 000000007bc9d25b <NtReleaseSemaphore+0x10b> movaps 0x110(%rsp),%xmm12 000000007bc9d264 <NtReleaseSemaphore+0x114> movaps 0x120(%rsp),%xmm13 000000007bc9d26d <NtReleaseSemaphore+0x11d> movaps 0x130(%rsp),%xmm14 000000007bc9d276 <NtReleaseSemaphore+0x126> movaps 0x140(%rsp),%xmm15 000000007bc9d27f <NtReleaseSemaphore+0x12f> add $0x150,%rsp 000000007bc9d286 <NtReleaseSemaphore+0x136> pop %rbx 000000007bc9d287 <NtReleaseSemaphore+0x137> pop %rsi 000000007bc9d288 <NtReleaseSemaphore+0x138> pop %rdi 000000007bc9d289 <NtReleaseSemaphore+0x139> retq So I looked at the rest of the file and all of the WINAPI functions were thus. So I looked at the rest of the build and the same thing, all WINAPI (i.e., __attribute__((ms_abi))) functions had these horribly bloated epilogues and prologues. I built ntdll again with -Dms_abi=sysv_abi and the problem went away (but of course wouldn't work). Surely this cannot be an inherent requirement of ms_abi!? I'm hoping that this is just some bug that has slipped through the cracks because not many people use ms_abi on Linux. Daniel

1 1