May 2020 - Wine-devel - list.winehq.org

Re: widl: Set name return value (passed by reference) in the alias case alias case in get_user_type.
by Alexandre Julliard 22 Nov '20

22 Nov '20

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > So, I admit I don't really know this code, but looking at it (triggered > by a warning issued by GCC development versions), I noticed that this > variable passed by reference is not initialized here. It's initialized when we return a type, and it doesn't need to be initialized on NULL return. The code is correct, but you could probably set the variable to NULL in the caller to silence the warning. -- Alexandre Julliard julliard(a)winehq.org

2 1

Error handling in RpcBindingVectorFree (dlls/rpcrt4/rpc_binding.c)
by Gerald Pfeifer 22 Nov '20

22 Nov '20

Looking at RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector ) { RPC_STATUS status; ULONG c; TRACE("(%p)\n", BindingVector); for (c=0; c<(*BindingVector)->Count; c++) { status = RpcBindingFree(&(*BindingVector)->BindingH[c]); } HeapFree(GetProcessHeap(), 0, *BindingVector); *BindingVector = NULL; return RPC_S_OK; } we currently always ignore the outcome of RpcBindingFree and return RPC_S_OK. However, there is one case where RpcBindingFree returns something different (which is if *Binding is null when RPC_S_INVALID_BINDING is returned). What is the proper way of handling this? Just keeping the code as is and removing the unused status variable? Breaking the loop once RpcBindingFree returns something different from RPC_S_OK? Continuing and returning the first / the last status different from RPC_S_OK? Gerald

1 1

[PATCH] xaudio2: Avoid redefining several F3DAudio related constants.
by Gerald Pfeifer 22 Nov '20

22 Nov '20

I noticed a bunch of compiler warnings like the following issued by GCC 10: In file included from ../xaudio2_7/x3daudio.c:29: .../include/F3DAudio.h:69: warning: "SPEAKER_2POINT1" redefined ../../include/x3daudio.h:127: note: this is the location of the previous definition Our own include/x3daudio.h tries to prevent that via #ifndef _SPEAKER_POSITIONS_ #define _SPEAKER_POSITIONS_ However, current it is included *before* the system provided F3DAudio.h, so this safety net falls short. Fixed thusly by changing the order of these two include files so that the system provided one comes first. Gerald Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> --- dlls/xaudio2_7/x3daudio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/dlls/xaudio2_7/x3daudio.c b/dlls/xaudio2_7/x3daudio.c index 240cd5c101..6f16ba3470 100644 --- a/dlls/xaudio2_7/x3daudio.c +++ b/dlls/xaudio2_7/x3daudio.c @@ -20,15 +20,13 @@ #include "config.h" #include <stdarg.h> - +#include <F3DAudio.h> #include "windef.h" #include "winbase.h" #include "x3daudio.h" #include "wine/debug.h" -#include <F3DAudio.h> - #if XAUDIO2_VER >= 8 || defined X3DAUDIO1_VER WINE_DEFAULT_DEBUG_CHANNEL(xaudio2); #endif -- 2.25.0

2 4

TestBot and graphics tests
by Francois Gouget 24 Aug '20

24 Aug '20

