February 2023 - wine-gitlab

[PATCH 0/1] MR71: Draft: vkd3d: Update Vulkan descriptors only when submitted to a command queue.
by Conor McCarthy (＠cmccarthy) 26 Apr '23

26 Apr '23

Unpolished. Raises framerate by around 15% in SotTR because vk_sets_mutex is locked only once for each descriptor heap. It's possible to collate multiple writes for a single vkUpdateDescriptorSets() call as was done in the optimised copying path, but it may not be worth it. A possible complication with this: if it becomes possible to remove the descriptor mutexes after the remaining problems with queue sequencing are fixed, we theoretically may still need them for this. Descriptors should not be updated while binding, but there's no reason more can't be written in another thread while a command list is submitted to a queue. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/71

2 2

[PATCH v3 0/1] MR1853: mf: Request more samples for MFT when needed.
by Shaun Ren (＠shaunren) 20 Apr '23

20 Apr '23

When an upstream node has not given enough samples to the transform, we need to request more samples from it to avoid stalling the pipeline. This fixes an issue where the intro audio of the game Airborne Kingdom stops playing after a few seconds. -- v3: mf: Request more samples for transforms when needed. https://gitlab.winehq.org/wine/wine/-/merge_requests/1853

2 3

[PATCH v3 0/3] MR2173: user32/tests: Fix WM_CHAR tests to use the input codepage.
by Akihiro Sagawa (＠sgwaki) 17 Apr '23

17 Apr '23

User32 uses the input codepage in Unicode edit control. However, it uses ANSI codepage, i.e. CP_ACP, in ANSI version control. Comctl32 is different from user32. It doesn't have A-W duality and uses the input codepage in it. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54424 -- v3: comctl32/tests: Add WM_CHAR tests for edit control. user32/edit: Use CP_ACP for WM_CHAR convresion in ANSI version control. user32/tests: Fix WM_CHAR tests to use the input codepage. https://gitlab.winehq.org/wine/wine/-/merge_requests/2173

2 5

[PATCH v3 0/5] MR2159: winegstreamer: Stride and RGB formats, part 2/2.
by Zebediah Figura (＠zfigura) 06 Apr '23

06 Apr '23

-- v3: winegstreamer: Output BGRx video from the media source. winegstreamer: Move flipping based on RGB to the frontends. winegstreamer: Translate the MF_MT_DEFAULT_STRIDE attribute to flipped video in mf_media_type_to_wg_format(). winegstreamer: Set the MF_MT_DEFAULT_STRIDE attribute in mf_media_type_from_wg_format(). winegstreamer: Initialize media source video types from a wg_video_format array. https://gitlab.winehq.org/wine/wine/-/merge_requests/2159

5 21

[PATCH v3 0/2] MR2068: Draft: comdlg32: Enable visual styles when showing IFileDialog.
by Vladislav Timonin (＠vt) 31 Mar '23

31 Mar '23

Required for !1857 to not break when comctl32 version 6 isn't requested by application (in particular, found this in [qapitrace](https://github.com/apitrace/apitrace)). Manifest resource id and assembly identity name match with Windows. For isolation purposes, activation context is disabled while emitting events. -- v3: comdlg32: Enable visual styles when showing IFileDialog. comdlg32: Return E_UNEXPECTED if IFileDialog is already shown https://gitlab.winehq.org/wine/wine/-/merge_requests/2068

4 8

[PATCH 0/1] MR989: d3d10core/tests: Mark tests failing randomly on Windows as flaky.
by Francois Gouget (＠fgouget) 29 Mar '23

29 Mar '23

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

6 6

[PATCH 0/5] MR1979: msvcrt: Remaining implementations and stubs for cm3
by Torge Matthies (＠tmatthies) 28 Mar '23

28 Mar '23

This adds the remaining `_StructuredTaskCollection` functions and other stubs needed for Crazy Machines 3 to work and decode preview images correctly in online mode. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1979

3 15

[PATCH v2 0/2] MR93: Draft: vkd3d-shader/hlsl: Fix assumptions in add_load_index() and add_load_component().
by Francisco Casas (＠fcasas) 27 Mar '23

27 Mar '23

Currently, we can't use `add_load_index()` or `add_load_component()` on the loads to the `"retval"` variables that come from `add_call()` because these functions assume that the loaded value (`var_instr`) won't change between its location and the location and the new load to be created. We can't get rid of this assumptions either, because, at least `add_load_index()` may be used in the lhs of an assignment, and in that case we can't store to the "deref" synthetic: ``` x[0] = 20; ``` Here I implemented the alternative solution of copying `"retval"` into a synthetic variable after each function call, but we may want to discuss this approach. -- v2: https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/93

3 10

[PATCH v2 0/2] MR109: vkd3d-shader/hlsl: Improve handling of builtin aliases "matrix" and "vector".
by Nikolay Sivov (＠nsivov) 22 Mar '23

22 Mar '23

-- v2: vkd3d-shader/hlsl: Improve handling of builtin alias type "vector". https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/109

4 6

[PATCH v4 0/4] MR2127: ntdll: Load known dlls from system directory
by Paul Gofman (＠gofman) 20 Mar '23

20 Mar '23

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

3 6

2025

2024

2023

2022

wine-gitlab February 2023