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

Re: [PATCH 5/5] xaudio2/tests: Add callback tests
by Marvin 28 Aug '15

28 Aug '15

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=16390 Your paranoid android. === build (build) === Unable to regenerate dlls/xaudio2_7/Makefile Unable to regenerate dlls/xaudio2_7/Makefile

1 0

Re: [PATCH 4/5] xaudio2: Add a simple audio streaming test
by Marvin 28 Aug '15

28 Aug '15

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=16389 Your paranoid android. === build (build) === Unable to regenerate dlls/xaudio2_7/Makefile Unable to regenerate dlls/xaudio2_7/Makefile

1 0

Re: [PATCH 5/5] d3d11/tests: Add test for 2D texture interfaces.
by Henri Verbeet 28 Aug '15

28 Aug '15

On 28 August 2015 at 00:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > + hr = ID3D11Texture2D_QueryInterface(texture, &IID_IDXGISurface, (void **)&surface); > + ok(hr == E_NOINTERFACE, "Texture should not implement IDXGISurface.\n"); > + if (SUCCEEDED(hr)) IDXGISurface_Release(surface); You don't need the Release(), if the QueryInterface() would succeed the test would fail. > + if (FAILED(hr)) > + { > + skip("2D textures do not implement ID3D10Texture2D, skipping tests.\n"); This should probably be a win_skip(). You're leaking the device here. > + hr = ID3D11Device_CreateTexture2D(device, &desc, NULL, &texture); > + ok(SUCCEEDED(hr), "%u: Failed to create a 2d texture, hr %#x.\n", i, hr); > + if (FAILED(hr)) continue; ... > + hr = ID3D11Texture2D_QueryInterface(texture, &IID_IDXGISurface, (void **)&surface); > + ok(SUCCEEDED(hr), "%u: Texture should implement IDXGISurface.\n", i); > + if (SUCCEEDED(hr)) IDXGISurface_Release(surface); ... > + hr = ID3D11Texture2D_QueryInterface(texture, &IID_ID3D10Texture2D, (void **)&d3d10_texture); > + ok(SUCCEEDED(hr), "%u: Texture should implement ID3D10Texture2D.\n", i); > + if (SUCCEEDED(hr)) > + { Similar to above, you don't need to account for conditions where the test would fail.

1 0

Re: [PATCH 4/5] d3d11/tests: Port test_create_texture2d() from d3d10core.
by Henri Verbeet 28 Aug '15

28 Aug '15

On 28 August 2015 at 00:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static ID3D11Device *create_default_device(void) > +{ > + ID3D11Device *device; > + > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, 0, NULL, 0, D3D11_SDK_VERSION, > + &device, NULL, NULL))) > + return device; > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_WARP, NULL, 0, NULL, 0, D3D11_SDK_VERSION, > + &device, NULL, NULL))) > + return device; > + if (SUCCEEDED(D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_REFERENCE, NULL, 0, NULL, 0, D3D11_SDK_VERSION, > + &device, NULL, NULL))) > + return device; > + > + return NULL; > +} > + I think I'd make the "feature_level" parameter to the existing create_device() a pointer, and then make it optional. See also e.g. create_device() in dlls/d3d9/tests/device.c.

1 0

Re: [PATCH 3/5] d3d11: Implement d3d11_device_CreateTexture2D().
by Henri Verbeet 28 Aug '15

28 Aug '15

