On Mon Jul 21 02:14:38 2025 +0000, Zhiyi Zhang wrote:
This is because Wine has a mechanism to load built-in DLLs (related to WINEDLLOVERRIDES). For example, all Wine built-in DLLs in the wine prefix have a built-in DLL signature. When loading such a DLL from the prefix, Wine will redirect it to the one in the build dir or the installed DLL dir. Please see find_builtin_dll(). This allows developers not to update the wine prefix after every rebuild because the ones in the build dir are loaded. This mechanism is also responsible for selecting native DLLs in the wine prefix or Wine's builtin DLLs in the build dir or installed DLL dir, depending on WINEDLLOVERRIDES or EXTRADLLFLAGS = -Wb,--prefer-native. Then, a problem with comctl32 is that both comctl32 v6 and v5 have the same name, "comctl32.dll". So when loading comctl32 from C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.2982_none_deadbeef\comctl32.dll, it gets redirected to "comctl32.dll" in the build dir, which is comctl32 v5. So for comctl32 v6 to work, we need to add a special case for comctl32 v6 and redirect it to "comctl32_v6.dll". Note that "comctl32_v6.dll" only exists in the build dir or installed DLL dir, not in the wine prefix.
Having this check in ntdll looks too dirty to me. Will it work if we build v6 variant as --prefer-native?
-
Nikolay Sivov (＠nsivov)