June 2025 - wine-gitlab

Re: [PATCH v2 0/5] MR8460: ntdll: Add support for multi-battery systems and energy-reporting batteries on Linux
by Tomas-Mendes-ai (＠Tomas-Mendes-ai) 30 Jun '25

30 Jun '25

Enhancement proposal: https://bugs.winehq.org/show_bug.cgi?id=58401 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8460#note_108325

1 0

Re: [PATCH v5 0/0] MR8378: urlmon: Add PersistentZoneIdentifier COM object
by Mike Kozelkov (＠augenzi) 30 Jun '25

30 Jun '25

On Thu Jun 26 22:17:25 2025 +0000, Jacek Caban wrote: > Yes, a stub is fine (and you may use this MR for that). Sorry, I think I messed up this MR branch, so it can't be merged fast-forward-merged. I've created a !8456 merge request for the stubs. Also I've implemented a PersistentZoneIdentifier interfaces with test cases in !8459, but it's just a mimic the behavior of PersistentZoneIdentifier without any writing or reading information about the zone. Some test cases fail due to no reading zone information. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8378#note_108320

1 0

[PATCH 0/5] MR8458: Draft: ntdll: Add support for multi-battery systems and energy-reporting batteries on Linux
by Tomas-Mendes-ai (＠Tomas-Mendes-ai) 30 Jun '25

30 Jun '25

Current implementation of system.fill_battery_state only reads "charge_*" and "current_*" attributes. Some batteries expose different attributes, namely "power_*" and "energy_*". Added the required logic to support both types. Further, when rewriting the function I also added support for systems with multiple batteries. Windows documentation was not clear but from what I gathered struct SYSTEM_BATTERY_STATE sets Charging and Discharging if ANY battery is charging/discharging. So, to check if the overall system is charging/discharging only Rate can be used. Also cleaned the code related to "AC". There was a "fixme" there which I didn't fully undertand as SYSTEM_BATTERY_STATE.AcOnLine == True if any AC is present, so the proper logic was already implemented -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8458

2 6

[PATCH 0/1] MR8457: kernel32: Update len in wine_get_dos_filename before using it to remove the \??\.
by William Horvath (＠whrvt) 30 Jun '25

30 Jun '25

The wcscat increases the size, so this happened: ``` trace:file:wine_get_dos_file_name start: "/usr/lib32/libXext.so.6" trace:file:NtCreateFile handle=0x109f37c access=80000000 name=L"\\??\\unix\\usr\\lib32\\libXext.so.6" objattr=00000000 root=(nil) sec=(nil) io=0x109f380 alloc_size=(nil) attr=00000000 sharing=00000003 disp=1 options=00000020 ea=(nil).0x00000000 trace:file:get_nt_and_unix_names L"\\??\\unix\\usr\\lib32\\libXext.so.6" -> ret 0 nt L"\\??\\Z:\\usr\\lib32\\libXext.so.6" unix "/usr/lib32/libXext.so.6" trace:file:wine_get_dos_file_name end: L"Z:\\usr\\lib32\\libXextXext.so.6" ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8457

2 3

[PATCH v2 0/1] MR8453: Draft: tools: Remove ~/.wine on every gitlab test run.
by Jinoh Kang (＠iamahuman) 30 Jun '25

30 Jun '25

Otherwise leftover settings from previous runs interfere with current tests. -- v2: tools: Remove ~/.wine on every gitlab test run. https://gitlab.winehq.org/wine/wine/-/merge_requests/8453

4 10

Re: [PATCH v30 0/3] MR8200: cmd: COPY should output file names as they are copied.
by Joe Souza (＠JoeS209) 30 Jun '25

30 Jun '25

On Sat Jun 28 16:39:09 2025 +0000, eric pouech wrote: > sorry for the delay > LGTM > two side remarks: > * you don't need to push the updates, unless there's a conflict between > new merge and your merge request > * WCMD_parameter's raw parameter to TRUE should return the parameter > with the double quotes untouched Thanks. Regarding pushing the updates, this is happening automatically when I rebase via the UI here. First rebase always fails, telling me to rebase locally, but if I click it again it is successful and it then pushes the changes to the fork. Not sure if there is a way for me to rebase without the subsequent push occurring. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_108308

1 0

Re: [PATCH v30 0/3] MR8200: cmd: COPY should output file names as they are copied. - approved
by eric pouech (＠epo) 30 Jun '25

30 Jun '25

This merge request was approved by eric pouech. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200

1 0

Re: [PATCH v30 0/3] MR8200: cmd: COPY should output file names as they are copied.
by eric pouech (＠epo) 30 Jun '25

30 Jun '25

sorry for the delay LGTM two side remarks: * you don't need to push the updates, unless there's a conflict between new merge and your merge request * WCMD_parameter's raw parameter to TRUE should return the parameter with the double quotes untouched -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_108305

1 0

[PATCH 0/1] MR8442: mscoree/tests: Fix string lengths passed to RegSetKeyValueA.
by Yuxuan Shui (＠yshui) 30 Jun '25

30 Jun '25

* * * A macro that does `RegSetKeyValueA(..., value, ARRAY_SIZE(value))` would be nice. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8442

3 2

Re: [PATCH v2 0/6] MR8445: server: Create inproc sync events for message queues.
by Elizabeth Figura (＠zfigura) 30 Jun '25

30 Jun '25

> The comment is added in a later change, when it really matters. For now the entries aren't cached. But now it doesn't make sense why it's arranged like this. If you really want to defer things like that, you should get rid of the double-pointer return. Obviously I didn't do that because it would have required a lot of refactoring once I did start caching objects, although sometimes that kind of refactoring is preferable, but if you are similarly going to avoid it, you should explain why there's two parameters. > Fwiw I kept a "cache" name for the stack variable but it should probably not even be named like that, it's not a cache. I don't think it matters much anyway, the code isn't so complicated. I can see why you see it as not a cache, although I think it also kind of is: the canonical information lives in the server, the client side can be dropped and reacquired, and the code is intended to work even if we don't have memory to store that information. But either way, we shouldn't name the single-pointer parameter just "cache". That's not its point compared to the double-pointer parameter; the point is to be a stack or fallback pointer to hold that information. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8445#note_108294

1 0

2025

2024

2023

2022

wine-gitlab June 2025