September 2014 - Wine-devel

Re: [PATCH 1/4] mshtml: Return E_POINTER when p is NULL in HTMLStyle_get_pixelLeft.
by Jacek Caban 09 Sep '14

09 Sep '14

Hi Jactry, On 09/09/14 08:06, Jactry Zeng wrote: > diff --git a/dlls/mshtml/htmlstyle.c b/dlls/mshtml/htmlstyle.c > index f098cb0..9469243 100644 > --- a/dlls/mshtml/htmlstyle.c > +++ b/dlls/mshtml/htmlstyle.c > @@ -2482,6 +2482,8 @@ static HRESULT WINAPI HTMLStyle_get_pixelLeft(IHTMLStyle *iface, LONG *p) > HTMLStyle *This = impl_from_IHTMLStyle(iface); > > TRACE("(%p)->(%p)\n", This, p); > + if(!p) > + return E_POINTER; Since you're adding those checks to many functions, it would probably make sense to move that to get_nsstyle_pixel_val. Jacek

2 1

Re: [PATCH 1/11] ntdll: Make nt_to_unix_file_name_attr return always safe to free.
by Alexandre Julliard 09 Sep '14

09 Sep '14

"Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > While working on an upcoming patch set I discovered that several of > the file handling primitives are not safe to free under all > circumstances. This would not normally be a problem (since a > comparison can usually be made against STATUS_SUCCESS). However, > there are several cases where this comparison is insufficient (mostly > when STATUS_NO_SUCH_FILE occurs). There are two ways to solve this > problem: > 1) Make these routines always safe to free (and always free them) > 2) Specifically add checks for STATUS_NO_SUCH_FILE and free all these > cases manually STATUS_NO_SUCH_FILE returning a valid string only happens when trying to create the file or things like that, not for normal opens, so most of your changes are unnecessary. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/4] mshtml: Add IHTMLStyle::pixelTop property implementation.
by Marvin 09 Sep '14

09 Sep '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=8853 Your paranoid android. === wxppro (32 bit style) === style.c:1295: Test failed: pixelHeight = 5 === wvistau64 (32 bit style) === style.c:1295: Test failed: pixelHeight = 5 === w2008s64 (32 bit style) === style.c:1295: Test failed: pixelHeight = 5 === w7u (32 bit style) === style.c:1295: Test failed: pixelHeight = 5 === w8 (32 bit style) === style.c:1295: Test failed: pixelHeight = 5 === wvistau64 (64 bit style) === style.c:1295: Test failed: pixelHeight = 5 === w2008s64 (64 bit style) === style.c:1295: Test failed: pixelHeight = 5

1 0

Re: [PATCH 3/4] mshtml: Add IHTMLStyle::pixelHeight property implementation.
by Marvin 09 Sep '14

09 Sep '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=8852 Your paranoid android. === wxppro (32 bit style) === style.c:1274: Test failed: pixelHeight = 5 === wvistau64 (32 bit style) === style.c:1274: Test failed: pixelHeight = 5 === w2008s64 (32 bit style) === style.c:1274: Test failed: pixelHeight = 5 === w7u (32 bit style) === style.c:1274: Test failed: pixelHeight = 5 === w8 (32 bit style) === style.c:1274: Test failed: pixelHeight = 5 === wvistau64 (64 bit style) === style.c:1274: Test failed: pixelHeight = 5 === w2008s64 (64 bit style) === style.c:1274: Test failed: pixelHeight = 5

1 0

Re: user32: Also set cch member in GetMenuItemInfo when passing a null pointer.
by Nikolay Sivov 08 Sep '14

08 Sep '14

A test would be nice.

1 0

Re: (resend 2)[1/4]dwrite: Implement GetInformationalStrings
by Alexandre Julliard 08 Sep '14

08 Sep '14

Aric Stewart <aric(a)codeweavers.com> writes: > read strings from OpenType 'name' table You are not reading anything, once again this is mostly dead code. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 4/5] d2d1: Implement initial clipping support.
by Matteo Bruni 07 Sep '14

07 Sep '14

