September 2017 - Wine-devel

Re: [PATCH v2 4/7] evr: Add tests
by Marvin 10 Sep '17

10 Sep '17

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=33024 Your paranoid android. === build (build) === Make failed

2 1

Re: [PATCH] test.patch
by Fabian Maurer 10 Sep '17

10 Sep '17

Please ignore this patch, didn't mean to send that. Regards, Fabian Maurer

1 0

Re: [PATCH 4/7] evr: Add tests
by Marvin 10 Sep '17

10 Sep '17

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=33019 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH] d2d1: Partially implement StrokeContainsPoint() for rectangles
by Henri Verbeet 08 Sep '17

08 Sep '17

On 8 September 2017 at 16:11, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > +static BOOL d2d_point_on_segment(const D2D1_POINT_2F *q, const D2D1_POINT_2F *p0, > + const D2D1_POINT_2F *p1, float tolerance) > +{ > + float dot, edge_length, distance; > + D2D1_POINT_2F v_p, v_q, n; > + > + d2d_point_subtract(&v_p, p1, p0); > + if ((edge_length = d2d_point_length(&v_p)) == 0.0f) > + return FALSE; > + > + /* Edge distance. */ > + d2d_point_subtract(&v_q, q, p0); > + > + n.x = -v_p.y; > + n.y = v_p.x; Unfortunately it's not that easy when "transform" is a world transformation instead of a geometry transformation. I.e., when you have for example a shear transformation, the "normal" is no longer necessarily perpendicular to the line segment. Put a different way, you're potentially testing against a parallelogram instead of a rectangle. In a sense you account for that with stroke_widths[], but see below. > + distance = fabsf(d2d_point_dot(&v_q, &n)) / edge_length; > + if (distance >= tolerance) > + return FALSE; > + > + /* Test if normal and edge intersect. */ > + dot = d2d_point_dot(&v_q, &v_p); > + return dot >= 0.0f && dot <= edge_length * edge_length; > +} Likewise, this doesn't do the right thing under all transformations. > + d2d_point_transform(&v_s[0], transform, stroke_width, 0.0f); > + d2d_point_transform(&v_s[1], transform, stroke_width, 0.0f); > + d2d_point_transform(&origin, transform, 0.0f, 0.0f); > + > + d2d_point_subtract(&v_s[0], &v_s[0], &origin); > + d2d_point_subtract(&v_s[1], &v_s[1], &origin); > + > + stroke_widths[0] = d2d_point_length(&v_s[0]); > + stroke_widths[1] = d2d_point_length(&v_s[1]); This ends up with the same value for stroke_widths[0] and stroke_widths[1]. > + d2d_point_subtract(&v, &point, &vertices[i]); > + > + if (d2d_point_dot(&v, &v) < tolerance * tolerance) > + { > + *contains = TRUE; > + break; > + } This tests around the corner of the joins, but note that there's potentially a space between that corner and the start of the line segment that this would miss. > + else > + { > + D2D1_POINT_2F d, s; > + > + s.x = rect->right - rect->left; > + s.y = rect->bottom - rect->top; > + d.x = fabsf((rect->right + rect->left) * 0.5f - point.x); > + d.y = fabsf((rect->bottom + rect->top) * 0.5f - point.y); > + > + /* Inside test. */ > + if (d.x <= (s.x - stroke_width) * 0.5f - tolerance && d.y <= (s.y - stroke_width) * 0.5f - tolerance) > + { > + *contains = FALSE; > + return S_OK; > + } > + > + if (tolerance == 0.0f) > + { > + *contains = d.x < (s.x + stroke_width) * 0.5f && d.y < (s.y + stroke_width) * 0.5f; > + } > + else > + { > + d.x = max(d.x - (s.x + stroke_width) * 0.5f, 0.0f); > + d.y = max(d.y - (s.y + stroke_width) * 0.5f, 0.0f); > + > + *contains = d2d_point_dot(&d, &d) < tolerance * tolerance; > + } > + } Ultimately it's not that important, but I think there's something to be said for handling the "!transform" case first as a special case. I.e., if (!transform) { ... return S_OK; } /* General case. */ > diff --git a/dlls/d2d1/tests/d2d1.c b/dlls/d2d1/tests/d2d1.c > index f6261295b6..95a010b13e 100644 > --- a/dlls/d2d1/tests/d2d1.c > +++ b/dlls/d2d1/tests/d2d1.c > @@ -76,6 +76,15 @@ struct expected_geometry_figure > const struct geometry_segment *segments; > }; > > +struct contains_point_test > +{ > + D2D1_MATRIX_3X2_F transform; > + D2D1_POINT_2F point; > + float tolerance; > + float stroke_width; > + BOOL contains; > +}; Unless these are reused between tests, we tend to keep them local to the function. > + static const struct contains_point_test stroke_contains[] = > + { > + {{0.0f, 0.0f, 0.0f, 1.0f}, {0.1f, 10.0f}, 0.0f, 1.0f, FALSE}, > + {{0.0f, 0.0f, 0.0f, 1.0f}, {5.0f, 10.0f}, 5.0f, 1.0f, FALSE}, > + {{0.0f, 0.0f, 0.0f, 1.0f}, {4.9f, 10.0f}, 5.0f, 1.0f, TRUE}, > + {{0.0f, 0.0f, 0.0f, 1.0f}, {5.0f, 10.0f}, -5.0f, 1.0f, FALSE}, > + {{0.0f, 0.0f, 0.0f, 1.0f}, {4.9f, 10.0f}, -5.0f, 1.0f, TRUE}, > + > + {{1.0f, 0.0f, 0.0f, 1.0f}, {0.0f, 10.0f}, 0.0f, 1.0f, TRUE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {0.1f, 10.0f}, 0.0f, 1.0f, TRUE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {0.5f, 10.0f}, 0.0f, 1.0f, FALSE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {0.0f, 10.0f}, 1.0f, 1.0f, TRUE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {0.59f, 10.0f}, 1.0f, 1.0f, TRUE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {-0.59f, 10.0f}, 1.0f, 1.0f, TRUE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {0.59f, 10.0f}, -1.0f, 1.0f, TRUE}, > + {{1.0f, 0.0f, 0.0f, 1.0f}, {-0.59f, 10.0f}, -1.0f, 1.0f, TRUE}, > + }; Rotations and shears are interesting. > @@ -2766,6 +2793,108 @@ static void test_rectangle_geometry(void) > ok(SUCCEEDED(hr), "FillContainsPoint() failed, hr %#x.\n", hr); > ok(!!contains, "Got wrong hit test result %d.\n", contains); > > + /* Stroked area hittesting. Edge. */ > + contains = FALSE; > + set_point(&point, 0.4f, 10.0f); > + hr = ID2D1RectangleGeometry_StrokeContainsPoint(geometry, point, 1.0f, NULL, NULL, 0.0f, &contains); > + ok(SUCCEEDED(hr), "StrokeContainsPoint() failed, hr %#x.\n", hr); > + ok(!!contains, "Got wrong hit test result %d.\n", contains); We tend to use %#x for BOOLs. And well, you might as well make these array based as well.

