January 2026 - Wine-gitlab - list.winehq.org

Re: [PATCH v3 0/1] MR9845: user32: Remove unused todo_wine handling from listbox test. - approved
by Alexandre Julliard (＠julliard) 02 Jan '26

02 Jan '26

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9845

1 0

[PATCH 0/2] MR9850: d3d*/tests: Test how lighting is affected by world and view matrices.
by Elizabeth Figura (＠zfigura) 02 Jan '26

02 Jan '26

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

2 2

[PATCH v5 0/5] MR9843: wtsapi32: Fix session id and desktop handling when using CreateProcessAsUserW with tokens from WTSQueryUserToken
by Katharina Bogad (＠hackathi) 02 Jan '26

02 Jan '26

This Merge request resolves [Wine-Bug #58588](https://bugs.winehq.org/show_bug.cgi?id=58588). The underlying problem was that services started on their own, non-interactive winstation, but within the current user's session. This is trivially not the case for system services on Windows: they run, by design, in other user contexts (e.g. NTAUTHORITY\SYSTEM). Whenever a service wants to start a process within another user's graphical session, it needs to set the session id to the correct value. This may be done using the WTS API. This MR implements this functionality in a (hopefully) wine-compatible way: 1. Patch wineserver so tokens can be transferred to other sessions 2. Implement NtSetInformationToken for TokenSessionId 3. Change the session of non-interactive services to session 0 (from the default session 1) in addition to setting their desktop to `__wineservice_winstation\Default` 4. Let CreateProcessAsUserW reset the desktop to the default value `__winsta0\Default` if the session of the to-be-created process is not a service session. This avoids implementing all user and session handling in-depth while still allowing the underlying functionality to work. A real-world user of this mechanism is the Dassault 3DEXPERIENCE launcher, which runs as a system service and wants to open interactive child processes within a user's scope. -- v5: kernelbase: Let CreateProcessInternalW overwrite the desktop if needed services: start services with session id 0 https://gitlab.winehq.org/wine/wine/-/merge_requests/9843

2 6

[PATCH v4 0/2] MR9822: Fix possible EA launcher hangs.
by Zhiyi Zhang (＠zhiyi) 02 Jan '26

02 Jan '26

Registering window classes in DllMain() is prone to deadlocks. Tests show that comctl32 window classes should probably be registered in RegisterClassNameW(). Fix possible EA launcher hangs due to deadlocks. A deadlock can happen, like the following, based on Tim Clem's findings. Say there are two threads, T1 and T2. T1: does some COM stuff that results in registering the window class OleMainThreadWndClass.\ T1: NtUserRegisterClassExWOW() does get_desktop_window(). Because this is not a built-in class.\ T1: doesn't yet have a desktop window, so it makes one and calls register_builtin_classes().\ T1: starts the pthread_once in register_builtin_classes() to actually register the classes.\ T1: starts calling NtUserRegisterClassExWOW() with its classes.\ T2: loads comctl32.dll, calls its PROCESS_ATTACH. It grabs the loader lock.\ T2: comctl32's DllMain starts registering its classes.\ T2: comctl32's attempts to register classes also call get_desktop_window().\ T2: get_desktop_window hits the pthread_once in register_builtin_classes() and starts waiting for T1 to finish it.\ T1: some built-in class registration results in a LoadImageW call for a class's cursor.\ T1: LoadImage has to grab a resource, so it tries to grab the loader lock.\ T1: the loader lock is held by T2. Deadlock; T2 is waiting on T1, which is waiting on T2. -- v4: comctl32: Register window classes in RegisterClassNameW() instead of DllMain(). comctl32/tests: Add more RegisterClassNameW() tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/9822

3 5

[PATCH 0/1] MR9847: winex11: Drop SCIM workaround.
by Byeongsik Jeon (＠bsjeon) 02 Jan '26

02 Jan '26

SCIM is no longer under active development (the latest release was on July 31, 2017) and has been replaced by ibus and fcitx. Nevertheless, I investigated this issue using the latest SCIM release and confirmed that this workaround is no longer necessary. It appears to have been a SCIM bug that has been fixed. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55849 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9847

3 2

[PATCH 0/1] MR9848: po: Update Finnish translation.
by Lauri Kenttä (＠lauri.kentta) 02 Jan '26

02 Jan '26

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

2 1

[PATCH 0/1] MR9846: winewayland: support wl_seat version 8
by Ashley Hauck (＠khyperia) 01 Jan '26

01 Jan '26

Bump wl_seat from version 5 to version 8 to support the axis_value120 event, required for high resolution scrolling. - Changes in version 5->6: adding the `shape` and `orientation` events to `wl_touch`. We do not create `wl_touch` objects, so no changes are needed. - Changes in version 6->7: wl_keyboard.keymap must be mmap'd with MAP_PRIVATE (MAP_SHARED is no longer allowed). We already do so, so no changes are needed. - Changes in version 7->8: addition of the wl_pointer.axis_value120 event. Implementing it is the purpose of this MR. This is my first Wine MR. Please let me know if there's anything I can do better! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9846

3 3