Jacek Caban (@jacek) commented about dlls/vbscript/global.c:
> + str = V_BSTR(&data[i]);
> +
> + if (i > lbound) {
> + string_len = SysStringLen(string);
> + tmp = SysAllocStringLen(string, string_len + delimiter_len);
> + memcpy(tmp + string_len, delimiter, delimiter_len * sizeof(WCHAR));
> + SysFreeString(string);
> + string = tmp;
> + }
> +
> + string_len = SysStringLen(string);
> + str_len = SysStringLen(str);
> + tmp = SysAllocStringLen(string, string_len + str_len);
> + memcpy(tmp + string_len, str, str_len * sizeof(WCHAR));
> + SysFreeString(string);
> + string = tmp;
That's potentially a lot of string reallocation. A cleaner and more efficient approach would be to first convert all necessary strings and store the results as pointers in an array and calculate the required length. Then, allocate the output buffer, and copy all the joined strings into it.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7052#note_91500
The code looks good, but it would be better to split the test refactoring into a separate commit. Specifically, the first commit should focus on updating existing tests to use the new helpers, and the second should include the implementation changes and any new tests.
Sorry for the delay. We're currently in a code freeze, so merging this will have to wait for the 11 cycle, but we can make sure it's ready in the meantime.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7049#note_91498
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.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57019
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7105
No reviews required.\
This is just to get the test results as seen by gitlab.\
MR will be cancelled afterwards.
--
v2: gitlab: Do not run the build script on each commit.
gitlab: Remove make -j options.
gitlab: Update configuration for the new Mac runner.
gitlab: Add 'build' tag on Linux build jobs.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7098