2 2

Re: [PATCH 1/2] msvcrt: Back up and restore the FPU state in setjmp/longjmp on arm
by Alexandre Julliard 08 Sep '17

08 Sep '17

Martin Storsjo <martin(a)martin.st> writes: > Signed-off-by: Martin Storsjo <martin(a)martin.st> > --- > dlls/msvcrt/except_arm.c | 22 ++++++++++++++++++++-- > 1 file changed, 20 insertions(+), 2 deletions(-) This doesn't build here with the Android NDK: arm-linux-androideabi-gcc -c -o except_arm.o ../../../wine/dlls/msvcrt/except_arm.c -I. -I../../../wine/dlls/msvcrt \ -I../../include -I../../../wine/include -D__WINESRC__ -D_MT -D_MSVCR_VER=0 -D_REENTRANT -fPIC \ -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret -D__ANDROID_API__=26 -marm {standard input}: Assembler messages: {standard input}:44: Error: selected processor does not support ARM mode `vmrs r2,fpscr' {standard input}:46: Error: selected processor does not support ARM mode `vstr d8,[r0,#0x30]' {standard input}:47: Error: selected processor does not support ARM mode `vstr d9,[r0,#0x38]' {standard input}:48: Error: selected processor does not support ARM mode `vstr d10,[r0,#0x40]' {standard input}:49: Error: selected processor does not support ARM mode `vstr d11,[r0,#0x48]' {standard input}:50: Error: selected processor does not support ARM mode `vstr d12,[r0,#0x50]' {standard input}:51: Error: selected processor does not support ARM mode `vstr d13,[r0,#0x58]' {standard input}:52: Error: selected processor does not support ARM mode `vstr d14,[r0,#0x60]' {standard input}:53: Error: selected processor does not support ARM mode `vstr d15,[r0,#0x68]' {standard input}:75: Error: selected processor does not support ARM mode `vmsr fpscr,r3' {standard input}:76: Error: selected processor does not support ARM mode `vldr d8,[r0,#0x30]' {standard input}:77: Error: selected processor does not support ARM mode `vldr d9,[r0,#0x38]' {standard input}:78: Error: selected processor does not support ARM mode `vldr d10,[r0,#0x40]' {standard input}:79: Error: selected processor does not support ARM mode `vldr d11,[r0,#0x48]' {standard input}:80: Error: selected processor does not support ARM mode `vldr d12,[r0,#0x50]' {standard input}:81: Error: selected processor does not support ARM mode `vldr d13,[r0,#0x58]' {standard input}:82: Error: selected processor does not support ARM mode `vldr d14,[r0,#0x60]' {standard input}:83: Error: selected processor does not support ARM mode `vldr d15,[r0,#0x68]' Makefile:311: recipe for target 'except_arm.o' failed -- Alexandre Julliard julliard(a)winehq.org

2 4

Strange behaviour of CreateProcess with Linux binary.
by John Found 08 Sep '17

08 Sep '17

I have a program running under WINE that need to start some external programs using CreateProcess API function. Some of these programs are Linux ELF executables, some are Windows PE. But recently, after some updates of my Linux distribution (Manjaro 64bit) some of the Linux executables stopped to start this way. CreateProcess returns 0, GetLastError returns 0C1h (193) == ERROR_BAD_EXE_FORMAT The same executable runs fine when started from the Linux path. One example file that behaves such way is xfce4-terminal (but the problem is not limited to only this file). For now I am wrapping such executables in short bash script in order to workaround: #!/usr/bin/sh /usr/bin/xfce4-terminal "$@" Any ideas about what is the problem and how can be fixed? -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound(a)asm32.info>

2 2

Re: [PATCH] comctl32/listview: Send NM_RELEASEDCAPTURE after the window focus has changed
by Nikolay Sivov 08 Sep '17

08 Sep '17

What use case does this fix? With this patch notification order is more broken than without. On Windows when clicking on item of unfocused control gives roughly: NM_RELEASEDCAPTURE LVN_ITEMCHANGING/LVN_ITEMCHANGED NM_CUSTOMDRAW NM_SETFOCUS NM_CLICK Without this patch we currently do: NM_RELEASEDCAPTURE LVN_ITEMCHANGIN/LVN_ITEMCHANGED NM_SETFOCUS NM_CLICK With the patch: LVN_ITEMCHANGING/LVN_ITEMCHANGED NM_SETFOCUS NM_RELEASECAPTURE NM_CLICK (in both cases on Wine sequence is interleaved with some NM_CUSTOMDRAW)

2 2

Re: webservices: Make alloc_float_text() static.
by Hans Leidekker 08 Sep '17

08 Sep '17

On Fri, 2017-09-08 at 02:24 +0200, Francois Gouget wrote: > dlls/webservices/reader.c | 2 +- > dlls/webservices/webservices_private.h | 1 - > 2 files changed, 1 insertion(+), 2 deletions(-) > > It was introduced in 82306e84 on 2017-07-20 and has not been used > outside reader.c since then. Ignore this patch if there are ongoing > plans to use it elsewhere. It will be used in the writer at some point.

1 0

Re: msi: Make MSI_ProcessMessageVerbatim() static.
by Hans Leidekker 08 Sep '17

08 Sep '17

On Fri, 2017-09-08 at 02:12 +0200, Francois Gouget wrote: > diff --git a/dlls/msi/msipriv.h b/dlls/msi/msipriv.h > index f316c0cce74..1bb0a849eed 100644 > --- a/dlls/msi/msipriv.h > +++ b/dlls/msi/msipriv.h > @@ -872,7 +872,6 @@ extern UINT MSI_SetInstallLevel( MSIPACKAGE *package, int iInstallLevel ) DECLSP > extern MSIPACKAGE *MSI_CreatePackage( MSIDATABASE *, LPCWSTR ) DECLSPEC_HIDDEN; > extern UINT MSI_OpenPackageW( LPCWSTR szPackage, MSIPACKAGE **pPackage ) DECLSPEC_HIDDEN; > extern UINT MSI_SetTargetPathW( MSIPACKAGE *, LPCWSTR, LPCWSTR ) DECLSPEC_HIDDEN; > -extern INT MSI_ProcessMessageVerbatim( MSIPACKAGE *, INSTALLMESSAGE, MSIRECORD * ) DECLSPEC_HIDDEN; > extern INT MSI_ProcessMessage( MSIPACKAGE *, INSTALLMESSAGE, MSIRECORD * ) DECLSPEC_HIDDEN; > extern MSICONDITION MSI_EvaluateConditionW( MSIPACKAGE *, LPCWSTR ) DECLSPEC_HIDDEN; > extern UINT MSI_GetComponentStateW( MSIPACKAGE *, LPCWSTR, INSTALLSTATE *, INSTALLSTATE * ) DECLSPEC_HIDDEN; > diff --git a/dlls/msi/package.c b/dlls/msi/package.c > index 47164613209..a88609a3dd8 100644 > --- a/dlls/msi/package.c > +++ b/dlls/msi/package.c > @@ -1444,6 +1444,8 @@ UINT msi_set_original_database_property( MSIDATABASE *db, const WCHAR *package ) > return r; > } > > +static INT MSI_ProcessMessageVerbatim(MSIPACKAGE*,INSTALLMESSAGE,MSIRECORD*); I'd prefer moving this function (and internal_ui_handler) up.

1 0

Re: [PATCH 1/3] d3dx9/tests: Add test for null shaders in effect.
by Matteo Bruni 07 Sep '17

07 Sep '17

2017-09-01 20:19 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > +static void test_effect_null_shader(void) > +{ > + D3DPRESENT_PARAMETERS present_parameters = {0}; > + IDirect3DDevice9 *device; > + ID3DXEffect *effect; > + D3DXPASS_DESC desc; > + IDirect3D9 *d3d; > + D3DXHANDLE pass; > + ULONG refcount; > + HWND window; > + HRESULT hr; > + > + /* Creating a fresh device because the existing device can have invalid render states > + from previous tests. If IDirect3DDevice9_ValidateDevice() returns certain error codes, > + native ValidateTechnique() fails. */ We generally want to be sure that each test is independent from the others so creating a separate device for each test function is a good idea regardless. Your point about ValidateDevice() is very interesting though, actually it makes a lot of sense and it probably means that ValidateTechnique() should delegate a good chunk of its work to ValidateDevice() (not surprising but somehow I forgot about it). It would be interesting to extend the d3d9 ValidateDevice() tests at some point.

1 0