Both window station visibility and session id are related to services being spawned in a non-interactive session, however the process window station can be manually set by the application while the session id can not be.
The enumerated display config should not change even in the case of a window station update, hence testing for SessionId == 0 is more reliable here.
From: Tatsuyuki Ishi ishitatsuyuki@gmail.com
Both window station visibility and session id are related to services being spawned in a non-interactive session, however the process window station can be manually set by the application while the session id can not be.
The enumerated display config should not change even in the case of a window station update, hence testing for SessionId == 0 is more reliable here.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55074 --- dlls/win32u/driver.c | 7 +------ dlls/win32u/sysparams.c | 5 +---- 2 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/dlls/win32u/driver.c b/dlls/win32u/driver.c index ed2e0973d39..2b39e239ac5 100644 --- a/dlls/win32u/driver.c +++ b/dlls/win32u/driver.c @@ -1016,14 +1016,9 @@ static BOOL load_desktop_driver( HWND hwnd )
static const struct user_driver_funcs *load_driver(void) { - USEROBJECTFLAGS flags; - HWINSTA winstation; - if (!load_desktop_driver( get_desktop_window() ) || user_driver == &lazy_load_driver) { - winstation = NtUserGetProcessWindowStation(); - if (!NtUserGetObjectInformation( winstation, UOI_FLAGS, &flags, sizeof(flags), NULL ) - || (flags.dwFlags & WSF_VISIBLE)) + if (NtCurrentTeb()->Peb->SessionId != 0) null_user_driver.pCreateWindow = nodrv_CreateWindow;
__wine_set_user_driver( &null_user_driver, WINE_GDI_DRIVER_VERSION ); diff --git a/dlls/win32u/sysparams.c b/dlls/win32u/sysparams.c index 4f69cac7040..b1e8f5d7bc0 100644 --- a/dlls/win32u/sysparams.c +++ b/dlls/win32u/sysparams.c @@ -1720,13 +1720,10 @@ static BOOL is_same_devmode( const DEVMODEW *a, const DEVMODEW *b )
static BOOL update_display_cache( BOOL force ) { - HWINSTA winstation = NtUserGetProcessWindowStation(); struct device_manager_ctx ctx = {0}; - USEROBJECTFLAGS flags;
/* services do not have any adapters, only a virtual monitor */ - if (NtUserGetObjectInformation( winstation, UOI_FLAGS, &flags, sizeof(flags), NULL ) - && !(flags.dwFlags & WSF_VISIBLE)) + if (NtCurrentTeb()->Peb->SessionId == 0) { pthread_mutex_lock( &display_lock ); clear_display_devices();
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=134019
Your paranoid android.
=== debian11 (32 bit report) ===
services.exe: service.c:420: Test failed: service: CreateWindow failed: 1400 service.c:420: Test failed: service: style = 0, expected visible service.c:420: Test failed: service: ShowWindow returned 0 service.c:420: Test failed: service: DestroyWindow failed: 00000005 service.c:420: Test failed: service: Unexpected rect: (0,0)-(1024,737) service.c:420: Test failed: service: Unexpected rcMonitor: (0,0)-(1024,737) service.c:420: Test failed: service: Unexpected rcWork: (0,0)-(1024,737) service.c:420: Test failed: service: Unexpected szDevice received: \.\DISPLAY1 service.c:420: Test failed: service: Unexpected rect: (1024,0)-(2048,737) service.c:420: Test failed: service: Unexpected rcMonitor: (1024,0)-(2048,737) service.c:420: Test failed: service: Unexpected rcWork: (1024,0)-(2048,737) service.c:420: Test failed: service: Unexpected szDevice received: \.\DISPLAY2 service.c:420: Test failed: service: Unexpected secondary monitor info. service.c:420: Test failed: service: Callback got called less or more than once. 2
=== debian11 (build log) ===
0444:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 0444:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
Using session IDs to check if an executable is running in a service context makes sense on Windows because all services run in session 0 after Vista. However, in Wine, all services are running in session 1. So your changes are not enough. Ideally, for Wine, we move the services to session 0. However, Wine also emulates XP as well, which does run services and applications all in session 0, so checking the session number seems error-prone. Actually, I think I've been working on the same thing and trying to upstream my patches. I later decided to check if the window station name is __wineservice_winstaiton. Steam also uses Chromium sandbox, which is the real issue here. Please see the attached three patches and see if they fix the issue for you.
[0001-win32u-Create-explorer-with-the-thread-effective-acces.txt](/uploads/baa72f744a41e341d4a0c5be6df1dce6/0001-win32u-Create-explorer-with-the-thread-effective-acces.txt)
[0002-win32u-Use-the-window-station-name-to-check-if-an-appl.txt](/uploads/eb422c72a7014ce0a38b4f5e1e6f752d/0002-win32u-Use-the-window-station-name-to-check-if-an-appl.txt)
[0003-server-Allow-creating-an-real-explorer-desktop-window-.txt](/uploads/60dfec7287b17105ec4792621cbc96ed/0003-server-Allow-creating-an-real-explorer-desktop-window-.txt)
Tatsuyuki, I can take the bug over if you want.
On Wed Jun 21 09:22:23 2023 +0000, Zhiyi Zhang wrote:
Tatsuyuki, I can take the bug over if you want.
Your patch makes sense (I'll test it later), and yeah I would appreciate you taking over the bug.
Closing the MR as I consider this superseded by Zhiyi's patch.
This merge request was closed by Tatsuyuki Ishi.