On 28 August 2015 at 00:39, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static inline struct d3d10_texture2d *impl_from_ID3D11Texture2D(ID3D11Texture2D *iface) > +{ > + return CONTAINING_RECORD(iface, struct d3d10_texture2d, ID3D11Texture2D_iface); > +} > + We usually try to keep these in the file that contains the interface implementation, texture.c in this case. We do make the occasional exception though. > + object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)); > + if (!object) You could just do "if (!(object = HeapAlloc(...)))" here, but it doesn't matter that much. > @@ -2006,15 +2025,12 @@ static HRESULT STDMETHODCALLTYPE d3d10_device_CreateTexture2D(ID3D10Device1 *ifa > { > struct d3d_device *device = impl_from_ID3D10Device(iface); > D3D11_TEXTURE2D_DESC d3d11_desc; > + ID3D11Texture2D *d3d11_texture; > struct d3d10_texture2d *object; > HRESULT hr; > > TRACE("iface %p, desc %p, data %p, texture %p.\n", iface, desc, data, texture); > > - object = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*object)); > - if (!object) > - return E_OUTOFMEMORY; > - > d3d11_desc.Width = desc->Width; > d3d11_desc.Height = desc->Height; > d3d11_desc.MipLevels = desc->MipLevels; > @@ -2026,16 +2042,14 @@ static HRESULT STDMETHODCALLTYPE d3d10_device_CreateTexture2D(ID3D10Device1 *ifa > d3d11_desc.CPUAccessFlags = d3d11_cpu_access_flags_from_d3d10_cpu_access_flags(desc->CPUAccessFlags); > d3d11_desc.MiscFlags = d3d11_resource_misc_flags_from_d3d10_resource_misc_flags(desc->MiscFlags); > > - if (FAILED(hr = d3d10_texture2d_init(object, device, &d3d11_desc, data))) > - { > - WARN("Failed to initialize texture, hr %#x.\n", hr); > - HeapFree(GetProcessHeap(), 0, object); > + if (FAILED(hr = d3d11_device_CreateTexture2D(&device->ID3D11Device_iface, &d3d11_desc, > + (const D3D11_SUBRESOURCE_DATA *)data, &d3d11_texture))) > return hr; > - } > > + object = impl_from_ID3D11Texture2D(d3d11_texture); > *texture = &object->ID3D10Texture2D_iface; > > - TRACE("Created ID3D10Texture2D %p\n", object); > + TRACE("Created ID3D10Texture2D %p.\n", object); > > return S_OK; > } This change doesn't really seem worth it. You do save a couple of lines by avoiding the memory allocation, but you need to make impl_from_ID3D11Texture2D() available outside of texture.c to do it. You could create a d3d_texture2d_create() function similar to e.g. d3d9_swapchain_create() in d3d9 and avoid the duplication that way, but it may not make much of a difference in line count. Up to you.

1 0

Re: [PATCH 5/5] d3d11/tests: Add test for 2D texture interfaces.
by Marvin 28 Aug '15

28 Aug '15

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=16380 Your paranoid android. === w7u (32 bit d3d11) === d3d11.c:360: Test failed: 0: Texture should implement ID3D10Texture2D. d3d11.c:352: Test failed: 2: Failed to create a 2d texture, hr 0x8007000e. === w8 (32 bit d3d11) === d3d11.c:360: Test failed: 0: Texture should implement ID3D10Texture2D.

2 1

Re: ieframe: Fixed random test failures.
by Marvin 28 Aug '15

28 Aug '15

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=16383 Your paranoid android. === w2000pro (32 bit webbrowser) === webbrowser.c:2972: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2977: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2972: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2977: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE webbrowser.c:2972: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEBACK_FALSE webbrowser.c:2977: Test failed: expected Invoke_COMMANDSTATECHANGE_NAVIGATEFORWARD_FALSE

1 0

What would the best approach for adding securing Wine and is it a reasonable goal?
by Steven Stewart-Gallus 28 Aug '15

28 Aug '15

