[PATCH v4 1/2] user32: Let nulldrv return some dummy monitor information.

[Bernhard Übelacker]

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

Signed-off-by: Bernhard Übelacker 
---
Supersedes patch 152109.

v2:
- No changes to v1.

v3:
- Make device static const WCHAR.
- Use a non-null value as HMONITOR handle.

v4:
- SetLastError on invalid handle.
---
 dlls/user32/driver.c | 27 +++++++++++++++++++++++++--
 1 file changed, 25 insertions(+), 2 deletions(-)

diff --git a/dlls/user32/driver.c b/dlls/user32/driver.c
index 561a126bd6..5b2929245c 100644
--- a/dlls/user32/driver.c
+++ b/dlls/user32/driver.c
@@ -197,6 +197,8 @@ void USER_unload_driver(void)
  * These are fallbacks for entry points that are not implemented in the real driver.
  */

+#define NULLDRV_DEFAULT_HMONITOR ((HMONITOR)(UINT_PTR)(0x10000 + 1))
+
 static HKL CDECL nulldrv_ActivateKeyboardLayout( HKL layout, UINT flags )
 {
     return 0;
@@ -354,7 +356,12 @@ static LONG CDECL nulldrv_ChangeDisplaySettingsEx( LPCWSTR name, LPDEVMODEW mode

static BOOL CDECL nulldrv_EnumDisplayMonitors( HDC hdc, LPRECT rect, MONITORENUMPROC proc, LPARAM lp )
 {
-    return FALSE;
+    RECT r = {0, 0, 640, 480};
+
+    TRACE("(%p, %p, %p, 0x%lx)\n", hdc, rect, proc, lp);
+
+    proc(NULLDRV_DEFAULT_HMONITOR, hdc, &r, lp);
+    return TRUE;
 }

static BOOL CDECL nulldrv_EnumDisplaySettingsEx( LPCWSTR name, DWORD num, LPDEVMODEW mode, DWORD flags )
@@ -364,7 +371,23 @@ static BOOL CDECL nulldrv_EnumDisplaySettingsEx( LPCWSTR name, DWORD num, LPDEVM

static BOOL CDECL nulldrv_GetMonitorInfo( HMONITOR handle, LPMONITORINFO info )
 {
-    return FALSE;
+    RECT r = {0, 0, 640, 480};
+    static const WCHAR device[] = {'W','i','n','D','i','s','c',0};
+
+    TRACE("(%p, %p)\n", handle, info);
+
+    if (handle != NULLDRV_DEFAULT_HMONITOR)
+    {
+        SetLastError(ERROR_INVALID_MONITOR_HANDLE);
+        return FALSE;
+    }
+
+    info->rcMonitor = r;
+    info->rcWork = r;
+    info->dwFlags = MONITORINFOF_PRIMARY;
+    if (info->cbSize >= sizeof(MONITORINFOEXW))
+        lstrcpyW( ((MONITORINFOEXW *)info)->szDevice, device );
+    return TRUE;
 }

static BOOL CDECL nulldrv_CreateDesktopWindow( HWND hwnd )

[PATCH v4 2/2] services/tests: Retrieve monitor information when executed as service.

[Bernhard Übelacker]

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

Signed-off-by: Bernhard Übelacker 
---
This patch is not merged with the previous one because there
is no todo_wine for service_ok.

Supersedes patch 152110.

v2:
- Fix test for wxppro or w2003.

v3:
- Test monitor handle.
- Test that callback got called just once.
- Test GetMonitorInfo with NULL HMONITOR.
- Test all bits of the dwFlags member.

v4:
- Test GetLastError on failing GetMonitorInfo calls.
---
 programs/services/tests/service.c | 48 +++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/programs/services/tests/service.c b/programs/services/tests/service.c
index 728d515f85..c68d37acdd 100644
--- a/programs/services/tests/service.c
+++ b/programs/services/tests/service.c
@@ -35,6 +35,8 @@ static SERVICE_STATUS_HANDLE service_handle;
 /* Service process global variables */
 static HANDLE service_stop_event;

+static int monitor_count;
+
 static void send_msg(const char *type, const char *msg)
 {
     DWORD written = 0;
@@ -127,6 +129,51 @@ static void test_create_window(void)
     service_ok(r, "DestroyWindow failed: %08x\n", GetLastError());
 }

+static BOOL CALLBACK monitor_enum_proc(HMONITOR hmon, HDC hdc, LPRECT lprc, LPARAM lparam)
+{
+    BOOL r;
+    MONITORINFOEXA mi;
+
+    service_ok(hmon != NULL, "Unexpected hmon=%#x\n", hmon);
+
+    monitor_count++;
+
+    mi.cbSize = sizeof(mi);
+
+    SetLastError(0xdeadbeef);
+    r = GetMonitorInfoA(NULL, (MONITORINFO*)&mi);
+    service_ok(GetLastError() == ERROR_INVALID_MONITOR_HANDLE, "Unexpected GetLastError: %#x.\n", GetLastError());
+    service_ok(!r, "GetMonitorInfo with NULL HMONITOR succeeded.\n");
+
+    r = GetMonitorInfoA(hmon, (MONITORINFO*)&mi);
+    service_ok(r, "GetMonitorInfo failed.\n");
+
+    service_ok(mi.rcMonitor.left == 0 && mi.rcMonitor.top == 0 && mi.rcMonitor.right >= 640 && mi.rcMonitor.bottom >= 480,
+               "Unexepected monitor rcMonitor values: {%d,%d,%d,%d}\n",
+               mi.rcMonitor.left, mi.rcMonitor.top, mi.rcMonitor.right, mi.rcMonitor.bottom);
+
+    service_ok(mi.rcWork.left == 0 && mi.rcWork.top == 0 && mi.rcWork.right >= 640 && mi.rcWork.bottom >= 480,
+               "Unexepected monitor rcWork values: {%d,%d,%d,%d}\n",
+               mi.rcWork.left, mi.rcWork.top, mi.rcWork.right, mi.rcWork.bottom);
+
+    service_ok(!strcmp(mi.szDevice, "WinDisc") || !strcmp(mi.szDevice, "\\.\DISPLAY1"),
+               "Unexpected szDevice received: %s\n", mi.szDevice);
+
+    service_ok(mi.dwFlags == MONITORINFOF_PRIMARY, "Unexpected secondary monitor info.\n");
+
+    return TRUE;
+}
+
+/* query informations monitor information, even in non-interactive services */
+static void test_monitors(void)
+{
+    BOOL r;
+
+    r = EnumDisplayMonitors(0, 0, monitor_enum_proc, 0);
+    service_ok(r, "EnumDisplayMonitors failed.\n");
+    service_ok(monitor_count == 1, "Callback got called less or more than once. %d\n", monitor_count);
+}
+
 static DWORD WINAPI service_handler(DWORD ctrl, DWORD event_type, void *event_data, void *context)
 {
     SERVICE_STATUS status;
@@ -151,6 +198,7 @@ static DWORD WINAPI service_handler(DWORD ctrl, DWORD event_type, void *event_da
     case 128:
         test_winstation();
         test_create_window();
+        test_monitors();
         service_event("CUSTOM");
         return 0xdeadbeef;
     default:

[PATCH v4 2/2] services/tests: Retrieve monitor information when executed as service.

[Marvin]

Hi,

While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?

Full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=42789

Your paranoid android.

=== wvistau64_he (32 bit Windows report) ===

services.exe:
service.c:431: Test failed: malformed service message: 1

[PATCH v4 2/2] services/tests: Retrieve monitor information when executed as service.

[Bernhard Übelacker]

Am 02.10.2018 um 16:33 schrieb Marvin:
> Hi,
>
> While running your changed tests on Windows, I think I found new failures.
> Being a bot and all I'm not very good at pattern recognition, so I might be
> wrong, but could you please double-check?
>
> Full results can be found at:
> https://testbot.winehq.org/JobDetails.pl?Key=42789
>
> Your paranoid android.
>
> === wvistau64_he (32 bit Windows report) ===
>
> services.exe:
> service.c:431: Test failed: malformed service message: 1

Could this just be caused by the pipe connecting the service with the
test process being opened with pipe type byte?
And due to more tests and/or longer lines the call to ReadLine takes now
not the whole line anymore?

I tried to stress the pipe by sending more data and it led to quite a
lot of failures [1], if the pipe is created with
PIPE_TYPE_BYTE|PIPE_READMODE_BYTE.

The same stress test with a pipe created with
PIPE_TYPE_MESSAGE|PIPE_READMODE_MESSAGE shows no failures [2].

[1] https://testbot.winehq.org/JobDetails.pl?Key=42797
[2] https://testbot.winehq.org/JobDetails.pl?Key=42798

If my opinion is considered right, should I just add to that patch
series at first a change of the pipe type from byte to message?

Kind regards,
Bernhard

[PATCH v4 2/2] services/tests: Retrieve monitor information when executed as service.

[Jacek Caban]

On 02/10/2018 18:55, Bernhard Übelacker wrote:
> Could this just be caused by the pipe connecting the service with the
> test process being opened with pipe type byte?
> And due to more tests and/or longer lines the call to ReadLine takes now
> not the whole line anymore?
>
> I tried to stress the pipe by sending more data and it led to quite a
> lot of failures [1], if the pipe is created with
> PIPE_TYPE_BYTE|PIPE_READMODE_BYTE.
>
> The same stress test with a pipe created with
> PIPE_TYPE_MESSAGE|PIPE_READMODE_MESSAGE shows no failures [2].
>
> [1] https://testbot.winehq.org/JobDetails.pl?Key=42797
> [2] https://testbot.winehq.org/JobDetails.pl?Key=42798
>
> If my opinion is considered right, should I just add to that patch
> series at first a change of the pipe type from byte to message?

Yes, this should use message mode. A separated patch is fine as well, if 
it doesn't conflict with the series.

Thanks,
Jacek

[PATCH v4 2/2] services/tests: Retrieve monitor information when executed as service.

[Jacek Caban]

Signed-off-by: Jacek Caban

[Jacek Caban]

Signed-off-by: Jacek Caban