On Tue Dec 30 07:35:30 2025 +0000, Zhiyi Zhang wrote:
changed this line in [version 3 of the diff](/wine/wine/-/merge_requests/9822/diffs?diff_id=235070&start_sha=0da761e7edd258d030071996abb7946dc6aaff46#d6979212dd411a0b880faf30a245da27a8b0f425_98_98) I've removed the flag. I tried to add a test as you said. But it seems that using comctl32 window class names will always get you comctl32 window classes, not the window classes with the same name. See [comctl32-unregistration-tests.txt](/uploads/5bf48d426900ae5d244d0762a5c60f90/comctl32-unregistration-tests.txt) for example. Maybe comctl32 window class names have a special prefix. Anyway, I haven't managed to overwrite the comctl32 window class, thus I was not able to figure out if a window class of the same name gets unregistered at DLL unload. Creating comctl32 window classes with hInstance set is wrong because the hInstance from GetClassInfoW() is NULL. So we can't use hInstance for that either.
Eventually, I decided to just remove the flag and unregister unconditionally. Wine used to do that before this MR, so it should be fine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9822#note_126234