- wine-devel - winehq.org

Re: [PATCH] winex11.drv: LoadKeyboardLayout - return default locale in stub instead of 0
by Matteo Bruni 10 Aug '16

10 Aug '16

2016-08-06 1:09 GMT+02:00 Nils Kuhnhenn <kuhnhenn.nils(a)gmail.com>: > This matches the behavior of the original more closely, which returns > the default locale in case of any error. > > See the section "Return value" here: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms646305(v=vs.85).… > > Guild Wars 2 will repeat the call to "LoadKeyboardLayout" every frame > if 0 is returned, followed by a call to "MapVirtualKeyEx" with the returned > (unsupported) layout. > --- > dlls/winex11.drv/keyboard.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/winex11.drv/keyboard.c b/dlls/winex11.drv/keyboard.c > index 47a9872..6f6eda8 100644 > --- a/dlls/winex11.drv/keyboard.c > +++ b/dlls/winex11.drv/keyboard.c > @@ -1947,9 +1947,9 @@ HKL CDECL X11DRV_GetKeyboardLayout(DWORD dwThreadid) > */ > HKL CDECL X11DRV_LoadKeyboardLayout(LPCWSTR name, UINT flags) > { > - FIXME("%s, %04x: stub!\n", debugstr_w(name), flags); > + FIXME("%s, %04x: stub! Returning default language.\n", debugstr_w(name), flags); > SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > - return 0; > + return get_locale_kbd_layout(); > } I'm not exactly an expert in the area but I think your patch makes sense. It's missing your sign-off though, please resend the patch with it. BTW, you can follow the status of your patch on http://source.winehq.org/patches/.

2 1

Re: [v2] kernel32: properly deal with double path delimiters in GetShortPathName.
by Matteo Bruni 10 Aug '16

10 Aug '16

2016-08-10 15:27 GMT+02:00 Peter Beutner <p.beutner(a)gmx.net>: > v2: ignore previous attempt, this is a better fix i think > > Remove the extra if clause that deals with paths starting with ".\\". The > code a few lines below that handles "." or ".." as part of the path > already handles that case. > That way the code handling path delimiters will properly work for > paths starting with ".\\\\". > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41002 > > Signed-off-by: Peter Beutner <p.beutner(a)gmx.net> > --- > dlls/kernel32/path.c | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/dlls/kernel32/path.c b/dlls/kernel32/path.c > index 620401d..3eff35e 100644 > --- a/dlls/kernel32/path.c > +++ b/dlls/kernel32/path.c > @@ -510,12 +510,6 @@ DWORD WINAPI GetShortPathNameW( LPCWSTR longpath, LPWSTR shortpath, DWORD shortl > } > > p = longpath + lp; > - if (lp == 0 && p[0] == '.' && (p[1] == '/' || p[1] == '\\')) > - { > - tmpshortpath[sp++] = *p++; > - tmpshortpath[sp++] = *p++; > - lp += 2; > - } > for (; *p && *p != '/' && *p != '\\'; p++); > tmplen = p - (longpath + lp); > lstrcpynW(tmpshortpath + sp, longpath + lp, tmplen + 1); > -- > 2.7.3 In case you haven't noticed, you patch was not accepted because it needs tests, as Bruno mentioned in the bug report. You can check the status of your patches on http://source.winehq.org/patches/. BTW, thank you for your work!

1 0

Re: [PATCH 1/5] mpr: Implement local name automatic redirection for disks. (try 6)
by Pierre Schweitzer 10 Aug '16

10 Aug '16

Le 10/08/2016 à 17:31, Bruno Jesus a écrit : > On Mon, Aug 8, 2016 at 7:09 AM, Pierre Schweitzer <pierre(a)reactos.org> wrote: >> This is a purely cosmetic change, as I had the opportunity to resend. I >> use uppercase letters instead of lowercase. >> -- >> Pierre Schweitzer <pierre at reactos.org> >> System & Network Administrator >> Senior Kernel Developer >> ReactOS Deutschland e.V. > > > Hiho, can you tell me how do we test this patches? Maybe with real > testing we can convince Alexandre to have the patches commited. Hi, Unfortunately, there's no easy way to test them, especially in Wine, as it comes without network provider. At the moment, the tests I'm doing are the following: - I developped a "net use" application against Windows 2003 (ie, it works in Windows 2003 as the native app - minus a few features I don't need yet): https://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/network… - This "net use" application obviously relies on MPR functions I'm working with. - I install an instance of ReactOS in VirtualBox/VMware and I try the various functions of net use, such as: * net use z: \\UNC path (it must mount the remote UNC path and try to assign the z: drive letter. As net use command has no idea about network providers or whatever, it requires the second patch in row which allows selecting the good network provider (in MPR) to perform the connection). * net use * \\UNC path (it must mount the remote UNC path and automatically assign a local drive letter). Typically, that's the patch you're replying to. It will attempt all the drive letters till one works. That one is also important because my net use implementation mimics the MS implementation: when connection is done with automatic drive letter selection, net use must write connection that was established (remote UNC to local letter), so it allows testing the return of the WNetUseConnection function: which is the local drive used). This is also covered by the 5th patch. net use z: /delete (it must cancel the connection). This covers the patches 3 and 4 of the serie. Note that I also have patches to implement connected resources enumeration (which is working nicely :-)), but I didn't submit them yet to Wine, waiting for these 5 patches to make it. This is for the "net use" and "net use z:" command. For the network provider "proper" implementation, I rely on open source software, known to work in Windows, such as VirtualBox guest additions (https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/WINNT/Shar…) and Winfsp (https://github.com/billziss-gh/winfsp/blob/master/src/dll/np.c). Screenshots here can give you an overview of what can Wine MPR achieve now: https://twitter.com/HeisSpiter/media ;-). I'll do a resend tonight to address a few style comments I received on #winehackers today (thanks!). Thanks for your help on this! > > Best wishes, > Bruno > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [PATCH 2/3] d3drm: Implement IDirect3DRMFrame*::GetScene. (v3)
by Aaryaman Vasishta 10 Aug '16

10 Aug '16

Hi, Please ignore this and go for v4 of this patch instead. Cheers, Aaryaman On Wed, Aug 10, 2016 at 9:07 PM, Aaryaman Vasishta < jem456.vasishta(a)gmail.com> wrote: > v3: Directly traverse through parent frames instead of using GetParent. > > Signed-off-by: Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > --- > dlls/d3drm/frame.c | 46 ++++++++++++++++++++++++++++++ > ++++++++++------ > dlls/d3drm/tests/d3drm.c | 24 ++++++++++++++++++++++++ > 2 files changed, 64 insertions(+), 6 deletions(-) > > diff --git a/dlls/d3drm/frame.c b/dlls/d3drm/frame.c > index 2ff0241..312007b 100644 > --- a/dlls/d3drm/frame.c > +++ b/dlls/d3drm/frame.c > @@ -1339,23 +1339,57 @@ static HRESULT WINAPI d3drm_frame1_GetRotation(IDirect3DRMFrame > *iface, > > static HRESULT WINAPI d3drm_frame3_GetScene(IDirect3DRMFrame3 *iface, > IDirect3DRMFrame3 **scene) > { > - FIXME("iface %p, scene %p stub!\n", iface, scene); > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame3(iface); > > - return E_NOTIMPL; > + TRACE("iface %p, scene %p.\n", iface, scene); > + > + if (!scene) > + return D3DRMERR_BADVALUE; > + > + *scene = &frame->IDirect3DRMFrame3_iface; > + > + while (frame->parent) > + { > + frame = frame->parent; > + *scene = &frame->IDirect3DRMFrame3_iface; > + } > + > + IDirect3DRMFrame3_AddRef(*scene); > + > + return D3DRM_OK; > } > > static HRESULT WINAPI d3drm_frame2_GetScene(IDirect3DRMFrame2 *iface, > IDirect3DRMFrame **scene) > { > - FIXME("iface %p, scene %p stub!\n", iface, scene); > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame2(iface); > + IDirect3DRMFrame3 *frame3; > + HRESULT hr; > > - return E_NOTIMPL; > + TRACE("iface %p, scene %p.\n", iface, scene); > + > + if (!scene) > + return D3DRMERR_BADVALUE; > + > + hr = IDirect3DRMFrame3_GetScene(&frame->IDirect3DRMFrame3_iface, > &frame3); > + if (FAILED(hr) || !frame3) > + { > + *scene = NULL; > + return hr; > + } > + > + hr = IDirect3DRMFrame3_QueryInterface(frame3, &IID_IDirect3DRMFrame, > (void **)scene); > + IDirect3DRMFrame3_Release(frame3); > + > + return hr; > } > > static HRESULT WINAPI d3drm_frame1_GetScene(IDirect3DRMFrame *iface, > IDirect3DRMFrame **scene) > { > - FIXME("iface %p, scene %p stub!\n", iface, scene); > + struct d3drm_frame *frame = impl_from_IDirect3DRMFrame(iface); > > - return E_NOTIMPL; > + TRACE("iface %p, scene %p.\n", iface, scene); > + > + return d3drm_frame2_GetScene(&frame->IDirect3DRMFrame2_iface, scene); > } > > static D3DRMSORTMODE WINAPI d3drm_frame3_GetSortMode(IDirect3DRMFrame3 > *iface) > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 1abaed5..d86477d 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -885,6 +885,7 @@ static void test_Frame(void) > IDirect3DRMFrame *pFrameP1; > IDirect3DRMFrame *pFrameP2; > IDirect3DRMFrame *pFrameTmp; > + IDirect3DRMFrame *scene_frame; > IDirect3DRMFrameArray *frame_array; > IDirect3DRMMeshBuilder *mesh_builder; > IDirect3DRMVisual *visual1; > @@ -967,6 +968,19 @@ static void test_Frame(void) > CHECK_REFCOUNT(pFrameP1, 1); > CHECK_REFCOUNT(pFrameC, 2); > > + hr = IDirect3DRMFrame_GetScene(pFrameC, NULL); > + ok(hr == D3DRMERR_BADVALUE, "Expected hr == D3DRMERR_BADVALUE, got > %#x.\n", hr); > + hr = IDirect3DRMFrame_GetScene(pFrameC, &scene_frame); > + ok(SUCCEEDED(hr), "Cannot get scene (hr == %#x).\n", hr); > + ok(scene_frame == pFrameP1, "Expected scene frame == %p, got %p.\n", > pFrameP1, scene_frame); > + CHECK_REFCOUNT(pFrameP1, 2); > + IDirect3DRMFrame_Release(scene_frame); > + hr = IDirect3DRMFrame_GetScene(pFrameP1, &scene_frame); > + ok(SUCCEEDED(hr), "Cannot get scene (hr == %#x).\n", hr); > + ok(scene_frame == pFrameP1, "Expected scene frame == %p, got %p.\n", > pFrameP1, scene_frame); > + CHECK_REFCOUNT(pFrameP1, 2); > + IDirect3DRMFrame_Release(scene_frame); > + > frame_array = NULL; > hr = IDirect3DRMFrame_GetChildren(pFrameP1, &frame_array); > ok(hr == D3DRM_OK, "Cannot get children (hr = %x)\n", hr); > @@ -1032,6 +1046,16 @@ static void test_Frame(void) > ok(pFrameTmp == NULL, "pFrameTmp = %p\n", pFrameTmp); > IDirect3DRMFrameArray_Release(frame_array); > } > + hr = IDirect3DRMFrame_GetScene(pFrameC, &scene_frame); > + ok(SUCCEEDED(hr), "Cannot get scene (hr == %#x).\n", hr); > + ok(scene_frame == pFrameP2, "Expected scene frame == %p, got %p.\n", > pFrameP2, scene_frame); > + CHECK_REFCOUNT(pFrameP2, 2); > + IDirect3DRMFrame_Release(scene_frame); > + hr = IDirect3DRMFrame_GetScene(pFrameP2, &scene_frame); > + ok(SUCCEEDED(hr), "Cannot get scene (hr == %#x).\n", hr); > + ok(scene_frame == pFrameP2, "Expected scene frame == %p, got %p.\n", > pFrameP2, scene_frame); > + CHECK_REFCOUNT(pFrameP2, 2); > + IDirect3DRMFrame_Release(scene_frame); > > pFrameTmp = (void*)0xdeadbeef; > hr = IDirect3DRMFrame_GetParent(pFrameC, &pFrameTmp); > -- > 2.3.2 (Apple Git-55) > >

