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

Re: [5/5] wininet/tests: Add tests for asynchronous InternetReadFile. (v4)

by Marvin

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=22660 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:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: 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: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:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

April 28, 2016

Re: [3/5] wininet: Send INTERNET_STATUS_RESPONSE_RECEIVED notification in async handler. (v4)

by Marvin

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=22659 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:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1 === w7pro64 (64 bit http) === http.c:5979: Test failed: HttpQueryInfoA failed 6 === w1064 (64 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:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

April 28, 2016

Re: [2/5] wininet/tests: Add tests for asynchronous InternetReadFileEx. (v4)

by Marvin

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=22658 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:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: 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: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:2406: Test failed: count was wrong http.c:2407: Test failed: http data wrong, got: Garbage: Header http.c:3070: Test failed: HttpAddRequestHeaders succeeded http.c:3071: Test failed: Expected error ERROR_HTTP_HEADER_NOT_FOUND, got 0 http.c:3076: Test failed: code = 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:3076: Test failed: unexpected status code 200, expected 400 http.c:523: Test failed: HTTP_QUERY_RAW_HEADERS: expected length 0, but got 1

April 28, 2016

Re: [v2 PATCH] d3dx10: Implement D3DX10UnsetAllDeviceObjects()

by Józef Kucia

On Wed, Apr 27, 2016 at 1:40 PM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > + /* Verify the initial state after device creation. */ I think it's unnecessary to duplicate tests for the device initial state in d3dx10 tests. > + /* Verify the behavior of set state methods. */ This part is a test for ID3D10Device_OMSetBlendState(). It isn't necessary as well. > + /* Verify the set state. */ This part isn't strictly necessary but it can be argued that it makes sense to verify that the state was properly set before calling D3DX10UnsetAllDeviceObjects().

April 27, 2016

Re: [PATCH 2/2] winmm/tests: Add tests showing window message processing while opening a video.

by Marvin

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=22649 Your paranoid android. === w7u (32 bit mci) === mci.c:1122: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) === w1064 (32 bit mci) === mci: unhandled exception c0000005 at 7698A3E7 === w864 (64 bit mci) === mci.c:1122: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close) === w1064 (64 bit mci) === mci.c:1122: Test failed: got 0001 instead of MCI_NOTIFY_xyz 0004 from command play (aborted by close)

April 27, 2016

Re: kernel32/tests: Add initial tests for GetConsoleFontInfo (v3)

by Sebastian Lackner

On 27.04.2016 15:24, Hugh McMaster wrote: > On Wednesday, 27 April 2016 2:41 AM, Sebastian Lackner wrote: > >> I am aware that this patch is already committed, but since you are probably >> still working on the follow-up patches, here some remarks: > >> On 26.04.2016 14:06, Hugh McMaster wrote: >>> + GetCurrentConsoleFont(std_output, FALSE, &cfi[0]); >>> + index = cfi[0].nFont; >>> + orig_font = GetConsoleFontSize(std_output, index); > >> You might want to do a memset here. Currently some of the tests pass, >> although Wine has no implementation yet. > > Do you mean to clear cfi[0] after calling GetCurrentConsoleFont? Yes, or even better the whole memory. HeapAlloc does not initialize it. > >>> + SetLastError(0xdeadbeef); >>> + ret = pGetConsoleFontInfo(std_output, FALSE, num_fonts, cfi); >>> + todo_wine ok(ret, "got %d, expected non-zero\n", ret); >>> + todo_wine ok(GetLastError() == 0xdeadbeef, "got %u, expected 0xdeadbeef\n", GetLastError()); >>> + >>> + ok(cfi[index].dwFontSize.X == win_width, "got %d, expected %d\n", cfi[index].dwFontSize.X, win_width); >>> + ok(cfi[index].dwFontSize.Y == win_height, "got %d, expected %d\n", cfi[index].dwFontSize.Y, win_height); > >> Could you add an additional test that (cfi[i].nFont == i) holds? >> If GetConsoleFontInfo would return elements in arbitrary order, the >> code above would not work. > > I'm not sure I understand what you're asking. Should I run the loop again? No, you can add it into the loop below. To make a bit more clear what I mean: You initialize "index" based on the nFont value, but here you access based on the array index. Its not immediately obvious that the array index and nFont value is the same. > > The TRUE/FALSE argument doens't seem to have an effect on the order of elements returned. > If you set a different font size, cfi[new font index].dwFontSize.X == win_width. The remaining dwFontSize > members are set relative to that font size. > >>> + for (i = 0; i < num_fonts; i++) >>> + { >>> + tmp_font = GetConsoleFontSize(std_output, cfi[i].nFont); >>> + tmp_w = (double)orig_font.X / tmp_font.X * win_width; >>> + tmp_h = (double)orig_font.Y / tmp_font.Y * win_height; >>> + ok(cfi[i].dwFontSize.X == tmp_w, "got %d, expected %d\n", cfi[i].dwFontSize.X, tmp_w); >>> + ok(cfi[i].dwFontSize.Y == tmp_h, "got %d, expected %d\n", cfi[i].dwFontSize.Y, tmp_h); >>> + } > >> It wouldn't hurt to HeapFree() cfi here. > > Yes, sorry, I missed that. I split the patch and forgot about the HeapFree(). > I'll add it when I send tests with the TRUE argument. >

April 27, 2016

Re: kernel32/tests: Add initial tests for GetConsoleFontInfo (v3)

by Hugh McMaster

