[PATCH v4 1/2] user32: Let nulldrv return some dummy monitor information.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43187 Signed-off-by: Bernhard Übelacker <bernhardu(a)mailbox.org> --- 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 ) -- 2.19.0
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=43187 Signed-off-by: Bernhard Übelacker <bernhardu(a)mailbox.org> --- 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: -- 2.19.0
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
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
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
Signed-off-by: Jacek Caban <jacek(a)codeweavers.com>
participants (3)
-
Bernhard Übelacker -
Jacek Caban -
Marvin