December 2014 - Wine-devel - list.winehq.org

Re: [PATCH v3 4/7] include: Add hstring.h and winstring.h.
by Alexandre Julliard 10 Dec '14

10 Dec '14

Martin Storsjo <martin(a)martin.st> writes: > --- > No changes since v2. > --- > include/Makefile.in | 2 ++ > include/hstring.h | 39 +++++++++++++++++++++++++++++++++++++++ > include/winstring.h | 46 ++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 87 insertions(+) > create mode 100644 include/hstring.h > create mode 100644 include/winstring.h hstring.h should be generated from idl. -- Alexandre Julliard julliard(a)winehq.org

2 1

RE: [PATCH v3 03/10] reg: Add system error printing function
by Hugh McMaster 09 Dec '14

09 Dec '14

On Saturday, 8 Nov 2014 11:26:44 +0100, Jonathan Vollebregt wrote: +static void reg_print_error(LSTATUS error_code) +{ + switch (error_code) + { + case ERROR_SUCCESS: + return; + case ERROR_BAD_COMMAND: + reg_message(STRING_INVALID_CMDLINE); + return; + default: + { + static const WCHAR error_string[] = {'%','0','5','d',':',' ','%','s',0}; + WCHAR *message = NULL; + FormatMessageW(FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_ALLOCATE_BUFFER, NULL, + error_code, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), (WCHAR *)&message, 0, NULL); + + reg_message(STRING_ERROR); + reg_printfW(error_string, error_code, message); + LocalFree(message); + return; + } + } +}This seems like a step backwards to me. It would be much better to add the required functionality -- e.g. FormatMessage() -- and fix reg.exe printf-style functions in one go. See http://source.winehq.org/patches/data/107578 for what I mean. Also, mixing reg_message() and reg_printfW() just seems wrong. A clear resource string incorporating your formatting above would suffice, I expect. -- Hugh McMaster

2 3

Re: [8/9] winhttp: Don't try to read data when the server response is HTTP_STATUS_NO_CONTENT or HTTP_STATUS_NOT_MODIFIED.
by Marvin 09 Dec '14

09 Dec '14

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=10702 Your paranoid android. === w7u (32 bit winhttp) === winhttp.c:2035: Test failed: failed to receive response 12030 winhttp.c:2039: Test failed: failed to query status code 12019 winhttp.c:2040: Test failed: request failed unexpectedly 589826 winhttp.c:2044: Test failed: failed to query authentication schemes 4317 winhttp.c:2045: Test failed: got deadbeef winhttp.c:2046: Test failed: got deadbeef winhttp.c:2047: Test failed: got deadbeef === w8 (32 bit winhttp) === winhttp.c:2035: Test failed: failed to receive response 12030 winhttp.c:2039: Test failed: failed to query status code 12019 winhttp.c:2040: Test failed: request failed unexpectedly 589826 winhttp.c:2044: Test failed: failed to query authentication schemes 4317 winhttp.c:2045: Test failed: got deadbeef winhttp.c:2046: Test failed: got deadbeef winhttp.c:2047: Test failed: got deadbeef

2 1

Re: [9/9] winhttp/tests: Close the connection immediately after authentication.
by Marvin 09 Dec '14

09 Dec '14

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=10703 Your paranoid android. === w2008s64 (32 bit winhttp) === winhttp.c:2250: Test failed: WinHttpReceiveResponse failed: 12152 winhttp.c:2255: Test failed: WinHttpQueryHeaders failed: 12019 winhttp.c:2256: Test failed: got 0 winhttp.c:2260: Test failed: WinHttpQueryDataAvailable failed: 12019 === w7u (32 bit winhttp) === winhttp.c:2041: Test failed: failed to receive response 12030 winhttp.c:2045: Test failed: failed to query status code 12019 winhttp.c:2046: Test failed: request failed unexpectedly 589826 winhttp.c:2050: Test failed: failed to query authentication schemes 4317 winhttp.c:2051: Test failed: got deadbeef winhttp.c:2052: Test failed: got deadbeef winhttp.c:2053: Test failed: got deadbeef === w8 (32 bit winhttp) === winhttp.c:2041: Test failed: failed to receive response 12030 winhttp.c:2045: Test failed: failed to query status code 12019 winhttp.c:2046: Test failed: request failed unexpectedly 589826 winhttp.c:2050: Test failed: failed to query authentication schemes 4317 winhttp.c:2051: Test failed: got deadbeef winhttp.c:2052: Test failed: got deadbeef winhttp.c:2053: Test failed: got deadbeef

