May 2023 - Wine-gitlab - list.winehq.org

[PATCH 0/4] MR2819: dinput, hid, w.g.i: Fix some leaks and uninitialized reads found with Valgrind.
by Rémi Bernon 15 May '23

15 May '23

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

1 4

[PATCH v3 0/4] MR2800: ntdll/heap: Reduce memory footprint by better matching Windows subheap sizes
by Paul Gofman (＠gofman) 15 May '23

15 May '23

Turns out Windows is more conservative both in initial allocation when creating new heap and also in growing the heap. Comments: - Without patch 1 the related test in test_block_layout fails on x64 for me ("unexpected padding") after the last patch. I don't think the last patches really changes much in this regard, looks like the test just depends on the uninitialized data; - Without patch 2 test_HeapCreate fails (line 601 where it checks the last block pointer). I think it is also only triggered by my patch, I think that last block detection only works correctly now when commit size is smaller than the subheap size (which happens to be not the case in the test after the last patch); - The last patch extends a bit a todo in test_block_layout(). The actual reason for (extended) todo is that we are probably not handling pending free blocks quite like on Windows. I watched the pointers on Windows in the same test and they are always withing the same subheap allocation which suggests that Windows might be reusing pending free block once it can't find normal free block and before extending the heap. So the last patch changes subheap sizes and that triggers different subheaps for the allocated pointers in Wine. So it looks like not an actual issue with my patch. Reusing pending free pointers is apparently possible to implement but it seems to me that it doesn't worth the trouble until anything depends on that (since those pending free blocks are only there when heap debug flags are enabled which is rarely the case outside of debugging). -- v3: ntdll: Better match Windows subheap sizes. kernel32/tests: Add tests for subheap sizes. https://gitlab.winehq.org/wine/wine/-/merge_requests/2800

3 6

[PATCH 0/2] MR2809: user32/tests: Use win_skip() for missing APIs.
by Francois Gouget (＠fgouget) 15 May '23

15 May '23

A missing API is a todo in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2809

3 3

[PATCH 0/2] MR2810: gdi32 & sti: Use win_skip() for missing APIs.
by Francois Gouget (＠fgouget) 14 May '23

14 May '23

A missing API is a todo in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2810

3 3

[PATCH 0/4] MR2812: iphlpapi, ws2_32, wtsapi32 & wintab32: Use win_skip() for missing APIs.
by Francois Gouget (＠fgouget) 14 May '23

14 May '23

A missing API is a todo in Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2812

3 5

[PATCH 0/4] MR2806: wine{alsa,coreaudio,oss,pulse}: Move AudioCaptureClient into mmdevapi.
by Davide Beatrici (＠davidebeatrici) 14 May '23

14 May '23

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

3 6

Re: [PATCH v2 0/4] MR2786: Add support for AF_UNIX sockets
by Loïc Rebmeister 14 May '23

14 May '23

"Unfortunately, last time I tried to write tests for Unix sockets, I started triggering kernel panics in Windows." It seems like a Windows specific issue! A kernel panic should never occur, even when provided with invalid data. @dropbear I think you could use the code and turn it into a test for theses patches? I think it's best to ignore Windows <-> Unix communications tests for now as I don't think `winetest` allow running tests in both Windows and Unix space at the same time, that would require `winetest` supporting `wsl` when testing on Windows10+, and I think `wsl` support is out of scope of this PR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_32726

1 0

Re: [PATCH v4 0/2] MR2808: Draft: SNI tray implementation
by Cherser-s (＠Cherser-s) 14 May '23

14 May '23

Also how can I remove the option to compile winesni.drv on macos from the configure script? Everything I change didn't do the trick with Mac OS pipeline. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2808#note_32725

1 0

Re: [PATCH v4 0/2] MR2808: Draft: SNI tray implementation
by Cherser-s (＠Cherser-s) 14 May '23

14 May '23

On Sun May 14 12:03:33 2023 +0000, Loïc Rebmeister wrote: > Nevermind I saw `org.freedesktop.StatusNotifierItem` used in the rest of > the code and assumed it was already supported, but I checked commit > names and saw it was intentional. > I saw the rest of the code reference `org.freedesktop.StatusNotifierItem` > A wine standard would be to remove the > `org.freedesktop.StatusNotifierItem` from the KDE SNI Implementation > commit, and then add the references back on the commit that add the > `org.freedesktop.StatusNotifierItem` based implementation. Maybe just remove freedesktop interface altogether? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2808#note_32724

1 0

Re: [PATCH v4 0/2] MR2808: Draft: SNI tray implementation
by Loïc Rebmeister 14 May '23

14 May '23

On Sun May 14 11:59:45 2023 +0000, Loïc Rebmeister wrote: > `watcher_interface_name` is `org.kde.StatusNotifierItem` and this code > is only checking that. > Is this intentional that `org.freedesktop.StatusNotifierItem` is not checked? Nevermind I saw `org.freedesktop.StatusNotifierItem` used in the rest of the code and assumed it was already supported, but I checked commit names and saw it was intentional. I saw the rest of the code reference `org.freedesktop.StatusNotifierItem` A wine standard would be to remove the `org.freedesktop.StatusNotifierItem` from the KDE SNI Implementation commit, and then add the references back on the commit that add the `org.freedesktop.StatusNotifierItem` based implementation. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2808#note_32723

1 0