August 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Paul Gofman

On 08/24/2017 04:39 PM, Henri Verbeet wrote: > On 23 August 2017 at 16:17, Paul Gofman <gofmanp(a)gmail.com> wrote: >> -static IDirect3DDevice9 *create_device(IDirect3D9 *d3d, HWND device_window, HWND focus_window, BOOL windowed) >> +static IDirect3DDevice9 *create_device_behavior(IDirect3D9 *d3d, HWND device_window, HWND focus_window, >> + BOOL windowed, DWORD behavior_flags) > It's perhaps a bit of an uncomfortable change to make due to the > number of tests in visual.c, but ideally this would match the version > of create_device() in device.c. Lacking that, there are a few tests in > visual.c that just call IDirect3D9_CreateDevice() directly. In either > case, we'd like device.c and visual.c to converge instead of diverge. So I will create the device without this helper function then. >> + hr = IDirect3DDevice9_SetVertexShader(device, NULL); >> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); >> + hr = IDirect3DDevice9_SetVertexShader(device, pure_sw_shader); >> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > Is resetting the shader to NULL really needed here? I will check once again, but I think I saw the second call to DrawPrimitiveUP succeeds for the next scene also if already failed once for previous scene. So it can be removed along with the first call returning invalid value below. > >> + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); >> + todo_wine >> + ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); >> + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); >> + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > Odd. It looks like pretty consistent behaviour between drivers, at least it worked the same way for me on Intel & Nvidia (WIndows 7) and test bot. I suppose directx "frontend" part resets the shader internally after returning an error on first call, and then falls back to fixed function vertex processing on the next call. Even if the shader is reset though calling GetVertexShader still returns that invalid one previously set. > >> + /* wined3d does not guarantee 0 for out of bounds constant access by default. */ > IIRC neither does Windows, in general. Matteo may have a better > recollection of the details, but IIRC while it mostly works out in > practice on current NVIDIA hardware, it doesn't necessarily everywhere > else, and is essentially hardware/driver specific behaviour. > So should I maybe change the test not to check for exact value but rather for not matching constant c256?

Aug. 24, 2017

Issue with suspended process

by Jonathan Doron

Hi all, I have an application that is creating a process suspended and then using detours modifies the imports of the new process prior to resuming it (the application is called Tracker.exe and is part of MS toolchain, it can be retrieved in MS EWDK package) The application does not work as it should on Wine, as the DLL its trying to inject to the new process is not getting loaded, I tracked down the problem here are the technical details: When a new process is created, after all the other set-ups its running the function: dlls/ntdll/server.c!server_init_process_done This function sets up the handlers for the different signals (signal_init_process) and makes a wine_server_call init_process_done. In the wine server function server/process.c!init_process_done a check is made to see if the thread of the process needs to be suspended (stop_thread_if_suspended) and indeed when a process is created with the CREATE_SUSPENDED flag, thread->suspend == 1, process->suspend == 0, and the process state is done at this point). This makes the wine_server call to stop_thread which will send a SIGUSR1 signal to the new process. The new process however still have the signals in a block state, thus not processing the signal and putting it into a pending state. The next thing that happens is LdrInitializeThunk continues and fixing up the EXE module imports, this is not the same behavior as Windows in which the Ldr only starts running after the thread has resumed. Only later signals are being unblocked and then the thread enters a suspended state, the function which unblocks the signals today is attach_process_dlls The interesting thing is that in the past Wine behavior was correct and the change that basically broke it is commit: commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Nov 19 14:27:07 2007 +0100 ntdll: Unblock signals in process init only after the dlls have been imported. Unfortunately though there I could not find any reason why the change was made or if there is any bug that it fixed back then (2007) . I was thinking that perhaps in order to resolve the problem and be closer in the behavior to Windows would be to unblock the signals just before server_init_process_done returns. Please let me know if you have any other questions, will be happy to resolve this now that we have all the information laid out. Thanks, -- Jon.

Aug. 24, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Henri Verbeet

