windows: get_dev_port_number try using VID / PID

[sonatique]

Since SPDRP_ADDRESS may return the actual port number, but not always, try another way of getting port number by matching VID/PID obtained via IOCTL_USB_GET_NODE_CONNECTION_INFORMATION_EX with values encoded in dev_id string, by brute-forcing initialization of temporary device objects.

If a match is found, Serial Number is verified as well. If all is succeed then port_nr is assigned to the value found, otherwise revert to port_nr and return value from SPDRP_ADDRESS.

[mcuee]

@sonatique

Please help to share some background info and show one example that SPDRP_ADDRESS is incorrect. Thanks.

[sonatique]

@sonatique

Please help to share some background info and show one example that SPDRP_ADDRESS is incorrect. Thanks.

As stated in a comment in the current code: "try SPDRP_ADDRESS, which returns a REG_DWORD. The address may be the port number", or it may not.

When experimenting with "FabulaTech Virtual USB Host Controller" (USB-Ethernet bridge) under Hyper-V virtual machine, I found out that indeed, SPDRP_ADDRESS access returns true (so this key is found in registry) but we get an obviously wrong port number. This is because SPDRP_ADDRESS registry key does not seem to be standardised. In my case the number found here was simply an instance number not related to port number at all.

Under regular Windows, I experienced that either we get an port number from SPDRP_LOCATION_INFORMATION or SPDRP_LOCATION_PATHS, or trying SPDRP_ADDRESS return false (such key don't exist).

Therefore I devised another alternate way to obtain a valid port_number. In my experience, either this code is not called at all (nor is the call using SDRP_ADDRESS) because earlier access to registry lead to a valid port_number, or the SDRP_ADDRESS is not valid and it makes sense to call my new, somehow heavier, implementation.

[mcuee]

@sonatique

I see. I think your explanation is good. I do not have such device to test though.

But at least I do not see any regressions.

PS C:\work\libusb\libusb_pr1269> .\build\v143\x64\Release\listdevs.exe
05e3:0612 (bus 2, device 1) path: 2
8087:0026 (bus 1, device 3) path: 10
04f2:b6dd (bus 1, device 1) path: 5
1c7a:0575 (bus 1, device 2) path: 7
8086:a0ed (bus 1, device 0)
05e3:0610 (bus 1, device 4) path: 2
04d8:fa2e (bus 1, device 10) path: 2.3
046d:c52b (bus 1, device 7) path: 3
8086:9a13 (bus 2, device 0)
PS C:\work\libusb\libusb_pr1269> cd ..\libusb
PS C:\work\libusb\libusb> .\build\v143\x64\Release\listdevs.exe
05e3:0612 (bus 2, device 1) path: 2
8087:0026 (bus 1, device 3) path: 10
04f2:b6dd (bus 1, device 1) path: 5
1c7a:0575 (bus 1, device 2) path: 7
8086:a0ed (bus 1, device 0)
05e3:0610 (bus 1, device 4) path: 2
04d8:fa2e (bus 1, device 10) path: 2.3
046d:c52b (bus 1, device 7) path: 3
8086:9a13 (bus 2, device 0)

[mcuee]

@tormodvolden

I think this PR is good to go. Please review as well. Thanks.