The Aim of this MR is to fix https://bugs.winehq.org/show_bug.cgi?id=10941
In a nutshell:
- CUI app starts, and CRT inits its std streams from console,
- app calls FreeConsole() then AllocConsole() and expects the CRT I/O
functions to be able to output to newly created console.
It fails:
- when run with wineconsole, as the inherited std consoles are closed
in FreeConsole(). Added tests, but current implementation of kernelbase
is correct. So, the fix is to force wineconsole to pass unbound console
handles with standard inheritance (to they are not closed),
- when run from unix console, the std handles were also closed. There's
no unbound console in that case. The fix is not to close these
handles in FreeConsole().
- the other cases from the bug entry work because cmd was created with
unbound console handles.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8136
I was able to replicate the issue seen in [Bug 58113](https://bugs.winehq.org/show_bug.cgi?id=58113) on my M1.
The issue stems from the usage of AudioDevicePropertyVolumeScalar, which the audio driver for the M1 does not support (at least so it appears.) Using AudioObjectIsPropertySettable allows for fast checking for this situation, including preemptively disabling main channel audio if it appears to be unsupported.
--
v2: winecoreaudio: revert unix_set_volumes from f46e9b8f120605d984f4ae14b4c815a67fbd1b59
https://gitlab.winehq.org/wine/wine/-/merge_requests/7920
1. For %fs/fsbase the patch follows the macOS logic with LDT descriptor registration and Linux with switching. One notable difference is that on 32->64 transition we set %fs to GSEL(GUFS32_SEL, SEL_UPL) before restoring fsbase, otherwise FreeBSD will just revert it by reloading the selector [at the first opportunity](https://github.com/freebsd/freebsd-src/blob/5673462af5330df207…. GSEL(GUFS32_SEL, SEL_UPL) is the default %fs value on FreeBSD and is special-cased to save/restore actual fsbase value to/from PCB.
2. I was told we could get rid of fsbase glitches in signal handlers by blocking signals with [sigfastblock(2)](https://man.freebsd.org/cgi/man.cgi?query=sigfastblock) between %fs reset to the default value and fsbase reset to pthread_teb. This is currently a part of internal API for libthr, which could be exposed as pthread_signal_block_np for Wine. I'm on the fence whether it's worth it.
3. I fully admit I have no idea what registers are worth preserving around fallback sysarch(AMD64_SET_FSBASE) syscalls and whether it's appropriate to push those registers to stack. ("Kernel" stack should be fine, I assume?) Syscalls definitely clobber r8-r11.
4. For %ss see https://lkml.org/lkml/2015/4/24/216. FreeBSD doesn't have a similar workaround in the kernel, so it goes into Wine.
--
v7: ntdll: Work around AMD SYSRET SS descriptor behavior on FreeBSD.
ntdll: Unbreak new wow64 mode on FreeBSD.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8073