Work around slow runtime of current FlushProcessWriteBuffers() implementation on macOS.
The total iteration count becomes:
```
- positive half: 32768 * 1 (old) = 8192 * 4 (new)
- negative half: 32768 * 1 (old) > 8192 * 1 (new)
```
--
v2: kernel32/tests: Shorten time for negative half of litmus test for FlushProcessWriteBuffers().
https://gitlab.winehq.org/wine/wine/-/merge_requests/7908
This reverts commit 504a305a60849704f2d83b55e9aabb26d89edf11.
The choice of weak barrier was by design. The stronger barrier broke the
positive half of the litmus test for FlushProcessWriteBuffers():
> virtual.c:4568: Test failed: expected write-read reordering with compiler barrier
> only (got 0 reorderings)
FlushProcessWriteBuffers() is used in tandem with a compiler-only
barrier to implement fast synchronization, where only one side is
executed frequently and the other side only occassionally (e.g., garbage
collection). Prominent applications include .NET and HotSpot JVM.
Although _ReadWriteBarrier() is "marked deprecated," it is in fact used
by Microsoft's own STL library (with explicit suppression of warning) to
implement a compiler-only memory barrier[^1]. The deprecation notice
suggests C++11 atomics as the (only?) alternative.
[^1]: https://github.com/microsoft/STL/blob/b5df16a98934319e2e6864d6036cbe9cd9c74…
--
v2: kernel32/tests: Don't use _ReadWriteBarrier() on clang.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7895
This reverts commit 504a305a60849704f2d83b55e9aabb26d89edf11.
The choice of weak barrier was by design. The stronger barrier broke the
positive half of the litmus test for FlushProcessWriteBuffers():
> virtual.c:4568: Test failed: expected write-read reordering with compiler barrier
> only (got 0 reorderings)
FlushProcessWriteBuffers() is used in tandem with a compiler-only
barrier to implement fast synchronization, where only one side is
executed frequently and the other side only occassionally (e.g., garbage
collection). Prominent applications include .NET and HotSpot JVM.
Although _ReadWriteBarrier() is "marked deprecated," it is in fact used
by Microsoft's own STL library (with explicit suppression of warning) to
implement a compiler-only memory barrier[^1]. The deprecation notice
suggests C++11 atomics as the (only?) alternative.
[^1]: https://github.com/microsoft/STL/blob/b5df16a98934319e2e6864d6036cbe9cd9c74…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7895
* Remove cases for vwin32 IOCTLs 0x10 and 0x29 numbers as they are unsupported by Windows 9x
* Fix functions accepted by IOCTLs VWIN32_DIOC_DOS_IOCTL and VWIN32_DIOC_DOS_DRIVEINFO
* Add missing IOCTL VWIN32_DIOC_DOS_INT13 case for TRACE log
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7907
To prevent performance degradation, we will cache the result of GetConsoleOutputCP() after executing every external command.
--
v4: cmd: Use the console output code page to read batch files.
programs/cmd: Factor out code_page when searching for a label.
cmd/tests: Add updated code page test in batch file.
cmd: Use the OEM code page if GetConsoleOutputCP fails.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6885
According to the DPMI specification, DPMI functions 0900h-0902h related to
Virtual Interrupt State has to always return state in AL register.
As wine does not support disabling virtual interrupt flag, report that
interrupts are always enabled (AL=1).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7904