October 2019 - Wine-Devel - list.winehq.org

[PATCH] advapi32/tests: Use unique service names in test_wow64().
by Zebediah Figura Oct. 5, 2019

Oct. 5, 2019

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47891 Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- dlls/advapi32/tests/service.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dlls/advapi32/tests/service.c b/dlls/advapi32/tests/service.c index 9dad710490b..83c0a9b2577 100644 --- a/dlls/advapi32/tests/service.c +++ b/dlls/advapi32/tests/service.c @@ -1806,7 +1806,7 @@ static void test_wow64(void) ok(ret, "Failed to delete service, error %u.\n", GetLastError()); CloseServiceHandle(service); - service = CreateServiceA(manager, "winetestsvc", "winetestsvc", SERVICE_START | DELETE, + service = CreateServiceA(manager, "winetestsvc2", "winetestsvc2", SERVICE_START | DELETE, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, "C:\\windows\\system32\\winetestsvc.exe", NULL, NULL, NULL, NULL, NULL); ok(!!service, "Failed to create service, error %u.\n", GetLastError()); @@ -1825,7 +1825,7 @@ static void test_wow64(void) 0, NULL, CREATE_ALWAYS, 0, NULL); CloseHandle(file); - service = CreateServiceA(manager, "winetestsvc", "winetestsvc", SERVICE_START | DELETE, + service = CreateServiceA(manager, "winetestsvc3", "winetestsvc3", SERVICE_START | DELETE, SERVICE_WIN32_OWN_PROCESS, SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, "C:\\windows\\system32\\winetestsvc.exe service serve", NULL, NULL, NULL, NULL, NULL); ok(!!service, "Failed to create service, error %u.\n", GetLastError()); @@ -1837,7 +1837,7 @@ static void test_wow64(void) ok(ret, "Failed to delete service, error %u.\n", GetLastError()); CloseServiceHandle(service); - service = CreateServiceA(manager, "winetestsvc", "winetestsvc", SERVICE_START | DELETE, + service = CreateServiceA(manager, "winetestsvc4", "winetestsvc4", SERVICE_START | DELETE, SERVICE_KERNEL_DRIVER, SERVICE_DEMAND_START, SERVICE_ERROR_NORMAL, "C:\\windows\\system32\\winetestsvc.exe", NULL, NULL, NULL, NULL, NULL); ok(!!service, "Failed to create service, error %u.\n", GetLastError()); -- 2.23.0

1 0

[PATCH 1/7] ncrypt: add NCryptEnumAlgorithms stub
by Joseph Kogut Oct. 5, 2019

Oct. 5, 2019

Signed-off-by: Joseph Kogut <joseph.kogut(a)gmail.com> --- dlls/ncrypt/main.c | 8 ++++++++ dlls/ncrypt/ncrypt.spec | 2 +- include/ncrypt.h | 7 +++++++ 3 files changed, 16 insertions(+), 1 deletion(-) diff --git a/dlls/ncrypt/main.c b/dlls/ncrypt/main.c index bfda1d8295..c2dd8c0d71 100644 --- a/dlls/ncrypt/main.c +++ b/dlls/ncrypt/main.c @@ -68,6 +68,14 @@ SECURITY_STATUS WINAPI NCryptEncrypt(NCRYPT_KEY_HANDLE key, BYTE *input, DWORD i return NTE_NOT_SUPPORTED; } +SECURITY_STATUS WINAPI NCryptEnumAlgorithms(NCRYPT_PROV_HANDLE provider, DWORD alg_ops, + DWORD *alg_count, NCryptAlgorithmName **alg_list, + DWORD flags) +{ + FIXME("(0x%lx, 0x%08x, %p, %p, 0x%08x): stub\n", provider, alg_ops, alg_count, alg_list, flags); + return NTE_NOT_SUPPORTED; +} + SECURITY_STATUS WINAPI NCryptFinalizeKey(NCRYPT_KEY_HANDLE key, DWORD flags) { FIXME("(0x%lx, 0x%08x): stub\n", key, flags); diff --git a/dlls/ncrypt/ncrypt.spec b/dlls/ncrypt/ncrypt.spec index b0141808a3..c94a17d1b2 100644 --- a/dlls/ncrypt/ncrypt.spec +++ b/dlls/ncrypt/ncrypt.spec @@ -67,7 +67,7 @@ @ stub NCryptDeriveKey @ stub NCryptDuplicateKeyProtectorHandle @ stdcall NCryptEncrypt(long ptr long ptr ptr long ptr long) -@ stub NCryptEnumAlgorithms +@ stdcall NCryptEnumAlgorithms(long long ptr ptr long) @ stub NCryptEnumKeys @ stub NCryptEnumStorageProviders @ stub NCryptExportKey diff --git a/include/ncrypt.h b/include/ncrypt.h index 85ced7a2fb..cf4442ccd8 100644 --- a/include/ncrypt.h +++ b/include/ncrypt.h @@ -32,6 +32,13 @@ typedef LONG SECURITY_STATUS; #define __SECSTATUS_DEFINED__ #endif +typedef struct _NCryptAlgorithmName { + LPWSTR pszName; + DWORD dwClass; + DWORD dwAlgOperations; + DWORD dwFlags; +} NCryptAlgorithmName; + typedef ULONG_PTR NCRYPT_HANDLE; typedef ULONG_PTR NCRYPT_PROV_HANDLE; typedef ULONG_PTR NCRYPT_KEY_HANDLE; -- 2.23.0

1 6

TestBot News
by Francois Gouget Oct. 5, 2019

Oct. 5, 2019

I updated the debian10 and w1064 VMs so let me know if there are problems. For now they are not base VMs yet, I'ĺl promote them after their first WineTest run. Here's what's new (tl;dr;-style): debian10: OSS4, dual-screen, Spice vdagent, ich9 sound card. (and likely wrong CPU) w1064: New locale snapshots, a dual-screen snapshot (QXL), metered network connection. cw-rx460: New AMD RX 460 GPU - Debian: OSS4, Vulkan, win32 trouble. - Windows: New graphics driver, partial Windows upgrades, some missing disk images. The TestBot feels a bit slow today, maybe because it fell behind while I was working on the VMs. If it continues being slow I may have to rebalance the VMs a bit. debian10 -------- This VM now has two screens. A side effect is that screenshots will sometimes not work. That's only one of many annoyances with multi-head support for Unix guests. You can read all about it there: https://bugs.winehq.org/show_bug.cgi?id=47844 With Unix guests, multi-head support requires installing and running Spice's VDAgent in the guest. The VDAgent servers are meant to integrate the guest environment with the host to simplify copy/paste between them, resizing the guest desktop by resizing the Spice window, etc. Hopefully none of that will interfere with the Wine tests but if it does, let me know. Also if we need to test both single and dual screen configurations then we'll need to duplicate that VM. So let me know if that's needed. In the process upgraded the virtual hardware the VM runs on from QEmu's i440FX to the Q35 platform which is the default nowadays. This should not have any impact on the tests except that the sound card changed from ich6 to ich9. Last thing, when rebuilding the VM I picked the 'Hypervisor default' for the emulated CPU. It's missing support for sse3 which, if I recall correctly, was causing bcrypt failures on Wine. And sure enough the failures are back. So I probably need to tweak the CPU configuration. w1064 ----- This VM has a new snapshot with a dual screen configuration. On windows this is only possible with the QXL graphics card whereas we normally use the VGA one. So this is likely to have an impact on the Direct 3D tests in that snapshot. Details: https://bugs.winehq.org/show_bug.cgi?id=47838 On Windows too the dual-screen configuration may cause the TestBot to 'fail' to produce a useful screenshot from time to time: https://testbot.winehq.org/JobDetails.pl?Key=57142&s205=1#k205 Also one needs to have one graphics cards per screen. So this is slightly different from the debian10 setup where there is a single graphics card with two screens. I also added five new locales: Arabic, French, Hebrew, Japanese and Simplified Chinese. Recreating the live snapshots was almost a breeze thanks to the recent TestBot work. The snag is that it turns out setting the location to a European country causes Windows 10 to through a 'Privacy wizard' when rebooting to have the new locale take effect. Of course that impacted the first locale I tested, French, and broke the automatically created live snapshot. Fortunately now I know what's causing the problem and only one snapshot needs to be created manually. Eventually I will probably demote the wvistau64 locale configurations to only run the daily WineTests or even just deal with jobs that developer manually pick for them. Another change I made is to put the network connection in metered mode. Before this I was blocking the Windows Updates simply by disabling the corresponding service. That worked fine in version 1507 but did not work so well with more recent versions. In particular a reboot would reenable the Windows Update service leading to upgrades takign place. Putting the network connection in metered mode seems to reliably stop Windows update in its tracks and is now easy in 1809 (and a bit more hidden in 1703). However I probably went overboard by setting a 1GB limit (a 100GB limit seems to work just as well) so there are notifications that the quota is exceeded. Let me know if this change is causing problems. Details: https://bugs.winehq.org/show_bug.cgi?id=47854 By the way only the new dual-screen and locale snapshots have the metere network connection. So comparing the results there with those of the old snapshots can help detect issues. If this is not causing trouble I'll eventually go back and do the same change in the other snapshots. cw-rx-460 --------- Not quite part of the TestBot but provides daily real hardware WineTest results. The AMD HD6800 graphics card died so it got replaced by an AMD RX 460 graphics card. On the Debian side I added OSS4 (Faudio is present too) and the new graphics card gains us Vulkan support. Yay! The WineTest results are not great. In particular the wow32 results look ok, but half the time WineTest / the system seems to crash in the middle of the win32 ones. It may just be that it reboots to Windows at the wrong time. The rest of the time the win32 results are on par with the wow32/wow64 ones. I did not have time to dig into this yet. On the Windows side the graphics driver has to be updated for each test configuration of course :-( And while that happens Windows Update starts applying updates :-(( But if the metered network connection trick works out I should be able to make clean updates to the windows images. In the meantime only the Windows 8.1 and Windows 10 1809 configurations are operational. -- Francois Gouget <fgouget(a)codeweavers.com>

1 1

gdi32:bitmap failures since 2019-09-09
by Francois Gouget Oct. 4, 2019

Oct. 4, 2019

Since winehq.org was upgraded gdi32:bitmap fails on Windows XP (wxppro) and Windows 2003 (w2003std): https://test.winehq.org/data/tests/gdi32:bitmap.html But I don't see a commit to the gdi32 tests in that range: there is a commit on august 9 and then on september 16. Yet the gdi32_test.exe was running the same number of tests before and all were succeeding. Furthermore, if I compile gdi32_test.exe using source from either sep 09 or aug 27 I still get failures. https://testbot.winehq.org/JobDetails.pl?Key=57290 https://testbot.winehq.org/JobDetails.pl?Key=57291 Was gdi32:bitmap succeeding due to a compiler bug? Could any other test be affected? Some other test units started failing one day earlier, makes no sense: https://test.winehq.org/data/tests/kernel32:heap.html https://test.winehq.org/data/tests/mstask:task.html https://test.winehq.org/data/tests/qmgr:job.html https://test.winehq.org/data/tests/secur32:schannel.html Finally, wtbbuild is still running Debian 9.9. Does that mean we could be missing some failures? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

[PATCH 2/2] wininet: Correct behaviour of error masking.
by Owen Rudge Oct. 4, 2019

Oct. 4, 2019

Signed-off-by: Owen Rudge <orudge(a)codeweavers.com> --- dlls/wininet/netconnection.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)

4 3

[PATCH] libwine: Collapse relative paths inside config directories.
by Paul Gofman Oct. 4, 2019

Oct. 4, 2019

Signed-off-by: Paul Gofman <gofmanp(a)gmail.com> --- The motivation under this patch is fixing the crash in Halo Online which originates from libcef.dll with Wine Staging. The crash scenario is the following. A staging patch puts a 'Times New Roman' font replacement to <datadir>/fonts/times.ttf. This is the only relevant difference introduced by Staging. When the font file is found there, gdi32 uses wine_get_data_dir() for a directory prefix to construct font file name. Later libcef.dll works with fonts through dwrite, and somehow gets confused by a "\\..\\" inside the font file name which it gets with IDWriteLocalFontFileLoader_GetFilePathFromKey() from system font file enumerator object. A minimally sufficient fix for that is to collapse the font file name in create_local_file_reference() or right in localfontfileloader_GetFilePathFromKey() in dwrite/font.c. But it probably makes sense to have the paths in registry free of spurious "\\..\\" as these values are also exposed to applications. libs/wine/config.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/libs/wine/config.c b/libs/wine/config.c index 2a3314cbfd..5fbda6ca51 100644 --- a/libs/wine/config.c +++ b/libs/wine/config.c @@ -132,10 +132,23 @@ static inline void remove_trailing_slashes( char *path ) static char *build_path( const char *dir, const char *name ) { size_t len = strlen(dir); - char *ret = xmalloc( len + strlen(name) + 2 ); + char *ret; + + if (len && dir[len - 1] == '/') + --len; + + while (len && name[0] == '.' && name[1] == '.' && name[2] == '/') + { + while (--len && dir[len] != '/') + ; + + name += 3; + } + + ret = xmalloc( len + strlen(name) + 2 ); memcpy( ret, dir, len ); - if (len && ret[len-1] != '/') ret[len++] = '/'; + ret[len++] = '/'; strcpy( ret + len, name ); return ret; } -- 2.21.0

2 2

[PATCH] wind3d: Add default case in wined3d_calculate_fog_factor.
by Gijs Vermeulen Oct. 4, 2019

Oct. 4, 2019

Signed-off-by: Gijs Vermeulen <gijsvrm(a)gmail.com> --- This silences a clang warning: warning: control may reach end of non-void function [-Wreturn-type] dlls/wined3d/device.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index 9b1b630014..0a668c46b5 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -3501,6 +3501,9 @@ static float wined3d_calculate_fog_factor(float fog_coord, const struct lights_s return expf(-fog_coord * ls->fog_density); case WINED3D_FOG_EXP2: return expf(-fog_coord * fog_coord * ls->fog_density * ls->fog_density); + default: + ERR("Unhandled fog mode %#x.\n", ls->fog_mode); + return 0.0f; } } -- 2.23.0

1 0

[PATCH 1/7] winex11.drv: Initialize XIM before opening it.
by Zhiyi Zhang Oct. 4, 2019

Oct. 4, 2019

This fixes a regression from 22795243b2d21e1a667215f54c3a15634735749c, which calls thread_init_display() and eventually XOpenIM() before X11DRV_InitXIM() is called. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47821 Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> --- dlls/winex11.drv/x11drv_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/dlls/winex11.drv/x11drv_main.c b/dlls/winex11.drv/x11drv_main.c index 21807af3f1..c2f1fd1bbc 100644 --- a/dlls/winex11.drv/x11drv_main.c +++ b/dlls/winex11.drv/x11drv_main.c @@ -578,6 +578,8 @@ static BOOL process_attach(void) if (TRACE_ON(synchronous)) XSynchronize( display, True ); + if (use_xim) use_xim = X11DRV_InitXIM( input_style ); + xinerama_init( DisplayWidth( display, default_visual.screen ), DisplayHeight( display, default_visual.screen )); X11DRV_Settings_Init(); @@ -595,7 +597,6 @@ static BOOL process_attach(void) if (use_xkb) use_xkb = XkbUseExtension( gdi_display, NULL, NULL ); #endif X11DRV_InitKeyboard( gdi_display ); - if (use_xim) use_xim = X11DRV_InitXIM( input_style ); X11DRV_DisplayDevices_Init(FALSE); return TRUE; -- 2.23.0

2 1

ntdll: Zero fl.l_pid field in user space before reading from it.
by Jefferson Carpenter Oct. 4, 2019

Oct. 4, 2019

When this code path is hit, memory sanitizers such as valgrind currently report an uninitialized read at fl.l_pid. This is most likely because the value is set in kernel space, which is out-of-bounds to user-space programs. This patch clears up that output, and ensures that there will not be a memory vulnerability even in the event that the kernel does not set l_pid (notwithstanding that POSIX specifies it should). - Jefferson

2 1

[PATCH v2] dmime/tests: Break out of loop if we fail to get segment pointer
by Michael Stefaniuc Oct. 4, 2019

Oct. 4, 2019

From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> Signed-off-by: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> Signed-off-by: Michael Stefaniuc <mstefani(a)winehq.org> --- v2: Style fix dlls/dmime/tests/performance.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/dlls/dmime/tests/performance.c b/dlls/dmime/tests/performance.c index 4433846f9b..073625f04b 100644 --- a/dlls/dmime/tests/performance.c +++ b/dlls/dmime/tests/performance.c @@ -454,6 +454,10 @@ static void test_notification_type(void) hr = IDirectMusicSegmentState8_GetSegment(segmentstate, &segment); ok(hr == S_OK, "Failed: %08x\n", hr); + if (FAILED(hr)) { + IDirectMusicSegmentState8_Release(segmentstate); + break; + } hr = IDirectMusicSegment_QueryInterface(segment, &IID_IDirectMusicSegment8, (void**)&segment8); ok(hr == S_OK, "Failed: %08x\n", hr); -- 2.20.1

1 0