Hello, I noticed that CreateRestrictedToken basically just duplicates the token and doesn't do anything. This makes sense as Wine is implemented as a compatibility library and program loader and not as a virtual machine and Windows programs running on Wine can break out and access Linux system calls so making CreateRestrictedToken do anything more wouldn't accomplish anything. I think it would be really cool though if CreateRestrictedToken and similar sandboxing APIs actually accomplished something in Wine though. What would the best approach for securing Wine be and is it a reasonable goal? First, see http://wiki.winehq.org/SecuringWine. So far, I can think of a few approaches. The first approach is to make a whole operating system such as ReactOS. The second approach is making a whole operating system that only has device drivers for working on top of virtual machines or hypervisors. The third approach is making a kernel that runs as a normal user process on top of a full OS (similar to User-Mode Linux or a weekend project I am working on at https://gitlab.com/sstewartgallus/wum, also see the Chrome sandbox at https://www.chromium.org/developers/design-documents/sandbox, https://code.google.com/p/chromium/wiki/LinuxSandboxing and https://dev.chromium.org/developers/design-documents/sandbox/osx-sandboxing…) The fourth approach is to abandon securing Wine itself and simply run Wine programs inside separate sandboxes. ReactOS already serves as an example of the first approach. The second approach is basically similar to ReactOS. My project at https://gitlab.com/sstewartgallus/wum serves as a tiny example of of the third approach might work. The fourth approach of separate sandboxes is actually very simple. One possible implementation of this fourth approach on Linux might be to use a script like the sandbox-X.sh script shown below and remove the Z: symlink in dosdevices (this isn't actually needed or improves security but just looks nice.) Note that to make this script work I had to do some configuration to let my automatically su into the sandbox account. As well, I also had to download a dummy Xorg configuration to the home directory of the sandbox account. Thank you, Steven Stewart-Gallus sandbox-X.sh: #! /bin/sh set -e set -C set -u exec su -l -c 'exec sh <&3' sstewartgallus-sandbox 3<<'EOF' set -e set -C set -u exec 3<&- export DISPLAY=':76' export XPRA_SOCKET_DIR='/tmp' exec xpra\ start\ ${DISPLAY}\ --xvfb="Xorg -noreset +extension GLX +extension RANDR +extension RENDER -logfile ./${DISPLAY}.log -config ./xorg.conf"\ "--no-daemon"\ "--mmap-group"\ "--no-sharing"\ "--bell"\ "--system-tray"\ "--xsettings"\ "--cursors"\ "--encoding=rgb"\ "--clipboard"\ --start-child=xterm

2 1

Re: [1/3] comdlg32: Implement open dropdown menu.
by Marvin 28 Aug '15

28 Aug '15

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=16371 Your paranoid android. === wvistau64 (64 bit itemdlg) === No test summary line found

1 0

Re: Winelib and C++ static initialization
by Luke Dunstan 28 Aug '15

28 Aug '15

On Thu, 27 Aug 2015 at 00:44 Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > You dropped the wine-devel CC. Was that intentional? There are people > who have more clues about winelib than I do. > No, it was accidental, sorry. > > >> I found that OutputDebugStringA doesn't write anything here, > >> even if successful. I replaced it with printf calls to get > >> actual output. > > > > OK, but why exactly is this necessary? This is just an artificial > > example to demonstrate the general problem. > I looked into the source code of OutputDebugStringA, but I couldn't find > an obvious answer. It certainly does a lot more than just write a string > to STDOUT. I didn't really understand what it was doing. > Yes, it sends the message to the attached debugger if any, not to stdout. On Windows or Wine you can run SysInternals DbgView.exe to see it. It's just an example though, and many other APIs also crash when called from initialisers. >> Though it's not quite working here either: > > > > Any ideas why, or how it could be fixed? > Sorry, no idea :-( . > > > Yes. My hope was that Winelib could be used to help port a legacy > > Windows CE 4.x application to Linux (ARM, though I am testing on > > x86 right now). Initially I could try compiling on Windows and > > running it on Linux, but the real goal would be to port the > > application in stages, so changing a few modules at a time to use > > Linux APIs while leaving some parts using the Win32 (and MFC) APIs. > > Eventually there would be no need for Winelib but I'd expect that > > porting all of the code at once would resulting in a lot more > > debugging effort because changes would not be localised. > Hmm yeah, that sounds like a task where you need winelib. Unfortunately > winelib isn't something that gets used a lot, and even less so with C++. > > Also keep in mind that Wine doesn't target Windows CE applications, so > you'll have to invest a lot of time into bridging Windows CE <-> Win32 > differences. > Yes I understand, but fortunately most of the application also runs on normal Win32. You'll also have to compile MFC with Winelib to target ARM. It should > be possible to compile MFC (or at least parts of it) with winelib, but > I don't expect this to be easy either. > That's true, and that was actually the first thing I tried to do. I tried both static and dynamic libraries but it crashes before it gets to WinMain(), hence my question. GDB can trap the crash but the stack trace gives no function names or other useful information. (gdb) bt #0 0x00000000 in ?? () #1 0x7ec4b7c0 in ?? () #2 0x7ec4b77e in ?? () #3 0x7ec4b79e in ?? () #4 0xb7febd77 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) Winedbg cannot even get that far. But I will try 1.7... Luke

2 1