This MR fix some video play crashes for KiriKiri games.
If we don't correctly return failure in dmo_wrapper_sink_Receive() call, the worker thread which calls Receive() will continue running and crashes then. With this MR, the worker thread will terminate as expected because Receive() fails.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6915
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
--
v10: server: Work around macOS W^X limitations in write_process_memory.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4826
According to the spec, the compiler is free to use a signed, unsigned, or even char type for enums, provided all values fit within the type. For example, constructs like `*_FORCE_DWORD` can force an unsigned type using a value like `0xffffffff`. While some headers use this approach, it’s inconsistent and 0x7fffffff is often used instead.
Unfortunately, MSVC and GCC differ in their behavior: GCC always uses an unsigned type, while MSVC uses a signed type when possible. Consequently, Clang’s behavior depends on the mode being used.
Additionally, Clang emits a warning for "useless" checks when building Wine in MinGW mode. For instance:
```
dlls/gdiplus/graphics.c:7337:18: warning: result of comparison of unsigned enum expression < 0 is always false [-WTautological-unsigned-enum-zero-compare]
7337 | src_space < 0 || src_space > CoordinateSpaceDevice)
```
This warning is impractical for code that aims to be portable. The check is not tautological when building in MSVC mode (e.g., in our CI). I considered disabling the warning, but since this is the only place in the codebase where it’s problematic, I believe we can simply adjust the check.
This resolves the last warning in LLVM builds, allowing -Werror to be used in MinGW mode as well.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6949