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/3295365ba5654d6ff2da37c1ffa84aed81291fc1/dlls/windows.networking.connectivity/network_information.c#L437)<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's-Guide/WinRT-in-Wine)<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`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6788#note_105997