July 2025 - wine-gitlab

[PATCH v2 0/1] MR8533: fonts: Make numbers bold for WineTahomaBold.
by Ziqing Hui (＠zhui) 21 Jul '25

21 Jul '25

The glyphs are based on BitstreamVeraSans-Bold. The glyphs in WineTahomaBold are not truely bold, this font is just a copy of WineTahoma. If this patch is acceptable, I'm planning to make more glyphs bold, including at least all ASCII characters. -- v2: fonts: Make numbers bold for WineTahomaBold. https://gitlab.winehq.org/wine/wine/-/merge_requests/8533

3 4

[PATCH 0/1] MR8610: crypt32: Retry with CRYPT_MACHINE_KEYSET in CRYPT_AcquirePrivateKeyFromProvInfo().
by Hans Leidekker (＠hans) 21 Jul '25

21 Jul '25

Debugged by Katharina Bogad. Wine-Bug: http://bugs.winehq.org/show_bug.cgi?id=58528 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8610

2 1

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Zhiyi Zhang (＠zhiyi) 21 Jul '25

21 Jul '25

> it doesn't matter if our v5 has manifest or not. I think we don't have to care about that at this point. Yeah. We don't need to care about whether comctl32 v5 has a manifest or not at this point. The problem with this part of the code is that comctl32 v6 doesn't get some of its window class version from its manifest without this change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110490

1 0

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Zhiyi Zhang (＠zhiyi) 21 Jul '25

21 Jul '25

On Mon Jul 21 08:03:29 2025 +0000, Nikolay Sivov wrote: > Another way would be to extend this builtin signature check to > optionally include installed module name instead of assuming it's the > same as a filename, so that we can specify comctl32_v6.dll there and > build everything as builtin. I don't know if it's easy, because it > requires variable length data. It will be a lot more work. First, we need to pack variable-length data into e_lfanew for every DLL/EXE(output_pe_file(),output_module16, etc). Then we need to change this signature parsing to support variable-length data(winedump, dbghelp, build_module() in NTDLL, ntdll DLL loader, setupapi fakedll support). There will probably be alignment issues to be handled. Also, increasing e_lfanew might increase the chance of anti-virus software misdetecting wine DLLs as malware. Overall, I don't think it's worth it to extend the built-in signature check for this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110489

1 0

[PATCH v3 0/2] MR8596: dsound: Check if 'cbPropData' for DSPROPERTY_Description1 is large enough
by Yeshun Ye (＠yeyeshun) 21 Jul '25

21 Jul '25

Avoid writing out of bounds. Signed-off-by: YeshunYe <yeyeshun(a)uniontech.com> -- v3: dsound/tests: Add test for DSPROPERTY_DIRECTSOUNDDEVICE_DESCRIPTION_1 dsound: Check if 'cbPropData' for DSPROPERTY_Description1 is large enough https://gitlab.winehq.org/wine/wine/-/merge_requests/8596

3 4

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Zhiyi Zhang (＠zhiyi) 21 Jul '25

21 Jul '25

> Is there an embedded manifest in comctl32.dll from system32? No. The manifest seems to be from somewhere else. Anyway, I think it's clearer that the manifest is for comctl32 v6 this way. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110485

1 0

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Nikolay Sivov (＠nsivov) 21 Jul '25

21 Jul '25

On Mon Jul 21 08:00:41 2025 +0000, Zhiyi Zhang wrote: > \--prefer-native works. However, we need to mark comctl32 v5 as > --perfer-native because comctl32.dll in the build dir is comctl32 v5. > Then we still need to update the wine prefix every time after making > changes to comctl32 v6 and rebuilding, because otherwise the comctl32 v6 > DLL in the wine prefix won't be updated, now that the DLL in the wine > prefix is preferred. This would make the comctl32 development experience > worse and bisecting comctl32 terrible. Comparing it to a special case in > find_builtin_dll(), I prefer the latter. The changes to > find_builtin_dll() are quite minimal. Another way would be to extend this builtin signature check to optionally include installed module name instead of assuming it's the same as a filename, so that we can specify comctl32_v6.dll there and build everything as builtin. I don't know if it's easy, because it requires variable length data. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110484

1 0

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Zhiyi Zhang (＠zhiyi) 21 Jul '25

21 Jul '25

On Mon Jul 21 07:46:07 2025 +0000, Nikolay Sivov wrote: > Having this check in ntdll looks too dirty to me. Will it work if we > build v6 variant as --prefer-native? \--prefer-native works. However, we need to mark comctl32 v5 as --perfer-native because comctl32.dll in the build dir is comctl32 v5. Then we still need to update the wine prefix every time after making changes to comctl32 v6 and rebuilding, because otherwise the comctl32 v6 DLL in the wine prefix won't be updated, now that the DLL in the wine prefix is preferred. This would make the comctl32 development worse. Comparing it to a special case in find_builtin_dll(), I prefer the latter. The changes to find_builtin_dll() are quite minimal. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110483

1 0

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Nikolay Sivov (＠nsivov) 21 Jul '25

21 Jul '25

On Mon Jul 21 02:14:39 2025 +0000, Zhiyi Zhang wrote: > As mentioned above. There is a manifest for comctl32 v5 on Windows. So I > think it's better to rename it now. Is there an embedded manifest in comctl32.dll from system32? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110482

1 0

Re: [PATCH v7 0/4] MR8595: comctl32: Separate v5 and v6.
by Nikolay Sivov (＠nsivov) 21 Jul '25

21 Jul '25

On Mon Jul 21 02:14:37 2025 +0000, Zhiyi Zhang wrote: > The issue happens because comctl32 v6 and v5 were both trying to > register "SysDateTimePick32" due to the "if (is_comctl32_class( > name->Buffer )) ... else (!RtlFindActivationContextSectionString(...))". > Because "SysDateTimePick32" is a comctl32 class, the version is not > appended to the window class. So, comctl32 v6 still tries to register > "SysDateTimePick32". Removing the else allows comtl32 v6 to get the > version from its manifest and uses "6.00.xx!SysDateTimePick32". Comctl32 > v5 has no manifest on Wine, so its behavior is the same. On Windows, > comctl32 v5 also has a manifest, but the `versioned` property is set to > `no`. You can find it on Windows 10 at > C:\Windows\WinSxS\Manifests\amd64_microsoft.windows.common-controls_6595b64144ccf1df_5.82.19041.5915_none_793527b5243cb406.manifest > > ``` > ... > <windowClass versioned="no">SysDateTimePick32</windowClass> > ... > ``` Wouldn't you need to reference sxs 5.82 version explicitly using application manifest? So unless application requests specific 5.x version (if that's really the purpose of having this manifest) it doesn't matter if our v5 has manifest or not. I think we don't have to care about that at this point. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8595#note_110481

1 0

2025

2024

2023

2022

wine-gitlab July 2025