On Wednesday, 27 April 2016 2:41 AM, Sebastian Lackner wrote: > I am aware that this patch is already committed, but since you are probably > still working on the follow-up patches, here some remarks: > On 26.04.2016 14:06, Hugh McMaster wrote: >> + GetCurrentConsoleFont(std_output, FALSE, &cfi[0]); >> + index = cfi[0].nFont; >> + orig_font = GetConsoleFontSize(std_output, index); > You might want to do a memset here. Currently some of the tests pass, > although Wine has no implementation yet. Do you mean to clear cfi[0] after calling GetCurrentConsoleFont? >> + SetLastError(0xdeadbeef); >> + ret = pGetConsoleFontInfo(std_output, FALSE, num_fonts, cfi); >> + todo_wine ok(ret, "got %d, expected non-zero\n", ret); >> + todo_wine ok(GetLastError() == 0xdeadbeef, "got %u, expected 0xdeadbeef\n", GetLastError()); >> + >> + ok(cfi[index].dwFontSize.X == win_width, "got %d, expected %d\n", cfi[index].dwFontSize.X, win_width); >> + ok(cfi[index].dwFontSize.Y == win_height, "got %d, expected %d\n", cfi[index].dwFontSize.Y, win_height); > Could you add an additional test that (cfi[i].nFont == i) holds? > If GetConsoleFontInfo would return elements in arbitrary order, the > code above would not work. I'm not sure I understand what you're asking. Should I run the loop again? The TRUE/FALSE argument doens't seem to have an effect on the order of elements returned. If you set a different font size, cfi[new font index].dwFontSize.X == win_width. The remaining dwFontSize members are set relative to that font size. >> + for (i = 0; i < num_fonts; i++) >> + { >> + tmp_font = GetConsoleFontSize(std_output, cfi[i].nFont); >> + tmp_w = (double)orig_font.X / tmp_font.X * win_width; >> + tmp_h = (double)orig_font.Y / tmp_font.Y * win_height; >> + ok(cfi[i].dwFontSize.X == tmp_w, "got %d, expected %d\n", cfi[i].dwFontSize.X, tmp_w); >> + ok(cfi[i].dwFontSize.Y == tmp_h, "got %d, expected %d\n", cfi[i].dwFontSize.Y, tmp_h); >> + } > It wouldn't hurt to HeapFree() cfi here. Yes, sorry, I missed that. I split the patch and forgot about the HeapFree(). I'll add it when I send tests with the TRUE argument.

April 27, 2016

Re: [PATCH] msvcrt: Handle overflow in calloc()

by Marvin

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=22628 Your paranoid android. === wxppro (32 bit heap) === heap.c:478: Test failed: got errno 0 === w2003std (32 bit heap) === heap.c:478: Test failed: got errno 0

April 27, 2016

Re: [PATCH 5/5] qedit: Implement IAMTimelineObj_GetTimelineNoRef and add tests.

by Nikolay Sivov

On 26.04.2016 16:33, Andrew Eikum wrote: > On Mon, Apr 25, 2016 at 11:46:09PM -0600, Alex Henrie wrote: >> 2016-04-25 23:10 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>> On 26.04.2016 7:57, Alex Henrie wrote: >>>> 2016-04-25 22:21 GMT-06:00 Nikolay Sivov <bunglehead(a)gmail.com>: >>>>> On 26.04.2016 6:10, Alex Henrie wrote: >>>>>> static HRESULT WINAPI TimelineObj_GetTimelineNoRef(IAMTimelineObj *iface, IAMTimeline **timeline) >>>>>> { >>>>>> + /* MSDN says that this function is "not supported" */ >>>>>> TimelineObjImpl *This = impl_from_IAMTimelineObj(iface); >>>>>> - FIXME("(%p)->(%p): not implemented!\n", This, timeline); >>>>>> - return E_NOTIMPL; >>>>>> + TRACE("(%p)->(%p)\n", This, timeline); >>>>>> + if (!timeline) return E_POINTER; >>>>>> + return E_NOINTERFACE; >>>>>> } >>>>> >>>>> This looks like a call to QI, according to your tests. >>>> >>>> It looks that way, but which interface would it be querying? The tests >>>> show that an IAMTimelineObj cannot double as an IAMTimeline, nor is >>>> the function supposed to return the IAMTimeline that was used to >>>> create the IAMTimelineObj. My best guess is that Microsoft never >>>> bothered implementing this function properly and so whatever >>>> implementation they have always winds up returning E_NOINTERFACE. >>> >>> Yes, return type is IAMTimeline, so I was suggesting a shortcut doing >>> same thing in one line IAMTimelineObj_QueryInterface(iface, >>> &IID_IAMTimeline, ...). This should cover for setting out pointer to >>> NULL, returning E_NOINTERFACE, and probably handling NULL case too, >>> though it's not a standard QI behavior. None of that is actually >>> important, what you did is fine, take it as a suggestion, or don't. >> >> OK, I see what you mean now, and I'll make that change in version 2 of >> this patchset. >> > > Eh, I'd rather keep it like it was. It's not clear whether it should > be QIing on this same object or on the parent Timeline object, and the > "NoRef" is weird behavior for a QI. Implementing it on top of QI > seems to imply confidence we don't have, and would confuse me if I was > reading this code blind. I agree, it's better to keep it simple, and NoRef implies something non-standard. Sorry for the noise. > > Andrew >

April 27, 2016

Re: kernel32: add GetVolumeInformationByHandleW stub (try 3)

by Nikolay Sivov

I didn't try myself, but I think we have everything to implement it, like this: GetFileInformationByHandleEx with FileNameInfo -> GetVolumePathNameW -> GetVolumeInformationW. If this works for affected application I think it's better to implement it instead of getting in a stub, to find out later that it's not enough.

April 27, 2016