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

WineTest reference Linux machines
by Francois Gouget 09 Dec '16

09 Dec '16

CodeWeavers has two machines that I have been running WineTest on, in Linux, Windows 8.1 and Windows 10, in 32 and 64 bit. They are identical except for the graphics cards: AMD HD6800 for cw1 and Nvidia GTX560 for cw2. During WineConf we decided that these should be able to run WineTest on Linux without any errors and thus become reference WineTest machines. We are not quite there yet so here is the current status starting with the 32 bit tests. * crypt32:chain Some of the certificates used by this test are present on Windows but missing on Linux, thus causing the error. Hans is looking into it and either the test will be modified to use other certificates present on both platforms, or the certificates will be added to these boxes. In the latter case this will be documented on the Wiki: https://wiki.winehq.org/Conformance_Tests#Running_WineTest_in_Wine * d2d1:d2d1, d3d10core:device These tests only fails on the GTX560. The reason is unknown. We need someone to look into it. * d3d8:device, d3d9:d3d9ex, d3d9:device, d3d9:visual Matteo fixed the radeon driver configuration and is looking into these failures, at least for the HD6800 case. It is possible some of these failures are caused by the window manager (currently xfwm from Xfce). Replacing the windows manager is no issue, we just need to know which one to pick. fvwm2? * kernel32:console, kernel32:process These failures happen because the tests are being run from cron, with their output redirected to a log file and thus they have no real terminal to work with. Interestingly the 64 bit tests are not failing. Vincent is investigating whether the tests should be modified or whether the test should be run from an xterm, screen session or some equivalent. * user32:winstation winstation.c:959: Test succeeded inside todo block: unexpected foreground window (nil) The cause for this failure has not been identified. Another window manager issue? * ws2_32:sock sock.c:2811: Test succeeded inside todo block: Test[2]: expected 0, got 0 We need someone to investigate this failure. It looks like it's random and relatively rare. Some tests just cannot be made to work reliably on Linux due to the asynchronous nature of X11 messaging. So another decision that was made that tests should be run up to 3 times until they succeed. It's not entirely clear if that applies to all tests or just to specific tests that are known to be flaky. The practical upshot is that people running 'make test' can re-run it a couple of times if it fails at first, and if it succeeds after 3 tries then you can consider that it's all good. These machines run WineTest so the results can be uploaded to test.winehq.org (with the relevant header describing the machine, the dlls, etc). So WineTest may need to be updated to deal with flaky tests according to policy. Here is more detail about these machines: * i7-2600K (4 cores+hyperthreading at 3.4GHz) * 16 GB of RAM * 768 GB of spinning disk * Debian 8.2 64 bit * cw1: AMD HD6800 running the open-source radeon driver. * cw2: Nvidia GTX560 running the proprietary driver. -- Francois Gouget <fgouget(a)codeweavers.com>

4 9

Code freeze
by Alexandre Julliard 09 Dec '16

09 Dec '16

Folks, The release of 2.0-rc1 marks the beginning of code freeze towards 2.0. Most of you probably know the drill already, but from now on, only targeted bug fixes and other "safe" changes, like test fixes, translation updates, etc. will be accepted. I know that many people will soon be out for the holidays, but I hope we can still make significant progress with the open bugs, particularly with the bugs from the regression list. Now would also be a good time to retest your favorite applications to make sure that there are no regressions that we have missed. As usual, I'll be making release candidates every week, until we run out of bugs... Thank you all for helping make Wine 2.0 as good as we can! -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 3/7] server: Added support for message mode named pipes.
by Alexandre Julliard 09 Dec '16

09 Dec '16

Jacek Caban <jacek(a)codeweavers.com> writes: > Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> > --- > dlls/kernel32/tests/pipe.c | 74 ++----- > dlls/ntdll/file.c | 7 +- > dlls/ntdll/tests/file.c | 2 +- > server/async.c | 15 ++ > server/file.h | 2 + > server/named_pipe.c | 499 > ++++++++++++++++++++++++++++++++++++++++++--- > 6 files changed, 510 insertions(+), 89 deletions(-) This is causing various random failures during make test. I don't have a good reproducible case, but it seems to randomly break communication with services. For instance I see mountmgr-related errors, or hangs in the msi tests. -- Alexandre Julliard julliard(a)winehq.org

3 6

Re: dsound: Avoid casts from COM object to interface.
by Andrew Eikum 09 Dec '16

09 Dec '16

