0

I'm trying to port code from SetupAPI to cfgmgr32, since Microsoft now recommends this, and I do the following query:

SetupDiGetClassDevsExA(&GUID_DEVINTERFACE_COMPORT, nullptr, nullptr, DIGCF_PRESENT | DIGCF_DEVICEINTERFACE, nullptr, nullptr, nullptr)

to find all devices that support the COMPORT interface class. I'm trying to implement something similar using the cfgmgr32 API.

CM_Get_Device_ID_ListA does not seem to have a way to specify a filter based on supported interfaces.

CM_Get_Device_Interface_ListA gives me a list of interfaces instead of instances or device ids. I could get an instance id from the interface using CM_Get_Device_Interface_Property except that for some reason there's only a CM_Get_Device_Interface_PropertyW version and no CM_Get_Device_Interface_PropertyA version, and that would require translating everything to use wide characters, which would incur a bunch of conversions, because this needs to interface with code that only uses narrow characters (ASCII/utf-8).

Is there a better way to accomplish something equivalent?

KitsuneSan
  • 39
  • 3
  • why you use `A` version of api ? always use `W` version – RbMm Dec 20 '21 at 18:23
  • @RbMm Several reasons: 1. This is part of a cross-platform component, and non-Windows platforms almost universally use narrow encodings, so the API has to use them and I don't want to keep converting back and forth between encodings. 2. The Windows software this component will integrate with uses `A` APIs (legacy software) 3. Recently, Microsoft has started [recommending](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page) using `A` APIs with UTF-8 codepage – KitsuneSan Dec 20 '21 at 18:50
  • you can write wrapper over `CM_Get_Device_Interface_PropertyW` - convert by self input string (*pszDeviceInterface*) to unicode, and convert return string to ansi. however all existng *A* versions *CM_* api do the same - convert input ansi to unicode, call *W* version and convert result back to *A*. better anyway use anywhere *W* version and only convert results to ansi at outer edge – RbMm Dec 20 '21 at 19:25
  • if you will use *A* version - you on every call will be convert input to unicode and output to ansi (by self or by system). if separate logic for work with *CM* - only final results you need be convert to ansi once. in all internal/intermediate calls better use unicode – RbMm Dec 20 '21 at 19:35
  • @RbMm OK, after some experimenting, you're correct. In fact it doesn't seem to work correctly if I mix calls. There must be internal state that's stored associated with the instance, because if I mix `A` and `W` functions, it appears some of the `A` functions return wide Unicode strings anyhow. I guess I just need to use `WideCharToMultiByte` to convert my strings to UTF-8 on the API surface. – KitsuneSan Dec 21 '21 at 18:06

0 Answers0