On Mon Nov 3 06:15:01 2025 +0000, Nikolay Sivov wrote:
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. Whatever is in winsxs, it must be specified in a manifest. Presumably that includes some special v5, we don't have that and won't support it at the moment anyway. What I'm describing is clearly visible, for unqualified path, after context deactivation, original module is returned returned. To me that looks like an important difference if we are dealing with mix of v5 and v6 and the same process.
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. Those functions set a few pointers and nothing else. But yes, we could use a full path, that leaves relative path case still not working right.
I see. You worry that user applications might use GetModuleHandle() with a relative path without activation contexts and expect the handle to be comctl32 v5, right?