On Sat Jul 19 02:45:01 2025 +0000, Zhiyi Zhang wrote:
Looks like it's triggering a memory corruption somewhere. I will look into it.
The datetime test failures are caused by a datetime window that is still alive after unloading comctl32 v5. Thus, the comctl32 v5 window classes fail to unregister, and then the comctl32 v6 datetime window class fails to register because they use the same name. So the comctl32 v6 datetime window creation failed.
The first problem is obviously to destroy the datetime window after it's done. The second problem is that such a failure doesn't happen on Windows. After looking further, comctl32 v6 should get its versioned window classes registered even when comctl32 v5 window classes are kept alive. This is addressed by "user32: Load version for comctl32 v6 window classes.". I'm not sure how to test the patch. It seems that there isn't an API to get the real versioned window class.