On 23 August 2017 at 16:17, Paul Gofman <gofmanp(a)gmail.com> wrote: > -static IDirect3DDevice9 *create_device(IDirect3D9 *d3d, HWND device_window, HWND focus_window, BOOL windowed) > +static IDirect3DDevice9 *create_device_behavior(IDirect3D9 *d3d, HWND device_window, HWND focus_window, > + BOOL windowed, DWORD behavior_flags) It's perhaps a bit of an uncomfortable change to make due to the number of tests in visual.c, but ideally this would match the version of create_device() in device.c. Lacking that, there are a few tests in visual.c that just call IDirect3D9_CreateDevice() directly. In either case, we'd like device.c and visual.c to converge instead of diverge. > + hr = IDirect3DDevice9_SetVertexShader(device, NULL); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); > + hr = IDirect3DDevice9_SetVertexShader(device, pure_sw_shader); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); Is resetting the shader to NULL really needed here? > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + todo_wine > + ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(*quad)); > + ok(SUCCEEDED(hr), "Got unexpected hr %#x.\n", hr); Odd. > + /* wined3d does not guarantee 0 for out of bounds constant access by default. */ IIRC neither does Windows, in general. Matteo may have a better recollection of the details, but IIRC while it mostly works out in practice on current NVIDIA hardware, it doesn't necessarily everywhere else, and is essentially hardware/driver specific behaviour.

Aug. 24, 2017

Re: [PATCH 2/2] mshtml: Properly expose IHTMLDocument6 interface to scripts.

by Marvin

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=32807 Your paranoid android. === w7u (32 bit htmldoc) === htmldoc.c:2682: Test failed: unexpected call GetOverrideKeyPath

Aug. 24, 2017

Issue with suspended process

by Jonathan Doron

Hi all, I have an application that is creating a process suspended and then using detours modifies the imports of the new process prior to resuming it (the application is called Tracker.exe and is part of MS toolchain, it can be retrieved in MS EWDK package) The application does not work as it should on Wine, as the DLL its trying to inject to the new process is not getting loaded, I tracked down the problem here are the technical details: When a new process is created, after all the other set-ups its running the function: dlls/ntdll/server.c!server_init_process_done This function sets up the handlers for the different signals (signal_init_process) and makes a wine_server_call init_process_done. In the wine server function server/process.c!init_process_done a check is made to see if the thread of the process needs to be suspended (stop_thread_if_suspended) and indeed when a process is created with the CREATE_SUSPENDED flag, thread->suspend == 1, process->suspend == 0, and the process state is done at this point). This makes the wine_server call to stop_thread which will send a SIGUSR1 signal to the new process. The new process however still have the signals in a block state, thus not processing the signal and putting it into a pending state. The next thing that happens is LdrInitializeThunk continues and fixing up the EXE module imports, this is not the same behavior as Windows in which the Ldr only starts running after the thread has resumed. Only later signals are being unblocked and then the thread enters a suspended state, the function which unblocks the signals today is attach_process_dlls The interesting thing is that in the past Wine behavior was correct and the change that basically broke it is commit: commit 0f5fc117a2320bb7e21b9ae4d07d717bed413171 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Nov 19 14:27:07 2007 +0100 ntdll: Unblock signals in process init only after the dlls have been imported. Unfortunately though there I could not find any reason why the change was made or if there is any bug that it fixed back then (2007) . I was thinking that perhaps in order to resolve the problem and be closer in the behavior to Windows would be to unblock the signals just before server_init_process_done returns. Please let me know if you have any other questions, will be happy to resolve this now that we have all the information laid out. Thanks, -- Jon.

Aug. 24, 2017

Re: Filling in ARM64 ABI structs

by Martin Storsjö

Hi André, On Wed, 23 Aug 2017, André Hentschel wrote: > Am 22.08.2017 um 15:48 schrieb Martin Storsjö: >> Hi, >> >> I've noticed that some of the ABI specific structs for ARM64 are incomplete or missing - namely _JUMP_BUFFER in include/msvcrt/setjmp.h (not yet available) and _CONTEXT (not missing but only has got made-up content so far) and associated CONTEXT_* defines, and structs like RUNTIME_FUNCTION and UNWIND_HISTORY_TABLE in include/winnt.h. >> >> As far as I know, these structs should be available in the win10 sdk. (MSDN doesn't have them but just says to refer to winnt.h for the CONTEXT struct at least). In order not to accidentally make myself uneligible for contributing code on these matters, I've tried to not look at the sdk. >> >> Can someone help out with completeing these data structures according to whatever clean-room guidelines are required? When looking at existing code with git blame, they mostly appear as such without any further explanation on how they were derived, so I'm taking the more cautious route here. >> >> // Martin >> >> > > Hi, > > IANAL, but you should be fine as long as you only study the headers and > don't copy&paste... Thanks - if someone else can confirm this I can proceed in this way myself. > Sadly I have no idea anymore how I implemented JUMP_BUFFER for ARM, but > it's a good thing to have an application which needs it, as it seems we > only have tests for amd64 Since I've got a pretty much working compiler for this, I can create whatever calling code I want to test it. I can't know for sure that it's correct with what the so far non-public MSVC/arm64 would do, but I doubt it'd differ too much. > What is also strongly needed is that distributions stop using x18, have > you done something in this regard? Not really. In all the code I've tested so far, I haven't struck any concrete issues with only wine but not the rest of the distro built with -ffixed-x18. But then again, the apps I've built myself don't use the TEB at all, so I won't notice either - I've mostly tested uuidgen.exe and midl.exe from the win10 sdk, for generic compatibility and compatibility with the va_args. // Martin

