This one is somewhat tricky, as the existing `ProcessorFeatures` array is limited to `PROCESSOR_FEATURE_MAX` aka 64 entries, while this now defines features up to index 88.
To handle the higher number of features, this patch extends `KUSER_SHARED_DATA` with a separate second array for the later features. This requires updating an assert about its size.
If there's a better place to store the excess feature bits, I'm open for suggestions. As far as I can see, there's no obvious place that would be ABI visible where it should be stored. (I also see that upstream definitions of `KUSER_SHARED_DATA` has been extended with another new field that Wine doesn't have - so having our own data there probably isn't ideal.)
So if there's some other convenient way of storing this (e.g. a global variable in ntdll) that also works, but it would need to be accessible from both the PE and unix sides, so it's probably not very straightforward either?
--
v2: arm64: Detect more new processor features.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9395
Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`.
The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`.
* * *
P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here?
--
v5: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
kernel32: Use GetCurrentProcess() handle in CreateToolheap32Snapshot if possible.
kernel32: Test CreateToolhelp32Snapshot with TH32CS_SNAPMODULE32.
include: Add TH32CS_SNAPMODULE32.
kernel32/tests: Fix CreateToolhelp32Snapshot failure check.
https://gitlab.winehq.org/wine/wine/-/merge_requests/9371
Some games (Alan Wake 2 Remastered, Control, Silent Hill 2, S.T.A.L.K.E.R 2) check DisplayConfigGetDeviceInfo(DISPLAYCONFIG_DEVICE_INFO_GET_ADVANCED_COLOR_INFO) before attempting to use HDR. Add a semi-stub to return the typical status for a non-HDR monitor, along with typical status for an HDR-capable monitor when `gdi_monitor.hdr_enabled` is true. Then add support to winemac for detecting HDR-capable displays and returning that status in `gdi_monitor`.
--
v2: winemac: Report whether monitors are HDR-capable based on NSScreen.maximumPotentialExtendedDynamicRangeColorComponentValue.
win32u: Store whether a monitor is HDR-capable in gdi_monitor.
win32u: Add semi-stub for NtUserDisplayConfigGetDeviceInfo( DISPLAYCONFIG_DEVICE_INFO_GET_ADVANCED_COLOR_INFO ).
user32/tests: Add tests for DisplayConfigGetDeviceInfo( DISPLAYCONFIG_DEVICE_INFO_GET_ADVANCED_COLOR_INFO ).
https://gitlab.winehq.org/wine/wine/-/merge_requests/9556