August 2016 - Wine-devel - list.winehq.org

Re: [PATCH 2/5] programs/winedevice.exe: allow loading multiple devices on the command line
by Sebastian Lackner 11 Aug '16

11 Aug '16

On 09.08.2016 18:40, Aric Stewart wrote: > Signed-off-by: Aric Stewart <aric(a)codeweavers.com> > --- > programs/winedevice/device.c | 92 ++++++++++++++++++++++++++++++++++++-------- > 1 file changed, 75 insertions(+), 17 deletions(-) > I am not sure if I'm missing something, but where is this functionality used? Is it only for manual testing, or where are the corresponding changes to programs/services to pass multiple drivers in the commandline?

2 1

Re: [PATCH 4/6] d3d10core/tests: Add test for swapchain views.
by Marvin 11 Aug '16

11 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=24991 Your paranoid android. === wvistau64 (32 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 0040F80E === w2008s64 (32 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 0040F80E === w8 (32 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 0040F80E === w864 (32 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 0040F80E === w1064 (32 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 0040F80E === wvistau64 (64 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 000000000040DED4 === w2008s64 (64 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 000000000040DED4 === w864 (64 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 000000000040DED4 === w1064 (64 bit device) === device.c:7284: Test failed: Failed to create render target view, hr 0x80070057. device.c:7288: Test failed: Got unexpected color 0xff804c33 at (0, 0), sub-resource 0. device: unhandled exception c0000005 at 000000000040DED4

1 0

Re: [PATCH 4/6] d3d10core/tests: Add test for swapchain views.
by Józef Kucia 11 Aug '16

11 Aug '16

On Thu, Aug 11, 2016 at 12:57 PM, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d10core/tests/device.c | 42 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 42 insertions(+) Please ignore this patch. It seems that this is a D3D11-only feature. I'll send other test for d3d10core in the next patch series.

1 0

Re: user32: Avoid -Wmisleading-indentation warnings and fix comments in comments in test_AppendMenu.
by Dmitry Timoshkov 11 Aug '16

11 Aug '16

Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > diff --git a/dlls/user32/tests/menu.c b/dlls/user32/tests/menu.c > index 33d8eb8..ea965cd 100644 > --- a/dlls/user32/tests/menu.c > +++ b/dlls/user32/tests/menu.c > @@ -3992,13 +3992,15 @@ static void test_AppendMenu(void) > mii.wID = 206; > ret = InsertMenuItemA(hmenu, 0, TRUE, &mii); > ok(ret, "InsertMenuItem failed\n"); > -if (0) /* FIXME: uncomment once Wine is fixed */ > +if (0) /* FIXME: enable once Wine is fixed */ { > check_menu_items(hmenu, 206, MF_SEPARATOR, MFS_GRAYED); > +} > mii.wID = 207; > ret = SetMenuItemInfoA(hmenu, 0, TRUE, &mii); > ok(ret, "SetMenuItemInfo failed\n"); > -if (0) /* FIXME: uncomment once Wine is fixed */ > +if (0) /* FIXME: enable once Wine is fixed */ { > check_menu_items(hmenu, 207, MF_SEPARATOR, MFS_GRAYED); > +} > DestroyMenu(hmenu); > > hbmp = CreateBitmap(1, 1, 1, 1, NULL); Please don't make the code look uglier than it already is. I'd personally argue that checking and forcing indentation rules by a C compiler is pretty disappointing and actually misleading. That warning should be turned off by default IMHO. -- Dmitry.

3 2

Re: [PATCH] msvcr120: Add lgamma
by Piotr Caban 11 Aug '16

11 Aug '16

Hi, On 08/10/16 18:54, Daniel Lehman wrote: > +/********************************************************************* > + * lgamma (MSVCR120.@) > + */ > +double CDECL MSVCR120_lgamma(double x) > +{ > + return lgamma(x); > +} lgamma function is not a C89 function. It probably shouldn't be used without appropriate configure checks. On the other hand there are some other non C89 functions calls in this file. I don't know why/if it's OK in other cases (like e.g. y0). Thanks, Piotr

1 0

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