DividedByZero said:
I am working with multiple Com ports and I was hoping to query the serial numbers or Vendor ID's (or similar) to determine what com port I want to deal with.
You would likely need to be developing at the USB host controller extension level, or at a similar driver level. See https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/building-usb-devices-for-windows for a bunch of resources.
That information usually isn't available at other levels in the chain.
DividedByZero said:
I could set up some sort of packet send/respond type handshake, but it doesn't seem ideal to send data to potentially unknown devices. Any advice would be greatly appreciated.
Correct, it is quite the wrong level you're talking about. It isn't ideal, and isn't directly allowed in user-space. That type of interface doesn't really exist elsewhere, since each one is bridging the gap between different levels of interfaces.
The question is mostly about the actual level you want to interface with.
If you're really looking at hardware-style interfaces where you are directly on the hardware, these days that is directly inside the kernel. If you were operating at that level you'd be looking at the assembly level of CPU instructions to in / out of ports and DMA to the device's bound memory, that's a thing programmers thankfully have moved away from for about 30 years. Instead there are people who write the hardware libraries and they provide a generic USB interface. If you're writing at this level you'd be pretty deep inside the OS kernel, which for Windows means either working at Microsoft or working at a company licensed through the Shared Source Initiative. If you want to look at the Linux version, or other operating systems, that source is freely available.
That level provides an interface to the kernel, which works based on vendor and product ID codes. At this level you have a list of information that describes the USB device, the Vendor ID and Product ID. For example you might register as handling VID 0x57E (Nintendo's ID), PID 0x306, which is the combination for a Nintendo Wii controller. Or you might register as handling VID 0x0x46D (Logitech's ID), PID 0x0x80F, the combination for a Logitech Webcam C120.
That's also the level that provides OS hardware descriptors, USB containers, and drivers. On Windows there are USB drivers at the kernel mode (KMDF) and in user mode (UMDF). At this level usually they implement some other interfaces that bridge the gap between hardware access and software access, such as implementing access through a virtual com port, or a HID interface like saying the device is a keyboard or mouse, or an audio device like a WaveRT interface, or a video interface like like a VCD provider, or whatever bridges the gap. That might be the level you're interested in.
Finally there's the level of the application a user runs, which connects to the drivers and follows a chain of interfaces and drivers that reference drivers that reference drivers until you hit the actual hardware. At the application level the actual hardware is completely abstracted away. Instead at this level you ask the OS for access to a specific interface, or to list all the interfaces of a type. For example, you might ask the OS for a list of all video media devices, which would include your USB cameras, but also any cameras connected through other methods that implement the interface.
But getting back up, probably the host controller driver extensions system is the only level that enumerates them the way you described.
