Enforce proper atomic update so that other threads do not read stale
data from IO_STATUS_BLOCK.
Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com>
--
v17: ntdll: Fix reading stale Information from IOSB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/155
On Windows, application-specific settings are stored in the registry
under HKCU\\Console\\<path_to_app>.
Our implementation of conhost.exe does not know which process is
connected to it, so we need to get the full process image name before
loading any application-specific console settings.
To do this, we extend the server protocol to pass the process Id of
the connected console process to conhost.exe.
Please run tools/make_requests before merging.
--
v4: conhost: Load/Save console settings using the process path or window title
https://gitlab.winehq.org/wine/wine/-/merge_requests/1492
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53863
This fixes a regression introduced by ebbcc10b0593948657b8e684c3a9be8ace1a5d25.
Prior to that commit, buffers which were not CPU-accessible would not have the
WINED3D_BUFFER_USE_BO flag set, and accordingly
buffer_resource_sub_resource_map() would simply return the SYSMEM location,
ignoring the DISCARD and NOOVERWRITE flags.
However, the "accelerated" path in wined3d_cs_map_upload_bo() only checks for
the DISCARD flag, assuming that it is only set for dynamic GPU-accessible
buffers, and would subsequently try to allocate non-mappable memory and then map
it.
This commit avoids the accelerated path for such buffers, once again matching
our old behaviour. According to [1], this also matches Windows: DISCARD on
SYSTEMMEM buffers is ignored on both AMD and NVidia, and NOOVERWRITE is ignored
on NVidia (but not AMD).
[1] https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/messa…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1864