1 0

Building Wine programs for Windows
by Ruslan Kabatsayev 10 Aug '16

10 Aug '16

Hello all. Is there any supported way to build programs supplied with Wine, e.g. `dxdiag` or `regedit`, for native Windows? There seems to be a `crosstest` target, but it appears to only build tests, not all the programs and libraries. Regards, Ruslan

2 4

Re: [PATCH] winhttp/tests: Fix indentation warning on GCC 6
by Marvin 10 Aug '16

10 Aug '16

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=24961 Your paranoid android. === w864 (32 bit winhttp) === winhttp.c:1030: Test failed: failed to send request 2148074273 winhttp.c:1034: Test failed: failed to retrieve certificate context 12019 winhttp.c:1039: Test failed: failed to retrieve key bitness 4317 winhttp.c:1043: Test failed: failed to retrieve certificate info 12019 winhttp.c:1056: Test failed: failed to receive response 12019 winhttp.c:1060: Test failed: failed to query available data 12019 winhttp.c:1061: Test failed: available_size = 0 winhttp.c:1066: Test failed: failed unexpectedly 12019 winhttp.c:1067: Test failed: request failed unexpectedly 3735928559 winhttp.c:1078: Test failed: WinHttpReadData failed: 12019.

1 0

Re: [PATCH resend 2/2] wined3d: Do not enable blending for edge/line antialiasing.
by Marvin 10 Aug '16

10 Aug '16

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=24955 Your paranoid android. === w1064 (32 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH resend 2/2] wined3d: Do not enable blending for edge/line antialiasing.
by Marvin 10 Aug '16

10 Aug '16

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=24951 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH v2 1/2] ddraw/tests: Add tests for edge antialiasing blending.
by Marvin 10 Aug '16

10 Aug '16

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=24948 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 5/7] ddraw/tests: Add test for edge antialiasing blending.
by Henri Verbeet 10 Aug '16

10 Aug '16

On 8 August 2016 at 16:52, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static D3DCOLOR get_surface_color_rb(IDirectDraw7 *ddraw, IDirectDrawSurface7 *surface, > + unsigned int x, unsigned int y) > +{ > + IDirectDrawSurface7 *readback_surface; > + DDSURFACEDESC2 surface_desc; > + D3DCOLOR color; > + HRESULT hr; > + > + memset(&surface_desc, 0, sizeof(surface_desc)); > + surface_desc.dwSize = sizeof(surface_desc); > + hr = IDirectDrawSurface7_GetSurfaceDesc(surface, &surface_desc); > + ok(SUCCEEDED(hr), "Failed to get surface desc, hr %#x.\n", hr); > + surface_desc.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_SYSTEMMEMORY; > + hr = IDirectDraw7_CreateSurface(ddraw, &surface_desc, &readback_surface, NULL); > + ok(SUCCEEDED(hr), "IDirectDraw7_CreateSurface failed, hr %#x.\n", hr); > + hr = IDirectDrawSurface_BltFast(readback_surface, 0, 0, surface, NULL, 0); > + ok(SUCCEEDED(hr), "IDirectDrawSurface7_BltFast failed, hr %#x.\n", hr); > + > + color = get_surface_color(readback_surface, x, y); > + > + IDirectDrawSurface7_Release(readback_surface); > + > + return color; > +} What is this for? Note that ddraw too has a D3DPRASTERCAPS_ANTIALIASEDGES cap. What about other versions? I think at least IDirect3DDevice3 also had D3DRENDERSTATE_EDGEANTIALIAS.

2 1

Re: [PATCH] msvcp140: Forward __ExceptionPtr* to msvcr120
by Piotr Caban 10 Aug '16

10 Aug '16

Hi Daniel, On 08/09/16 18:31, Daniel Lehman wrote: > -@ stub -arch=win32 ?__ExceptionPtrCopy@@YAXPAXPBX@Z > -@ stub -arch=win64 ?__ExceptionPtrCopy@@YAXPEAXPEBX@Z > +@ cdecl -arch=win32 ?__ExceptionPtrCopy@@YAXPAXPBX@Z(ptr ptr) __ExceptionPtrCopy > +@ cdecl -arch=win64 ?__ExceptionPtrCopy@@YAXPEAXPEBX@Z(ptr ptr) __ExceptionPtrCopy Why can't you just add forwards to msvcr120.dll in spec file? Thanks, Piotr

2 2

Re: [v2] riched20: allow setting background text color
by Huw Davies 10 Aug '16

10 Aug '16

