February 2025 - wine-gitlab

[PATCH 0/6] MR7261: Splay tree part 3
by Zhiyi Zhang (＠zhiyi) 05 Feb '25

05 Feb '25

For React Native. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7261

3 7

[PATCH v3 0/10] MR7254: windowscodecs: Move component info registry key cleanup to a common failure path.
by Nikolay Sivov (＠nsivov) 05 Feb '25

05 Feb '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v3: windowscodecs: Remove redundant guid-to-string conversion when writing readers registration entries. windowscodecs: Fix a typo in metadata readers registration helper. windowscodecs/metadata: Add a stub for WICIfdMetadataWriter. windowscodecs/metadata: Add a stub for WICExifMetadataWriter. windowscodecs/metadata: Add a stub for WICGpsMetadataWriter. windowscodecs/metadata: Add a stub for WICUnknownMetadataWriter. windowscodecs/metadata: Add registration information for the "Unknown" writer. windowscodecs: Add a stub for IWICMetadataWriterInfo. windowscodecs: Move an hkey handle to the component info base structure. windowscodecs: Move component info registry key cleanup to a common failure path. https://gitlab.winehq.org/wine/wine/-/merge_requests/7254

4 13

[PATCH 0/6] MR7236: winewayland: Clipboard support
by Alexandros Frantzis (＠afrantzis) 05 Feb '25

05 Feb '25

This MR adds clipboard support to the winewayland driver. Under Wayland only applications that have the keyboard focus can interact with the clipboard (a.k.a. `wl_data_device`). Such constraints are not a natural fit for Wine's current clipboard infrastructure, which uses a separate thread and window in the desktop process to act as the win32-side clipboard proxy for all native windows. This MR tries to work within the current Wine clipboard Wine by forwarding relevant clipboard messages to the foreground window which is likely to have the keyboard focus and that can actually handle them. This works well in practice (although there are some edge cases this fails), but I am open to different ideas about implementing the clipboard integration. Some notes about the MR: 1. Some formats that require special treatment (e.g., CF_HTML, CF_HDROP) are not implemented in this MR to keep the size reasonable (and also to not distract from the goal of this MR which is to propose/discuss the basic design of clipboard integration). 2. Dynamic registration of newly-seen/unknown formats is not supported at the moment. It's not clear to what degree that's useful, since many (most?) Windows clipboard format strings are free-form and don't use the MIME type standard. But perhaps enough Windows apps know about MIME types nowadays to make this addition worth it? 3. Since access to the Wayland clipboard data is performed from the focused window threads (rather than the dedicated clipboard thread), any blocking while waiting for data to be sent/received has more potential to affect the applications. I have implemented reasonable timeouts which are hopefully enough to make this a non-issue. A (more complex) alternative would be a different design that attempts to offload any potentially blocking work to the dedicated clipboard thread (or is there some kind of async read/write mechanism we can use?). I am not convinced the extra complexity is worth it, though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7236

4 9

[PATCH v20 0/3] MR7131: DIR command improvements: Make /o by itself behave equal to how it does in Windows
by Joe Souza (＠JoeS209) 05 Feb '25

05 Feb '25

"DIR /o" (no order specifier after /o) hasn't functioned the same as it does on Windows. This change makes the functionality of /o by itself equivalent to behavior on Windows. -- v20: programs/cmd: Remove @todo_wine@ from working tests. programs/cmd: Cleanup DIR /O logic. programs/cmd: Add tests patch from @epo. https://gitlab.winehq.org/wine/wine/-/merge_requests/7131

2 3

[PATCH v2 0/1] MR7231: rpcrt4, winedbg, winevulkan: Various small fixes for Clang 20 + -Werror.
by William Horvath (＠whrvth) 04 Feb '25

04 Feb '25

I don't think these are serious problems, but Clang 20's defaults (from llvm-mingw nightly) were resulting in build failures with `--enable-werror` due to `-Wtautological-compare` and `-Wunused-function`. I hope that the buffer wrap checking is somewhat idiomatic/standard. If necessary, I can split off the winevulkan change, but it seems minor enough to be grouped in this MR. -- v2: rpcrt4: Pointer arithmetic fixes (-Wtautological-compare). https://gitlab.winehq.org/wine/wine/-/merge_requests/7231

3 3