On Thu, Dec 08, 2016 at 11:29:42AM +0100, Michael Stefaniuc wrote: > Signed-off-by: Michael Stefaniuc <mstefani(a)redhat.de> > --- > dlls/dsound/dsound.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/dsound/dsound.c b/dlls/dsound/dsound.c > index 43b252d..d11c864 100644 > --- a/dlls/dsound/dsound.c > +++ b/dlls/dsound/dsound.c > @@ -452,8 +452,8 @@ static HRESULT DirectSoundDevice_CreateSoundBuffer( > > if (device->primary) { > WARN("Primary Buffer already created\n"); > - IDirectSoundBuffer_AddRef((LPDIRECTSOUNDBUFFER8)(device->primary)); > - *ppdsb = (LPDIRECTSOUNDBUFFER)(device->primary); > + *ppdsb = (IDirectSoundBuffer *)&device->primary->IDirectSoundBuffer8_iface; > + IDirectSoundBuffer_AddRef(*ppdsb); > } else { Changing the order of these statements makes me nervous. Some applications use the returned pointers before the function returns, see 6a7c2f66e0569d2419eb9619e78716a9a5f94966. Andrew

1 0

[PATCH][RFC] msctf: Remove incorrect dereference of double pointer.
by Brock York 09 Dec '16

09 Dec '16

This is my attempt at a fix for Helldivers crashing on startup. This is my first Wine patch and I don't know the msctf system. I'm removing a dereference because it *seems* like the right thing to do. It seems to pass the msctf tests on my Arch box. If someone with more knowledge of msctf can give this a review and see if it's sane that would be appreciated. --------Patch below-------- Fixes https://bugs.winehq.org/show_bug.cgi?id=41252 ThreadMgr_QueryInterface is expecting ppvOut to be a pointer to a pointer. When UIElementMgr_QueryInterface calls the ThreadMgr_QueryInterface function it derefences the void **ppvOut making it a void *ppvOut when passing it in. When ThreadMgr_QueryInterface attempts to dereference this pointer to assign a pointer to it, it is instead accessing the value ppvOut is suppose to be pointing at. When the pointer ppvOut points to is NULL this causes a null pointer dereference Tested on Arch Linux Signed-off-by: Brock York <twunknown(a)gmail.com> --- dlls/msctf/threadmgr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dlls/msctf/threadmgr.c b/dlls/msctf/threadmgr.c index e1f56f1..62ddfd2 100644 --- a/dlls/msctf/threadmgr.c +++ b/dlls/msctf/threadmgr.c @@ -1187,7 +1187,7 @@ static HRESULT WINAPI UIElementMgr_QueryInterface(ITfUIElementMgr *iface, REFIID { ThreadMgr *This = impl_from_ITfUIElementMgr(iface); - return ITfThreadMgrEx_QueryInterface(&This->ITfThreadMgrEx_iface, iid, *ppvOut); + return ITfThreadMgrEx_QueryInterface(&This->ITfThreadMgrEx_iface, iid, ppvOut); } static ULONG WINAPI UIElementMgr_AddRef(ITfUIElementMgr *iface) -- 2.10.2

2 1

Re: [website] German translation for release 1.9.24
by Henri Verbeet 09 Dec '16

09 Dec '16

On 8 December 2016 at 16:06, Julian Rüger <jr98(a)gmx.net> wrote: > Dear D3D guys (esp. Stefan), do you have any suggestions or better translations for "unordered access views"? > Thanks! > My German isn't great, but "ungeordneten View-Zugriffen" sounds like "unordered view access" to me, which would be something else. (An UAV is a resource view that allows unordered/random read/write access to a resource from a shader, as opposed to e.g. shader resource views that only allow read access, or e.g. render target views that allow write access but only to a specific location.) You should probably check if Microsoft has an official translation for this, but lacking that I'd expect something along the lines of "ungeordnete Zugriffsview". Or whatever the appropriate translation of "view" would be in this context.

3 2

Re: [PATCH] ws2_32: Fix build failure on Mac
by Bruno Jesus 09 Dec '16

09 Dec '16

On Fri, Dec 9, 2016 at 3:11 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> > --- > dlls/ws2_32/socket.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 3cdeade..6bf3c9d 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -1230,7 +1230,7 @@ static BOOL get_dont_fragment(SOCKET s, int level, BOOL *out) > static int once; > if (!once++) > FIXME("IP_DONTFRAGMENT for IPv6 not supported in this platform\n"); > - return TRUE /* fake success */ > + return TRUE; /* fake success */ > #endif Sorry for that, I tested the defines before cloning the block and for some reason I messed the last block.

1 0

Re: [PATCH] user32/tests: Add tests for LockWindowUpdate.
by Alexandre Julliard 08 Dec '16

08 Dec '16

Lauri Kenttä <lauri.kentta(a)gmail.com> writes: > v2: Win8 and Win10 give different results (sometimes even > different different results), so mark some cases as broken. > Also simplify the patch overall. I don't think that painting on the desktop window is a very useful test, and it can fail for various reasons. If the goal is to test LockWindowUpdate, you should do that with top-level windows instead. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: [PATCH 09/11] wined3d: Recognize dynamic linking shader instructions.
by Henri Verbeet 08 Dec '16

08 Dec '16

On 7 December 2016 at 12:43, Józef Kucia <jkucia(a)codeweavers.com> wrote: > This patch was written while testing the ret instruction in subroutines. Sets > of function bodies/tables are not parsed yet. If preferred, it can be split > into 5 patches (one for each instruction). > Not enough to make you redo it, but yes, split would have been preferred.

1 0

Re: [PATCH 08/11] d3d11/tests: Add test for primitive restart.
by Henri Verbeet 08 Dec '16

08 Dec '16

On 7 December 2016 at 12:43, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + get_texture_readback(test_context.backbuffer, 0, &rb); > + for (y = 0; y < 480; ++y) > + { > + for (x = 0; x < 640; ++x) > + { > + DWORD color = get_readback_color(&rb, x, y); > + DWORD expected_color; > + if (x < 240) > + expected_color = 0xffffff00; > + else if (x >= 640 - 240) > + expected_color = 0xff0000ff; > + else > + expected_color = 0x00000000; > + ok(compare_color(color, expected_color, 1), > + "Test %u: Got 0x%08x, expected 0x%08x at (%u, %u).\n", > + i, color, expected_color, x, y); > + } > + } > + release_resource_readback(&rb); For what it's worth, if we'll have more tests like this in the future, adding an optional rectangle argument to check_texture_color() may be useful.

1 0