- wine-devel - winehq.org

Re: msvcrt: Use Dragon4 algorithm to fix inconsistent rounding behaviour for sprintf and add tests. The Dragon4 algorithm implementation is based on http://www.ryanjuckett.com/programming/printing-floating-point-numbers/.
by YongHao Hu 31 Mar '15

31 Mar '15

Excuse me, Is there anything to do to improve this patch? Thanks. On 2015年03月25日 15:46, YongHao Hu wrote: > Try 3: > - Superseded Patch 109456. > - Use appropriate win32 types instead of typedef. > (Thanks Dmitry Timoshkov) > > Try 2: > - Superseded Patch 109432 > - Use typedef instead of C99 types > - Delete useless #ifndef > - Add memset to test > > Try1: > - Fix bug https://bugs.winehq.org/show_bug.cgi?id=37913 . > - The Dragon4 algorithm implementation is based on > http://www.ryanjuckett.com/programming/printing-floating-point-numbers/. > > --- > dlls/msvcrt/dragon4.h | 668 > ++++++++++++++++++++++++++++++++++++++++++ > dlls/msvcrt/printf.h | 43 +-- > dlls/msvcrt/tests/printf.c | 96 ++++++ > dlls/msvcrt/wine_printfloat.h | 246 ++++++++++++++++ > 4 files changed, 1036 insertions(+), 17 deletions(-) > create mode 100644 dlls/msvcrt/dragon4.h > create mode 100644 dlls/msvcrt/wine_printfloat.h > >

2 2

Re: [7/8] server: Implement waiting for job objects.
by Marvin 31 Mar '15

31 Mar '15

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=12521 Your paranoid android. === w7u (32 bit process) === process.c:2552: Test failed: WaitForSingleObject returned 258

1 0

Re: [1/8] server: Basic implementation of job objects. (rev 2)
by Marvin 30 Mar '15

30 Mar '15

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=12516 Your paranoid android. === w7u (32 bit process) === process.c:2532: Test failed: WaitForSingleObject returned 258

1 0

Re: [PATCH 3/3] comctl32/listview: Always forward HDM_SETORDERARRAY to a header
by Marvin 30 Mar '15

