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

Re: [PATCH 1/3] gdiplus: fix get_graphics_bounds when window origin point changed
by Dmitry Timoshkov 23 Dec '14

23 Dec '14

"Changhui Liu" <liuchanghui(a)linuxdeepin.com> wrote: > @@ -5619,7 +5674,7 @@ START_TEST(graphics) > test_alpha_hdc(); > test_bitmapfromgraphics(); > test_GdipFillRectangles(); > - > + test_GdipGetVisibleClipBounds_memoryDC(); > GdiplusShutdown(gdiplusToken); > DestroyWindow( hwnd ); > } An empty line before GdiplusShutdown is intentional and makes it clearer to separate tests from the clean up. Please keep it that way. -- Dmitry.

1 0

Re: gdiplus: fix GdipFillRectangleI no effect on memoryDCwhosewindoworiginpoint has changed
by Changhui Liu 23 Dec '14

23 Dec '14

Hi, > I would prefer that you use the expect() macro when comparing integers in tests. > >If you don't expect a function (in this case GetDIBits, in patch 2) to >fail when running a test, use ok() to check that it succeeded. It's OK >if the test will crash when the ok() check fails. > >If GetDIBits really does fail sometimes, we need to understand why >that happens and document it in the test. > >When writing comments about this, make sure you specify that you are >talking about gdi32 device coordinates, which are different from >gdiplus device coordinates. I have modified, please see the new patch file. >+ status = GdipSetClipRectI(graphics, rect.left+width/2, rect.top+height/2, >+ rect.right, rect.bottom, CombineModeReplace); > >This looks wrong to me. GdipSetClipRectI takes a width and height, not >right and bottom. The above statement is setting a clip range: (rect.left+width/2, rect.top+height/2) - (rect.left+rect.right+width/2, rect.top+rect.bottom+height/2). Because the rect is {100, 100, 180, 180}, so the clip range is: (140,140) - (320,320). In fact GdipSetClipRectI can take any int value to specify a clip region. But according to your advice, I have changed to take a width and height . For helping review, I attached a BMP file which is the output of each test_GdipFillRectangle drawing on Memory DC. Thank you. ------------------ Regards.

3 4

Re: [PATCH 2/3] urlmon: Skip query and hash part in find_mime_from_url.
by Marvin 22 Dec '14

22 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=10873 Your paranoid android. === w2000pro (32 bit misc) === misc.c:723: Test failed: [5] wrong mime: L"text/plain" === wxppro (32 bit misc) === misc.c:723: Test failed: [5] wrong mime: L"text/plain"

1 0

Re: mshtml: Added IHTMLDOMTextNode::splitText implementation.
by Marvin 21 Dec '14

21 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=10849 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

1 0

Re: shell32: Added stub IPropertyStore for a shell link object
by Marvin 20 Dec '14

20 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=10846 Your paranoid android. === wxppro (32 bit shelllink) === shelllink.c:1170: Test failed: got 0x80004002 shelllink: unhandled exception c0000005 at 0041529E

1 0

Re: [PATCH] libs/wine/string.c: Duplicate Windows behaviour in vsnprintfW
by Hugh McMaster 20 Dec '14

20 Dec '14

