--
v2: win32u: Move GetMenuItemID implementation from user32.
user32: Reimplement GetMenuStringW on top of NtUserThunkedMenuItemInfo.
user32: Reimplement GetMenuStringA on top of NtUserThunkedMenuItemInfo.
win32u: Move get_menu_item_info implementation from user32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/294
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53175
Commit 910d58520a6d75cada82d992757ca013099d9345 (iphlpapi: Return ERROR_NO_DATA from GetIpNetTable() if no entries are found.) introduced a regression in Roon application. It looks like the app doesn't tolerate an error return from GetIpNetTable() if there are active interfaces found. The blamed patch still looks correct to me per se, that is, if number of entries ends up being zero Windows returns ERROR_NO_DATA. However, number of entries is never zero on Windows if there is any network adapter.
There are two things why Windows always has some arp entries and we do not:
1. We currently parse /proc/net/arp line on Linux a bit wrong and end up getting no entries from there (patch 1 fixes that);
2. With the patch patch 1 there Roon seems happy (at least as far as I could test it right at start), at least as long we have an entry in /proc/sys/net (which might not be necessarily the case if there is, e. g., no actual network connection). But that breaks SCP: Secret Laboratory again the same way as before 910d58520a6d75cada82d992757ca013099d9345. It turns out the latter game depends on GetIpNetTable() returning at least 4 entries when returning success (for some reason, I am not sure why but I think I saw that quite clearly). And both apps can actually work reliably on Windows as there are always at least 4 static arp entries if there is any network adaptere configured at all.
There are "224.0.0.22" and "239.255.255.250" static arp multicast entries which are always there for any interface on Windows, including loopback (starting from Win10; earlier versions might be missing "239.255.255.250" but have "224.0.0.22"). So adding those like on Windows should hopefully fix all those cases.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/286
All of the new tests that are marked todo_wine fail because Wine's
PathCombineW does not handle ".", "...", "....", or "foobar." correctly.
They will pass once PathCombineW is fixed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52506
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com>
--
v4: shell32: Sanitize Program Manager icon and group names.
https://gitlab.winehq.org/wine/wine/-/merge_requests/23
All of the new tests that are marked todo_wine fail because Wine's
PathCombineW does not handle ".", "...", "....", or "foobar." correctly.
They will pass once PathCombineW is fixed.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52506
Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com>
--
v3: shell32: Sanitize Program Manager icon and group names
https://gitlab.winehq.org/wine/wine/-/merge_requests/23
Fixes ClaDun X2 missing rendering parts on AMD. The GL game uses stencil and requests pixel format with depth 16, stencil 8. On Wine / AMD that ends up with 16x0 format as there is no 16x8 advertised (16x0 only) and depth takes absolute priority. On the same Windows machine I see both 16x0 and 16x8 formats, but when 16x8 is requested 24x8 is returned (and 16x0 if 16x0 is requested).
That currently works under Wine / Nvidia because there is no 16 bit depth formats advertised at all and it ends up with 24x8 without this patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/132
.NET 6's HTTP/Socket code queries this. Winsock allows getsockname
on the AcceptEx AcceptSocket, but only if SO_UPDATE_ACCEPT_CONTEXT
is set.
Signed-off-by: David Curtiss <david.curtiss(a)ni.com>
--
v5: ws2_32: Allow getsockname after AcceptEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/192