2014-09-05 15:50 GMT+02:00 Henri Verbeet <hverbeet(a)codeweavers.com>: > +static BOOL d2d_clip_stack_push(struct d2d_clip_stack *stack, const D2D1_RECT_F *rect) > +{ > + if (stack->current == stack->stack_size - 1) > + { > + D2D1_RECT_F *new_stack; > + unsigned int new_size; > + > + if (stack->stack_size > UINT_MAX / 2) > + return FALSE; > + > + new_size = stack->stack_size * 2; > + if (!(new_stack = HeapReAlloc(GetProcessHeap(), 0, stack->stack, new_size * sizeof(*stack->stack)))) > + return FALSE; > + > + stack->stack = new_stack; > + stack->stack_size = new_size; > + } > + > + stack->stack[stack->current++] = *rect; > + d2d_rect_intersect(&stack->clip_rect, rect); > + > + return TRUE; > +} > + > +static void d2d_clip_stack_pop(struct d2d_clip_stack *stack, unsigned int w, unsigned int h) > +{ > + unsigned int i; > + > + if (!stack->current) > + return; > + > + --stack->current; > + stack->clip_rect.left = 0.0f; > + stack->clip_rect.top = 0.0f; > + stack->clip_rect.right = w; > + stack->clip_rect.bottom = h; > + > + for (i = 0; i < stack->current; ++i) > + { > + d2d_rect_intersect(&stack->clip_rect, &stack->stack[i]); > + } > +} Would it be possible to store the clipped rectangles in the stack instead (so that stack->clip_rect == stack->stack[stack->current] at any given moment)? That way you don't need to recompute clip_rect on each pop.

2 1

[RFC 0/11] Linux FF: Intro
by Elias Vanderstuyft 07 Sep '14

07 Sep '14

Hi, This is the sequel of the mail with title: "Discussion and Improvement of Wine's Linux Force Feedback implementation". This mail is meant to give an introduction to the next 11 mails: All tests were performed using wine-1.7.11-206-g82b3813 (but none of the files of which I propose changes to be made in, are affected in the current (2014-03-04) wine-version 1.7.13) Because I haven't created any (formal) patch yet (and instead first request for comments), I tried to keep the line numbers to reference the affected files more or less based to the version I started from, where I could. However, the orig code of a (informal) patch that has to be applied after (and thus is dependent of) a previous patch, may be different from the initial code of the wine-version I started from. After having discussed everything, I will send a proper patchset. In these mails, sometimes 'FEdit' is mentioned: it's a MS application that allows to create all FF effect types (except CustomForce and rumble/vibration effects), and therefore the ideal test application. Physical behavior is compared between Windows7 (using Logitech MOMO wheel with latest drivers installed) running in Virtualbox, and my patched Wine-version. In the end, (using a dummy FF driver on the Linux side, thanks to Michal Malý), the behavior of Wine is almost (limitations caused by the dummy ff driver, such as updating an effect while playing is not implemented) identical, if not better (in some aspects) then the Windows equivalent. Sometimes I refer to linux-input mailing lists to prove a statement, because the links may vanish (unlikely though), I provide the titles corresponding with the links: (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08513.html) "ff-core effect id handling in case of a failed effect upload" (http://www.mail-archive.com/linux-input(a)vger.kernel.org/msg08459.html) "Questions about the documentation/specification of Linux ForceFeedback input.h" Subjects [11] ------------- - Joystick control panel program [2] - Linux effect status management [3] - Linux effect parameter: start delay [1] - Linux effect parameter: periodic effect's phase [1] - Linux effect parameters: time parameters [3] - Linux effect: conditional effect's parameters [2] - Linux effect: axes [1] - Linux effect direction [7] - Linux effect parameters (global) [6] - Linux joystick initialization [1] - Debug message fixes/additions [6] Elias

2 3

Re: [PATCH 5/5] d2d1/tests: Add a basic clipping tests.
by Marvin 05 Sep '14

05 Sep '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=8807 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

2 1

Re: [PATCH 1/5] widl: Handle aggregate returns in a MSVC compatible way.
by Piotr Caban 05 Sep '14

05 Sep '14

On 09/05/14 15:50, Henri Verbeet wrote: > -static D2D1_COLOR_F STDMETHODCALLTYPE d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface) > +static void STDMETHODCALLTYPE d2d_solid_color_brush_GetColor(ID2D1SolidColorBrush *iface, D2D1_COLOR_F *color) > { > static const D2D1_COLOR_F black = {0.0f, 0.0f, 0.0f, 1.0f}; > > FIXME("iface %p stub!\n", iface); > > - return black; > + *color = black; > } Shouldn't it return pointer to D2D1_COLOR_F?

3 2