1 0

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose windoworigin point has changed
by Marvin 09 Dec '14

09 Dec '14

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=10699 Your paranoid android. === w7u (32 bit graphics) === graphics.c:5575: Test failed: Expected the color of memory bitmap is blue!graphics: 4644 tests executed (0 marked as todo, 1 failure), 0 skipped.

1 0

Re: [PATCH v2 08/10] combase: Implement creation and deletion of HSTRING objects.
by Sebastian Lackner 09 Dec '14

09 Dec '14

On 08.12.2014 10:26, Martin Storsjo wrote: > + return E_INVALIDARG; > + if (str == NULL) > + { > + *out = NULL; <--- > + return S_OK; <--- > + } > + if (priv->reference) > + return WindowsCreateString(priv->buffer, priv->length, out); Wrong indentation. Moreover I noticed a mistake in patch 10. I had the guess that preallocating an empty string should also return a NULL string-buffer. + /* Test creation of an empty buffer */ + ok(pWindowsPreallocateStringBuffer(0, &ptr, &buf) == S_OK, "Failed to preallocate string buffer\n"); + ok(buf != NULL, "Empty string buffer is a null string\n"); + ok(ptr != NULL, "Empty string didn't return a buffer pointer\n"); + ok(pWindowsDeleteStringBuffer(buf) == S_OK, "Failed to delete string buffer\n"); + The testbot seems to confirm that: https://newtestbot.winehq.org/JobDetails.pl?Key=10687 ( I would suggest to wait with resending till after the daily commits, everything from patch 1-7 should be fine, and it probably doesn't make sense to resend the whole series several times. ;) ) Regards, Sebastian

2 2

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose window origin point has changed
by Marvin 09 Dec '14

09 Dec '14

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=10695 Your paranoid android. === w7u (32 bit graphics) === graphics.c:5575: Test failed: Expected the color of memory bitmap is blue!graphics: 4645 tests executed (0 marked as todo, 1 failure), 0 skipped.

1 0

Puzzle about ExtSelectClipRgn?
by Changhui Liu 08 Dec '14

08 Dec '14

Dear all, I test this code : void test (HDC hdc, HRGN hregion) { RECT srcbox; RECT dstbox; GetClipBox(hdc, &dstbox); GetRgnBox(hregion, &srcbox); TRACE("Before ExtSelectClipRgn:%s,%s\n", wine_dbgstr_rect(&srcbox), wine_dbgstr_rect(&dstbox) ); ExtSelectClipRgn(hdc, hregion, RGN_AND ); GetClipBox(graphics->hdc,&dstbox); TRACE("After ExtSelectClipRgn:%s,%s\n", wine_dbgstr_rect(&dstbox) ); } It output in wine is : Before ExtSelectClipRgn:(693,5)-(763,28),(693,5)-(763,28) After ExtSelectClipRgn:(693,5)-(693,5) But I think it should be output: Before ExtSelectClipRgn:(693,5)-(763,28),(693,5)-(763,28) After ExtSelectClipRgn:(693,5)-(763,28) Where is my understanding mistake, or is it a bug in ExtSelectClipRgn? Thank you!

3 3

Re: [PATCH 4/4] dwrite: Implement GetDesignGlyphAdvances()
by Marvin 08 Dec '14

08 Dec '14

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=10681 Your paranoid android. === wvistau64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === w2008s64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === wvistau64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275 === w2008s64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275

1 0

Re: [PATCH 3/4] dwrite: Implement IsMonospacedFont()
by Marvin 08 Dec '14

08 Dec '14

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=10680 Your paranoid android. === wvistau64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === w2008s64 (32 bit font) === font: unhandled exception c0000005 at 00409EDC === wvistau64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275 === w2008s64 (64 bit font) === font: unhandled exception c0000005 at 0000000000409275

1 0