Enumerating devices
-
Has anyone ever used SetupDiEnumDeviceInterfaces? If so what the &%$#@ is the "CONST LPGUID InterfaceClassGuid" parameter refering to? I have tried values from the "devguid.h" but I get nothing. SetupDiGetClassDevs works with GUID_DEVCLASS_PRINTER and others like it. Has anyone ever found a generic way of enumerating devices and/or drivers on Win NT/2000. I'm just about to tear my hair out trying to find the device name for a USB printer. Why does it have to be so hard??? X| X| X|
-
Has anyone ever used SetupDiEnumDeviceInterfaces? If so what the &%$#@ is the "CONST LPGUID InterfaceClassGuid" parameter refering to? I have tried values from the "devguid.h" but I get nothing. SetupDiGetClassDevs works with GUID_DEVCLASS_PRINTER and others like it. Has anyone ever found a generic way of enumerating devices and/or drivers on Win NT/2000. I'm just about to tear my hair out trying to find the device name for a USB printer. Why does it have to be so hard??? X| X| X|
Joe Moldovan wrote: Why does it have to be so hard??? Because you are going too fast. I've had a copy of 'Programming the Windows Driver Model' for about a month now and have reached page 44. (Well, I skipped over some of the hard to remember names - ever read Dostoyevski?). You have plunged right into stuff that doesn't surface till page 62. But the key seems to be the call to SetupDiGetClassDevs. Check the docs on that. If you would like to rant together, I suggest we start by whining about the fact that once we figure this out, we'll have to find out how NT does it... sigh...
-
Has anyone ever used SetupDiEnumDeviceInterfaces? If so what the &%$#@ is the "CONST LPGUID InterfaceClassGuid" parameter refering to? I have tried values from the "devguid.h" but I get nothing. SetupDiGetClassDevs works with GUID_DEVCLASS_PRINTER and others like it. Has anyone ever found a generic way of enumerating devices and/or drivers on Win NT/2000. I'm just about to tear my hair out trying to find the device name for a USB printer. Why does it have to be so hard??? X| X| X|
Ah - this works: HOWTO: Enumerate Hardware Devices by Using SetupDi Calls (Q259695) Seems to work on NT as well - had to add the setupapi.lib to the linker settings, and, because I dropped the code into a .cpp file, cast a void * to char *.
-
Ah - this works: HOWTO: Enumerate Hardware Devices by Using SetupDi Calls (Q259695) Seems to work on NT as well - had to add the setupapi.lib to the linker settings, and, because I dropped the code into a .cpp file, cast a void * to char *.
Thanks for that. But I need the bit with "Device Instance Handle, such as the Config Manager set of API functions, can use the DevInst value in the structure SP_DEVINFO_DATA returned by the SetupDiEnumDeviceInfo function" to work. And no, this call is not documented in the DDK any better than in the MSDN! Hope you have fun persevering with the book.
-
Thanks for that. But I need the bit with "Device Instance Handle, such as the Config Manager set of API functions, can use the DevInst value in the structure SP_DEVINFO_DATA returned by the SetupDiEnumDeviceInfo function" to work. And no, this call is not documented in the DDK any better than in the MSDN! Hope you have fun persevering with the book.
Yes - I am starting to see the problem. The USB devices are layered on top of the Root USB device. They won't appear in the list the sample retrieves. I think in general the idea is that you know the name of the device you want to work with, and use the USBD_ fns or the IoBuildDeviceIoControlRequest call with the IOCTL_INTERNAL_USB_SUBMIT_URB type to get things going, and somehow identify the instance handle as a Device Extension to the USB device object. As I google and grep one eyeball is making a concerted effort to crawl into the other socket - I realize now that we're dealing with more difficult stuff than I thought, and I hate posting msgs when I just _know_ I'm dealing with forces I cannot possibly comprehend. But... One thing you might find helpful on W2K is an examination of the keys in HKLM\SYSTEM\CurrentControlSet\Enum\USB. This should contain some sort of string for the printer driver - maybe something that can be used as the Enumerator param for SetupDiGetClassDevs - do the USB devs classify as PnP? (?). I just don't see a generic USB device enumeration procedure, although some sort of use of UsbBuildGetDescriptorRequest might be able to do it. Looks like working with USB devices is worth a book on its own - the WDM book I mentioned devotes a chapter to it, but at my rate I won't get there till... lets see... the time_t bug rears its ugly head...
-
Yes - I am starting to see the problem. The USB devices are layered on top of the Root USB device. They won't appear in the list the sample retrieves. I think in general the idea is that you know the name of the device you want to work with, and use the USBD_ fns or the IoBuildDeviceIoControlRequest call with the IOCTL_INTERNAL_USB_SUBMIT_URB type to get things going, and somehow identify the instance handle as a Device Extension to the USB device object. As I google and grep one eyeball is making a concerted effort to crawl into the other socket - I realize now that we're dealing with more difficult stuff than I thought, and I hate posting msgs when I just _know_ I'm dealing with forces I cannot possibly comprehend. But... One thing you might find helpful on W2K is an examination of the keys in HKLM\SYSTEM\CurrentControlSet\Enum\USB. This should contain some sort of string for the printer driver - maybe something that can be used as the Enumerator param for SetupDiGetClassDevs - do the USB devs classify as PnP? (?). I just don't see a generic USB device enumeration procedure, although some sort of use of UsbBuildGetDescriptorRequest might be able to do it. Looks like working with USB devices is worth a book on its own - the WDM book I mentioned devotes a chapter to it, but at my rate I won't get there till... lets see... the time_t bug rears its ugly head...
For someone who says he doesn't know much you sure know a lot more about this stuff than me! Thank you for your very helpful tips. The whole device/driver architecture/interface from MS is absolutely shocking. I have spent THREE whole days trying to do something which is trivial (send a "keep alive" null message every 5 minutes to a USB POS printer, an insignificant task for LPT1: or PRN: ) and I'm still scratching my head. But I did manage to answer the original question about SetupDiEnumDeviceInterfaces() parameters. To help others struggling with this stuff, the "Pointer to a GUID that specifies the device interface class for the requested interface" mentioned in the ISDN, can be found in HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses. MS does not want us to access these directly but I have found no other way. NOTE that there are a set of GUIDS which are the SETUP classes and are given in devguid.h. They won't work with this call but can be used in SetupDiGetClassDevs etc. as selectors for restricting the device data. I am going to use IOCTL as per your suggestion. Who knows! In another ten years or so I might even understand all this.
-
For someone who says he doesn't know much you sure know a lot more about this stuff than me! Thank you for your very helpful tips. The whole device/driver architecture/interface from MS is absolutely shocking. I have spent THREE whole days trying to do something which is trivial (send a "keep alive" null message every 5 minutes to a USB POS printer, an insignificant task for LPT1: or PRN: ) and I'm still scratching my head. But I did manage to answer the original question about SetupDiEnumDeviceInterfaces() parameters. To help others struggling with this stuff, the "Pointer to a GUID that specifies the device interface class for the requested interface" mentioned in the ISDN, can be found in HKLM\SYSTEM\CurrentControlSet\Control\DeviceClasses. MS does not want us to access these directly but I have found no other way. NOTE that there are a set of GUIDS which are the SETUP classes and are given in devguid.h. They won't work with this call but can be used in SetupDiGetClassDevs etc. as selectors for restricting the device data. I am going to use IOCTL as per your suggestion. Who knows! In another ten years or so I might even understand all this.
Cool. I have printer off a copy of your reply which I hope I will understand someday. Maybe you could resurrect this thread when you get things going - I'd be interested - my post was more of a 'well maybe its got something to do with' attempt than anything else. Glad it helped! What a neat site.
-
Cool. I have printer off a copy of your reply which I hope I will understand someday. Maybe you could resurrect this thread when you get things going - I'd be interested - my post was more of a 'well maybe its got something to do with' attempt than anything else. Glad it helped! What a neat site.
I have solved my original problem. I will post a solution as a new thread because it has some very interesting implications for direct access to devices. As I suspected, the solution is grotesque but works very well.