30 Mar '15

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=12515 Your paranoid android. === w2000pro (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2003std (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w7u (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w8 (32 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5162: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5167: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

1 0

Re: [PATCH 7/7] ddraw/tests: Port the lighting test to the previous d3d versions.
by Marvin 30 Mar '15

30 Mar '15

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=12513 Your paranoid android. === wvistau64 (32 bit ddraw1) === ddraw1.c:2498: Test failed: Expected message 0x46, but didn't receive it. ddraw1.c:2500: Test failed: Expected screen size 1024x768, got 0x0. ddraw1.c:2506: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2537: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2545: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2572: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2592: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2616: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2643: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2660: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2697: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2708: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2735: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2755: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2772: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2799: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2816: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. ddraw1.c:2854: Test failed: Expected {0, 0, 1024, 768}, got {-8, -8, 1032, 746}. === w8 (32 bit ddraw1) === ddraw1.c:1376: Test failed: Expected color 0x00ff0000 for test 0, got 0x0000ff00. ddraw1.c:1400: Test failed: Expected color 0x000000ff for test 0, got 0x0000ff00.

1 0

Re: [PATCH 6/7] ddraw/tests: Add more d3d7 lighting tests.
by Marvin 30 Mar '15

30 Mar '15

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=12512 Your paranoid android. === w8 (32 bit visual) === visual.c:1494: Test failed: unexpected colortable on offscreen surface

1 0

Re: [PATCH 3/7] ddraw: Make sure to activate / deactivate the light on D3DLIGHT_ACTIVE flag changes.
by Sergey Isakov 30 Mar '15

30 Mar '15

Sorry, but seems current revision has no “flags” variable On 30 марта 2015 г., at 21:18, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > --- > dlls/ddraw/light.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/dlls/ddraw/light.c b/dlls/ddraw/light.c > index baaf6a3..c632c32 100644 > --- a/dlls/ddraw/light.c > +++ b/dlls/ddraw/light.c > @@ -201,7 +201,11 @@ static HRESULT WINAPI d3d_light_SetLight(IDirect3DLight *iface, D3DLIGHT *data) > > wined3d_mutex_lock(); > memcpy(&light->light, data, sizeof(D3DLIGHT)); > - if (flags & D3DLIGHT_ACTIVE) > + if (!(light->light.dwFlags & D3DLIGHT_ACTIVE) && flags & D3DLIGHT_ACTIVE) > + light_activate(light); > + else if (light->light.dwFlags & D3DLIGHT_ACTIVE && !(flags & D3DLIGHT_ACTIVE)) > + light_deactivate(light); > + else if (flags & D3DLIGHT_ACTIVE) > light_update(light); > light->light.dwFlags = flags; > wined3d_mutex_unlock(); > -- > 2.0.5 > > >

1 0

Re: [PATCH 1/5] wined3d: Give tex_type and its values a better name.
by Henri Verbeet 30 Mar '15

30 Mar '15

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > @@ -179,7 +179,7 @@ static void surface_get_blt_info(GLenum target, const RECT *rect, GLsizei w, GLs > case GL_TEXTURE_2D: > info->binding = GL_TEXTURE_BINDING_2D; > info->bind_target = GL_TEXTURE_2D; > - info->tex_type = tex_2d; > + info->tex_type = WINED3D_FFP_TEXTURE_TYPE_2D; > coords[0][0] = (float)rect->left / w; > coords[0][1] = (float)rect->top / h; > coords[0][2] = 0.0f; Note that there isn't anything particularly fixed-function about blits. That currently doesn't matter a whole lot since this is effectively only used for onscreen/offscreen depth blits, but I get the impression your intention is to use this for the blitter interface in general. In that case, something like wined3d_shader_resource_type may be more appropriate, since eventually we'll have to deal with e.g. buffers and array textures as well (for ID3D10Device::CopySubresourceRegion() in particular.) > +enum wined3d_ffp_texture_type > { > - tex_1d = 0, > - tex_2d = 1, > - tex_3d = 2, > - tex_cube = 3, > - tex_rect = 4, > - tex_type_count = 5, > + WINED3D_FFP_TEXTURE_TYPE_1D = 0, > + WINED3D_FFP_TEXTURE_TYPE_2D = 1, > + WINED3D_FFP_TEXTURE_TYPE_3D = 2, > + WINED3D_FFP_TEXTURE_TYPE_CUBE = 3, > + WINED3D_FFP_TEXTURE_TYPE_RECT = 4, > + WINED3D_FFP_TEXTURE_TYPE_COUNT = 5, > }; Somewhat related to above, if this is supposed to be fixed-function we don't need WINED3D_FFP_TEXTURE_TYPE_1D. If it's supposed to be for blits we do, but the "FFP" in the name would be inappropriate. > -/* Similar to tex_types, except that it doesn't have 1d textures > - * (can't be bound), rect textures (handled via np2_fixup) and > - * none / unknown (treated as 2d and handled via dummy textures). */ > +/* Similar to wined3d_ffp_texture_type, except that it doesn't > + * have 1d textures (can't be bound), rect textures (handled via > + * np2_fixup) and none / unknown (treated as 2d and handled via > + * dummy textures). */ wined3d_ffp_texture_type doesn't have a none/unknown element either.

2 2

Re: [PATCH 3/5] wined3d: Use bitfields in struct arbfp_blit_type.
by Henri Verbeet 30 Mar '15

30 Mar '15

On 28 March 2015 at 17:06, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > struct arbfp_blit_type > { > - enum complex_fixup fixup; > - GLenum textype; > + enum complex_fixup fixup : 4; > + enum wined3d_ffp_texture_type textype : 3; > + unsigned padding : 1; > }; > I don't keep a very close eye on arb_program_shader.c, but I suspect this doesn't quite do what you think it does. The structure is going to get aligned to the alignment of the largest scalar field (which would be 32 bits in this case because of enum/unsigned), so you'll have another 24 bits of padding after the "padding" field.

1 0

Re: dwrite/tests: Test the correct return code.
by Marvin 30 Mar '15

30 Mar '15

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=12500 Your paranoid android. === wvistau64 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w2008s64 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w7u (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === w8 (32 bit font) === font.c:1818: Test failed: got 0x8faecafe === wvistau64 (64 bit font) === font.c:1818: Test failed: got 0x8faecafe === w2008s64 (64 bit font) === font.c:1818: Test failed: got 0x8faecafe

1 0

Re: [7/7] ws2_32: Better trace setsockopt/getsockopt (try 2)
by Alexandre Julliard 30 Mar '15

30 Mar '15

Bruno Jesus <00cpxxx(a)gmail.com> writes: > Use wine_dbg_sprintf instead of plain sprintf, that simplified the patch =) What you really want is to implement a debugstr_sockopt and something like a debugstr_optval and use these in normal TRACE statements, instead of hiding the trace inside a helper function. Also you can't append to a wine_dbg_sprintf string, that's why it's const... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32: add a stub for QueryThreadCycleTime
by Dmitry Timoshkov 30 Mar '15

30 Mar '15

Austin English <austinenglish(a)gmail.com> wrote: > +@ stdcall QueryThreadCycleTime(ptr ptr) ... > +BOOL WINAPI QueryThreadCycleTime(HANDLE thread, PULONG64 cycle) 'ptr' is not suitable for HANDLE in the .spec file. -- Dmitry.

1 0

Re: d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame
by Stefan Dösinger 29 Mar '15

29 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-29 um 15:37 schrieb Aaryaman Vasishta: > + { &IID_IDirect3DRM, NULL, E_NOINTERFACE, FALSE }, It's funny that this interface returns the right error value on QI. > + hr = IDirect3DRM_CreateFrame(d3drm3, NULL, &frame3); Minor nitpick: IDirect3DRM3_CreateFrame . You can resend the patch with a fix if you want, but I'm OK with this patch as it is. Something to think about for future tests: It may make sense to split up d3drm.c into d3drm1.c, d3drm2.c and d3drm3.c for each interface version, similar to the ddraw tests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVGBWOAAoJEN0/YqbEcdMwLkUP/3S8gOP5XSYOgOkELFOSznNp ir09O5ef1HUpECpZjCks7ez4IbUhswcb/idJ3UeEx3lSBy4vIk3vY0usXcXKkfMl TlioDlOuzKhpXxb/5lZ/SUoG/nguBvzisKeifAA1gi8ne+3REhWeJvY6iBNDNDEX dNUYiTP+qxsq8c+bzgydxDuu0OT7LVEXrVrDO1g3qOebJjFSdkXOnf1bCntejX4S WdnxPlioWBMvffP42r0oinXzjoqobi5BDw8r4YppflEUou1bH3oT7fczJEpK4rBm 2ZDz9EOhvMOa6M5PSiqwPpINfI1PpH+p9S0r3iMZz8ux2VbXDyfJ0i/5CdzQ3HX8 rnNq/NcObXVgweBYIN7uFvjlo0Si963ACYDperAVyBNgP/oJXsz3dA5ysvrf6Lf8 Xy1kdP2B79AxWR3DRumQS9sbruaofENF16/7d9MZE933uWY9xBS6JIKTP0AVdDsP tqF8ppHwVdPfpiazYnrG1ivpE0jNIPJJ67I6FWRC1S8k7QQVmbAdVnDgczDs6lLx hiZbjksd4Uf16oGO29bXeZ2YM3Zi75K9pCa7ruYoftcF2ihd0tU01+jbM6hY32qm K1RKe7/HCMANoal7pQEukARHVRvHDpVFRGJzeMbysc8yumnpbgl7/UI9z0wZvoYI aCAXfxi21aSdCzxC7mIU =9SMA -----END PGP SIGNATURE-----

2 2

Re: [PATCH 4/5] comctl32/listview: Always forward LVM_GETCOLUMNORDERARRAY to header
by Marvin 29 Mar '15

29 Mar '15

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=12491 Your paranoid android. === w7u (32 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === wvistau64 (64 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000 === w2008s64 (64 bit listview) === listview.c:5141: Test failed: NM_HOVER allow test: the msg sequence is not complete: expected 0087 - actual 0000 listview.c:5146: Test failed: NM_HOVER block test: the msg sequence is not complete: expected 0087 - actual 0000

2 1

Re: dsound: Fix angle to sound source calculation.
by Andrew Eikum 29 Mar '15

29 Mar '15

Forwarding on to wine-devel, Stas, and Ruslan from Bug 38041. Any thoughts on the coning breakage, Stas? Andrew On Mon, Mar 23, 2015 at 09:52:32PM +0000, Mark Harmstone wrote: > Hi, > > I've had a play with it, and yes, I think he's right. It seems to be a > lot more robust than my code. One thing though that I think he's > overlooked is that he changes the behaviour of AngleBetweenVectorsRad, > which is called by AngleBetweenVectorsDeg and thus the coning code - > I think this patch will probably break that. > > I've not tested it yet, but there's a chance this patch might fix > bug 38041. > > Mark > > On 23/03/15 14:39, Andrew Eikum wrote: > > This seems sane to me, but I never had a good grasp on this to begin > > with. Does it look OK to you, Mark? > > > > Andrew > > > > On Sun, Mar 22, 2015 at 08:59:15PM +0300, Стас Цымбалов wrote: > >> This patch fixes incorrect sound positioning in dsound. > >> As of now, angle to sound source is calculated as angle between > >> vDistance and vOrientFront. > >> This leads to incorrect results for all sources that are not in the > >> same plane as speakers. > >> In extreme case: for sources directly above or below origin, angle is > >> calculated to -90 degrees, and they are played in the left speaker. > >> > >> This patch changes angle calculation: angle to sound source is > >> calculated as angle between vDistance and plane given by vectors > >> vOrientFront and vOrientTop. > >> --- > >> dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > >> 1 file changed, 14 insertions(+), 11 deletions(-) > > > >> From 1ebe3761b0d6acfca58cec17472336a05b7f2679 Mon Sep 17 00:00:00 2001 > >> From: Stas Cymbalov <dummyunit(a)gmail.com> > >> Date: Sun, 22 Mar 2015 18:22:49 +0300 > >> Subject: dsound: Fix angle to sound source calculation. > >> > >> --- > >> dlls/dsound/sound3d.c | 25 ++++++++++++++----------- > >> 1 file changed, 14 insertions(+), 11 deletions(-) > >> > >> diff --git a/dlls/dsound/sound3d.c b/dlls/dsound/sound3d.c > >> index 9a0226a..ffd4d45 100644 > >> --- a/dlls/dsound/sound3d.c > >> +++ b/dlls/dsound/sound3d.c > >> @@ -112,7 +112,6 @@ static inline D3DVALUE AngleBetweenVectorsRad (const D3DVECTOR *a, const D3DVECT > >> > >> cos = product/(la*lb); > >> angle = acos(cos); > >> - if (cos < 0.0f) { angle -= M_PI; } > >> TRACE("angle between (%f,%f,%f) and (%f,%f,%f) = %f radians (%f degrees)\n", a->x, a->y, a->z, b->x, > >> b->y, b->z, angle, RadToDeg(angle)); > >> return angle; > >> @@ -264,16 +263,20 @@ void DSOUND_Calc3DBuffer(IDirectSoundBufferImpl *dsb) > >> else > >> { > >> vLeft = VectorProduct(&dsb->device->ds3dl.vOrientFront, &dsb->device->ds3dl.vOrientTop); > >> - flAngle = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > >> - flAngle2 = AngleBetweenVectorsRad(&vLeft, &vDistance); > >> - > >> - /* AngleBetweenVectorsRad performs a dot product, which gives us the cosine of the angle > >> - * between two vectors. Unfortunately, because cos(theta) = cos(-theta), we've no idea from > >> - * this whether the sound is to our left or to our right. We have to perform another dot > >> - * product, with a vector at right angles to the initial one, to get the correct angle. > >> - * The angle should be between -180 degrees and 180 degrees. */ > >> - if (flAngle < 0.0f) { flAngle += M_PI; } > >> - if (flAngle2 > 0.0f) { flAngle = -flAngle; } > >> + /* To calculate angle to sound source we need to: > >> + * 1) Get angle between vDistance and a plane on which angle to sound source should be 0. > >> + * Such a plane is given by vectors vOrientFront and vOrientTop, and angle between vector > >> + * and a plane equals to M_PI_2 - angle between vector and normal to this plane (vLeft in this case). > >> + * 2) Determine if the source is behind or in front of us by calculating angle between vDistance > >> + * and vOrientFront. > >> + */ > >> + flAngle = AngleBetweenVectorsRad(&vLeft, &vDistance); > >> + flAngle2 = AngleBetweenVectorsRad(&dsb->device->ds3dl.vOrientFront, &vDistance); > >> + if (flAngle2 > M_PI_2) > >> + flAngle = -flAngle; > >> + flAngle -= M_PI_2; > >> + if (flAngle < -M_PI) > >> + flAngle += 2*M_PI; > >> } > >> TRACE("panning: Angle = %f rad, lPan = %d\n", flAngle, dsb->volpan.lPan); > >> > >> -- > >> 2.0.5 > >> > > > >> > > >

4 4

Re: d3drm/tests: Add QueryInterface tests for IDirect3DRMFrame
by Marvin 29 Mar '15

29 Mar '15

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=12490 Your paranoid android. === w2000pro (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 780273CD === wxppro (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 77C46F07 === w2003std (32 bit d3drm) === d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 1, expected 0. d3drm.c:1738: Test failed: Got refcount 2 for test "frame_qi" 0, 2, expected 0. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 3. d3drm.c:1728: Test failed: Got hr 0x80040111 for test "frame_qi" 0, 4. d3drm.c:1728: Test failed: Got hr 0 for test "frame_qi" 0, 5. d3drm: unhandled exception c0000005 at 77BD7D8D

1 0

Re: [PATCH] user32: Support activation context class redirection in CreateWindow.
by Nikolay Sivov 29 Mar '15

29 Mar '15

On 03/29/2015 01:54 AM, Mark Harmstone wrote: > This patch implements the class redirection feature of activation contexts, as > used by version 6 of comctl32. Among other things, this is a necessary step in > fixing the behaviour seen in bug 38124. > > --- > dlls/user32/win.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 62 insertions(+) > In principle it looks almost okay, except that I don't think we need it right now, as long as comctl32 doesn't register versioned classes at all. It will just wait time for every window creation requested looking for something that can't be created. Comments on code itself to follow. > + classatom = get_int_atom_value(className); > + if (classatom) > + GlobalGetAtomNameW(classatom, classNameStr, sizeof(classNameStr) / sizeof(*classNameStr)); > + else > + strcpyW(classNameStr, className); You don't need to copy in case of a string. > + if (wcrd->name_len == 0) > + return FALSE; I don't think it can be 0, ever. Name comes from class name from module manifest and assembly version string. > + memcpy(redirClassName, (unsigned char*)askd.lpData + wcrd->name_offset, wcrd->name_len); > + redirClassName[wcrd->name_len / sizeof(WCHAR)] = 0; All strings in context data are null-terminated, so you don't need this complexity. In fact you don't need to copy anything at all, you can just use a (WCHAR*)((BYTE*)askd.lpData + wcrd->name_offset) as a ready-to-use pointer, I think it's a preferred way, given that overhead of this redirection lookup should be minimal. So your helper only needs to return a pointer - original one or computed from redirection data. And atoms should be resolved outside of it. > + WCHAR redirClassName[256]; Is it defined somewhere to be limited to that? > + > + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode ); > + > + if (GetLastError() == ERROR_INVALID_HANDLE && GetClassInfoW( 0, redirClassName, &wc )) > + wndPtr = create_window_handle( parent, owner, redirClassName, module, unicode ); > + I don't quite get what you're trying to do here? How does same call help if called second time? Also last error check is strange.

1 0

Re: [PATCH] wined3d: Fix some videocards property detection
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This patch has a few unrelated changes. The core change is that it re-introduces a hack we once had in Wine and removed because it broke newer mac GPUs. The CrossOver version of the hack works a bit better than the unconditional Wine version, but it's still ugly. Am 2015-03-28 um 06:15 schrieb Sergey Isakov: > + /* Non-Apple GL vendors report uniforms correctly */ > + if (!match_apple(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return FALSE; > + /* All dx9 cards are overreported on OSX */ > + if (!match_dx10_capable(gl_info, gl_renderer, gl_vendor, card_vendor, device)) return TRUE; > + /* Nvidia and Intel DX10 cards support > 256 uniforms */ > + if (card_vendor != HW_VENDOR_AMD) return FALSE; It is terrible that OSX lies about the GPU capability and then forces applications to have a crystal ball that tells them what the GPU can actually do. - From a pragmatic point of view I don't think OSX will ever change in this regard. It was a design decision by Apple to do this, and they stopped updating drivers for the old hardware a long time ago. I am open to re-introducing the hack if we can find a way to detect the bug more directly. E.g. try to declare a shader with 257 uniforms, read them with indirect addressing so the driver can't optimize the access and then check for software fallbacks. There's a CGL function for checking that, but I don't remember from the top of my head how it works. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFoC/AAoJEN0/YqbEcdMwcUIP/Rw24kSROYMK2Xvfe9vyEZ9S NQd9RPHRQRNiXuXRfAmAUKm/PF17O7SUMKLAwjg90HGZySdDOH4MCb7rwaXryKYU qV1ba75KR/JOi7db0r/WrZjf+mQ2+z1hES0SEg9jSYHxIcSNRhWvjB3H3rId7Och TAEvsiT897rE7U/2GQmnw9popFPOPRm0Y2YY4f1XecF1XSdmBokpdmpcDzoRTxbX 8q11cWlPyqi3u6xiyX7SwEwoh7v/zpNd4c1yuL6kytSfV1w+sD4fMC4BitIvfd2X OltqvQz5MfexglNlLJaeE1yplhrEKE2NHHdoIXhOhg7TdOeHYJfvrzgpjLWlUVnC 6BWsSkgge3OO3Pk7Fhi7Lht0EPhds+iq+7NCLwDV051Qi89kBlyJOY33bMMjryez wHo+YEZEvk0IkkVQGkAjJfZzLFtxjMzIxcixijkJc3/aYwuF0ZyDVqFe3hj4gPTw Ei1IThyWC4hdVqIuduD4t+5VH3GwU6JiYE6a16uHVTfoTSboN9te1WzV+lnhRFMf P54xaJ+98sJrpq+670WU68jHzM/BmXXojyF+lxv8t0noXmHLJy7S4yskzDhowMMG myjbDbeb/fB2O/oSdeOEXkskl2+XkotROM9qwF7a/yyaGe1/f47Y16gmrPyeCFD5 0Z68wLM5//XliOz91+hs =1uP/ -----END PGP SIGNATURE-----

2 1

[BISECTED REGRESSION] file dialog does not shown
by Andrey Skvortsov 28 Mar '15

28 Mar '15

Hi, original problem is described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I have the same problem with running Nanocad 5.1. The file open/import dialog does not open with wine-1.7.39. I bisected the problem to commit: [bbf2cce16041e90d621a1f5889ea1bd760e21a0e] comdlg32: Do not modify dialog resource directly. I reverted this commit on latest wine and that fixed my issue with file open dialog. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

2 1

Re: [PATCH] wined3d: Fix some videocards property detection
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Please keep wine-devel in CC. There are more developers than just myself :-) . Am 2015-03-28 um 12:38 schrieb Sergey Isakov: > I know this crash. It was appeared because this patch was > introduced in the wrong place as I describe in the bug 38277 Too > slow test Advanced Pixel Shaders in 3DMark2001SE > <https://bugs.winehq.org/show_bug.cgi?id=38277> My patch works > fine. It may work fine on the Macs you tested or even all the macs that ever shipped, but it is still ugly to hardcode GPU capabilities that the driver should provide. There are OpenGL flags winemac.drv can set to disable the software fallback: https://developer.apple.com/library/mac/qa/qa1502/_index.html . What happens when you set them? Do they influence the reported capabilities? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFpW6AAoJEN0/YqbEcdMwaz4P/298Ha4rtgWPYEFF+w6HzAWP f7G9fenhHkgjaudNwjcFXTr1dweYTVwvVll5Ahpu9bRd4iC/hM4jyKf2TVcpcXbM +yIri1UnsgSt63YJ1+XRfvVsV28BYlhqnlZvqKkmNHf/5dxg0iOfz0noDYAcspFZ BjfVQOFgaRmuiS9AyVpgc5WO2+IptKvDa1ExSOSNhOO5ye7T9Nh071QoWCgakqza invrADPRjRm/Ri7JV6CtQeRZCLYdMjeONchhJOHif2KYjk8/J5PNVAUeSSt73ZXQ TPA/VmPAs9mge3QlKgD9NgIab8auPt0tHW3MLLluKbLmwOJSMsOuxx85VC4yxlvK K/h0Q7Ldx8BvmsraLjmNMPmB9FMUNuxmEhjrkdbN90v9FwfsfZs5PGm6V+Rmt4uq gBHQxY2wd6xUt6I4AFH+6s088Ubl7zQRdAsE12LTMnRHF0ctIvHZCVdtdgVG/0hu ZpxrnHgoWm4E9arzslkHOxaqAh1Tln8k9WtpF6PcGNv4xbLWKLNiRBHMF4fK9MQI PtbT7gzL71+38lArzqnCzKb4Ijw1X7PkgA//4ZlkENyCp9SKxWpLQaDq853mhGlQ Q8z6TqAgb1wIwqO/rfiX6Rqj+aWt9Zet4XDhLaLbsifRnGjr4gad9LSC28GzQfet d80ZXwigJshmdtl05+I6 =+1lX -----END PGP SIGNATURE-----

2 2

Re: [PATCH] krnl386.exe16: Fix NULL pointer dereferencing
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-27 um 19:16 schrieb Sergey Isakov: > This if statement body will perform only if driver_request is NULL > pointer. Next statements will cause crash. Bug 38159 NULL pointer > dereferencing <https://bugs.winehq.org/show_bug.cgi?id=38159> I think in this case the segfault is intentional. The caller passes a stupid parameter. Also I'm not sure if it actually segfaults. In vm86 mode memory is mapped to this page, so NULL may be a valid address. The best solution would be to write a test and see what happens on an ancient DOS, but we don't have a test infrastructure for DOS and Win16. The next best idea might be to just remove the entire block. It's funny though since (according to git) the patch that added this check already added the "/* FIXME - to be deleted ?? */" comment. At some point we may as well remove the entire DOS code since we just call dosbox these days and 64 bit CPUs don't allow vm86 mode anyway. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFpBqAAoJEN0/YqbEcdMwVUQP/itrU95T4mlo2vo7f4J3k7fd Wx4goKV1/s5iPT+56T3q+MsqYp0gcNgmiwmVrf+HSNl94jXo1ysWfsuD1LeAAPGi O6FJBpszJdjw+fjm0whKidM3L+QYOEqGb/8AP5ZuXQ2zE0+iDA2cGo5oFrP2LpmM ZR7t3uYTIqk4VYWuZz4rlfSaHu552LpT/zEIYghteL/ANTqkad+oVleOFLB6Nbb/ j1PK7QKl6D+n6Kd2KSwlI9jj3XADf14i96J2knNh7yyLVZAsjNTe/3F9eoI98N5M cI22fGkW6jp70HoS1yMpJG66jqrhamAi6QBzMUI2cfAhHtjngKj36X3MRZMXIiK7 4E1g/Z7hcJ3ZtbrfzHnUdUXCQMXHszA93U69QRERTnjatDB+VNTZ67AaPGMXBiE9 2i5KlGg5TXjZPJwPqetHuGZ18uUXwCXfbC5+VPXP5AqbhxltE6IPfbKs95Bo90gh EvZsooU7pqNJxNAfscDIKliDsIcFV3TATqEyr/LCeczKNbE1DOKQ/afBrGyivabe f/YzcLLHfx5x8Lxx5bsmn2+3xR+LVfppH/rCSC5YA2ZwU6gB8NeuDAHh/BvsV7E1 i9IkN43sbQ4xZQFckBsyhdcpJd0kCCp3n1kmCfCWx3c2uIwLNvzzwT9HM8mY36my qcBfCcz1CCOpKpaayCSL =78sc -----END PGP SIGNATURE-----

1 0

Re: [PATCH] user32: Use function parameter if it set to be not stub
by Stefan Dösinger 28 Mar '15

28 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-03-27 um 21:52 schrieb Sergey Isakov: > { + if (!lpDisplayDevice) { + return FALSE; + } This is probably correct, but it needs a test. Currently this function crashes if this parameter is NULL. I can imagine that EnumDisplayDevices(NULL, 1, NULL, 0) returns TRUE if display 1 exists and FALSE otherwise. > + + if (i) { FIXME("(%s,%d,%p,0x%08x), > stub!\n",debugstr_w(lpDevice),i,lpDisplayDevice,dwFlags); - - if > (i) return FALSE; + } This is an unrelated change and matters more for what the patch description says it does. Though if I understand this right we want this check to be "if (i || lpDevice)" because the application can also pass in a device name. > > + if (lpDevice) { + strcpyW(lpDisplayDevice->DeviceName, > lpDevice); + } else { memcpy(lpDisplayDevice->DeviceName, > primary_device_name, sizeof(primary_device_name)); + } This is yet another unrelated change. It looks OK, but I don't think it really matters. Copying the input display name will at best paper over the fact that our implementation of this function does not support multiple display devices. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVFo0tAAoJEN0/YqbEcdMw+eQP/1SnlfkRjPZ/8PW8+m3iOYHC OTLWOE7Io94FzLfFQO487pCbsqgd9199UWp3IolfUe/y2vS4LtosxQQh1tLG7j7A rsypwNjV8OwSHvXiL5BH/4QvZTAqoctW484E7z7IHzMXMqa2Oyrj5K3QXHVes6O5 9xEB1UuSkB19Z0jIQqHPR4Hc/o8gYuCAER05BiTqOZcBSsrVhfOOZ+FKR7krWqdP o3VkOmUSWhX+9ziTsKmWGsBEZk0r81RMG2cbT/eShAtBBZs/+YtUfYiNY2q+tCoF fMiEfiMU7e1TqroBJAw37gYju+qt3xon/RuyOQD13a3hwWSDzMeoE9PAf9TxCK4Q OinEV45U8RiDkczviuOQluojfmJSXmVCC2BjPPQ2ZtmGXyuRXLrlRZ4KsCE/xhyV p2+Za2U/cvfqy0ug5isnnFGu/lKi1RCeGXsbHX6ZF5amTEfuklQpWolacrGilxZ2 kYiBtV93A/IJzUPaj2d97JbEFG2nMP6pT+KTSFBJIY2bzzzhnX1Fltd8kt3Vp/rv MOUPs/peC9sv17wDc5LREPAbA7LOBuN4M3M+5O2glO/F96gt8FSsPYyZy9sMRXEv eEuQgGbFbm9KKCWBK53mm78aAFiulqEd3S4vFXnvNU5sFxUW/BO3TxDZJhPEAK2v BeJJ0ZjH01mfQ8lhDQph =RL+u -----END PGP SIGNATURE-----

1 0

Re: [PATCH] vbscript: Fixed Hex
by Marvin 28 Mar '15

28 Mar '15

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=12482 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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: [PATCH] vbscript: Implemented Oct(try 3)
by Marvin 28 Mar '15

28 Mar '15

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=12480 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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: [2/9] kernel32/tests: Add tests for IsProcessInJob.
by Marvin 28 Mar '15

28 Mar '15

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=12470 Your paranoid android. === w7u (32 bit process) === process.c:2177: Test failed: WaitForSingleObject returned 258

2 1

Re: [PATCH] vbscript: Implemented Oct(try 2)
by Shuai Meng 28 Mar '15

28 Mar '15

Hi, I find Oct("test") returns error number 13 on windows, while 445 on wine. So I shall resend this patch. 2015-03-27 23:28 GMT+08:00 Shuai Meng <mengshuaicalendr(a)gmail.com>: > testbot: > https://newtestbot.winehq.org/JobDetails.pl?Key=12461 > Changelog: > Added support for other subtypes; > Added more tests. > --- > dlls/vbscript/global.c | 53 ++++++++++++++++++++++++++++++ > +++++++++++++-- > dlls/vbscript/tests/api.vbs | 31 ++++++++++++++++++++++++++ > 2 files changed, 82 insertions(+), 2 deletions(-) > > >

1 0

winegcc & stdin
by Leon Bogaert 27 Mar '15

27 Mar '15

I'm getting an error when using winegcc with stdin: > $ cat test.c | winegcc -xc -c - > gcc: warning: ‘-x c’ after last input file has no effect > gcc: error: -E or -x required when input is from standard input > winegcc: gcc failed Does anyone know what I could be doing wrong? I'm trying to use stdin because that's what the go (cgo) build tool is trying to use. Leon

2 2

Re: [PATCH] icnsformat.c: wrong pointer to formal parameters
by Bruno Jesus 27 Mar '15

27 Mar '15

On Fri, Mar 27, 2015 at 3:01 PM, Sergey Isakov <isakov-sl(a)bk.ru> wrote: > Bug 38288 > Wrong pointer in icnsformat.c IcnsFrameEncode_WriteSource Hi Sergey. Usually the patch subject is the dll name followed by the change. I think a better subject in this case would be: windowscodecs: Fix wrong pointer to formal parameter

1 0

[GSOC 2015] Direct3DRM - Implement rendering for D3DRM
by Aaryaman Vasishta 27 Mar '15

27 Mar '15

Hello! I have submitted my proposal on melange. Please take a look at it whenever possible. Any feedback would be very appreciated. Thank You! jam

1 0

[BISECTED REGRESSION] icons in nanocad have black background
by Andrey Skvortsov 27 Mar '15

27 Mar '15

Hi, The issue was originally described here: https://bugs.winehq.org/show_bug.cgi?id=34825 I bisected both issues, but I'll create separate thread to the issue with file dialog. First bad commit that causes black background on icons is: [ b81a7d976e3c3de36a01401d125871d3014e6c67 ] gdi32: Always use the DIB engine for monochrome bitmap rendering. To see how the issue looks like, I attached small screenshots. -- Best regards, Andrey Skvortsov Secure eMail with gnupg: See http://www.gnupg.org/ PGP Key ID: 0x57A3AEAD

2 1

Re: [PATCH] vbscript: Implemented Oct(try 2)
by Marvin 27 Mar '15

27 Mar '15

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=12462 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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: [PATCH] schannel_gnutls: when calling pgnutls_server_name_set ensure that the values are sane
by Jacek Caban 27 Mar '15

27 Mar '15

Hi Nikos, On 03/27/15 17:25, Nikos Mavrogiannopoulos wrote: > This patch addresses issue with schan_imp_set_session_target() > translation to gnutls API. It does not pass invalid (null) parameters to > it, as this seems to cause issues. Addresses > https://bugs.winehq.org/show_bug.cgi?id=38134 Take a look at schan_imp_set_session_target caller in schannel.c. It already ensures that passed target is not NULL. If your patch indeed fixes a real problem, it's probably because it also ignores an empty string. That's, however, something that should also be done on caller side. Thanks, Jacek

1 0

Re: [PATCH] wineconsole: Set input stream buffer length per OS limit
by Nikolay Sivov 27 Mar '15

27 Mar '15

On 26.03.2015 14:32, Hugh McMaster wrote: > --- > programs/wineconsole/wineconsole.c | 32 ++++++++++++++++++++++++++++++-- > 1 file changed, 30 insertions(+), 2 deletions(-) > > diff --git a/programs/wineconsole/wineconsole.c b/programs/wineconsole/wineconsole.c > index 3c2faf5..81300ed 100644 > --- a/programs/wineconsole/wineconsole.c > +++ b/programs/wineconsole/wineconsole.c > @@ -797,6 +797,11 @@ static UINT WINECON_ParseOptions(const char* lpCmdLine, struct wc_init* wci) > return 0; > } > > +#define MAXSTRING_NON_NT 128 > +#define MAXSTRING_NT351 260 > +#define MAXSTRING_NT4_W2K 2048 > +#define MAXSTRING_XP 8192 > + Why do you need this mess?

3 3

Re: [PATCH 5/6] wined3d: Introduce a shader_snprintf() function.
by Henri Verbeet 27 Mar '15

27 Mar '15

On 26 March 2015 at 20:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > It could be used in more places, some of them need additional rework > though. > I'm not sure this is what you had in mind. I didn't feel like making > these strings heap allocated, it seems to get quite ugly that way. It's not quite fully worked out at this point, but what I have in mind is roughly to use wined3d_shader_buffer. The shader_glsl_priv structure can then keep a list of scratch buffers from which you can get one to construct these kinds of intermediate strings and release back to when you're done with them. It would probably also involve cleanup functions for e.g. glsl_src_param and glsl_dst_param at some point. In principle this patch is in the right direction, but I'd rather avoid putting this in now and then having to change it again later.

1 0

Re: [PATCH] cmd: Add basic handling of Ctrl-C
by Nikolay Sivov 27 Mar '15

27 Mar '15

On 26.03.2015 14:32, Hugh McMaster wrote: > + /* Enable handling of Ctrl-C signals */ > + if (SetConsoleCtrlHandler((PHANDLER_ROUTINE)console_ctrl_handler, TRUE)) > + WINE_TRACE("cmd: Ctrl handler was installed.\n"); > + else > + WINE_ERR("cmd: Unable to install Ctrl handler.\n"); > + Judging by the fact that you needed a cast, that's not right.

3 3

Re: [PATCH 3/4] advapi32: Add DACL inheritance support in SetSecurityInfo
by Erich E. Hoover 27 Mar '15

27 Mar '15

On Thu, Mar 26, 2015 at 2:59 PM, Erich E. Hoover <erich.e.hoover(a)wine-staging.com> wrote: > On Thu, Mar 26, 2015 at 12:10 PM, Piotr Caban <piotr.caban(a)gmail.com> wrote: >> ... >> The inheritance doesn't occur when function from ntdll are used for setting >> DACL. This makes your code inside server incorrect. Also your code is not >> checking handle permissions correctly. If you try to test it keep in mind >> that if correct inheritance flags are set in security descriptor control >> field the permissions will be filled when you right-click on file and >> display security properties on windows. > > I don’t have the time to write a test at the moment, but I find it > highly unlikely that MS would implement security descriptors in a > high-level DLL. If that were the case then an application could > easily hijack the API in order to permit access to files that would > otherwise be inaccessible. I would guess that > UNPROTECTED_DACL_SECURITY_INFORMATION and SE_DACL_AUTO_INHERITED > probably enter into this somehow. > > Besides that I think we should start implementing stored ACLs first, > before even thinking about implementing suitable inheritance > mechanisms. I submitted a bunch of patches for this some time ago, > but Alexandre wasn’t happy with using extended user attributes to > store this information. I’m just not sure that it’s useful to > implement inheritance without storing the ACLs, it’ll certainly fix > some apps but it will likely break a bunch of others. Whoops, forgot reply-all - sorry for the duplicate Piotr. Best, Erich

2 1

Re: [PATCH 1/5] include: Add Wine-specific theming hook struct to winuser.h
by Alexandre Julliard 27 Mar '15

27 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > @@ -4060,6 +4060,15 @@ WORD WINAPI SYSTEM_KillSystemTimer( WORD ); > WINUSERAPI BOOL CDECL __wine_send_input( HWND hwnd, const INPUT *input ); > #endif > > +/* Wine-specific version of the undocumented structs > + * used by uxtheme to hook into user32. */ > + > +typedef struct > +{ > + WNDPROC DefWindowProcA; > + WNDPROC DefWindowProcW; > +} WINEUSERAPIHOOK; This doesn't belong in winuser.h. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] comctl32: Redraw themed button on WM_ENABLE.
by Alexandre Julliard 27 Mar '15

27 Mar '15

Mark Harmstone <hellas(a)burntcomma.com> writes: > When a themed button received a WM_ENABLE message, comctl32 redraws it, > then passes the message to the parent proc in user32. Unfortunately, this > is the wrong way round - as user32 redraws the window itself, the themed > button will be redrawn as its unthemed counterpart. It sounds like it's only hiding the problem. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] vbscript: Implemented Oct
by Marvin 27 Mar '15

27 Mar '15

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=12441 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === w2003std (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

2 1

Re: [2/3] windowscodecs: Implement PngDecoder_Block_GetCount.
by Alexandre Julliard 27 Mar '15

27 Mar '15

Vincent Povirk <madewokherd(a)gmail.com> writes: > From 398cd35190fddb05de97f6b125897be6c0e9e92d Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Wed, 25 Mar 2015 14:26:28 -0500 > Subject: [PATCH 2/3] windowscodecs: Implement PngDecoder_Block_GetCount. > > --- > dlls/windowscodecs/pngformat.c | 80 +++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 76 insertions(+), 4 deletions(-) ../../../tools/runtest -q -P wine -T ../../.. -M windowscodecs.dll -p windowscodecs_test.exe.so metadata && touch metadata.ok metadata.c:949: Test succeeded inside todo block: GetCount failed, hr=80070057 metadata.c:952: Test succeeded inside todo block: GetCount failed, hr=0 metadata.c:953: Test succeeded inside todo block: unexpected count 1 Makefile:375: recipe for target 'metadata.ok' failed -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/4] advapi32: Add DACL inheritance support in SetSecurityInfo
by Erich E. Hoover 26 Mar '15

26 Mar '15

I do not believe this is the correct place to make this change. Inheritance still needs to occur even when SetSecurityInfo is not used, which pretty much means it has to be within the wineserver itself so that the same code can be used for CreateFile. The code I put together for this (as written it is somewhat dependent on my other ACL code) can be found here: https://github.com/wine-compholio/wine-staging/tree/master/patches/server-I… The first patch is for CreateFile and the second one is for SetSecurityInfo. I'm happy to try and change this to help you solve your problem without my other ACL code, it's been on my TODO list anyway - I've just been too busy with work lately :/ Best, Erich

4 4

Re: urlmon: Remove unneeded NONAMELESSXXX directives.
by Jacek Caban 26 Mar '15

26 Mar '15

Hi Francois, On 03/26/15 15:29, Francois Gouget wrote: > Also put them in the files that need them. It may be a bit late for such question after so many patches already went in, but what's the point of this patch? Those defines are defined in central place, so that we don't have to deal with them in each .c file. Even if they are not needed for some .c files, they are harmless. BTW, I think we could even consider putting this macro in a central place like windef.h inside __WINESRC__ guard. Jacek

1 0

named memory-mapped file
by Leon Bogaert 26 Mar '15

26 Mar '15

Hi all, I don't know if this is the correct list. If it's not I'm sorry. I have kind of a weird question. I'm playing this game iRacing which exposed it's api via named memory map ( https://github.com/meltingice/node-iracing/blob/master/lib/irsdk_utils.cpp). Is there a way I can access that named memory-mapped file via Linux? I did some Googling and I don't think it's possible but I thought I made sure to ask around here. If that isn't possible I think I'll write a simple program that would run under wine and expose that data in a Linux-friendly manner. Leon

3 4

how to upload and view reports
by Shubham kumar 26 Mar '15

26 Mar '15

Sir, i have applied for winetest graphical user interface project. Problem is to see the test results in application itself we first need to know that how it shows report on test.winehq.org so that, we could get idea on how it shows report after uploading. But, on the website i could not find any link to upload the report. Where/How am i supposed to upload the report and view the test results on website?

2 1

Application for GSoc 2015 - Implement vbscript.dll builtins for Wine
by Shuai Meng 26 Mar '15

26 Mar '15

Hello everyone, I'm Shuai Meng, a student from Beihang University of China, who have attended Gosc 2014 for wine vbscript. I would like to continue to work on this module this year: on one hand, I am familiar with it through last year's experience; on the other hand, as I have studied it deeper and deeper, I find it more difficult than imagined, and I think understanding and fulfilling this interpreter of vbscript is very meaningful and interesting. Last year, the relatively simple built-in functions have been implemented by my effort, with the generous help of many warm-hearted people. The left functions are more challenging, I have to study more about COM and DLL in order to understand the mechanism. Now let's talk about the details of my plan, the functions unimplemented can be sorted as below: 1.The first kind is the functions about date and time, they have not been implemented because Wine's vbscript is not able to parse date constant in the form of "#yy-mm-dd#" yet. The functions below can be hopefully implemented as long as I sovle this problem: IsDate CDate Day Month Weekday Year Hour Minute Second DateValue TimeValue DateSerial TimeSerial DateAdd DateDiff DatePart. 2.The second kind is about strings, they are LenB LeftB RightB MidB InStrB Replace String StrComp. I have sent some patches to implement String, which all failed. Then I realized that I have to solve the problem of locale before I can implement them. 3.The third kind is about characters: Asc AscB ChrB ChrW Escape Unescape, I have already sent patch for Asc, but due to the same problem as strings, it didn't work. Again I have to implement GetLocale and SetLocale function, however as Piotr pointed, these two functions are not registered in native typelib, so I have to figure out another way to implement them, instead of using idl files. 4.The fourth kind is about arrays: IsArray LBound UBound Array Filter Join Split. Though haven't considered them seriously, but I can feel that they harder than those listed before. 5.The fifth kind is about math, but only left Randomize and Rnd, they are a little difficult, but I think it's unnecessary to implement them manually, I mean there must be a wrapper function. I have found some samples in jscript and other modules, I will learn from them. 6.The sixth kind is others: Eval Execute ExecuteGlobal GetRef LoadPicture InputBox FormatNumber FormatCurrency FormatPercent FormatDateTime, they are the most difficult, I am not sure whether I can implement them, but I will try. 7.The remaining functions are about Error handling: Err_Description Err_HelpContext Err_HelpFile Err_Source Err_Raise. I haven't studied them yet, but sooner or later I will meet them. This is my idea for GSoC 2015, I appreciate for any comment. Thank you.

1 0

Re: ntdll/tests: Add tests for GetFinalPathNameByHandleA/W.
by Marvin 26 Mar '15

26 Mar '15

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=12425 Your paranoid android. === wvistau64 (32 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820 === wvistau64 (64 bit file) === file.c:369: Test failed: attributes of file "testfile.xxx" are 0x0820

1 0

Re: winecfg: add note about 32 bit prefixes to dialog
by Stefan Dösinger 26 Mar '15

26 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I think making this visible on some way is a good idea. I have wondered about this myself, and so have many other users. > Context behind this: To run Simcity 2000 I change my Wine prefix > settings to mimic NT 3.5 so that it uses a different file chooser > dialog which doesn't crash the game (for whatever reason). This > last time installing things I was confused about why I didn't see > the option for NT 3.5 until slackner reminded me on IRC that I need > a 32 bit prefix to have that option. Somewhat offtopic to your patch: Is this a known bug in the game? Does it crash in Windows XP or newer unless you set Win9x or Win NT compatibility? It may be a good idea to investigate the actual crash. > So, I thought it might be useful if the dialog could have a note > explaining why those options aren't there if you're running from a > 64 bit prefix -- and thus this patch. To make room for the text I > made the applications Listbox 20 pixels shorter. - From a user interface point of view, what do you think about adding those old Windows versions in the listbox, maybe with a different text like "Windows 98 not available in 64 bit", and programming the code to set the dropdown field back to the last setting if the user decides to choose one of those settings? Or instead of having the modified text, pop up an error box and set the setting back. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVEea8AAoJEN0/YqbEcdMwQCsP/0Uw+ogXWRBtTZz46g8s6hAD wZjtYdFWfx9FMbITjpA9E2VLvmHj4tN6wZDanqOLuaHIRL3Mxa8eKaeZZ+LqE6pL mZWWJcWEQ+V8C/Fr6UTFUsbFhhSDTPhw9BJH/vZBof7uw0evNfBvV6lFQ+nf5bq7 Tpcwu+cBCeVlm9atvChZLwFAuBqjeVuH5ibyGnADIxKScHKvM9rbuJf2f3g3d7bW jCpR5sxoXfgeDeZYyaFh4o3WPHjVKriT3Twz2pYgHe/yZbxgoto72a7WNr5dMdHu 4/2FCQoBoDX2HahnCgWiL7fSDLk3pZFBQ78JRZUKDcS5nj868PszszAn4REVPXEW sgL5dgQqEJs0WhlhAePnUhuPudEaOIdKRDHqMftqJZpTwMxBwo16vnEnsLejrhlB Br2s2YIlqhpF0GKx4TeaefYFlJI/uRlxyhsmUBOvcfZ/BrLtpY9JMSHg0nGPnbI4 IUyU6iBQ5KSLjyDFDFTQ/gS19vbVtzJuEI88wtcUb0I2FknIa2zZN7GBDKN+VxOl hhtiiz1wgfxrrejVTxRKVVDF6bk5BpBWHLIyVIWVxZLiKy46I5Zie2MhbG74A5ks P1vph231JUHeea51wxFOfbUjw7LcTwhHswj8YM2I1EPizOH0AWJS5WQg0K+19o+g ch59pOw13mCF3Fl3LCtz =8FQi -----END PGP SIGNATURE-----

4 4

Re: [PATCH] advapi32: succeed for null pointer in ChangeServiceConfig2
by Nikolay Sivov 25 Mar '15

25 Mar '15

On 19.03.2015 15:06, Bernhard Übelacker wrote: > Hello, > attached patch avoids an issue when trying to run Flatout 2 with copy > protection. > > When starting Flatout2.exe for the first time it wants to install some > services, but shows in wine some error messages. > > The only visible sign in terminal output, that something went wrong, is > this: > err:rpc:I_RpcReceive we got fault packet with status 0x3e6 > > And of course later some dialog showing error 998 (=0x3e6) and a > unhandled exception. > > This is because the SC_RPC_CONFIG_INFOW parameter has in its > descr->lpDescription a null pointer instead of a valid LPWSTR. > > Right now this null pointer would be accessed in > svcctl_ChangeServiceConfig2W and causes an exception there , but is > hidden by the RPC layer. > > (And of course this makes the SF4 protection still not working.) > > Kind regards, > Bernhard > Is it actually called with infolevel 1?

3 9

Re: msvcrt: Fix _copysign bugs for NAN/INF(try 2)
by Henri Verbeet 25 Mar '15

25 Mar '15

On 25 March 2015 at 12:51, Zheng Chen <chanchengcc(a)gmail.com> wrote: > The last patch was damaged by my email client. > I would recommend everyone that doesn't already use it to spend a couple of minutes to learn git send-email. It avoids a lot of issues, and in general just saves everyone (not just reviewers) a lot of time.

2 1

Re: msvcrt: Use NAN and INFINITY definitions from port.h in printf tests
by Marvin 25 Mar '15

25 Mar '15

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=12406 Your paranoid android. === w2000pro (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === wxppro (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w2003std (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === wvistau64 (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w2008s64 (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w7u (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w8 (32 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === wvistau64 (64 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R" === w2008s64 (64 bit printf) === printf.c:693: Test failed: r = 8 printf.c:694: Test failed: failed: "1.#QNAN0" printf.c:701: Test failed: r = 13 printf.c:702: Test failed: failed: "1.#QNAN0e+000" printf.c:710: Test failed: failed: "1.#QNAN" printf.c:718: Test failed: failed: "0000001.#R"

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel