(Follow up from !6788)
The goal is to use the device object API as the backend for Windows.Devices.Enumeration, as most concepts from the latter have a one-to-one mapping to the former:
* The device object API is centred around the [`DEV_OBJECT`](https://learn.microsoft.com/en-us/windows/win32/api/devquerydef/ns-devquerydef-dev_object) type, which provides a unified representation for devnodes, device interfaces/containers, device interface classes, and association endpoints (networking protocols and service instances, like UPnP and Bluetooth), together with the properties associated with it. The [`DevObjectType`](https://learn.microsoft.com/en-us/windows/win32/api/devquerydef/ne-devquerydef-dev_object_type) enum maps to [`Windows.Devices.Enumeration.DeviceInformationKind`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformationkind?view=winrt-26100). This would be used to implement the [`DeviceInformation`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation?view=winrt-26100) class.
* [`DEVPROP_FILTER_EXPRESSION`](https://learn.microsoft.com/en-us/windows/win32/api/devfiltertypes/ns-devfiltertypes-devprop_filter_expression) allows filtering device queries by their properties. AQS filter strings would be parsed into an array of filters, which are then passed to the query object methods.
* `DevCreateObjectQuery` would be the backend for `DeviceWatcher`, as it provides asynchronous callbacks for initial device enumeration, device addition, removal and updates.
* [`DevGetObjects`](https://learn.microsoft.com/en-us/windows/win32/api/devquery/nf-devquery-devgetobjects) would be used to implement the `FindAllAsync*` methods.
This MR adds a basic implementation and tests for `DevGetObjects`.
--
v10: cfgmgr32: Add a basic implementation for DevGetObjects(Ex) for device interface objects.
cfgmgr32/test: Add tests for DevGetObjects.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8438
On Mon Jun 30 13:17:18 2025 +0000, Rémi Bernon wrote:
> 77622615b657feedfb379f51346b4d05a2cbd0c4 still fails with:
> ```
> cfgmgr32.c:561: Test succeeded inside todo block: got len 0
> cfgmgr32.c:562: Test succeeded inside todo block: got objects 0000000000000000
> cfgmgr32.c:566: Test succeeded inside todo block: got len 0
> cfgmgr32.c:567: Test succeeded inside todo block: got objects 0000000000000000
> ```
Apologies, I forgot to run final tests on this commit. Should be fixed now, thanks. Since the returned code in these two cases is `S_OK`, I have set both `len` and `objects` to dummy values to test whether they are correct set to zero/NULL respectively.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8438#note_108361
I'm dealing with a game that relies on this constant.
Tagging @rbernon since this is using a proton commit of his.
Tests should be run both with HKCU\\Software\\Wine\\MediaFoundation\\DisableGstByteStreamHandler enabled and disabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8183
Always copying client class name to temporary buffer, to which version string also points to, in order to convert integral class names to string and unify the logic for versioning later on.
--
v2: user32: Always copy class names to a temporary buffer.
comctl32: Fix class name case in manifest.
user32: Move get_class_version out of get_class_info.
user32: Load class module in get_class_version.
user32: Move user32_module default out of get_class_info.
user32: Init class name outside of get_versioned_name.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8358
77622615b657feedfb379f51346b4d05a2cbd0c4 still fails with:
```
cfgmgr32.c:561: Test succeeded inside todo block: got len 0
cfgmgr32.c:562: Test succeeded inside todo block: got objects 0000000000000000
cfgmgr32.c:566: Test succeeded inside todo block: got len 0
cfgmgr32.c:567: Test succeeded inside todo block: got objects 0000000000000000
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8438#note_108344