Surfaces without DDSCAPS_TEXTURE can still be textured when used with a software
device.
wined3d currently doesn't care about the bind flags for surfaces set with
wined3d_stateblock_set_texture(), but we currently set the right bind flags
anyway.
More saliently, I plan to change this fact, and internally translate those
textures to SRVs, in order to simplify some internal code and make d3d1-9
support for the Vulkan backend easier. In this case we really will need
WINED3D_BIND_SHADER_RESOURCE to be set.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4038
--
v3: uiautomationcore: Use EVENT_OBJECT_DESTROY to remove HWNDs from the COM API focus change HWND map.
uiautomationcore: Use EVENT_OBJECT_FOCUS to advise HWND providers of focus change events in the COM API.
uiautomationcore: Query EVENT_OBJECT_FOCUS HWND for a serverside provider if there is a registered focus change event handler.
uiautomationcore/tests: Add tests for IUIAutomationFocusChangedEventHandler event advisement behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4024
**Overview:**
Wine currently reports an exit code of zero for processes that terminate due to either of the following conditions:
- The Linux process that represents the Windows process receives a signal such as `SIGKILL` (e.g. due to a user manually killing the process, or the Linux OOM killer targeting the process due to memory pressure)
- The process fails to start because the image is a 32-bit executable and Wine has only been built with 64-bit support
Both of these scenarios represent failures, and so a non-zero exit code is appropriate. This patch ensures that an exit code of 1 is reported for these abnormal process termination edge cases.
**Underlying cause:**
The following logic flow occurs in the Wine server for typical process termination:
1. When a `process` object is created by the Wine server, its `exit_code` field is [set to an initial value](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.… of `STILL_ACTIVE`, and the `exit_code` field in each of its corresponding `thread` objects is [set to a default value of zero](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/thread.c?….
2. When a client process terminates, it sends a `terminate_process` protocol request to the server, and the handler [passes the specified exit code](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c… to the `terminate_process()` function. This function sets the `is_terminating` field of the process object [to a value of 1](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c?re…, and if the exit code is non-zero then it also [copies its value to each of the thread objects](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/proces… for the process.
3. The client process closes the pipe that it had been using to communicate with the server.
4. The server [detects the pipe close event](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.… and calls the `kill_process()` function, specifying a value of zero for the `violent_death` parameter.
5. The logic in the `kill_process()` function identifies this as a [normal termination on pipe close](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.…, and then subsequently calls the `kill_thread()` function to [kill each of the threads for the process](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/proces….
6. The `kill_thread()` function [then calls](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/thread.c… `remove_process_thread()`, which [copies the exit code from the last thread object](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process… to the `exit_code` field of the process object.
7. The final value of the `exit_code` field is [reported when responding](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/pro… to `get_process_info` protocol requests, [as sent by](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/dlls/ntdll/unix/pr… `NtQueryInformationProcess()`.
The abnormal process termination scenarios listed earlier will skip the `terminate_process` protocol request and immediately close the pipe. As a result, the `is_terminating` field of the process object will retain its default value of zero, and the `exit_code` field of each thread for the process will also remain at the default value of zero.
Since the logic in `process_poll_event()` always treats a pipe close event as a non-violent termination, `remove_process_thread()` will simply copy the exit code value of zero from the last thread into the process object, and this will then be reported when querying the process exit code.
**Fix details:**
The fix modifies `process_poll_event()` to check the value of the `is_terminating` field of the process object, and to treat a pipe close event as a violent termination if the value of the field is zero. This triggers the alternative code path in `kill_process()` that calls `terminate_process()` and [specifies an exit code value of 1](https://gitlab.winehq.org/wine/wine/-/blob/wine-8.16/server/process.c?re…, which is copied to the thread objects and subsequently to the process object.
In my testing, only the abnormal process termination scenarios listed above result in the value of the `is_terminating` field being zero when the pipe is closed. In all other scenarios, I have observed the value to be 1 when the pipe close event is detected. Non-abnormal scenarios tested include ordinary process completion with both zero and non-zero exit codes, crashes in Windows processes due to unhandled exceptions, and ending processes via the Wine implementation of Task Manager.
--
v3: wineserver: Report non-zero exit code for abnormal process termination
https://gitlab.winehq.org/wine/wine/-/merge_requests/3908
I also looked into supporting that in NtEnumerateValueKey() at once, but it doesn't look like Windows supports it with KeyValuePartialInformationAlign64, I was only getting STATUS_INVALID_PARAMETER in tests. I also don't see NtQueryValueKey actually enforcing 64 bit alignment requirement (this part is in the tests).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4059
--
v4: dmsynth: Create and register a fluid_sfont instance.
dmsynth: Create a fluid_synth instance on Open.
dmsynth: Simplify IDirectMusicSynth8_Open checks.
fluidsynth: Use Wine debugging facility for traces.
dmsynth: Import and use FluidSynth 2.3.3.
dmime/tests: Queue the message before calling SendPMsg twice.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3996
This defines (and, broadly, implements) the API for mapping sm1 combined
samplers to the target environment. This is possibly the simplest bit of API for
sm1 support thus far.
It does not actually involve any API changes. Rather, each combined sampler is
split into two descriptors, one for the sampler and one for the texture, both
with the same binding index as the original combined sampler.
--
I feel rather positive about this bit of API. it required very little design
concern or implementation difficulty on the vkd3d side.
On the Wine side, it required quite a lot of change, but I think pretty much all
of that change was positive on its own merits, and should probably be applied
independently of the sm1/Vulkan work. We've talked about translating
wined3d_device_set_sampler_state() and wined3d_device_set_texture() to
wined3d_device_set_sampler() and wined3d_device_set_shader_resource_view() for
quite some time now, and that was pretty much exactly what was required to make
this work—that and choosing the obvious mapping of "same index for both state
objects".
The most obvious alternative to this design, to me, would be to reroll
struct vkd3d_shader_interface_info (or extend it without rerolling), adding a
new array for mapping a combined sampler in the *source* environment to two
separate descriptors in the *target* environment, i.e.
struct vkd3d_shader_resource_binding in reverse. We would probably also want to
design a way to map a combined sampler to a combined sampler (a sixth array? Or
reuse struct vkd3d_shader_descriptor_binding with a new descriptor type?)
I suppose the advantage of such an alternative design would be that it reports
"one" descriptor as "one", not "two", but the associated complexity seems far
greater, and accordingly I don't really want to give it the time of day. (Note
also that this patch set handles combined -> combined mapping without any extra
effort). I will of course yield to maintainer preference, though.
--
As before, I've prepared proof-of-concept code for Wine. The branches are here:
https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5https://gitlab.winehq.org/zfigura/wine/-/commits/himavant6
The relevant test can be run with:
make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/tex2D.shader_test
These branches are rather larger than the previous ones. By way of summary, the
vkd3d branch contains these patches, plus about two dozen patches to hook up sm1
tests and to fix various corner cases surrounding semantic translation (much of
which should be rewritten with a VSIR-based "lowering" approach in mind).
The Wine branch contains:
* Wine merge request 4027,
* the patches for sm1 constant buffers,
* a set of patches to transform individual sampler states into sampler objects
(of which [1] is the most interesting), and
* a set of patches to transform textures into SRVs (of which [2] is the most
interesting).
As described above, there is not actually any part of the Wine side that touches
the vkd3d-shader interface.
[1] https://gitlab.winehq.org/zfigura/wine/-/commit/984e478763c99157a6ec49388fe…
[2] https://gitlab.winehq.org/zfigura/wine/-/commit/722c1bf1f6a7691c9ed431bd433…
```
What are the roots that clutch, what branches grow
Out of this stony rubbish? Son of man,
You cannot say, or guess, for you know only
A heap of broken images, where the sun beats,
And the dead tree gives no shelter, the cricket no relief,
And the dry stone no sound of water.
```
--
v2: vkd3d-shader/ir: Translate TEX instructions to SAMPLE.
vkd3d-shader: Scan combined sampler declarations.
include: Define an API for mapping sm1 samplers to the target environment.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/394
--
v3: mf: Handle errors with source event generator in session.
mf/test: Test error case when session is streaming.
mf/test: Move stream sink stub above media sink stub.
mf/test: Test error cases in media sesssion.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3789
This defines (and, broadly, implements) the API for mapping sm1 combined
samplers to the target environment. This is possibly the simplest bit of API for
sm1 support thus far.
It does not actually involve any API changes. Rather, each combined sampler is
split into two descriptors, one for the sampler and one for the texture, both
with the same binding index as the original combined sampler.
--
I feel rather positive about this bit of API. it required very little design
concern or implementation difficulty on the vkd3d side.
On the Wine side, it required quite a lot of change, but I think pretty much all
of that change was positive on its own merits, and should probably be applied
independently of the sm1/Vulkan work. We've talked about translating
wined3d_device_set_sampler_state() and wined3d_device_set_texture() to
wined3d_device_set_sampler() and wined3d_device_set_shader_resource_view() for
quite some time now, and that was pretty much exactly what was required to make
this work—that and choosing the obvious mapping of "same index for both state
objects".
The most obvious alternative to this design, to me, would be to reroll
struct vkd3d_shader_interface_info (or extend it without rerolling), adding a
new array for mapping a combined sampler in the *source* environment to two
separate descriptors in the *target* environment, i.e.
struct vkd3d_shader_resource_binding in reverse. We would probably also want to
design a way to map a combined sampler to a combined sampler (a sixth array? Or
reuse struct vkd3d_shader_descriptor_binding with a new descriptor type?)
I suppose the advantage of such an alternative design would be that it reports
"one" descriptor as "one", not "two", but the associated complexity seems far
greater, and accordingly I don't really want to give it the time of day. (Note
also that this patch set handles combined -> combined mapping without any extra
effort). I will of course yield to maintainer preference, though.
--
As before, I've prepared proof-of-concept code for Wine. The branches are here:
https://gitlab.winehq.org/zfigura/vkd3d/-/commits/himavant5https://gitlab.winehq.org/zfigura/wine/-/commits/himavant6
The relevant test can be run with:
make tests/shader_runner.exe && WINE_D3D_CONFIG=renderer=vulkan wine tests/shader_runner.exe ../vkd3d/tests/hlsl/tex2D.shader_test
These branches are rather larger than the previous ones. By way of summary, the
vkd3d branch contains these patches, plus about two dozen patches to hook up sm1
tests and to fix various corner cases surrounding semantic translation (much of
which should be rewritten with a VSIR-based "lowering" approach in mind).
The Wine branch contains:
* Wine merge request 4027,
* the patches for sm1 constant buffers,
* a set of patches to transform individual sampler states into sampler objects
(of which [1] is the most interesting), and
* a set of patches to transform textures into SRVs (of which [2] is the most
interesting).
As described above, there is not actually any part of the Wine side that touches
the vkd3d-shader interface.
[1] https://gitlab.winehq.org/zfigura/wine/-/commit/984e478763c99157a6ec49388fe…
[2] https://gitlab.winehq.org/zfigura/wine/-/commit/722c1bf1f6a7691c9ed431bd433…
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/394
Nikolay Sivov (@nsivov) commented about dlls/dwrite/gdiinterop.c:
> return hr;
> }
>
> - scaled_run = *run;
> - scaled_run.fontEmSize *= target->ppdip;
> - hr = IDWriteFactory7_CreateGlyphRunAnalysis(target->factory, &scaled_run, &target->m, rendermode, measuring_mode,
> + scaled_matrix = target->m;
> + scaled_matrix.m11 *= target->ppdip;
> + scaled_matrix.m22 *= target->ppdip;
> + hr = IDWriteFactory7_CreateGlyphRunAnalysis(target->factory, run, &scaled_matrix, rendermode, measuring_mode,
> gridfitmode, target->antialiasmode, originX, originY, &analysis);
> if (FAILED(hr))
The reason we currently modify font size is to produce better quality output. If you keep original size, then scale 10 times, it won't necessarily be looking good. Regarding matrix modification, how does that work for other components, for e.g. rotation? Maybe we should multiply by diagonal matrix instead?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3718#note_48043
--
v2: uiautomationcore: Use EVENT_OBJECT_FOCUS to advise HWND providers of focus change events in the COM API.
uiautomationcore: Query EVENT_OBJECT_FOCUS HWND for a serverside provider if there is a registered focus change event handler.
uiautomationcore/tests: Add tests for IUIAutomationFocusChangedEventHandler event advisement behavior.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4024
This allows *BSDs to also have a fast path similar to futexes for thread-ID alerts.
Also a kevent with `EV_CLEAR` and `NOTE_TRIGGER` maps perfectly to the thread alertable state, fixing the issue of the current mach-semaphore implementation not correctly waiting in the test case below:
```
NtAlertThreadByThreadId((HANDLE)GetCurrentThreadId());
NtAlertThreadByThreadId((HANDLE)GetCurrentThreadId());
NtWaitForAlertByThreadId(NULL, NULL);
NtWaitForAlertByThreadId(NULL, NULL);
```
I took the liberty to remove this mach semaphore implementation, since all versions of OSX have supported kqueue().
--
v3: ntdll: Implement thread-ID alerts using kqueue/kevent.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4049
In clock_change_state() when a clock is running, a timer is removed from clock->timers. The same
timer is then used to create an async result, which will eventually calls present_clock_timer_callback_Invoke()
and removes the same timer.
--
v2: mf: Avoid a double free of presentation clock timers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3955
It makes sense to use the {id}_{range_first} naming scheme for SRVs, UAVs and samplers too because their registers contain the same info, but just fixing this for now.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/395
Fixes Starfield not being able to take photos in photo mode (due to failing to creating windowscodecs' image factory due to COM apartment being initialized). Turns out on Windows RoGetActivationFactory() initializes implicit MTA apartment when called from STA thread, and so after that called once COM is implicitly uninitialized for any (new) thread until COM is uninitialized in the thread which called RoGetActivationFactory (or that thread exited). This is not the case on Win8 (where the function was first introduced) but looks consistent after that.
--
v4: combase: Ensure MTA existence in RoGetActivationFactory().
combase/tests: Add tests for implicit MTA with RoGetActivationFactory().
https://gitlab.winehq.org/wine/wine/-/merge_requests/3806
Since a81c53504ae32715e6e91bd020fdebd5bef20d48, reading the
debuggee environment could fail.
Depending on context, it could end up with no longer being
able to find ELF/Mach-O modules (as some codepaths get
the path to Wine's loader from debuggee environment).
Code was aligning read on allocation granularity, but this
can fail when not all the pages within that range are
committed. So align on page instead.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4048
--
v3: dmsynth: Create and register a fluid_sfont instance.
dmsynth: Create a fluid_synth instance on Open.
dmsynth: Simplify IDirectMusicSynth8_Open checks.
fluidsynth: Use Wine debugging facility for traces.
dmsynth: Import and use FluidSynth 2.3.3.
dmime/tests: Queue the message before calling SendPMsg twice.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3996
Windows gives this content special protection from being painted over, by some means that I have not investigated yet.
Emulate this protection for the trivial case of an InvalidateRect(...); call on the parent window.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3416
This allows *BSDs to also have a fast path similar to futexes for thread-ID alerts.
Also a kevent with `EV_CLEAR` and `NOTE_TRIGGER` maps perfectly to the thread alertable state, fixing the issue of the current mach-semaphore implementation not correctly waiting in the test case below:
```
NtAlertThreadByThreadId((HANDLE)GetCurrentThreadId());
NtAlertThreadByThreadId((HANDLE)GetCurrentThreadId());
NtWaitForAlertByThreadId(NULL, NULL);
NtWaitForAlertByThreadId(NULL, NULL);
```
I took the liberty to remove this mach semaphore implementation, since all versions of OSX have supported kqueue().
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4049
Test that there is a ~1.5s timer after entering fullscreen mode and restores WS_EX_TOPMOST if it's
missing when the timer times out.
--
v2: ddraw: Restore WS_EX_TOPMOST in exclusive fullscreen mode if it got removed.
ddraw/tests: Test WS_EX_TOPMOST restoration.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3915
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v6: vkd3d-shader/tpf: Write out 'switch' statements.
vkd3d-shader/hlsl: Initial support for 'switch' statement.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/361
Windows 10 [received support](https://devblogs.microsoft.com/commandline/af_unix-comes-to-window… for AF_UNIX sockets in Insider Build 17063. This merge request adds basic support for AF_UNIX sockets to ws2_32 and wineserver.
Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32. I considered the following options:
* Pass the Windows path to wineserver and do the conversion there.
* This is, as far as I can tell, not possible without major rearchitecting. wineserver does not have functions to translate Windows paths to Unix paths, for obvious reasons.
* Obtain the current working directory of the requesting process and temporarily change directories to there.
* This only handles relative paths and fails for absolute paths, UNC paths, etc.
* Conditionally change directories based on whether the path is relative or not.
* This is error-prone and wineserver does not have the requisite functions to do this cleanly.
I ultimately decided to pass the translated Unix path to wineserver, which changes directories to `dirname(path)`. It then provides `bind` and `connect` with `basename(path)`. This is not threadsafe, but wineserver is not (currently) multithreaded.
Abstract sockets are not fully supported by this patch, matching the behavior of Windows.
--
v65: ws2_32/tests: Add test for AF_UNIX sockets.
server: Fix getsockname() and accept() on AF_UNIX sockets.
server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket.
server: Allow for deletion of socket files.
ws2_32: Add support for AF_UNIX sockets.
ws2_32: Add afunix.h header.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786
- Make it present some frames
- Make it check that the frames are from the new device, instead of checking TerminateDevice count; fixes https://bugs.winehq.org/show_bug.cgi?id=55649
- ~~Make it check for and avoid some absurd crash on Windows~~
~~I tried everything I could think of, but Windows absolutely refuses to present a frame after changing the D3D device, instead choosing to return various absurd errors (segfaults, deadlocks, out of memory, etc). I suspect the VMR9 is haunted.~~
edit: Works on Windows now
--
v2: quartz/tests: Improve VMR9 ChangeD3DDevice test.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970
The last change adds a todo_wine for the time offset check, because we don't implement it. It wasn't necessary before becase InitPlay wasn't called yet.
It also adds a todo_wine for the playing state, because we don't implement start_time yet, and the segment start should be delayed instead of starting right away. Same, it wasn't necessary before because we were not calling Play.
We use notification messages to carry segment state and extend its lifetime for the entire play time, even though notifications might not be actually enabled. When notifications aren't enabled, we don't stamp the messages, so they are directly delivered to the performance output tool, and we then won't queue them to the notification message list. I don't think it matters very much, though we could alternatively use some internal message types instead.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4036
- Make it present some frames
- Make it check that the frames are from the new device, instead of checking TerminateDevice count; fixes https://bugs.winehq.org/show_bug.cgi?id=55649
- Make it check for and avoid some absurd crash on Windows
I tried everything I could think of, but Windows absolutely refuses to present a frame after changing the D3D device, instead choosing to return various absurd errors (segfaults, deadlocks, out of memory, etc). I suspect the VMR9 is haunted.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3970