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.
On what platforms does this happen?
WSALookupServiceBegin can fail with the error code WSASERVICE_NOT_FOUND if no devices are found.
On which platforms do the different errors appear?
WSAEFAULT is expected at least once, so that we can resize the buffer appropriately. I'll remove `WSA_E_NO_MORE`, but it's supposed to be returned by some older versions of Winsock, though I haven't been able to find one that does.
Those flags aren't Bluetooth-specific. Also, what's that union for?
I have replaced it with a `lookup_devices` flag instead. 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.
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.
Does native touch the buffer at all if the size is insufficient? This isn't tested.
I wrote a bit of code to test this, and Windows doesn't seem to modify the buffer if it's not appropriately sized. I'll simplify the code and try adding a test case for this, thanks.