On Mon Nov 3 02:24:40 2025 +0000, Nikolay Sivov wrote:
On Windows GetModuleHandle("comctl32.dll") definitely reflects context. So doing:
- GetModuleHandle("comctl32.dll") <- returns v5 module
- activate context + loadlibrary("comctl32.dll") +
GetModuleHandle("comctl32.dll") <- returns v6 module
- deactivate + GetModuleHandle("comctl32.dll") <- returns v5 module
On current Wine, with or without this MR, last step returns v6 module for me. Is it possible we should be fixing that instead of using full paths? If the intent is to load v5 from user32 regardless of the context, we should just do that dance with fast-frame context push/pop.
From [MSDN](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloade...)
If lpModuleName does not include a path and there is more than one loaded module with the same base name and extension, you cannot predict which module handle will be returned. To work around this problem, you could specify a path, use side-by-side assemblies, or specify a memory location rather than a DLL name in the lpModuleName parameter.
So it seems like using only the DLL name is not recommended in this case. Thus, I am not sure we should make changes to GetModuleHandle(). For example, on Windows, there is also comctl32 v5 in WinSxS. What happens then? Using a full path is one of the workaround suggested by MSDN.
If the intent is to load v5 from user32 regardless of the context, we should just do that dance with fast-frame context push/pop.
We could. However, its effect is the same as using a full path. Using fast-frame context push/pop also requires two more function calls, making the window class loader a bit slower.