For all mach vm operations this removes the task suspend and resume, which are not needed.
This uses `mach_vm_read_overwrite` to read into a caller-specified buffer, saving the `mach_vm_deallocate` call (bringing all read operations down to 1 syscall from 4).
The only alignment restriction on `mach_vm_write` according to the original CMU documentation is that data is
> [pointer to page aligned in array of bytes] An array of data to be written.
(In practice it also works with arbitrary addresses on macOS, but it probably doesn't hurt to follow the original specifications here).
The only other reference that these read/writes should be page-aligned is from the GNU Hurd documentation
> The current implementation requires that address, data and data_count all be page-aligned. Otherwise, KERN_INVALID_ARGUMENT is returned.
which I assume was the reason why this was originally done (plus it sounds to me like they will fix that in the future and 4fe19777 already broke GNU Hurd support anyways, if that was supposed to be working).
Also this includes the missing mach part of 5b1f3b14, which was only applied to the ptrace backend, and together with the `write_process_memory` rework, this gets rid of all fixmes in mach.c
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4826
Checking flags of the thread desktop to determine whether virtual desktop is on is unreliable.
For example, CEF applications create their own desktop and so is_virtual_desktop() could incorrectly
report that virtual desktop is off.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55810
--
v3: server: inherit wine internal desktop flags when creating desktops.
include: Rename DF_WINE_CREATE_DESKTOP to DF_WINE_VIRTUAL_DESKTOP.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4786
Jan Sikorski (@jsikorski) commented about dlls/ddraw/surface.c:
> src_impl ? &src_impl->IDirectDrawSurface_iface : NULL, flags);
> }
>
> +/* Emperor: Rise of the Middle Kingdom accesses the map pointer outside of
> + * Lock()/Unlock(), and expects those updates to be propagated by a Blt().
> + * It also blits to the surface, and color-fills it.
> + *
> + * This function is called after a blit or color-fill that might update the GPU
I'm a little confused because the comment says it's called after a blit or color fill, but in `ddraw_surface_blt` it's apparently only called after a color fill, and not after a blit.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4781#note_57154
--
v8: vkd3d-shader/dxil: Handle the DXIL SWITCH instruction.
vkd3d-shader/dxil: Handle the DXIL PHI instruction.
vkd3d-shader/dxil: Handle the DXIL BR instruction conditional variant.
vkd3d-shader/dxil: Handle the DXIL BR instruction unconditional variant.
vkd3d-shader/dxil: Introduce a code block terminator struct.
vkd3d-shader/ir: Include an initial label instruction in the first control flow block.
vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten SWITCH/CASE/DEFAULT/ENDSWITCH control flow instructions.
vkd3d-shader/ir: Flatten LOOP/BREAK/CONTINUE/ENDLOOP control flow instructions.
vkd3d-shader/ir: Flatten IF/ELSE/ENDIF control flow instructions.
vkd3d-shader/spirv: Handle RETP in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Handle DISCARD and TEXKILL in spirv_compiler_handle_instruction().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/491
--
v21: vkd3d-shader/ir: Include an initial label instruction in the first control flow block.
vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten SWITCH/CASE/DEFAULT/ENDSWITCH control flow instructions.
vkd3d-shader/ir: Flatten LOOP/BREAK/CONTINUE/ENDLOOP control flow instructions.
vkd3d-shader/ir: Flatten IF/ELSE/ENDIF control flow instructions.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
This fixes a rendering issue (and ultimately a crash) in PowerPoint when
compiling with GCC 8.
GCC8 doesn't support the `excess-precision=standard` option under the
`#pragma GCC optimize` directive.
This results in unpredictable floating point rounding leading to errors
when inserting segments (with missing edges and/or triangles).
Using 24-bit precision ensures we don't have any excess precision.
--
v3: d2d1: Fix double free bug when d2d_geometry_sink_Close fails
https://gitlab.winehq.org/wine/wine/-/merge_requests/4824
This fixes a rendering issue (and ultimately a crash) in PowerPoint when
compiling with GCC 8.
GCC8 doesn't support the `excess-precision=standard` option under the
`#pragma GCC optimize` directive.
This results in unpredictable floating point rounding leading to errors
when inserting segments (with missing edges and/or triangles).
Using 24-bit precision ensures we don't have any excess precision.
--
v2: d2d1: Use 24-bit FP precision for triangulate.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4824
This fixes a rendering issue (and ultimately a crash) in PowerPoint when
compiling with GCC 8.
GCC8 doesn't support the `excess-precision=standard` option under the
`#pragma GCC optimize` directive.
This results in unpredictable floating point rounding leading to errors
when inserting segments (with missing edges and/or triangles).
Using 24-bit precision ensures we don't have any excess precision.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4824
I had a bugreport here: https://bugs.winehq.org/show_bug.cgi?id=56161
This pull req fixes the bug that programs that do VirtualAlloc(placeholder)/VirtualFree(keep placeholder)/MapViewOfFile3(replace placeholder), do not run. Like the dotnet pe loader in .net 7 for example.
It was not clear to me at first, because i didnt notice it on msdn, but the way that Dmitry Timoshkov
"hacked" it in https://bugs.winehq.org/show_bug.cgi?id=56122 is actually exactly how it is supposed to happen according to msdn.
From here: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-…

So thanks to Dmitry Timoshkov.
If you are interested you could also look into the thing i mentioned in the bug report, that MapViewOfFile3 doesn't round down to 64k, but, i don't think this is a serious problem yet.
--
v11: kernelbase: Added a test for MapViewOfFile3 with MEM_REPLACE_PLACEHOLDER
https://gitlab.winehq.org/wine/wine/-/merge_requests/4822