On Tue, Aug 09, 2016 at 03:17:36PM -0600, Kenneth Haley wrote: > --- a/dlls/riched20/paint.c > +++ b/dlls/riched20/paint.c > @@ -318,10 +318,23 @@ static void get_selection_rect( ME_Context *c, ME_Run *run, int from, int to, in > static void draw_text( ME_Context *c, ME_Run *run, int x, int y, BOOL selected, RECT *sel_rect ) > { > COLORREF text_color = get_text_color( c, run->style, selected ); > - COLORREF back_color = selected ? ITextHost_TxGetSysColor( c->editor->texthost, COLOR_HIGHLIGHT ) : 0; > + COLORREF back_color = 0; > COLORREF old_text, old_back = 0; > const WCHAR *text = get_text( run, 0 ); > ME_String *masked = NULL; > + BOOL paint_bg = FALSE; > + > + if (selected) > + { > + back_color = ITextHost_TxGetSysColor(c->editor->texthost, COLOR_HIGHLIGHT); > + paint_bg = TRUE; > + } > + else if (run->style->fmt.dwMask & CFM_BACKCOLOR && > + !(CFE_AUTOBACKCOLOR & run->style->fmt.dwEffects)) > + { > + back_color = run->style->fmt.crBackColor; > + paint_bg = TRUE; > + } This doesn't work for me. You need to use the new paint_bg boolean to trigger the ETO_OPAQUE flags below. Also there's some odd behaviour if you select text in a run with background colour - the selection is correctly highlighted, but the rest of the run loses its background colour. Huw.

1 0

Re: mmdevapi: Another use case for todo_wine_if().
by Marvin 09 Aug '16

09 Aug '16

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=24917 Your paranoid android. === w8 (32 bit capture) === capture.c:181: Test failed: Position 119 expected 0 capture.c:231: Test failed: Position 2167 expected 567 capture.c:261: Test failed: Position 2167 expected 567 capture.c:318: Test failed: Position 3191 gap 2176 capture.c:321: Test failed: GCP 13440 vs. BufferSize 21996 === w864 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:261: Test failed: Position 2167 expected 1527 capture.c:318: Test failed: Position 3191 gap 1216 capture.c:321: Test failed: GCP 14336 vs. BufferSize 21996 capture.c:341: Test failed: Position 4279 expected 3639 capture.c:342: Test failed: flags 1 capture.c:366: Test failed: Position 5303 expected 4087 capture.c:367: Test failed: flags 1 === w1064 (32 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:261: Test failed: Position 2167 expected 1527 capture.c:318: Test failed: Position 3255 gap 1280 capture.c:321: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:341: Test failed: Position 4343 expected 3703 capture.c:342: Test failed: flags 1 capture.c:366: Test failed: Position 4791 expected 4151 === w864 (64 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:261: Test failed: Position 2167 expected 1527 capture.c:318: Test failed: Position 3127 gap 1152 capture.c:321: Test failed: GCP 13888 vs. BufferSize 21996 capture.c:341: Test failed: Position 4215 expected 3575 capture.c:342: Test failed: flags 1 capture.c:366: Test failed: Position 5303 expected 4023 capture.c:367: Test failed: flags 1 === w1064 (64 bit capture) === capture.c:181: Test failed: Position 1079 expected 0 capture.c:231: Test failed: Position 2167 expected 1527 capture.c:261: Test failed: Position 2167 expected 1527 capture.c:318: Test failed: Position 3255 gap 1280 capture.c:321: Test failed: GCP 11648 vs. BufferSize 21996 capture.c:341: Test failed: Position 4343 expected 3703 capture.c:342: Test failed: flags 1 capture.c:366: Test failed: Position 4791 expected 4151

1 0

Re: [PATCH] wshom.ocx/tests: Fix indentation warning on GCC 6
by Bruno Jesus 09 Aug '16

09 Aug '16

On Tue, Aug 9, 2016 at 2:07 PM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> Are you going to also change lines starting with todo_wine? Like http://source.winehq.org/source/dlls/ws2_32/tests/sock.c#1468 Because it is made like this to make it more evident and to reduce diff files when the problem is fixed. Best wishes, Bruno

2 1

Re: [PATCH 2/3] d3drm: Implement IDirect3DRMFrame*::GetScene. (v2)
by Henri Verbeet 09 Aug '16

09 Aug '16

On 9 August 2016 at 03:16, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > static HRESULT WINAPI d3drm_frame3_GetScene(IDirect3DRMFrame3 *iface, IDirect3DRMFrame3 **scene) > { > - FIXME("iface %p, scene %p stub!\n", iface, scene); > + HRESULT hr; > + IDirect3DRMFrame3 *frame = iface, *parent_frame = NULL; > > - return E_NOTIMPL; > + TRACE("iface %p, scene %p.\n", iface, scene); > + > + if (!scene) > + return D3DRMERR_BADVALUE; > + > + for (;;) > + { > + if (FAILED(hr = IDirect3DRMFrame3_GetParent(frame, &parent_frame))) > + return hr; > + if (parent_frame) > + { > + frame = parent_frame; > + IDirect3DRMFrame3_Release(parent_frame); > + } > + else > + break; > + } You could just do if (!parent_frame) break; More importantly though, as Stefan already mentioned, the reference counting is weird. I think the code would be much nicer if you just used impl_from_IDirect3DRMFrame3() and then followed the frame->parent pointers.

2 1

Re: [PATCH 3/3] d3drm: Implement IDirect3DRMViewport*::Clear. (v3)
by Henri Verbeet 09 Aug '16

09 Aug '16

On 9 August 2016 at 03:20, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > v2: Remove some redundancies and add more tests. Handling of Clear without depth surface is still a bit weird as wined3d_device_clear seems to return an error on a device with no depth surface since the start vs device whose depth surface was deleted after it was created, in which case it (oddly) returns successfully, even having access to and successfully clearing the depth surface. > What does "deleted" and "surface" mean in the above? If it's just releasing the references to the depth/stencil texture and view, note that the device state keeps a reference to view that wouldn't be released until you set a different view or NULL.

2 1

Re: [PATCH 1/3] d3drm: Store reference to render target in IDirect3DRM*::CreateDeviceFromD3D.
by Henri Verbeet 09 Aug '16

09 Aug '16

On 9 August 2016 at 03:16, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index 1abaed5..2c82ecb 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -4572,7 +4572,7 @@ static void test_create_device_from_d3d1(void) > ref3 = get_refcount((IUnknown *)d3drm1); > ok(ref3 > ref2, "expected ref3 > ref1, got ref1 = %u , ref3 = %u.\n", ref1, ref3); > ref3 = get_refcount((IUnknown *)temp_d3ddevice1); > - ok(ref3 == device_ref2, "Expected ref3 == device_ref2, got ref3 = %u, device_ref2 = %u.\n", ref3, device_ref2); > + todo_wine ok(ref3 == device_ref2, "Expected ref3 == device_ref2, got ref3 = %u, device_ref2 = %u.\n", ref3, device_ref2); So what does this patch fix?

2 1

Re: imm32, user32: Create and destroy the default IME window implicitly. (try 9)
by Alexandre Julliard 09 Aug '16

09 Aug '16

Akihiro Sagawa <sagawa.aki(a)gmail.com> writes: > Try 9: > - Withdraw try 8 changes as we have ImmDisableIME now. > - Rebased and resolve conflicts against ImmDisableIME patch. This is still breaking some tests: ../../../tools/runtest -q -P wine -T ../../.. -M ole32.dll -p ole32_test.exe.so compobj && touch compobj.ok compobj.c:2618: Test failed: CoWaitForMultipleHandles unexpectedly pumped messages make: *** [compobj.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] usp10: Better implementation for ScriptGetLogicalWidths()
by Marvin 09 Aug '16

09 Aug '16

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=24886 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

[RFC PATCH 2/2] programs/services: Load device drivers of the same group into the same winedevice process
by Aric Stewart 09 Aug '16

09 Aug '16

--- programs/services/services.c | 112 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+)

1 0

[RFC PATCH 1/2] programs/services: Break services into Loader groups
by Aric Stewart 09 Aug '16

09 Aug '16

Sort the groups by the service's tag to start in order --- programs/services/services.c | 101 ++++++++++++++++++++++++++++++++----------- 1 file changed, 75 insertions(+), 26 deletions(-)

1 0

[RFC PATCH 2/2] programs/winedevice: Dynamically load devices into group device
by Aric Stewart 09 Aug '16

09 Aug '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> --- programs/winedevice/device.c | 55 +++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 54 insertions(+), 1 deletion(-)

1 0

[RFC PATCH 1/2] programs/winedevice.exe: allow loading multiple devices on the command line
by Aric Stewart 09 Aug '16

09 Aug '16

Signed-off-by: Aric Stewart <aric(a)codeweavers.com> --- programs/winedevice/device.c | 92 ++++++++++++++++++++++++++++++++++++-------- 1 file changed, 75 insertions(+), 17 deletions(-)

1 0

Re: [PATCH] advapi32: Allow for sending extended control events to services
by Sebastian Lackner 09 Aug '16

09 Aug '16

On 08.08.2016 17:41, Aric Stewart wrote: > > This allows dwEventType and lpEventData parameters to be sent > > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > dlls/advapi32/service.c | 36 ++++++++++++++++++++++++++++-------- > include/wine/svcctl.idl | 11 ++++++++++- > 2 files changed, 38 insertions(+), 9 deletions(-) > It might be useful to validate the parameters received from the control pipe before assuming its safe to access the data. The existing code is also not really perfect yet, however it wouldn't hurt to add some checks. Nevertheless, even more important, it would also be good to combine this in a series with the corresponding programs/services part, so that it can be tested and we are sure this is the right way to solve it. Best regards, Sebastian

2 1

Re: [PATCH] msvcp140/tests: Initial tests for thread functions
by Piotr Caban 09 Aug '16

09 Aug '16

Hi Nikolay, On 08/08/16 23:26, Nikolay Sivov wrote: > + ret = p__Thrd_create(&ta, thrd_thread, NULL); > + ok(!ret, "failed to create thread, got %d\n", ret); > + ret = p__Thrd_detach(ta); > + ok(!ret, "_Thrd_detach failed, got %d\n", ret); Could you please duplicate the thread handle and wait for the thread to finish before exiting the tests? It would be nice to also change the msvcp120 tests this way. Thanks, Piotr

1 0

Re: [PATCH] vcomp140: Add vcomp140 stub
by Sebastian Lackner 09 Aug '16

09 Aug '16

On 09.08.2016 05:31, Daniel Lehman wrote: > > 0001-vcomp140-Add-vcomp140-stub.txt > > > From 4a1bccc08c4fce6c37921cc7d94d4e738433c92b Mon Sep 17 00:00:00 2001 > From: Daniel Lehman <dlehman(a)esri.com> > Date: Mon, 8 Aug 2016 19:56:29 -0700 > Subject: [PATCH] vcomp140: Add vcomp140 stub > > Signed-off-by: Daniel Lehman <dlehman(a)esri.com> > --- > configure.ac | 1 + > dlls/vcomp140/Makefile.in | 1 + > dlls/vcomp140/vcomp140.spec | 113 ++++++++++++++++++++++++++++++++++++++++++++ > tools/make_specfiles | 1 + > 4 files changed, 116 insertions(+) > create mode 100644 dlls/vcomp140/Makefile.in > create mode 100644 dlls/vcomp140/vcomp140.spec Thanks for working on this. Is there any specific reason why you omitted the DllMain method? It might be better to return FALSE from DLL_WINE_PREATTACH to ensure the native dll is preferred if available (like done in all other vcomp* dlls). I would also be fine to switch vcomp to "prefer builtin" at some point, however I am not sure if it is sufficiently tested yet. There are still various unimplemented functions, so apps could stop working if they were using native vcomp140 before. Other opinions are also welcome of course. ;) Regards, Sebastian

2 3

Re: [PATCH] ntdll: Call __finally blocks in __C_specific_handler (try3)
by Piotr Caban 09 Aug '16

09 Aug '16

Hi, On 08/09/16 00:33, Daniel Lehman wrote: > Try2: don't use exception handler signature for termination handler You've sent old patch, with wrong termination handler signature. Thanks, Piotr

1 0

Re: [PATCH 3/5] server: Get and set the console ColorTable
by Alexandre Julliard 09 Aug '16

09 Aug '16

Hugh McMaster <hugh.mcmaster(a)outlook.com> writes: > @@ -1568,6 +1568,22 @@ struct console_renderer_event > short int font_height; > @END > > + > +/* Fill the console ColorTable */ > +@REQ(set_console_colortable) > + obj_handle_t handle; /* handle to the console */ > + VARARG(color,unsigned_int); /* ColorTable */ > +@END > + > + > +/* Fetch the console ColorTable */ > +@REQ(get_console_colortable) > + obj_handle_t handle; /* handle to the console */ > +@REPLY > + VARARG(color,unsigned_int); /* ColorTable */ > +@END It would probably be better to add this to the existing get/set_console_output_info requests. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 7/7] wined3d: Do not enable blending for edge/line antialiasing.
by Marvin 08 Aug '16

08 Aug '16

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=24847 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2295: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2295: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 7/7] wined3d: Do not enable blending for edge/line antialiasing.
by Marvin 08 Aug '16

08 Aug '16

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=24846 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2295: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2295: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: [PATCH 5/7] ddraw/tests: Add test for edge antialiasing blending.
by Marvin 08 Aug '16

08 Aug '16

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=24841 Your paranoid android. === w1064 (32 bit ddraw7) === ddraw7.c:2295: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2295: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: server: Fix loading of IMAGE_OPTIONAL_HEADER
by Marvin 08 Aug '16

08 Aug '16

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=24836 Your paranoid android. === w1064 (32 bit loader) === loader.c:2867: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2868: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2867: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2868: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2867: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2868: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2875: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2876: Test failed: Test 3: Wrong callback count: 0 loader.c:2875: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2876: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:720: Test failed: 2: unexpected error 193 loader.c:720: Test failed: 3: unexpected error 193 loader.c:720: Test failed: 4: unexpected error 193 loader.c:720: Test failed: 6: unexpected error 193 loader.c:720: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784

2 1

Re: [PATCH 1/1] riched20: allow setting background text color
by Huw Davies 08 Aug '16

08 Aug '16

Hi Kenneth, Thanks for your contribution to Wine. Please see below for some comments. On Sat, Aug 06, 2016 at 02:17:34PM -0600, Kenneth Haley wrote: > diff --git a/dlls/riched20/paint.c b/dlls/riched20/paint.c > index 42434b9..df7af79 100644 > --- a/dlls/riched20/paint.c > +++ b/dlls/riched20/paint.c > @@ -318,11 +318,20 @@ static void get_selection_rect( ME_Context *c, ME_Run *run, int from, int to, in > static void draw_text( ME_Context *c, ME_Run *run, int x, int y, BOOL selected, RECT *sel_rect ) > { > COLORREF text_color = get_text_color( c, run->style, selected ); > - COLORREF back_color = selected ? ITextHost_TxGetSysColor( c->editor->texthost, COLOR_HIGHLIGHT ) : 0; > + COLORREF back_color = 0; > COLORREF old_text, old_back = 0; > const WCHAR *text = get_text( run, 0 ); > ME_String *masked = NULL; > > + if (selected) > + back_color = ITextHost_TxGetSysColor( c->editor->texthost, COLOR_HIGHLIGHT ); > + else if(run->style->fmt.dwMask & CFM_BACKCOLOR) > + if (!(CFE_AUTOBACKCOLOR & run->style->fmt.dwEffects)) > + { > + back_color = run->style->fmt.crBackColor; > + selected = TRUE; > + } > + You don't need two 'if's in the 'else' clause, just combine them with an &&. I think we should introduce a new boolean 'paint_bkgnd' (or something) rather than hijacking 'selected' here. It would be set to TRUE if 'selected' or we have a background colour. The code that follows this would then use that rather than 'selected'. Also, please use 4-space indents in this function and be consistant about spaces after an 'if'. > @@ -385,6 +394,18 @@ static void ME_DrawTextWithStyle(ME_Context *c, ME_Run *run, int x, int y, > } > } > } > + else if(run->style->fmt.dwMask & CFM_BACKCOLOR) Again, space after 'if'. > + { > + get_selection_rect( c, run, 0, run->len, cy, &sel_rect ); > + OffsetRect( &sel_rect, x, ymin ); > + sel_rgn = CreateRectRgnIndirect( &sel_rect ); > + clip = CreateRectRgn( 0, 0, 0, 0 ); > + if (GetClipRgn( hDC, clip ) != 1) > + { > + DeleteObject( clip ); > + clip = NULL; > + } > + } This block is essentially a copy of the selected block. It should be possible to rewrite the if condition in that block so you don't need to duplicate this code. Huw.

1 0

Re: [PATCH] winedevice: Remove static driver_obj variable
by Sebastian Lackner 08 Aug '16

08 Aug '16

On 05.08.2016 14:26, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > programs/winedevice/device.c | 36 ++++++++++++++++++++++++++++++------ > 1 file changed, 30 insertions(+), 6 deletions(-) > > > > 0001-winedevice-Remove-static-driver_obj-variable.txt > > > diff --git a/programs/winedevice/device.c b/programs/winedevice/device.c > index e31318c..2744b9d5 100644 > --- a/programs/winedevice/device.c > +++ b/programs/winedevice/device.c > @@ -42,7 +42,16 @@ extern NTSTATUS CDECL wine_ntoskrnl_main_loop( HANDLE stop_event ); > > static SERVICE_STATUS_HANDLE service_handle; > static HANDLE stop_event; > -static DRIVER_OBJECT *driver_obj; > + > +static const WCHAR driverW[] = {'\\','D','r','i','v','e','r','\\',0}; > +extern NTSTATUS WINAPI ObReferenceObjectByName( UNICODE_STRING *ObjectName, > + ULONG Attributes, > + ACCESS_STATE *AccessState, > + ACCESS_MASK DesiredAccess, > + POBJECT_TYPE ObjectType, > + KPROCESSOR_MODE AccessMode, > + void *ParseContext, > + void **Object); It might be better to add this to a public header file. On Windows its in a different header file, but Wine already has a couple of ObReference* functions in include/ddk/wdm.h. You could add it there, too. > > /* find the LDR_MODULE corresponding to the driver module */ > static LDR_MODULE *find_ldr_module( HMODULE module ) > @@ -225,7 +234,6 @@ static NTSTATUS WINAPI init_driver( DRIVER_OBJECT *driver_object, UNICODE_STRING > if (!module) > return STATUS_DLL_INIT_FAILED; > > - driver_obj = driver_object; > driver_object->DriverSection = find_ldr_module( module ); > > nt = RtlImageNtHeader( module ); > @@ -253,9 +261,26 @@ static NTSTATUS WINAPI init_driver( DRIVER_OBJECT *driver_object, UNICODE_STRING > } > > /* call the driver unload function */ > -static void unload_driver( DRIVER_OBJECT *driver_obj ) > +static void unload_driver( const WCHAR *driver_name ) > { > - LDR_MODULE *ldr = driver_obj->DriverSection; > + DRIVER_OBJECT *driver_obj; > + LDR_MODULE *ldr; > + UNICODE_STRING drv_name; > + WCHAR *str; > + > + str = HeapAlloc( GetProcessHeap(), 0, sizeof(driverW) + strlenW(driver_name)*sizeof(WCHAR) ); > + lstrcpyW( str, driverW); > + lstrcatW( str, driver_name ); > + RtlInitUnicodeString( &drv_name, str ); > + > + if (ObReferenceObjectByName( &drv_name, OBJ_CASE_INSENSITIVE, NULL, > + 0, NULL, KernelMode, NULL, (void**)&driver_obj ) != STATUS_SUCCESS) To avoid putting together the string twice, you could already call this function immediately after loading. Also, in theory you would have to release the reference obtained by "ObReferenceObjectByName" using ObDereferenceObject. Since there is no refcounting yet its fine to skip it, but it might be important at some later point. > + { > + ERR("Failed to locate loaded driver (%s)\n", wine_dbgstr_w(driver_name)); > + return; You are leaking the drv_name variable here and at the end of the function. > + } > + > + ldr = driver_obj->DriverSection; > > if (driver_obj->DriverUnload) > { > @@ -276,7 +301,6 @@ static void unload_driver( DRIVER_OBJECT *driver_obj ) > > static NTSTATUS create_driver(const WCHAR *driver_name) > { > - static const WCHAR driverW[] = {'\\','D','r','i','v','e','r','\\',0}; > UNICODE_STRING drv_name; > NTSTATUS status; > WCHAR *str; > @@ -351,7 +375,7 @@ static void WINAPI ServiceMain( DWORD argc, LPWSTR *argv ) > SetServiceStatus( service_handle, &status ); > > wine_ntoskrnl_main_loop( stop_event ); > - unload_driver( driver_obj ); > + unload_driver( driver_name ); > } > else WINE_ERR( "driver %s failed to load\n", wine_dbgstr_w(driver_name) ); > > > >

2 3

Re: [3/3] kernel32/tests: Remove superfluous filler definitions
by Marvin 07 Aug '16

07 Aug '16

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=24824 Your paranoid android. === w7u (32 bit loader) === loader.c:2439: Test failed: WaitForSingleObject failed: 102 === w1064 (32 bit loader) === loader.c:2855: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2856: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2855: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2856: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2855: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2856: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2863: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2864: Test failed: Test 3: Wrong callback count: 0 loader.c:2863: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2864: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784

1 0

Re: [2/3] kernel32/tests: Use SetFilePointer instead of GetFileSize with WriteFile
by Marvin 07 Aug '16

07 Aug '16

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=24823 Your paranoid android. === w7u (32 bit loader) === loader.c:2440: Test failed: WaitForSingleObject failed: 102 loader.c:2442: Test failed: expected exit code 199, got 259 loader.c:2461: Test failed: expected 198, got 199 === w1064 (32 bit loader) === loader.c:2857: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2858: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2857: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2858: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2857: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2858: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2865: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2866: Test failed: Test 3: Wrong callback count: 0 loader.c:2865: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2866: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 The test timed out

1 0

Re: [1/3] kernel32/tests: Explicitly set SizeOfRawData
by Marvin 07 Aug '16

07 Aug '16

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=24822 Your paranoid android. === w1064 (32 bit loader) === loader.c:2867: Test failed: Test 0: ResolveDelayLoadedAPI failed loader.c:2868: Test failed: Test 0: expected 74374550, got 00000000 loader.c:2867: Test failed: Test 1: ResolveDelayLoadedAPI failed loader.c:2868: Test failed: Test 1: expected 72BC2CF0, got 00000000 loader.c:2867: Test failed: Test 2: ResolveDelayLoadedAPI failed loader.c:2868: Test failed: Test 2: expected 74372DC0, got 00000000 loader.c:2875: Test failed: Test 3: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2876: Test failed: Test 3: Wrong callback count: 0 loader.c:2875: Test failed: Test 4: ResolveDelayLoadedAPI succeeded with 00000000 loader.c:2876: Test failed: Test 4: Wrong callback count: 0 === wvistau64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w2008s64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w7pro64 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w864 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784 === w1064 (64 bit loader) === loader.c:718: Test failed: 2: unexpected error 193 loader.c:718: Test failed: 3: unexpected error 193 loader.c:718: Test failed: 4: unexpected error 193 loader.c:718: Test failed: 6: unexpected error 193 loader.c:718: Test failed: 7: unexpected error 193 loader.c:173: Test failed: WriteFile error 1784

1 0

Re: [PATCH 1/2] ddraw/tests: Skip overlay tests if DWM is on.
by Marvin 07 Aug '16

07 Aug '16

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=24816 Your paranoid android. === w1064 (32 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw2) === ddraw2.c:2357: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw7) === ddraw7.c:2272: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw1) === ddraw1.c:2206: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2206: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (32 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw4) === ddraw4.c:2542: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

WineHQ upgrade breaking dinput8:dinput?
by Francois Gouget 07 Aug '16

07 Aug '16

This is a truly weird one. dinput8:dinput start failing on the 17th, the day after WineHQ was upgraded: https://test.winehq.org/data/tests/dinput8:dinput.html What makes this weird is that: * There has been no change to these tests between bd332f53f2d7 and 966a07149a02. In fact the last patch goes back to 2013. So it's not a bad patch. * The failures happen on every 32 bit test environment, from XP to Windows 10, VM or not, TestBot or not. Only 64 bit is spared. * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue. The official WineTest binaries are build on WineHQ so I suspect the MinGW upgrade is somehow responsible for the new failures. However I don't know if the old compiler was masking them, of if the new one is causing them. Any ideas? For reference: * Debian Testing (my environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 * Debian 7 (close to former WineHQ environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.9.1 -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

5 15

Re: [PATCH 2/2] d3drm: Implement IDirect3DRMViewport*::Clear.
by Stefan Dösinger 07 Aug '16

07 Aug '16

On 2016-08-06 16:29, Aaryaman Vasishta wrote: > Signed-off-by: Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > --- > dlls/d3drm/tests/d3drm.c | 640 +++++++++++++++++++++++++++++++++++++++++++++++ > dlls/d3drm/viewport.c | 71 +++++- > 2 files changed, 704 insertions(+), 7 deletions(-) > > diff --git a/dlls/d3drm/tests/d3drm.c b/dlls/d3drm/tests/d3drm.c > index c4020e4..b9a83a0 100644 > --- a/dlls/d3drm/tests/d3drm.c > +++ b/dlls/d3drm/tests/d3drm.c > @@ -5852,6 +5852,644 @@ static void test_viewport_qi(void) > IDirect3DRM_Release(d3drm1); > } > > +static D3DCOLOR get_surface_color(IDirectDrawSurface *surface, UINT x, UINT y) > +{ > + RECT rect = { x, y, x + 1, y + 1 }; > + DDSURFACEDESC surface_desc; > + D3DCOLOR color; > + HRESULT hr; > + > + memset(&surface_desc, 0, sizeof(surface_desc)); > + surface_desc.dwSize = sizeof(surface_desc); > + > + hr = IDirectDrawSurface_Lock(surface, &rect, &surface_desc, DDLOCK_READONLY | DDLOCK_WAIT, NULL); > + ok(SUCCEEDED(hr), "Failed to lock surface, hr %#x.\n", hr); > + if (FAILED(hr)) > + return 0xdeadbeef; > + > + color = *((DWORD *)surface_desc.lpSurface) & 0x00ffffff; > + > + hr = IDirectDrawSurface_Unlock(surface, NULL); > + ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); > + > + return color; > +} > + > +static BOOL compare_color(D3DCOLOR c1, D3DCOLOR c2, BYTE max_diff) > +{ > + if ((c1 & 0xff) - (c2 & 0xff) > max_diff) return FALSE; > + c1 >>= 8; c2 >>= 8; > + if ((c1 & 0xff) - (c2 & 0xff) > max_diff) return FALSE; > + c1 >>= 8; c2 >>= 8; > + if ((c1 & 0xff) - (c2 & 0xff) > max_diff) return FALSE; > + c1 >>= 8; c2 >>= 8; > + if ((c1 & 0xff) - (c2 & 0xff) > max_diff) return FALSE; > + return TRUE; > +} > + > +static void clear_depth_surface(IDirectDrawSurface *surface, DWORD value) > +{ > + HRESULT hr; > + DDBLTFX fx; > + > + memset(&fx, 0, sizeof(fx)); > + fx.dwSize = sizeof(fx); > + U5(fx).dwFillDepth = value; > + > + hr = IDirectDrawSurface_Blt(surface, NULL, NULL, NULL, DDBLT_DEPTHFILL | DDBLT_WAIT, &fx); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > +} > + > +static void set_execute_data(IDirect3DExecuteBuffer *execute_buffer, UINT vertex_count, UINT offset, UINT len) > +{ > + D3DEXECUTEDATA exec_data; > + HRESULT hr; > + > + memset(&exec_data, 0, sizeof(exec_data)); > + exec_data.dwSize = sizeof(exec_data); > + exec_data.dwVertexCount = vertex_count; > + exec_data.dwInstructionOffset = offset; > + exec_data.dwInstructionLength = len; > + hr = IDirect3DExecuteBuffer_SetExecuteData(execute_buffer, &exec_data); > + ok(SUCCEEDED(hr), "Failed to set execute data, hr %#x.\n", hr); > +} > + > +static void emit_set_ts(void **ptr, D3DTRANSFORMSTATETYPE state, DWORD value) > +{ > + D3DINSTRUCTION *inst = *ptr; > + D3DSTATE *ts = (D3DSTATE *)(inst + 1); > + > + inst->bOpcode = D3DOP_STATETRANSFORM; > + inst->bSize = sizeof(*ts); > + inst->wCount = 1; > + > + U1(*ts).dtstTransformStateType = state; > + U2(*ts).dwArg[0] = value; > + > + *ptr = ts + 1; > +} > + > +static void emit_set_rs(void **ptr, D3DRENDERSTATETYPE state, DWORD value) > +{ > + D3DINSTRUCTION *inst = *ptr; > + D3DSTATE *rs = (D3DSTATE *)(inst + 1); > + > + inst->bOpcode = D3DOP_STATERENDER; > + inst->bSize = sizeof(*rs); > + inst->wCount = 1; > + > + U1(*rs).drstRenderStateType = state; > + U2(*rs).dwArg[0] = value; > + > + *ptr = rs + 1; > +} > + > +static void emit_process_vertices(void **ptr, DWORD flags, WORD base_idx, DWORD vertex_count) > +{ > + D3DINSTRUCTION *inst = *ptr; > + D3DPROCESSVERTICES *pv = (D3DPROCESSVERTICES *)(inst + 1); > + > + inst->bOpcode = D3DOP_PROCESSVERTICES; > + inst->bSize = sizeof(*pv); > + inst->wCount = 1; > + > + pv->dwFlags = flags; > + pv->wStart = base_idx; > + pv->wDest = 0; > + pv->dwCount = vertex_count; > + pv->dwReserved = 0; > + > + *ptr = pv + 1; > +} > + > +static void emit_tquad(void **ptr, WORD base_idx) > +{ > + D3DINSTRUCTION *inst = *ptr; > + D3DTRIANGLE *tri = (D3DTRIANGLE *)(inst + 1); > + > + inst->bOpcode = D3DOP_TRIANGLE; > + inst->bSize = sizeof(*tri); > + inst->wCount = 2; > + > + U1(*tri).v1 = base_idx; > + U2(*tri).v2 = base_idx + 1; > + U3(*tri).v3 = base_idx + 2; > + tri->wFlags = D3DTRIFLAG_START; > + ++tri; > + > + U1(*tri).v1 = base_idx + 2; > + U2(*tri).v2 = base_idx + 1; > + U3(*tri).v3 = base_idx + 3; > + tri->wFlags = D3DTRIFLAG_ODD; > + ++tri; > + > + *ptr = tri; > +} > + > +static void emit_end(void **ptr) > +{ > + D3DINSTRUCTION *inst = *ptr; > + > + inst->bOpcode = D3DOP_EXIT; > + inst->bSize = 0; > + inst->wCount = 0; > + > + *ptr = inst + 1; > +} > + > +static void d3d_draw_quad1(IDirect3DDevice *device, IDirect3DViewport *viewport) > +{ > + IDirect3DExecuteBuffer *execute_buffer; > + D3DEXECUTEBUFFERDESC exec_desc; > + HRESULT hr; > + void *ptr; > + UINT inst_length; > + D3DMATRIXHANDLE world_handle, view_handle, proj_handle; > + static D3DMATRIX mat = > + { > + 1.0f, 0.0f, 0.0f, 0.0f, > + 0.0f, 1.0f, 0.0f, 0.0f, > + 0.0f, 0.0f, 1.0f, 0.0f, > + 0.0f, 0.0f, 0.0f, 1.0f, > + }; > + static const D3DLVERTEX quad_strip[] = > + { > + {{-1.0f}, {-1.0f}, {0.80f}, 0, {0xffbada55}}, > + {{-1.0f}, { 1.0f}, {0.80f}, 0, {0xffbada55}}, > + {{ 1.0f}, {-1.0f}, {0.80f}, 0, {0xffbada55}}, > + {{ 1.0f}, { 1.0f}, {0.80f}, 0, {0xffbada55}}, > + }; You could make this {{-1.0f}, {-1.0f}, {0.0f}, 0, {0xffbada55}}, {{-1.0f}, { 1.0f}, {0.0f}, 0, {0xffbada55}}, {{ 1.0f}, {-1.0f}, {1.0f}, 0, {0xffbada55}}, {{ 1.0f}, { 1.0f}, {1.0f}, 0, {0xffbada55}}, Then your currently discarded draws will draw to ca x = 250. That way you can make sure the draw is really discarded by the depth test and not some other reason. > + /* Check what happens if we release the depth surface that d3drm created, and clear the viewport */ > ... > + hr = IDirect3DRMViewport_Clear(viewport1); > + ok(SUCCEEDED(hr), "Cannot clear viewport (hr = %#x).\n", hr); It's worth checking the color surface here to see if the clear was completely ignored or if it realized that there's no depth surface and it only cleared color. Also clear with a different color than what's left behind by the previous test. > ... > + d3d_draw_quad1(d3d_device1, d3d_viewport); > + > + ret_color = get_surface_color(surface, 100, 200); > + todo_wine ok(compare_color(ret_color, 0x000000ff, 1), "Got unexpected color 0x%08x.\n", ret_color); My reading of this is that the depth surface wasn't cleared (everything else would be very surprising). If the color surface was indeed cleared this shows that native at some place expects your ugly deed of removing the depth surface. If the color is not cleared it and the clear call is completely ignored I'd say something is broken somewhere and we shouldn't care too much about this corner case. > + hr = IDirect3DRM_CreateViewport(d3drm1, device1, dummy_frame1, 0, 0, rc.right, > + rc.bottom, &viewport1); > + ok(SUCCEEDED(hr), "Cannot get IDirect3DRMViewport interface (hr = %#x)\n", hr); > + > + > + /* Clear uses the scene/root frame's background color. */ Two newlines. Is that intentional? > + hr = IDirect3DRMFrame_SetSceneBackgroundRGB(frame1, 1.0f, 1.0f, 1.0f); > + ok(SUCCEEDED(hr), "Cannot set scene background RGB (hr = %#x)\n", hr); > + ret_color = IDirect3DRMFrame_GetSceneBackground(frame1); > + ok(ret_color == 0xffffffff, "Expected scene color returned == 0xffffffff, got %#x.\n", ret_color); > + hr = IDirect3DRMFrame_SetSceneBackgroundRGB(dummy_frame1, 0.0f, 1.0f, 0.0f); > + ok(SUCCEEDED(hr), "Cannot set scene background RGB (hr = %#x)\n", hr); > + ret_color = IDirect3DRMFrame_GetSceneBackground(dummy_frame1); > + ok(ret_color == 0xff00ff00, "Expected scene color returned == 0xff00ff00, got %#x.\n", ret_color); > + hr = IDirect3DRMFrame_SetSceneBackgroundRGB(dummy_frame1, 0.0f, 0.0f, 1.0f); > + ok(SUCCEEDED(hr), "Cannot set scene background RGB (hr = %#x)\n", hr); > + ret_color = IDirect3DRMFrame_GetSceneBackground(dummy_frame1); > + ok(ret_color == 0xff0000ff, "Expected scene color returned == 0xff0000ff, got %#x.\n", ret_color); Can't the "where does the color come from" test be merged into the clear test at the start? > +static void draw_quad2(IDirect3DDevice2 *device, IDirect3DViewport *viewport) > +{ Do you need to draw with IDirect3DDevice2 directly here? What about QI'ing IDirect3DDevice and calling d3d_draw_quad1? > diff --git a/dlls/d3drm/viewport.c b/dlls/d3drm/viewport.c > index cb57fe0..371aae3 100644 > --- a/dlls/d3drm/viewport.c > +++ b/dlls/d3drm/viewport.c > @@ -39,6 +39,42 @@ static inline struct d3drm_viewport *impl_from_IDirect3DRMViewport2(IDirect3DRMV > return CONTAINING_RECORD(iface, struct d3drm_viewport, IDirect3DRMViewport2_iface); > } > > +static inline void d3drm_normalize_d3d_color(D3DCOLORVALUE *color_value, D3DCOLOR color) > +{ > + color_value->r = RGBA_GETRED(color) / 255.0f; > + color_value->g = RGBA_GETGREEN(color) / 255.0f; > + color_value->b = RGBA_GETBLUE(color) / 255.0f; > + color_value->a = RGBA_GETALPHA(color) / 255.0f; > +} > + > +static HRESULT d3drm_update_background_material(struct d3drm_viewport *viewport) > +{ > + IDirect3DRMFrame *root_frame; > + D3DCOLOR color; > + D3DMATERIAL mat; > + D3DMATERIALHANDLE hmat; > + HRESULT hr; > + > + if (FAILED(hr = IDirect3DRMFrame_GetScene(viewport->camera, &root_frame))) > + return hr; > + color = IDirect3DRMFrame_GetSceneBackground(root_frame); You are leaking root_frame here. > + if (FAILED(hr = IDirect3DMaterial_GetHandle(viewport->material, viewport->device->device, &hmat))) > + return hr; > + > + if (FAILED(hr = IDirect3DViewport_SetBackground(viewport->d3d_viewport, hmat))) > + return hr; You can do these two calls during viewport creation, you don't have to repeat them every time. > @@ -344,10 +380,7 @@ static HRESULT WINAPI d3drm_viewport2_Init(IDirect3DRMViewport2 *iface, IDirect3 > > memset(&mat, 0, sizeof(mat)); > mat.dwSize = sizeof(mat); > - mat.diffuse.r = RGBA_GETRED(color) / 255.0f; > - mat.diffuse.g = RGBA_GETGREEN(color) / 255.0f; > - mat.diffuse.b = RGBA_GETBLUE(color) / 255.0f; > - mat.diffuse.a = RGBA_GETALPHA(color) / 255.0f; > + d3drm_normalize_d3d_color(&mat.diffuse, color); > > if (FAILED(hr = IDirect3DMaterial_SetMaterial(material, &mat))) > goto cleanup; You can remove the IDirect3DMaterial::SetMaterial call from Init because you have to do it every time clear is called anyway. Keep the GetHandle / SetBackground call in Init though to link the material with the viewport. > static HRESULT WINAPI d3drm_viewport2_Clear(IDirect3DRMViewport2 *iface, DWORD flags) > ... > + if (flags & D3DRMCLEAR_ZBUFFER) > + clear_flags |= D3DCLEAR_ZBUFFER; I guess somewhere here or in the IDirect3DViewport::Clear implementation in ddraw you'll have to handle your missing depth buffer case.

2 4

Re: [PATCH 1/2] d3drm: Implement IDirect3DRMFrame*::GetScene.
by Stefan Dösinger 06 Aug '16

06 Aug '16

On 2016-08-06 16:29, Aaryaman Vasishta wrote: > + while (!done) > + { > + if (FAILED(hr = IDirect3DRMFrame3_GetParent(frame, &parent_frame))) > + return hr; > + if (parent_frame) > + { > + frame = parent_frame; > + IDirect3DRMFrame3_Release(parent_frame); > + } > + else > + done = TRUE; > + } What happens if GetScene is called on the root frame? Does it return itself or NULL or an error? You can eliminate the done variable from this loop by replacing it with a break: for (;;) { if (FAILED(hr = IDirect3DRMFrame3_GetParent(frame, &parent_frame))) return hr; if (parent_frame) { frame = parent_frame; IDirect3DRMFrame3_Release(parent_frame); } else break; } I originally thought about a do {} while(parent_frame); kind of construct but that doesn't gain you much because you need the if check anyway to release parent_frame. It's not nice to call GetParent in the next iteration after you release the frame, but so far I haven't come up with an implementation that avoids that and isn't terribly ugly. I'll keep thinking.

2 1

Re: winealsa.drv: Use debugstr_guid() to trace a guid.
by Andrew Eikum 06 Aug '16

06 Aug '16

On Fri, Aug 05, 2016 at 03:55:55PM +0200, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/winealsa.drv/mmdevdrv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c > index 14eac39..8577e75 100644 > --- a/dlls/winealsa.drv/mmdevdrv.c > +++ b/dlls/winealsa.drv/mmdevdrv.c > @@ -3390,7 +3390,7 @@ static HRESULT WINAPI SimpleAudioVolume_SetMute(ISimpleAudioVolume *iface, > AudioSessionWrapper *This = impl_from_ISimpleAudioVolume(iface); > AudioSession *session = This->session; > > - TRACE("(%p)->(%u, %p)\n", session, mute, context); > + TRACE("(%p)->(%u, %p)\n", session, mute, debugstr_guid(context)); > The format on these should be changed to %s, right? Andrew

2 1

Re: [PATCH] ntdll: Catch page fault in RtlWow64EnableFsRedirectionEx
by Nikolay Sivov 06 Aug '16

06 Aug '16

On 04.08.2016 20:05, Matt Robinson wrote: > Previously, RtlWow64EnableFsRedirectionEx only returned > STATUS_NOT_IMPLEMENTED if the old_value pointer started with 0x0000, and > would cause an unhandled page fault if an invalid handle not starting > with 0x00 was passed. However, Windows seems to catch page faults when > accessing old_value and returns STATUS_ACCESS_VIOLATION. > > This adds a test to confirm the behaviour and then wraps the access to > old_value in an exception handler. > > Fixes https://bugs.winehq.org/show_bug.cgi?id=41066 > > Signed-off-by: Matt Robinson <git(a)nerdoftheherd.com> > --- > dlls/ntdll/directory.c | 12 +++++++++++- > dlls/ntdll/tests/directory.c | 2 ++ > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c > index 4a34475..13df0d1 100644 > --- a/dlls/ntdll/directory.c > +++ b/dlls/ntdll/directory.c > @@ -106,6 +106,7 @@ > #include "wine/list.h" > #include "wine/library.h" > #include "wine/debug.h" > +#include "wine/exception.h" > > WINE_DEFAULT_DEBUG_CHANNEL(file); > > @@ -2998,7 +2999,16 @@ NTSTATUS WINAPI RtlWow64EnableFsRedirectionEx( ULONG disable, ULONG *old_value ) > if (!is_wow64) return STATUS_NOT_IMPLEMENTED; > if (((ULONG_PTR)old_value >> 16) == 0) return STATUS_ACCESS_VIOLATION; Looks like you can remove this old pointer check now. > > - *old_value = !ntdll_get_thread_data()->wow64_redir; > + __TRY > + { > + *old_value = !ntdll_get_thread_data()->wow64_redir; > + } > + __EXCEPT_PAGE_FAULT > + { > + return STATUS_ACCESS_VIOLATION; > + } > + __ENDTRY > + > ntdll_get_thread_data()->wow64_redir = !disable; > return STATUS_SUCCESS; > }

1 0

Re: kernel32/tests: Convert fiber back to thread even when IsThreadAFiber is not available.
by Nikolay Sivov 06 Aug '16

06 Aug '16

On 06.08.2016 15:40, Bernhard Übelacker wrote: > Testbot shows the fiber test failing for Windows 2003 recently. > https://test.winehq.org/data/tests/kernel32:fiber.html > > This is probably related to the last change in > http://source.winehq.org/git/wine.git/commit/556fef3dd184e71e1f0345bd8f3725… > > As Windows 2003 seems to have no IsThreadAFiber the test never > calls test_ConvertFiberToThread. > This leads probably sometimes to the crash now visible. > > By calling test_ConvertFiberToThread before return the crash disappears > on Windows 2003. > > Signed-off-by: Bernhard Übelacker <bernhardu(a)mailbox.org> > --- > dlls/kernel32/tests/fiber.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/dlls/kernel32/tests/fiber.c b/dlls/kernel32/tests/fiber.c > index 9ff9366..0c989af 100644 > --- a/dlls/kernel32/tests/fiber.c > +++ b/dlls/kernel32/tests/fiber.c > @@ -158,6 +158,7 @@ static void test_FiberHandling(void) > if (!pCreateFiberEx) > { > win_skip( "CreateFiberEx not present\n" ); > + test_ConvertFiberToThread(); > return; > } > > @@ -171,6 +172,7 @@ static void test_FiberHandling(void) > if (!pIsThreadAFiber) > { > win_skip( "IsThreadAFiber not present\n" ); > + test_ConvertFiberToThread(); > return; > } > > It's better to have a helper for such cleanup, and not to call one test from another.

2 1

Re: [v2 4/8] msvcirt: Add a partial implementation of class istream_withassign.
by Piotr Caban 06 Aug '16

06 Aug '16

On 08/05/16 18:56, Iván Matellanes wrote: > +/* ??0istream_withassign@@QAE@XZ */ > +/* ??0istream_withassign@@QEAA@XZ */ > +DEFINE_THISCALL_WRAPPER(istream_withassign_ctor, 12) > +istream* __thiscall istream_withassign_ctor(istream *this, BOOL virt_init) There should be 8 instead of 12. Thanks, Piotr

1 0

Re: [PATCH] ntdll: Call __finally blocks in __C_specific_handler (try2)
by Piotr Caban 06 Aug '16

06 Aug '16

On 08/06/16 01:39, Daniel Lehman wrote: > + if (rec->ExceptionFlags & EH_TARGET_UNWIND && > + dispatch->TargetIp < dispatch->ImageBase + table->ScopeRecord[i].EndAddress) > + { > + break; > + } Here's a test that shows that you also need to check BeginAddress: BOOL first = TRUE; __try { begin: if(!first) { printf("here\n"); return 0; } first = FALSE; __try { __try { goto begin; } __finally { printf("finally 1\n"); } } __finally { printf("finally 2\n"); } } __finally { printf("finally 3\n"); }

1 0

Re: [PATCH 1/5] d3dx11: Use debugstr_a() to trace a user-supplied string.
by Henri Verbeet 05 Aug '16

05 Aug '16

On 5 August 2016 at 20:56, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -32,7 +32,7 @@ HRESULT WINAPI D3DX11CompileFromMemory(const char *data, SIZE_T data_size, const > { > TRACE("data %s, data_size %lu, filename %s, defines %p, include %p, entry_point %s, target %s, " > "sflags %#x, eflags %#x, pump %p, shader %p, error_messages %p, hresult %p.\n", > - debugstr_a(data), data_size, debugstr_a(filename), defines, include, entry_point, > + debugstr_a(data), data_size, debugstr_a(filename), defines, include, debugstr_a(entry_point), Somewhat related, this seems to assume "data" is a zero-terminated string.

2 1

Re: Simple D3D/WGL demos for wine
by Matteo Bruni 05 Aug '16

05 Aug '16

2016-08-05 22:00 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: > On Fri, Aug 5, 2016 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> 2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: >>> Hello all. I'd like to implement a set of simple demos which would be >>> something like glxgears for Wine — a simple way to check that WGL, >>> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need >>> to look for a real app to test. I suppose it's not very interesting to >>> have just flat untextured gears, so I'd instead draw a textured cube >>> (similarly to what the tests in dxdiag do). >> >> Do you plan to include these demos in Wine or maintain them >> separately? I'd be in favor of including them in Wine proper (others >> might disagree though) but that introduces a few additional >> constraints, like no C++ code allowed. > I intended them to eventually get into Wine source, after I bring them > to more or less final form. It seems Wine does provide some macros to > call Direct3D virtual functions from C code — like > IDirect3D9_CreateDevice. Actually those macros are also in the original MS headers. Except when they aren't, like for a bunch of d3dx9 interfaces. In those cases we shouldn't have them either. If there is no macro for a method you need you can just manually call the function pointer through the vtable; see the relevant test sources for examples of that if it turns out to be the case. >> BTW, actually we do have a (VERY sketchy) dxdiag implementation in >> Wine, under programs/dxdiag/. You could integrate those demos into it >> in principle. > Good to know it exists, will look into integration of the demos there. > Do you think the WGL demo still fits there? I'd like to have a demo > for WGL since it's the simplest 3D interface for Wine, it's used by > wined3d, and if even it's not working then the users would be better > directed to where their problems might be (i.e. graphics > configuration, not wined3d code). I think it would be fine and nice to have, yes. >>> I have some prototype code for this (standalone and written in C++ for >>> now), and it uses D3DXCreateTextureFromFile. This is all OK when I >>> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with >>> ming32. But when I try to compile for D3D8 with wineg++, there's a >>> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. >>> >>> Is it undesirable for Wine to have d3dx8 (I remember some commits >>> removing the library and headers related to it several years ago)? >> >> You remember correctly. It turns out d3dx8 in practice was always >> statically compiled into the game executables. IIRC the DX8 SDK had no >> d3dx8.dll at all, just a d3dx8.lib with the full library. There was >> also a d3dx8_d.dll with a debug version of the library but that wasn't >> installed by the usual DirectX redistributable so applications can't >> depend on its presence either. In any case, we've had 0 applications >> using our d3dx8.dll, which means our implementation wasn't actually >> used or tested and there was no point in keeping it. >> >>> Should I just drop usage of D3DXCreateTextureFromFile and use plain >>> IDirect3DDeviceX::CreateTexture? >> >> You could use some other API to load the image files. I imagine that >> mixing d3dx9.h with d3d8 won't be a great experience. There are other >> options though, depending on the texture file format you want to use; >> WIC (windowscodecs) might be a good choice generally speaking. >> Another possibility is to create the textures you need procedurally, >> without needing to load them from a file or a resource. > For WGL version I used GdiPlus (flat) API, so I guess this is the way > to go for D3D versions. > The texture I thought of using was something like the following: > http://6g6.eu/sih0-winehq-logo-glass.png > I don't think it'd be easy to generate procedurally, although if > there's a good idea on what image to use instead, I'd favor the > procedural version due to its better reliability (i.e. no dependency > on external file being readable, residing in the expected location > etc.). The procedural generation thing was just an idea, loading from file or, probably better, from resource is okay too. >>> Also I use some matrix functions, which are identical between d3dx8 >>> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for >>> d3d9 and d3d8 versions of it? Or should I just reimplement all the >>> needed functions? >> >> As I mentioned above, I suspect you would get issues when trying to >> include d3dx9.h together with d3d8.h, although you can probably >> workaround that in this case by carefully dividing your code over >> multiple .c files. >> Depending on what you exactly need, just copying or reimplementing the >> relevant functions might be simpler. > Yeah there were some issues with including d3dx9.h directly, I worked > around them by manually declaring the necessary functions and types > and still linking to d3dx9 DLL. I guess that works too. It doesn't seem critical for the time being and it will probably be easier to give more sensible suggestions during an actual patch review. Looking forward to your patches :)

1 0

Re: usp10/tests: Reserve for InClass a byte for every character in teststr. (v4)
by Marvin 05 Aug '16

05 Aug '16

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=24770 Your paranoid android. === w1064 (32 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1) === w1064 (64 bit usp10) === usp10.c:1467: Test failed: 0: uJustification incorrect (0) usp10.c:1467: Test failed: 1: uJustification incorrect (0) usp10.c:1467: Test failed: 2: uJustification incorrect (0) usp10.c:1467: Test failed: 3: uJustification incorrect (0) usp10.c:1467: Test failed: 4: uJustification incorrect (0) usp10.c:1467: Test failed: 5: uJustification incorrect (0) usp10.c:1467: Test failed: 6: uJustification incorrect (0) usp10.c:1467: Test failed: 7: uJustification incorrect (0) usp10.c:1467: Test failed: 8: uJustification incorrect (0) usp10.c:1467: Test failed: 9: uJustification incorrect (0) usp10.c:1483: Test failed: 3: uJustification incorrect (0) usp10.c:1483: Test failed: 5: fDiacritic incorrect (1) usp10.c:1483: Test failed: 5: fZeroWidth incorrect (1) usp10.c:1483: Test failed: 15: fDiacritic incorrect (1) usp10.c:1483: Test failed: 15: fZeroWidth incorrect (1)

1 0

Fwd: Simple D3D/WGL demos for wine
by Ruslan Kabatsayev 05 Aug '16

05 Aug '16

Sorry, forgot to include the mailing list to recipients. ---------- Forwarded message ---------- From: Ruslan Kabatsayev <b7.10110111(a)gmail.com> Date: Fri, Aug 5, 2016 at 11:00 PM Subject: Re: Simple D3D/WGL demos for wine To: Matteo Bruni <matteo.mystral(a)gmail.com> On Fri, Aug 5, 2016 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2016-08-04 19:29 GMT+02:00 Ruslan Kabatsayev <b7.10110111(a)gmail.com>: >> Hello all. I'd like to implement a set of simple demos which would be >> something like glxgears for Wine — a simple way to check that WGL, >> D3D8, D3D9 and later D3D10 and D3D11 are operational, without any need >> to look for a real app to test. I suppose it's not very interesting to >> have just flat untextured gears, so I'd instead draw a textured cube >> (similarly to what the tests in dxdiag do). > > Do you plan to include these demos in Wine or maintain them > separately? I'd be in favor of including them in Wine proper (others > might disagree though) but that introduces a few additional > constraints, like no C++ code allowed. I intended them to eventually get into Wine source, after I bring them to more or less final form. It seems Wine does provide some macros to call Direct3D virtual functions from C code — like IDirect3D9_CreateDevice. > BTW, actually we do have a (VERY sketchy) dxdiag implementation in > Wine, under programs/dxdiag/. You could integrate those demos into it > in principle. Good to know it exists, will look into integration of the demos there. Do you think the WGL demo still fits there? I'd like to have a demo for WGL since it's the simplest 3D interface for Wine, it's used by wined3d, and if even it's not working then the users would be better directed to where their problems might be (i.e. graphics configuration, not wined3d code). > >> I have some prototype code for this (standalone and written in C++ for >> now), and it uses D3DXCreateTextureFromFile. This is all OK when I >> compile for D3D9 with wineg++ or when I compile for D3D8 and D3D9 with >> ming32. But when I try to compile for D3D8 with wineg++, there's a >> problem, since there's no d3dx8*.h nor d3dx8.dll in Wine. >> >> Is it undesirable for Wine to have d3dx8 (I remember some commits >> removing the library and headers related to it several years ago)? > > You remember correctly. It turns out d3dx8 in practice was always > statically compiled into the game executables. IIRC the DX8 SDK had no > d3dx8.dll at all, just a d3dx8.lib with the full library. There was > also a d3dx8_d.dll with a debug version of the library but that wasn't > installed by the usual DirectX redistributable so applications can't > depend on its presence either. In any case, we've had 0 applications > using our d3dx8.dll, which means our implementation wasn't actually > used or tested and there was no point in keeping it. > >> Should I just drop usage of D3DXCreateTextureFromFile and use plain >> IDirect3DDeviceX::CreateTexture? > > You could use some other API to load the image files. I imagine that > mixing d3dx9.h with d3d8 won't be a great experience. There are other > options though, depending on the texture file format you want to use; > WIC (windowscodecs) might be a good choice generally speaking. > Another possibility is to create the textures you need procedurally, > without needing to load them from a file or a resource. For WGL version I used GdiPlus (flat) API, so I guess this is the way to go for D3D versions. The texture I thought of using was something like the following: http://6g6.eu/sih0-winehq-logo-glass.png I don't think it'd be easy to generate procedurally, although if there's a good idea on what image to use instead, I'd favor the procedural version due to its better reliability (i.e. no dependency on external file being readable, residing in the expected location etc.). > >> Also I use some matrix functions, which are identical between d3dx8 >> and d3dx9. Would it be OK if a wine demo would link to d3dx9 both for >> d3d9 and d3d8 versions of it? Or should I just reimplement all the >> needed functions? > > As I mentioned above, I suspect you would get issues when trying to > include d3dx9.h together with d3d8.h, although you can probably > workaround that in this case by carefully dividing your code over > multiple .c files. > Depending on what you exactly need, just copying or reimplementing the > relevant functions might be simpler. Yeah there were some issues with including d3dx9.h directly, I worked around them by manually declaring the necessary functions and types and still linking to d3dx9 DLL. > > As an aside, one possible objection to these demos could be "but we > have tests already!" IMO these cover a somewhat separate use case and > having simple d3d* demos that common users could easily run, similarly > to the "Test sound" button in winecfg, could be valuable.

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