[PATCH 0/1] MR1011: user32: Correctly detect and assign an int resource

[Alistair Leslie-Hughes (＠alesliehughes)]

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53646

Signed-off-by: Alistair Leslie-Hughes

[PATCH 1/1] user32: Correctly detect and assign an int resource

[Alistair Leslie-Hughes]

From: Alistair Leslie-Hughes

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53646

Signed-off-by: Alistair Leslie-Hughes 
---
 dlls/user32/win.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/dlls/user32/win.c b/dlls/user32/win.c
index 0605f94abe1..534db908ee0 100644
--- a/dlls/user32/win.c
+++ b/dlls/user32/win.c
@@ -379,12 +379,11 @@ HWND WIN_CreateWindowEx( CREATESTRUCTW *cs, LPCWSTR className, HINSTANCE module,

if (!unicode && cs->lpszName)
     {
-        const char *nameA = (const char *)cs->lpszName;
         /* resource ID string is a special case */
-        if (nameA[0] == '\xff')
+        if (IS_INTRESOURCE(cs->lpszName))
         {
             name_buf[0] = 0xffff;
-            name_buf[1] = MAKEWORD( nameA[1], nameA[2] );
+            name_buf[1] = LOWORD(cs->lpszName);
             name_buf[2] = 0;
             RtlInitUnicodeString( &window_name, name_buf );
         }

[PATCH 1/1] user32: Correctly detect and assign an int resource

[Marvin]

Hi,

It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.

The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:

The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=124786

Your paranoid android.

=== debian11 (32 bit report) ===

comctl32:
static.c:297: Test failed: got NULL
static.c:170: Test failed: got 3
static.c:171: Test failed: got 7666984
static.c:172: Test failed: got 0
static.c:178: Test failed: bits: 00 00 00 00
static.c:207: Test failed: bits: 00 00 00 00

user32:
dialog.c:2302: Test failed: name param = "\xff\x00\x00"
msg.c:19036: Test failed: name param = L"\00ff\0000"

=== debian11 (32 bit zh:CN report) ===

user32:
dialog.c:2302: Test failed: name param = "\xff\x00\x00"
msg.c:19036: Test failed: name param = L"\f8f5\0000"

=== debian11 (64 bit WoW report) ===

user32:
dialog.c:2302: Test failed: name param = "\xff\x00\x01"
msg.c:19036: Test failed: name param = L"\00ff\0000"

[Jacek Caban (＠jacek)]

Jacek Caban (@jacek) commented about dlls/user32/win.c:
>  if (!unicode && cs->lpszName)
>  {
> -
>    const char *nameA = (const char *)cs->lpszName;
>    /* resource ID string is a special case */
> -
>    if (nameA[0] == '\xff')
> -
>    if (IS_INTRESOURCE(cs->lpszName))

That doesn't look right, AFAIR such window names just crash on Windows. See commits like 0739aa610c, f28824eb58 and test failures in this MR. Where is this window name coming from?