Here are some things I've learned about PCI-passthrough recently, which would be one way (probably the best) to add "real hardware" to the TestBot. I don't want to give anyone false hopes though: this just went from "this is a mysterious thing I need to learn about" to "I think I know how to do it but have not tried it yet". So graphics card PCI-passthrough is now relatively well documented on the Internet and seems to have seen some use-cases that would indicate it may even be reasonably usable. * There are two machines intended to run real GPU tests for Wine: cw1-hd6800 and cw2-gtx560. For now they are only used to run WineTest daily on Windows 8.1, Windows 10 1507, 1709, 1809 and Linux. That's quite a bunch but it would be much better if they were integrated with the TestBot as that would allow developers to submit their own tests. So I had a look at what it would imply to convert them to VM hosts using QEmu + PCI-passthrough. * First one needs a processor with hardware virtualisation support. For Intel that's VT-d. Both machines have an Intel Core 2600 which supports VT-d. Good. * Second the motherboard too needs to support VT-d. Both machines have an ASRock P67 Extreme4 motherboard. Unfortunately UEFI says "unsupported" next to the "VT-d" setting for the motherboard :-( It looks like there was some confusion as to whether the P67 chipset supported VT-d initially. From what I gathered it's only Q67 that does but this caused some manufacturers, among which ASRock, to initially claim support and later retract it. * Then one needs to add the intel_iommu=on option to the kernel command line (resp. amd_iommu). This is should make all the PCI devices appear in /sys/kernel/iommu_groups. But that folder remains empty which confirms that full VT-d support is missing. * Another important aspect is to have a graphics card which is hot-restartable. In some cases when a VM's graphics card is crashed the only way to reset it is to reboot the host. The TestBot is likely to crash the graphics card, particularly if we do a hard-power off on the VMs like we currently do, and it would relaly be annoying to have to reboot the host everytime the graphics card goes belly up. I don't know if the AMD HD6800 and Nvidia GTX560 are suitable but it's quite possible they are not. All I know for now is that we should avoid AMD's R9 line of graphics cards. I still need to find a couple of suitable reasonably lower power graphics cards: one AMD and one Nvidia. * Then one needs to prevent the host from using the graphics card. Usually that's done by having the host use the processor's IGP and dedicating the discrete GPU to the VMs. Unfortunately the 2600's IGP cannot be active when there's a discrete card so that route is denied to us. Fortunately there's quite a bit of documentation on how to shut down not just X but also the Linux virtual consoles to free the GPU and hand it over to the VMs after boot. Doing so means losing KVM access to the host which is a bit annoying in case something goes wrong. So ideally we'd make sure this does not happen in grub's "safe mode" boot option. * Although I have not done any test yet I'm reasonably certain that PCI-passthrough rules out live snapshots: QEmu would have no way to restore the graphics card's internal state. - For Windows VMs that's not an issue: if we provide a power off snapshot the TestBot already knows how to power on the VM and wait for it to boot (as long as the boot is shorter than the connection timeout but it works out usually). - For Linux VM's that's more of an issue: the TestBot will power on the VM as usual. The problem is when it updates Wine: after recompiling everything it deletes the old snapshot and creates a new one from the current state of the VM, which means a live snapshot. So the TestBot will need to be modified so it knows when and how to power off the VM and take a powered off snapshot. * Since the VM has full control of the graphics card QEmu has no access to the content of the screen. That's not an issue for the normal TestBot operation, just for the initial VM setup. Fortunately the graphics card is connected to a KVM so the screen can be accessed through that means. It does mean assigning the mouse and keyboard to the VM too. Should that prove impractical there are a bunch of other options too: VNC, LookingGlass, Synergy, etc. But the less needs to be installed in the VMs the better. * Also the TestBot uses QEmu to take the screenshots. But QEmu does not have access to the content of the screen. The fix is to use a tool to take the screenshots from within the VM and use TestAgent to retrieve them. On Linux there are standard tools we can use. On Windows there's code floating around we can use. So the next steps would be: * Maybe test on my box using the builtin IGP. But that likely won't be very conclusive beyond confirming the snapshot issues, screen access, etc. * Find a suitable AMD or Nvidia graphics card and test that on my box. That would allow me to fully test integration with the TestBot, check for stability issues, etc. * Then see what can be done with the existing cw1 and cw2 boxes. -- Francois Gouget <fgouget(a)codeweavers.com>

4 10

[PATCH 1/2] fsutil: make usage and unsupported command messages localizable
by Vijay Kiran Kamuju 04 Aug '20

04 Aug '20

split the original patch Signed-off-by: Vijay Kiran Kamuju <infyquest(a)gmail.com>

3 2

winegstreamer: Avoid Fedora and openSUSE?
by Francois Gouget 21 Jun '20

21 Jun '20

So I ran into an issue 3 years ago where the 32-bit GStreamer plugins are unusable on Fedora and openSUSE despite these distributions shipping the needed 32-bit packages. So did anyone manage to get winegstreamer.dll to work for 32-bit Windows applications on Fedora and openSUSE or is it widely known that one should avoid them when using Wine? Note that of course I reported this issue to the distributions and this is where you'll find more details about this issue: * Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1472160 -> Reported against Fedora 26, then 28, still present in Fedora 32 but fixing this bug seems to have been postponed indefinitely. * openSUSE https://bugzilla.opensuse.org/show_bug.cgi?id=1049452 -> Supposedly fixed on Tumbleweed 2 years ago but still present on openSUSE Leap 15.1 https://bugzilla.opensuse.org/show_bug.cgi?id=1172018 -> New bug for openSUSE Leap 15.1. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

6 28

[PATCH resend 01/13] msscript.ocx: Move parse_script_text up.
by Gabriel Ivăncescu 12 Jun '20

12 Jun '20

Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- So it's near the other helpers and will be needed for later patches in the series. dlls/msscript.ocx/msscript.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/dlls/msscript.ocx/msscript.c b/dlls/msscript.ocx/msscript.c index c4c6485..6d098cd 100644 --- a/dlls/msscript.ocx/msscript.c +++ b/dlls/msscript.ocx/msscript.c @@ -237,6 +237,20 @@ static HRESULT start_script(struct ScriptControl *control) return hr; } +static HRESULT parse_script_text(ScriptControl *control, BSTR script_text, DWORD flag, VARIANT *res) +{ + EXCEPINFO excepinfo; + HRESULT hr; + + hr = start_script(control); + if (FAILED(hr)) return hr; + + hr = IActiveScriptParse_ParseScriptText(control->host->parse, script_text, NULL, + NULL, NULL, 0, 1, flag, res, &excepinfo); + /* FIXME: more error handling */ + return hr; +} + static inline ScriptControl *impl_from_IScriptControl(IScriptControl *iface) { return CONTAINING_RECORD(iface, ScriptControl, IScriptControl_iface); @@ -1008,20 +1022,6 @@ static HRESULT WINAPI ScriptControl_Reset(IScriptControl *iface) return set_script_state(This->host, SCRIPTSTATE_INITIALIZED); } -static HRESULT parse_script_text(ScriptControl *control, BSTR script_text, DWORD flag, VARIANT *res) -{ - EXCEPINFO excepinfo; - HRESULT hr; - - hr = start_script(control); - if (FAILED(hr)) return hr; - - hr = IActiveScriptParse_ParseScriptText(control->host->parse, script_text, NULL, - NULL, NULL, 0, 1, flag, res, &excepinfo); - /* FIXME: more error handling */ - return hr; -} - static HRESULT WINAPI ScriptControl_AddCode(IScriptControl *iface, BSTR code) { ScriptControl *This = impl_from_IScriptControl(iface); -- 2.21.0

2 23

[PATCH resend 1/2] gdi32/tests: Remove tests for VidPnSourceId.
by Zhiyi Zhang 10 Jun '20

10 Jun '20

VidPnSourceId may be zero for non-primary adapters. Signed-off-by: Zhiyi Zhang <zzhang(a)codeweavers.com> --- dlls/gdi32/tests/driver.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/dlls/gdi32/tests/driver.c b/dlls/gdi32/tests/driver.c index ed83a728131..6172d4a7983 100644 --- a/dlls/gdi32/tests/driver.c +++ b/dlls/gdi32/tests/driver.c @@ -86,11 +86,6 @@ static void test_D3DKMTOpenAdapterFromGdiDisplayName(void) } ok(open_adapter_gdi_desc.hAdapter, "Expect not null.\n"); - if (display_device.StateFlags & DISPLAY_DEVICE_PRIMARY_DEVICE) - ok(open_adapter_gdi_desc.VidPnSourceId == 0, "Got unexpected value %#x.\n", - open_adapter_gdi_desc.VidPnSourceId); - else - ok(open_adapter_gdi_desc.VidPnSourceId, "Got unexpected value %#x.\n", open_adapter_gdi_desc.VidPnSourceId); close_adapter_desc.hAdapter = open_adapter_gdi_desc.hAdapter; status = pD3DKMTCloseAdapter(&close_adapter_desc); @@ -135,12 +130,6 @@ static void test_D3DKMTOpenAdapterFromHdc(void) status = pD3DKMTOpenAdapterFromHdc(&open_adapter_hdc_desc); todo_wine ok(status == STATUS_SUCCESS, "Got unexpected return code %#x.\n", status); todo_wine ok(open_adapter_hdc_desc.hAdapter, "Expect not null.\n"); - if (display_device.StateFlags & DISPLAY_DEVICE_PRIMARY_DEVICE) - ok(open_adapter_hdc_desc.VidPnSourceId == 0, "Got unexpected value %#x.\n", - open_adapter_hdc_desc.VidPnSourceId); - else - todo_wine ok(open_adapter_hdc_desc.VidPnSourceId, "Got unexpected value %#x.\n", - open_adapter_hdc_desc.VidPnSourceId); DeleteDC(hdc); if (status == STATUS_SUCCESS) -- 2.25.1

