May 2025 - Wine-GitLab - list.winehq.org

[PATCH v2 0/1] MR7964: quartz/tests: Increase the timeout of a pause test in test_media_event.
by Alex Henrie (＠alexhenrie) May 15, 2025

May 15, 2025

This test failed on Linux 2 out of the last 67 times on test.winehq.org because IMediaControl_GetState returned VFW_S_STATE_INTERMEDIATE, evidently meaning that the command to pause had been received but not yet carried out. Give it two seconds to complete instead of one to ensure that it finishes. -- v2: quartz/tests: Increase the timeout of a pause test in test_media_event. https://gitlab.winehq.org/wine/wine/-/merge_requests/7964

3 2

[PATCH 0/1] MR7946: winegstreamer: Only align the first plane in gst_video_info_align.
by Brendan McGrath (＠redmcg) May 15, 2025

May 15, 2025

This ensures that the stride calculation performed by `gst_video_info_align` matches the result in `wg_format_get_stride`. Otherwise, we can get a size mismatch which will result in a `STATUS_BUFFER_TOO_SMALL` error. This affected formats where not all planes had the same stride. For example: I420, YV12, etc (where the 'U' and 'V' planes are horizontally subsampled and stored in their own plane). The error would occur if half the aligned primary plane stride was not also on the desired alignment. For example: a width of 1828 would be padded to 1840 (aligned to the next multiple of 16), but half of this is 920 which is not a multiple of 16. Hence `gst_video_info_align` was adding additional padding to also align that, which is 928. The result would be a stride of 1856 for the primary plane, whilst `wg_format_get_stride` would stay with the original value of 1840. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7946

4 6

[PATCH v2 0/1] MR7872: shell32: Avoid writing past end of xlpFile or lpResult in SHELL_FindExecutable().
by Paul Gofman (＠gofman) May 15, 2025

May 15, 2025

-- v2: shell32: Avoid writing past end of xlpFile or lpResult in SHELL_FindExecutable(). https://gitlab.winehq.org/wine/wine/-/merge_requests/7872

3 3

[PATCH 0/1] MR7823: winegstreamer: Allow decodebin to eliminate caps that don't use system memory.
by Brendan McGrath (＠redmcg) May 15, 2025

May 15, 2025

This speeds up pipeline creation and fixes a timing issue where caps negotiation is not completed prior to the first buffer being sent. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7823

3 9

[PATCH v4 0/4] MR2127: ntdll: Load known dlls from system directory
by Paul Gofman (＠gofman) May 15, 2025

May 15, 2025

The practical issue I am trying to solve is the following scenario (encountered with a game using some Uplay plugin) which has regressed with apisets implementation in Wine. The game imports ucrtbase.dll. Then, a plugin calls GetModuleHandle("api-ms-win-crt-runtime-l1-1-0.dll") and expects GetProcAddress("\_crt_atexit") to succeed on the returned handle. The problem is that the game has ucrtbase.dll in its .exe directory. That one currently gets loaded. Then, find_dll_file() resolves api-ms-win-crt-runtime-l1-1-0.dll to the ucrtbase with a full path in system32 and tries to find that one (this part matches Windows behaviour as far as tests show). Since we have ucrtbase loaded with another path this results in NULL module handle. Windows maintains the list of "Known DLLs" (probably aimed for speeding up processes startup by using pre-mapped dll images for commonly used system dlls). On Windows, known dlls have specifics in load path resolution when dll name doesn't contain path (relative or full): - they are loaded from system directory even if there is another dll with the same name in priority search path; - they are found even if library search paths do not contain system directory; Those "Known DLLs" are basically listed in HKLM\\System\\CurrentControlSet\\Control\\Session Manager\KnownDLLs registry key. But the actual list of "known dlls" is bigger (probably includes all dependencies of those listed under registry key). The full actual list of "known dlls" is in '\\KnownDlls\' directory object which contains image sections under dll names. Most notably, ucrtbase.dll (which is of the concern in the regression) is not listed in registry but is present in \\KnownDlls. Technically nothing prevents us from implementing these mechanics and creating directory object with mapped load dlls, also resolving the explicitly listed dlls' dependencies. But it is not apparent to me if that is going to improve load times noticably in Wine, and also that is worth the inherent complications until anything actually depends on that \\KnownDlls sections. So instead of implementing all of that throughout the loader I added a few missing dlls to registry. The current list in this pat chset corresponds to the contents of \\KnownDlls directory on an up to date Windows 10. -- v4: ntdll: Load known dlls from system directory. loader/wine.inf: Add known dlls key. ntdll: Factor out prepend_system_dir() function. kernel32/tests: Add tests for known dlls load specifics. https://gitlab.winehq.org/wine/wine/-/merge_requests/2127

4 8

[PATCH v7 0/5] MR7848: server: Use events as a sync for several objects.
by Rémi Bernon May 15, 2025

May 15, 2025

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object. This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later. -- v7: server: Use an event sync for fd objects. server: Introduce a new event sync object. server: Redirect fd-based objects sync to the fd. server: Add an operation to retrieve an object sync. server: Move object grab/release out of (add|remove)_queue. https://gitlab.winehq.org/wine/wine/-/merge_requests/7848

1 6

[PATCH v5 0/5] MR7848: server: Use events as a sync for several objects.
by Rémi Bernon May 15, 2025

May 15, 2025

Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/7815, for https://gitlab.winehq.org/wine/wine/-/merge_requests/7226, this only split the sync ops to a separate vtable and let objects delegate theirs to a separate object. This starts using a event-like interface for most objects, leaving the decision regarding if/how to split sync themselves / integrate inproc syncs for later. -- v5: server: Use an event sync for fd objects. server: Introduce a new event sync object. server: Redirect fd-based objects sync to the fd. server: Add an operation to retrieve an object sync. server: Move object grab/release out of (add|remove)_queue. https://gitlab.winehq.org/wine/wine/-/merge_requests/7848

1 5

[PATCH 0/1] MR7983: server: Remove const qualifier from shared memory pointers.
by Rémi Bernon May 15, 2025

May 15, 2025

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7610 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7983

2 2

[PATCH 0/1] MR7981: include: Add IHTMLOptionButtonElement interface
by Alistair Leslie-Hughes (＠alesliehughes) May 15, 2025

May 15, 2025

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

3 2

[PATCH v17 0/7] MR7610: win32u: Create a shared object for user handle entries.
by Rémi Bernon May 15, 2025

May 15, 2025

For https://gitlab.winehq.org/wine/wine/-/merge_requests/7512 to use it to locate window shared objects. -- v17: win32u: Use the session shared object for user handle entries. win32u: Use the session shared object to implement is_window. server: Move the user object handle table to the shared memory. server: Allocate a session shared memory header structure. server: Use NTUSER_OBJ constants for user object types. server: Remove const qualifier from shared memory pointers. include: Implement ReadAcquire64. https://gitlab.winehq.org/wine/wine/-/merge_requests/7610

2 11