Since ecbc4cf06d6c9253ba92065f320ddd6eeff3177f ("wineboot: Retrieve CPU details through the SMBIOS table."), wineboot assumes that an SMBIOS 3.0+ processor information table is present, and uses those values to populate CPU info in the registry.
On most platforms, raw SMBIOS tables are not available to unprivileged applications, so ntdll "creates" SMBIOS tables with information from other APIs. ntdll creates a v3.0+ processor table, and wineboot is happy.
However on Intel macOS, raw SMBIOS tables are available to unprivileged applications, and ntdll passes them straight through to wineboot. Macs did not start using SMBIOS v3.0 until ~2017, any machines older than that are missing the `thread_count2` variable that `wineboot` uses, leading to a crash or undefined behavior.
One solution would be to stop using actual SMBIOS tables on any Macs, and have ntdll generate the tables. I worry this could cause issues with software that "fingerprints" a machine using SMBIOS tables though (MS Office needed reactivation when GetSystemFirmwareTable was implemented, for example).
Instead, with some small fixes, we can keep using actual SMBIOS tables for most Intel Macs.
There are 4 categories of Macs to consider: - Macs with v2.4 or earlier SMBIOS tables (~2014 and earlier): The processor table doesn't have any `thread_count` fields. Given the age of these machines (none can run an OS still supported by Apple), I think it's acceptable to avoid larger changes to wineboot and have ntdll generate SMBIOS tables. - Macs with v2.5 - v2.9 tables (~2015-2017): These have the `thread_count` field, but not `thread_count2`. With this MR, these should be working again and will still use actual SMBIOS tables. - Macs with v3.0 or later tables (~2018 and newer): These have all the needed fields, and are still using actual SMBIOS tables. - Apple Silicon Macs don't use SMBIOS, ntdll generates the tables.