Aug. 23, 2017

Re: Filling in ARM64 ABI structs

by André Hentschel

Am 22.08.2017 um 15:48 schrieb Martin Storsjö: > Hi, > > I've noticed that some of the ABI specific structs for ARM64 are incomplete or missing - namely _JUMP_BUFFER in include/msvcrt/setjmp.h (not yet available) and _CONTEXT (not missing but only has got made-up content so far) and associated CONTEXT_* defines, and structs like RUNTIME_FUNCTION and UNWIND_HISTORY_TABLE in include/winnt.h. > > As far as I know, these structs should be available in the win10 sdk. (MSDN doesn't have them but just says to refer to winnt.h for the CONTEXT struct at least). In order not to accidentally make myself uneligible for contributing code on these matters, I've tried to not look at the sdk. > > Can someone help out with completeing these data structures according to whatever clean-room guidelines are required? When looking at existing code with git blame, they mostly appear as such without any further explanation on how they were derived, so I'm taking the more cautious route here. > > // Martin > > Hi, IANAL, but you should be fine as long as you only study the headers and don't copy&paste... Sadly I have no idea anymore how I implemented JUMP_BUFFER for ARM, but it's a good thing to have an application which needs it, as it seems we only have tests for amd64 What is also strongly needed is that distributions stop using x18, have you done something in this regard?

Aug. 23, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Paul Gofman

Test failure (https://source.winehq.org/patches/data/136654.testfail) is unrelated to this patch. It fails in a different test run before the newly added one. Besides, I tested with a dummy patch (adding just a newline in visual.c), similar failure is there: https://testbot.winehq.org/JobDetails.pl?Key=32779. On 08/23/2017 05:33 PM, Marvin wrote: > 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=32778 > > Your paranoid android. > > > === w8 (32 bit visual) === > visual.c:7975: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 > > === w1064 (64 bit visual) === > visual.c:8023: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors). >

Aug. 23, 2017

Re: JACK driver for WINE

by Andrew Eikum

On Fri, Aug 18, 2017 at 02:07:29PM -0600, Jeremy Banks wrote: > I noticed those .spec files in the driver sources. I've been trying to put > together a mental model of how the drivers in Wine work. I noticed the first > function on each line wasn't in the driver source file, but often the 2nd > function was (though the ones in the MMDevAPI section do have nigh-identical > names). Do I correctly understand that for a line in the .spec file, the > first function listed is the function that will be called by MMDevAPi or the > application, and the second one is the function that the former will be > translated to? Do I correctly understand that the driver files thus contain > the translated function calls, plus any additional necessary support > functions and data structure needed for getting data to and from the audio > system in question? > Right. Our mmdevapi loads functions from the drivers and calls them to do stuff like determine which driver to use, and to create the IMMDevice and IAudioClient objects. > It occurs to me that since Wine interfaces with Windows applications, I > might want to study the documentation for the Windows sound and driver APIs. > Is this a correct assumption, or is this not particularly necessary in this > case? > Yes, you'll need to understand the APIs that you will be implementing. You don't need to dig into Windows DDK stuff, our drivers operate at a higher level than that. MSDN's mmdevapi docs are pretty good, and you can always reference the other Wine drivers to see how they implement the functions. Andrew

Aug. 23, 2017

Re: [PATCH 3/3] d3d9/tests: Add test for SW shader in MVP mode.

by Marvin

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=32778 Your paranoid android. === w8 (32 bit visual) === visual.c:7975: Test failed: Input test: Quad 3(2crd-wrongidx) returned color 0x00ff00ff, expected 0x00ff0080 === w1064 (64 bit visual) === visual.c:8023: Test failed: Got unexpected color 0x00007580 for quad 2 (different colors).

Aug. 23, 2017