https://bugs.winehq.org/show_bug.cgi?id=53581
--- Comment #6 from Lorenzo Ferrillo lorenzofer@live.it --- Created attachment 73022 --> https://bugs.winehq.org/attachment.cgi?id=73022 Recreate Resource Integer from special resource string window name
I found the issue. Basically the CS (it happens with the standard CS too I discovered) use the comctl32 static dialog. The dialog have the possibility to use the resource integer to load icons and bitmaps. Before the initial commit adding Unicode strings in Win_CreateWindowEx and after with the hack, the integer was passed unmutated.
The affecting commit instead change this to a special string. I understood this is the correct behaviour (I don't understand however if the special string is the same in windows too). However this special string isn't recognized as a resource string or a resource integer to functions that are aware of resources (in this case LoadImageW).
The patch recreate the Resource integer from the special string, and pass it to the relevant function.
This is how commit 2e9c40d50acbbbb915488fdc70e70c4cc1d205bb did to the User32 static control (they basically seems to share a very similar code), so I believe this may be correct. I will try to check tests and to upstream tomorrow.