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

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) June 30, 2025

June 30, 2025

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

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) June 30, 2025

June 30, 2025

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) June 30, 2025

June 30, 2025

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) June 30, 2025

June 30, 2025

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) June 30, 2025

June 30, 2025

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) June 30, 2025

June 30, 2025

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) June 30, 2025

June 30, 2025

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) June 30, 2025

June 30, 2025

* * * 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) June 30, 2025

June 30, 2025

> 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

Re: [PATCH v3 0/5] MR8446: server: Initialize global and user tables with some atoms. - approved
by Alexandre Julliard (＠julliard) June 30, 2025

June 30, 2025

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

1 0