[PATCH 0/1] MR4084: user32/tests: Improve the GetWindowModuleFileName() checks.

[Francois Gouget (＠fgouget)]

Check that NULL has no special meaning.  
Check GetLastError() for systray windows.  
Trace the module filename in case of unexpected success and enclose it
in quotes in case there are leading or trailing spaces.  
Fix the filename buffer initialization.

---
The buf2[0] = 0 line at the top of the patch was introduced in
914cb228685b but buf2 was not used after that. So clearly it is buf1
that should have been initialized there.  
That said I'm not sure initializing buf1 & buf2 is really necessary as
they are only used in case of success. I guess the fear was that
GetWindowModuleFileName() would sometimes return success without
touching the buffer but I'm not convinced that fear is justified. Still
I decided to be conservative and preserve the initializations. I'm fine
with removing them though (maybe the buf2 case is a bit special).  
Finally this is meant to help figure out the reason for the failure
decribed in bug 55777.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/4084

[PATCH 1/1] user32/tests: Improve the GetWindowModuleFileName() checks.

[Francois Gouget]

From: Francois Gouget <fgouget(a)codeweavers.com>

Check that NULL has no special meaning.
Check GetLastError() for systray windows.
Trace the module filename in case of unexpected success and enclose it
in quotes in case there are leading or trailing spaces.
Fix the filename buffer initialization.
---
The buf2[0] = 0 line at the top of the patch was introduced in
914cb228685b but buf2 was not used after that. So clearly it is buf1
that should have been initialized there.
That said I'm not sure initializing buf1 & buf2 is really necessary as
they are only used in case of success. I guess the fear was that
GetWindowModuleFileName() would sometimes return success without
touching the buffer but I'm not convinced that fear is justified. Still
I decided to be conservative and preserve the initializations. I'm fine
with removing them though (maybe the buf2 case is a bit special).
Finally this is meant to help figure out the reason for the failure
decribed in bug 55777.
---
 dlls/user32/tests/win.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c
index cf5f0d932e8..458e758232d 100644
--- a/dlls/user32/tests/win.c
+++ b/dlls/user32/tests/win.c
@@ -8777,27 +8777,40 @@ static void test_GetWindowModuleFileName(void)
 
     DestroyWindow(hwnd);
 
-    buf2[0] = 0;
     hwnd = (HWND)0xdeadbeef;
+    buf1[0] = 0;
     SetLastError(0xdeadbeef);
     ret1 = pGetWindowModuleFileNameA(hwnd, buf1, sizeof(buf1));
-    ok(!ret1, "expected 0, got %u\n", ret1);
+    ok(!ret1, "expected 0, got %u '%s'\n", ret1, buf1);
+    ok(GetLastError() == ERROR_INVALID_WINDOW_HANDLE,
+       "expected ERROR_INVALID_WINDOW_HANDLE, got %lu\n", GetLastError());
+
+    /* check that NULL has no special meaning */
+    buf1[0] = 0;
+    SetLastError(0xdeadbeef);
+    ret1 = pGetWindowModuleFileNameA(NULL, buf1, sizeof(buf1));
+    ok(!ret1, "expected 0, got %u '%s'\n", ret1, buf1);
     ok(GetLastError() == ERROR_INVALID_WINDOW_HANDLE,
        "expected ERROR_INVALID_WINDOW_HANDLE, got %lu\n", GetLastError());
 
     hwnd = FindWindowA("Shell_TrayWnd", NULL);
     ok(IsWindow(hwnd) || broken(!hwnd), "got invalid tray window %p\n", hwnd);
     SetLastError(0xdeadbeef);
+    buf1[0] = 0;
     ret1 = pGetWindowModuleFileNameA(hwnd, buf1, sizeof(buf1));
-    ok(!ret1, "expected 0, got %u\n", ret1);
+    ok(!ret1, "expected 0, got %u '%s'\n", ret1, buf1);
+    todo_wine ok(GetLastError() == ERROR_MOD_NOT_FOUND ||
+                 broken(GetLastError() == 0xdeadbeef), /* win7 wow64 */
+       "expected ERROR_MOD_NOT_FOUND, got %lu\n", GetLastError());
     ret1 = GetModuleFileNameA(0, buf1, sizeof(buf1));
     hwnd = GetDesktopWindow();
     ok(IsWindow(hwnd), "got invalid desktop window %p\n", hwnd);
+    buf2[0] = 0;
     SetLastError(0xdeadbeef);
     ret2 = pGetWindowModuleFileNameA(hwnd, buf2, sizeof(buf2));
     ok(!ret2 ||
        ret1 == ret2, /* vista */
-       "expected 0 or %u, got %u %s\n", ret1, ret2, buf2);
+       "expected 0 or %u, got %u '%s'\n", ret1, ret2, buf2);
 }
 
 static void test_hwnd_message(void)
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/4084

[PATCH 1/1] user32/tests: Improve the GetWindowModuleFileName() checks.

[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=138685

Your paranoid android.


=== w10pro64 (32 bit report) ===

user32:
win.c:3817: Test failed: GetForegroundWindow returned 0003017E
win.c:3749: Test failed: SetForegroundWindow failed, error 0
win.c:3752: Test failed: GetForegroundWindow returned 0003017E
win.c:3789: Test failed: GetForegroundWindow returned 0003017E
win.c:3874: Test failed: GetActiveWindow() = 0002028E
win.c:3878: Test failed: GetFocus() = 00000000
win.c:3881: Test failed: GetFocus() = 00000000

[Alexandre Julliard (＠julliard)]

That's most likely because the systray window module happens to match an existing module in the current process.

I don't think it makes sense to test GetWindowModuleFileName on windows belonging to a different process.

-- 
https://gitlab.winehq.org/wine/wine/-/merge_requests/4084#note_48544