On Mon Apr 6 16:50:33 2026 +0000, Paul Gofman wrote:
[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. Regarding your question about interfaces: `gif0` and `stf0` are macOS tunnel interfaces (Generic Tunnel and 6to4). The `utun*` interfaces are used by macOS for system and third-party VPNs.
These are macOS-specific interfaces that don't exist in Windows (as far as I can tell). Filtering them out in `nsiproxy.sys` would make the list of adapters more similar to what Windows would return on equivalent hardware, and would also reduce the likelihood that applications would encounter buffer size issues, given the typical number of adapters in Windows. I also considered filtering out these macOS-specific interfaces in `nsiproxy.sys`, but couldn’t find a reliable way to identify them. Hard-coding interface names such as gif0, stf0, and utun seems unreliable, and I don’t know of a better macOS-specific attribute that could be used. Maybe someone knows of one? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10553#note_135159