Nikolay Sivov (@nsivov) commented about dlls/user32/class.c:
{ if (load && !(hmod = GetModuleHandleW( L"comctl32" ))) hmod = LoadLibraryW( L"comctl32" ); }
- else if (!RtlFindActivationContextSectionString( 0, NULL, ACTIVATION_CONTEXT_SECTION_WINDOW_CLASS_REDIRECTION, name, &data ))
- if (!RtlFindActivationContextSectionString( 0, NULL, ACTIVATION_CONTEXT_SECTION_WINDOW_CLASS_REDIRECTION, name, &data )) {
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().