2 1

[PATCH] crypt32: Store CRYPT_KEY_PROV_INFO in a platform independent way.
by Dmitry Timoshkov 09 Jun '20

09 Jun '20

This makes reading and writing of CRYPT_KEY_PROV_INFO certificate property from/to the certificate storage independent from architecture the crypt32.dll code being executed on. Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/crypt32/cert.c | 162 +++++++++++++++++++++++++++++--------------- 1 file changed, 109 insertions(+), 53 deletions(-) diff --git a/dlls/crypt32/cert.c b/dlls/crypt32/cert.c index 488b84001c..5b7e031338 100644 --- a/dlls/crypt32/cert.c +++ b/dlls/crypt32/cert.c @@ -520,38 +520,90 @@ static BOOL CertContext_GetProperty(cert_t *cert, DWORD dwPropId, return ret; } -void CRYPT_FixKeyProvInfoPointers(PCRYPT_KEY_PROV_INFO info) -{ - DWORD i, containerLen, provNameLen; - LPBYTE data = (LPBYTE)info + sizeof(CRYPT_KEY_PROV_INFO); - - if (info->pwszContainerName) - { - info->pwszContainerName = (LPWSTR)data; - containerLen = (lstrlenW(info->pwszContainerName) + 1) * sizeof(WCHAR); - data += containerLen; +/* 64-bit compatible definitions */ +typedef struct +{ + DWORD pwszContainerName; + DWORD pad1; + DWORD pwszProvName; + DWORD pad2; + DWORD dwProvType; + DWORD dwFlags; + DWORD cProvParam; + DWORD pad3; + DWORD rgProvParam; + DWORD pad4; + DWORD dwKeySpec; + DWORD pad5; +} store_CRYPT_KEY_PROV_INFO; + +typedef struct +{ + DWORD dwParam; + DWORD pad1; + DWORD pbData; + DWORD pad2; + DWORD cbData; + DWORD dwFlags; +} store_CRYPT_KEY_PROV_PARAM; + +void CRYPT_FixKeyProvInfoPointers(PCRYPT_KEY_PROV_INFO buf) +{ + CRYPT_KEY_PROV_INFO info; + store_CRYPT_KEY_PROV_INFO *store = (store_CRYPT_KEY_PROV_INFO *)buf; + BYTE *p = (BYTE *)(store + 1); + + if (store->pwszContainerName) + { + info.pwszContainerName = (LPWSTR)p; + p += (lstrlenW(info.pwszContainerName) + 1) * sizeof(WCHAR); } + else + info.pwszContainerName = NULL; - if (info->pwszProvName) + if (store->pwszProvName) { - info->pwszProvName = (LPWSTR)data; - provNameLen = (lstrlenW(info->pwszProvName) + 1) * sizeof(WCHAR); - data += provNameLen; + info.pwszProvName = (LPWSTR)p; + p += (lstrlenW(info.pwszProvName) + 1) * sizeof(WCHAR); } + else + info.pwszProvName = NULL; + + info.dwProvType = store->dwProvType; + info.dwFlags = store->dwFlags; + info.dwKeySpec = store->dwKeySpec; + info.cProvParam = store->cProvParam; - if (info->cProvParam) + if (info.cProvParam) { - info->rgProvParam = (PCRYPT_KEY_PROV_PARAM)data; - data += info->cProvParam * sizeof(CRYPT_KEY_PROV_PARAM); + DWORD i; - for (i = 0; i < info->cProvParam; i++) + info.rgProvParam = (CRYPT_KEY_PROV_PARAM *)p; + + for (i = 0; i < store->cProvParam; i++) { - info->rgProvParam[i].pbData = data; - data += info->rgProvParam[i].cbData; + CRYPT_KEY_PROV_PARAM param; + store_CRYPT_KEY_PROV_PARAM *store_param; + + store_param = (store_CRYPT_KEY_PROV_PARAM *)p; + p += sizeof(*store_param); + + param.dwParam = store_param[i].dwParam; + param.dwFlags = store_param[i].dwFlags; + param.cbData = store_param[i].cbData; + param.pbData = param.cbData ? p : NULL; + p += store_param[i].cbData; + + memcpy(&info.rgProvParam[i], &param, sizeof(param)); } } else - info->rgProvParam = NULL; + info.rgProvParam = NULL; + + TRACE("%s,%s,%u,%08x,%u,%p,%u\n", debugstr_w(info.pwszContainerName), debugstr_w(info.pwszProvName), + info.dwProvType, info.dwFlags, info.cProvParam, info.rgProvParam, info.dwKeySpec); + + *buf = info; } BOOL WINAPI CertGetCertificateContextProperty(PCCERT_CONTEXT pCertContext, @@ -606,72 +658,76 @@ BOOL WINAPI CertGetCertificateContextProperty(PCCERT_CONTEXT pCertContext, * data, but whose pointers are uninitialized. * Upon return, to contains a contiguous copy of from, packed in the following * order: - * - CRYPT_KEY_PROV_INFO + * - store_CRYPT_KEY_PROV_INFO * - pwszContainerName * - pwszProvName - * - rgProvParam[0]... + * - store_CRYPT_KEY_PROV_PARAM[0] + * - store_CRYPT_KEY_PROV_PARAM[0].data + * - ... */ -static void CRYPT_CopyKeyProvInfo(PCRYPT_KEY_PROV_INFO to, - const CRYPT_KEY_PROV_INFO *from) +static void CRYPT_CopyKeyProvInfo(store_CRYPT_KEY_PROV_INFO *to, const CRYPT_KEY_PROV_INFO *from) { DWORD i; - LPBYTE nextData = (LPBYTE)to + sizeof(CRYPT_KEY_PROV_INFO); + BYTE *p; + store_CRYPT_KEY_PROV_PARAM *param; + + p = (BYTE *)(to + 1); if (from->pwszContainerName) { - to->pwszContainerName = (LPWSTR)nextData; - lstrcpyW(to->pwszContainerName, from->pwszContainerName); - nextData += (lstrlenW(from->pwszContainerName) + 1) * sizeof(WCHAR); + to->pwszContainerName = p - (BYTE *)to; + lstrcpyW((LPWSTR)p, from->pwszContainerName); + p += (lstrlenW(from->pwszContainerName) + 1) * sizeof(WCHAR); } else - to->pwszContainerName = NULL; + to->pwszContainerName = 0; + if (from->pwszProvName) { - to->pwszProvName = (LPWSTR)nextData; - lstrcpyW(to->pwszProvName, from->pwszProvName); - nextData += (lstrlenW(from->pwszProvName) + 1) * sizeof(WCHAR); + to->pwszProvName = p - (BYTE *)to; + lstrcpyW((LPWSTR)p, from->pwszProvName); + p += (lstrlenW(from->pwszProvName) + 1) * sizeof(WCHAR); } else - to->pwszProvName = NULL; + to->pwszProvName = 0; + to->dwProvType = from->dwProvType; to->dwFlags = from->dwFlags; to->cProvParam = from->cProvParam; - to->rgProvParam = (PCRYPT_KEY_PROV_PARAM)nextData; - nextData += to->cProvParam * sizeof(CRYPT_KEY_PROV_PARAM); to->dwKeySpec = from->dwKeySpec; + for (i = 0; i < to->cProvParam; i++) { - memcpy(&to->rgProvParam[i], &from->rgProvParam[i], - sizeof(CRYPT_KEY_PROV_PARAM)); - to->rgProvParam[i].pbData = nextData; - memcpy(to->rgProvParam[i].pbData, from->rgProvParam[i].pbData, - from->rgProvParam[i].cbData); - nextData += from->rgProvParam[i].cbData; + param = (store_CRYPT_KEY_PROV_PARAM *)p; + p += sizeof(*param); + + param->dwParam = from->rgProvParam[i].dwParam; + param->cbData = from->rgProvParam[i].cbData; + param->dwFlags = from->rgProvParam[i].dwFlags; + memcpy(p, from->rgProvParam[i].pbData, from->rgProvParam[i].cbData); + p += from->rgProvParam[i].cbData; } } static BOOL CertContext_SetKeyProvInfoProperty(CONTEXT_PROPERTY_LIST *properties, const CRYPT_KEY_PROV_INFO *info) { + BYTE *buf; + DWORD size = sizeof(store_CRYPT_KEY_PROV_INFO), i; BOOL ret; - LPBYTE buf = NULL; - DWORD size = sizeof(CRYPT_KEY_PROV_INFO), i, containerSize, provNameSize; if (info->pwszContainerName) - containerSize = (lstrlenW(info->pwszContainerName) + 1) * sizeof(WCHAR); - else - containerSize = 0; + size += (lstrlenW(info->pwszContainerName) + 1) * sizeof(WCHAR); if (info->pwszProvName) - provNameSize = (lstrlenW(info->pwszProvName) + 1) * sizeof(WCHAR); - else - provNameSize = 0; - size += containerSize + provNameSize; + size += (lstrlenW(info->pwszProvName) + 1) * sizeof(WCHAR); + for (i = 0; i < info->cProvParam; i++) - size += sizeof(CRYPT_KEY_PROV_PARAM) + info->rgProvParam[i].cbData; + size += sizeof(store_CRYPT_KEY_PROV_PARAM) + info->rgProvParam[i].cbData; + buf = CryptMemAlloc(size); if (buf) { - CRYPT_CopyKeyProvInfo((PCRYPT_KEY_PROV_INFO)buf, info); + CRYPT_CopyKeyProvInfo((store_CRYPT_KEY_PROV_INFO *)buf, info); ret = ContextPropertyList_SetProperty(properties, CERT_KEY_PROV_INFO_PROP_ID, buf, size); CryptMemFree(buf); -- 2.26.2

2 8

[PATCH resend] oleaut32: Retrieve funcdesc from TLB by memberid and invkind.
by mo porot 07 Jun '20

07 Jun '20

This allows searching exact property access functions which share same memberid. Signed-off-by: porotmjp <porotmjp(a)gmail.com> --- dlls/oleaut32/typelib.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-)

3 2