[PATCH v8 0/5] MR7: ntdll: Properly track refcount with forwarded exports.
by Jinoh Kang (＠iamahuman) 04 Feb '25

04 Feb '25

This fixes https://bugs.winehq.org/show_bug.cgi?id=52094. -- v8: ntdll: Properly track refcount with forwarded exports. ntdll: Don't re-add a module dependency if it already exists. ntdll: Remove some unnecessary NULL checks for current_importer. ntdll: Set export forwarder DLL as the dynamic importer in LdrGetProcedureAddress(). ntdll: Wrap current_modref variable in a new structure. https://gitlab.winehq.org/wine/wine/-/merge_requests/7

4 9

Re: [PATCH v3 0/3] MR7256: ntdll: monotonic_counter and NtQuerySystemTime performance improvements on macOS.
by Marc-Aurel Zent (＠mzent) 04 Feb '25

04 Feb '25

On Tue Feb 4 17:55:14 2025 +0000, Tim Clem wrote: > I think this calls for a quick comment (or at least a note in the commit > message) as to why we're using this function. Added a comment, explaining the rationale there. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7256#note_93649

1 0

[PATCH v2 0/3] MR7256: ntdll: monotonic_counter and NtQuerySystemTime performance improvements on macOS.
by Marc-Aurel Zent (＠mzent) 04 Feb '25

04 Feb '25

`mach_continuous_approximate_time()` has the necessary precision for win32 ticks and can be up to 4x faster than `mach_continuous_time()`. Also `clock_gettime( CLOCK_REALTIME, &ts )` calls always end up in `__commpage_gettimeofday( struct timeval *tp )`: ``` * frame #0: 0x00007ff806788763 libsystem_kernel.dylib`__commpage_gettimeofday frame #1: 0x00007ff8066709a3 libsystem_c.dylib`gettimeofday + 45 frame #2: 0x00007ff806678b31 libsystem_c.dylib`clock_gettime + 117 ``` These extra calls, setup and converting from one struct format to another costs another 60 CPU cycles and in my testing makes `NtQuerySystemTime` approximately 30% faster as well with this MR. This is a fairly hot code path (especially when using certain out-of-tree in process synchronization patch sets), so probably worth the optimization here. All of these APIs are available since 10.12. -- v2: ntdll: Replace '0' with 'NULL' in gettimeofday() calls. ntdll: Use __commpage_gettimeofday in NtQuerySystemTime on macOS. ntdll: Always use mach_continuous_approximate_time on macOS. https://gitlab.winehq.org/wine/wine/-/merge_requests/7256

2 4

[PATCH 0/2] MR7256: ntdll: monotonic_counter and NtQuerySystemTime performance improvements on macOS.
by Marc-Aurel Zent (＠mzent) 04 Feb '25

04 Feb '25

`mach_continuous_approximate_time()` has the necessary precision for win32 ticks and can be up to 4x faster than `mach_continuous_time()`. Also `clock_gettime( CLOCK_REALTIME, &ts )` calls always end up in `__commpage_gettimeofday( struct timeval *tp )`: ``` * frame #0: 0x00007ff806788763 libsystem_kernel.dylib`__commpage_gettimeofday frame #1: 0x00007ff8066709a3 libsystem_c.dylib`gettimeofday + 45 frame #2: 0x00007ff806678b31 libsystem_c.dylib`clock_gettime + 117 ``` These extra calls, setup and converting from one struct format to another costs another 60 CPU cycles and in my testing makes `NtQuerySystemTime` approximately 30% faster as well with this MR. This is a fairly hot code path (especially when using certain out-of-tree in process synchronization patch sets), so probably worth the optimization here. All of these APIs are available since 10.12. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7256

5 12

Re: [PATCH v3 0/1] MR7115: Added support of case FileAllocationInformation in SetFileInformationByHandle
by Stéphane Bacri (＠fr33z00) 04 Feb '25

04 Feb '25

@julliard Thanks for taking the time to review. About the file size increase, it sounds like a direct consequence of what this function is supposed to do, since it shall allocate some space for a file. Can you detail your thoughts about it? About the tests, I guess you mean unit tests, right? Or did you mean tests on the parameters (say check that size is aligned with cluster size, or > to current size)? In the first case, I'm gonna try to add something, as digging a bit more the code showed that there is a basis. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7115#note_93641

1 0

2025

2024

2023

2022

wine-gitlab February 2025