On Sun Jul 20 17:17:32 2025 +0000, Nikolay Sivov wrote:
So that versioned window classes gets registered as well. Otherwise,
comctl32 v6 fails to register
its window classes when comctl32 v5 window classes are still being
used. This can happen, for
example, when creating a window using comctl32 v5, then unload
comctl32 v5 and not destroying the
window, and then load comctl32 v6.
This shouldn't happen, it should be able to register both variants at the same time. On Windows using only comctl32 v5 you should be able to register class names like "6.00.xx!ListView", as there is nothing in the context to give special meaning to a version prefix. Is it a problem to RegisterClassW(version-name) when "name" is already registered? If that's the case we could use a trick to clear context with unsafe-fast Rtl function around RegisterClassW().
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> ... ```