For a simpler proposal (and one that will take less time running the tests, although I don't know how much that's a concern since I don't have immediate access to a machine that doesn't skip) how about we just tests the flag one at a time?
The tests will only query cached Bluetooth devices (unless winetest_interactive is set, at which point an actual discovery is performed), so these tests don't take more than a second or two.
Fair enough. I think it's still a bit simpler, mind, since you don't need that get_nth_lookup_flags() helper.
On what platforms does this happen?
WSALookupServiceBegin can fail with the error code WSASERVICE_NOT_FOUND if no devices are found.
Thanks. Can you add a comment to this effect please?
Those flags aren't Bluetooth-specific. Also, what's that union for?
I have replaced it with a `lookup_devices` flag instead.
That's not quite what I was saying though. The flag still isn't Bluetooth-specific but you've just changed its form. Rather I was suggesting to store the flags outside the union, in the ws_lookup_service_ctx structure.
Basically, `WSALookupService` can be used to perform either device or service discovery, controlled by the existence of the `LUP_CONTAINERS` flag. The union only has a single member as of now, but will also have a `ws_query_bth_services` struct once support for service discovery is added as well.
If you don't specify either flag, what happens? The documentation looks like both things are returned.
How many other places are you planning to use this function? The callback design looks kind of excessive for how much it's actually doing...
The other place would be for performing service discovery locally. The idea is that we need to go through all radios to collect which SDP records have been registered for each one.
If it's only two I'd kinda be inclined to not use the callback, but I can't say I feel that strongly about it.