`mach_continuous_approximate_time()` has the necessary precision for win32 ticks and can be up to 4x faster than `mach_continuous_time()`.
Also `clock_gettime( CLOCK_REALTIME, &ts )` calls always end up in `__commpage_gettimeofday( struct timeval *tp )`:
```
* frame #0: 0x00007ff806788763 libsystem_kernel.dylib`__commpage_gettimeofday
frame #1: 0x00007ff8066709a3 libsystem_c.dylib`gettimeofday + 45
frame #2: 0x00007ff806678b31 libsystem_c.dylib`clock_gettime + 117
```
These extra calls, setup and converting from one struct format to another costs another 60 CPU cycles and in my testing makes `NtQuerySystemTime` approximately 30% faster as well with this MR. This is a fairly hot code path (especially when using certain out-of-tree in process synchronization patch sets), so probably worth the optimization here.
All of these APIs are available since 10.12.
--
v4: ntdll: Replace '0' with 'NULL' in gettimeofday() calls.
ntdll: Use gettimeofday in system_time_precise on macOS.
ntdll: Use __commpage_gettimeofday in NtQuerySystemTime on macOS.
ntdll: Always use mach_continuous_approximate_time on macOS.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7256
Based on Piotr's findings.
On MSVC i386 targets, structs requiring alignment greater than 4 are never passed by value.
Clang follows the same behavior in MSVC mode (see [1] for details and [2] for a follow-up
that applies this logic when fields, not necessarily the entire struct, are aligned).
A number of ios functions take fpos_mbstatet as an argument and expect it to be passed by value.
[1] https://reviews.llvm.org/D72114
[2] https://github.com/llvm/llvm-project/issues/63257
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57817
--
v2: msvcp60/tests: Avoid explicitly aligning structs passed by value.
msvcp60: Avoid explicitly aligning structs passed by value.
msvcp90/tests: Avoid explicitly aligning structs passed by value.
msvcp: Avoid explicitly aligning structs passed by value.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7312
When dlls/win32u fails to load/initialize the \`FreeType font library', a device context object ends up with the only GDI driver attached -- `null_driver`. The latter implements the `pGetTextMetrics` callback function as do-nothing code. This causes the `NtGdiGetTextMetricsW()` function to fail not modifying fields of its `metrics` argument. In result the `normalize_nonclientmetrics()` ends up with uninitialized `tm` local variable after call to the `get_text_metr_size()` function. Using uninitialized fields of the `TEXTMETRICW` structure gives unpredictable results.
This memset(3)'s the `tm` structure before using. After that, even if we failed to load the \`FreeType font library', the \`CaptionHeight', \`SmCaptionHeight' and \`MenuHeight' metrics keep their current values (the `normalize_nonclientmetrics()` function is called after `get_twips_entry()` callback function, thus value of an entry should not be negative).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7316