On Fri Jul 4 10:14:40 2025 +0000, Rémi Bernon wrote:
I think there's two approaches there, depending on the answer to the question "Do we really need to implement the async/callback version of this API?".
- No: then you don't need all this.
- Yes: then I'd suggest to start implementing it first, and change the
bit of code that's already there before adding more code for properties, so that you don't have to undo all the synchronous code you just added to implement the asynchronous one. Same thing for the tests, you can probably write helpers to test the async API and use them for the sync API, rather than the other way around which requires undoing/moving all the code into helpers after you added it. Also note that if this is only meant to be used internally, then for future-proofness and performance considerations, implementing only the callback version might be a smarter choice. This would make the implementation of the sync API later fairly easy but you don't need to bother with it now.
Both the "async" and sync versions of this method use the callback. The `DevQueryFlagAsyncClose` flag only modifies how `DevCloseObjectQuery` behaves:
* When present, `DevCloseObjectQuery` will asynchronously send a `DevQueryStateClosed` event to the callback, and free the query handle once the callback has been invoked. * Otherwise, `DevCloseObjectQuery` waits until all queued callbacks have been dispatched, and then frees the handle.
Re`DevQueryFlagsAsyncClose` being needed, as `HDEVQUERY` is meant to be the backend for `Windows.Devices.Enumeration.DeviceWatcher`, we forward the `DevQueryStateClosed` event to the `Stopped` handlers registered with the `DeviceWatcher` object. The associated code for that is available in my branch [here](https://gitlab.winehq.org/vibhavp/wine/-/commit/fa776e677c3595162be943ae893f...).
I'd suggest to start implementing it first, and change the bit of code that's already there before adding more code for properties, so that you don't have to undo all the synchronous code you just added to implement the asynchronous one. Same thing for the tests, you can probably write helpers to test the async API and use them for the sync API, rather than the other way around which requires undoing/moving all the code into helpers after you added it.
Yes, that would make the commits a little more readable. I have tried to organize the commits a little more cleanly in the latest revision. Thanks.