Sorry, I didn't see your message as it was sent to wine-patches. On Thursday, 18 Dec 2014 18:09:01 +0100, Jonathan Vollebregt wrote: >> If buffer or format is NULL, or if count is less than or equal to zero, these functions invoke the invalid parameter handler, as described in Parameter Validation. If execution is allowed to continue, these functions return -1 and set errno to EINVAL. >This doc says that vsnprintf *should* always return -1 given your example. Yes, MSDN does say that. >Is there a test that shows the MSDN docs are wrong? I'm not sure if Wine has one, but I'll check. Running multiple tests with Visual Studio 2013 on Windows 7 64-bit returns the number of chars that would be written for vsnprintf(NULL, 0, fmt, args). -1 is returned in cases when "the number of characters to write is greater than count". So some examples would be vsnprintf(valid buffer, 0, fmt, args) or vsnprintf(very small buffer, 8, fmt, args). >On 12/18/2014 11:57 AM, Hugh McMaster wrote: >> Recent discussions on the wine-devel mailing list conclude that Wine's vsnprintfW must duplicate Windows' vsnprintf behaviourW[1]. >> >> Currently, there are two issues. >> >> 1. vsnprintfW(NULL, 0, fmt, args). Both Windows and GCC allow these arguments. Both return the number of chars that would be written in this instance. Wine returns -1, which is incorrect. >> >> 2. vsnprintfW(some buffer, 0, fmt, args). Both Windows and Wine return -1, but in this case, Wine does this by default. We need to maintain this behaviour. >> >> To fix these inconsistencies, we need to add an 'else' block to the check for len (i.e. checking for a non-zero value). Then we check for a NULL pointer. If true, we return (int)written, like Windows and GCC do, because vsnprintfW(NULL, 0, fmt, args) was called. >> >> This patch fixes these issues. >> >> [1] https://www.winehq.org/pipermail/wine-devel/2014-December/106066.html

3 3

Re: gdiplus: fix GdipFillRectangleI no effect on memory DC whose windoworigin point has changed
by Vincent Povirk 19 Dec '14

19 Dec '14

- rect->X = 0; - rect->Y = 0; + /*The user maybe has called SetWindowOrgEx to change origin point*/ + POINT pt = {0, 0}; + GetWindowOrgEx(graphics->hdc, &pt); + rect->X = pt.x; + rect->Y = pt.y; I don't think we should use GetWindowOrgEx in gdiplus. There are too many ways to change the mapping of co-ordinates for an HDC, and it doesn't make sense to specifically account for them all. In get_graphics_bounds, we already have code that accounts for the HDC transform using DPtoLP. Maybe we should do that even when GetMapMode == MM_TEXT. Transforming the region in alpha_blend_pixels_hrgn looks wrong to me, because we can't do that in the general case. Logical coordinates on the HDC may not be pixels. Your test is very unclear. A good test for this should make it obvious how the HDC's transform affects GDI+ world coordinates. If I fill a rectangle at (0,0) using GDI+, on an HDC with window origin (5,5), what is the origin of that rectangle on the screen?

3 7

Re: [PATCH 1/4] ntdll: Implement retrieving DOS attributes in NtQueryInformationFile (try 2).
by Alexandre Julliard 19 Dec '14

19 Dec '14

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > Currently only Linux extended attributes are supported, when they are > not available at compile time the ports implementation will fall back > to a "not-supported" return and any such attributes will be ignored. > It is necessary to place this feature in ports so that Mac and FreeBSD > can be supported separately, as the semantics of these APIs are quite > different on such systems (patches to come after this initial > implementation). That doesn't mean they should go into ports, especially not as such non-standard functions. Unless you really have to use them all over the place, they should remain in ntdll. -- Alexandre Julliard julliard(a)winehq.org

2 6

Re: [3/3] advapi32: Fix HKLM\Software handling when opening with KEY_WOW64_32KEY.
by Nikolay Sivov 19 Dec '14

19 Dec '14

On 12/18/2014 06:21 PM, Akihiro Sagawa wrote: > --- > dlls/advapi32/registry.c | 99 ++++++++++++++++++++++++++++++++++++------ > dlls/advapi32/tests/registry.c | 6 +-- > 2 files changed, 88 insertions(+), 17 deletions(-) > Just curious, why HKLM\Software needs special handling in this case? In other words is there a solution that covers all paths?

2 1

Patch 108275 superseded incorrectly?
by Dmitry Kozliuk 19 Dec '14

19 Dec '14

Hello, Patch status page shows patch http://source.winehq.org/patches/data/108275 as "Superseded", and patch http://source.winehq.org/patches/data/108285 as "New". However, the former is supposed to supersede the latter: it has "(try 2)" mark an was submitted later with an explanation. Please consider patch status correction. -- Dmitry Kozliuk

1 0