On Mon Jun 9 15:01:13 2025 +0000, Vibhav Pant wrote:
Why do you think this is required? Is it possible we need to use API
like DevCreateObjectQuery instead? Methods in `DeviceInformationStatics` like `FindAllAsyncAqsFilter` take an additional AQS filter string, which still needs to be parsed in order to create a `DEVPROP_FILTER_EXPRESSION` to pass to `DevCreateObjectQuery` in the first place.
Also using COM-activated objects from another library is questionable.
`INetworkListManager`<span dir="">, a classic COM object activated from </span>`netprofm.dll`<span dir="">, gets used to implement </span>`Windows.Networking.Connectivity.ConnectionProfile`<span dir=""> </span>[here](https://gitlab.winehq.org/wine/wine/-/blob/3295365ba5654d6ff2da37c1ffa84aed8...)<span dir="">. Admittedly, there isn't a lot of WinRT code in Wine, and I'm not very familiar with the rules for writing it, outside of what the </span>[wiki says](https://gitlab.winehq.org/wine/wine/-/wikis/Wine-Developer%27s-Guide/WinRT-i...)<span dir="">.</span>
According to https://windows10dll.nirsoft.net/windows_devices_enumeration_dll.html `windows.devices.enumeration` seems to implement the AQS parsing itself, and exports `AqsFreeDevQueryFilter` and `AqsToDevQueryFilter`, which although undocumented seem closer to be some kind of adapters to what `DevCreateObjectQUery` would take as input than the interfaces that you can get out of `structuredquery.dll`.
It would also seem possible to then implement `structuredquery.dll` using these parsing functions, rather than the other way around, or just share the parser sources through Wine PARENTSRC, if we ever need to implement `structuredquery.dll`.