On Mon Apr 6 16:41:15 2026 +0000, Paul Gofman wrote:
This needs checks on Windows. I did one, enabling Proton VPN. I am attaching the patch which adds a bit more of info to GetAdaptersInfo test output and the output from up to date Windows 11. [test.patch](/uploads/6b62a42e1997d6621d7a9e499e522999/test.patch)
[out.txt](/uploads/a83be2f1939cfc8784e1b9c20d7a1a01/out.txt) That test shows that: * adapters with 0 HW id are possible on Windows; * GetAdaptersInfo on Windows **does not sort by that** and the 0 HW address does not appear last. So it looks like the change is not correct. Also, the change affects the most basic NPI_MS_NDIS_MODULEID table which is used in many places, not only in GetAdaptersInfo, and changing the sort order of that one requires more tests and, first of all, directly testing the output from NsiAllocateAndGetTable( &NPI_MS_NDIS_MODULEID ). When I was mentioning doing things in nsiproxy.sys I was referring specifically to filtering out the interfaces. The sorting could maybe be done in iphlpapi (like we do in GetAdaptersAddresses) but that needs to be backed by some tests and my ad-hoc tests shows that the suggested sorting is incorrect either way. So the proper fix needs to be somehow different. I am not versed with Macs, what are those lo0, gif0 interfaces exactly which go first? Do we need those? Maybe if we don't we should still filter those out in nsiproxy.sys (the direction initial patch suggested), just based not on HW address but based on some other attribute(s) MAC specific, and in nsiproxy.sys and not iphlpapi. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10553#note_135130