I have noticed that the GetComPortNames function returns a different list of Com port names to that shown by Device Manager. By searching the Registry, it would seem that Device Manager shows the list maintained by Bluetooth if installed, if not it shows the list from Local_Machine\Hardware. GetComPortNames however always works from the Hardware list.
Is there any particular reason for this difference? Is it significant to the way a program should work or what ports are available?
David.
The current code will show the list of regular COM ports retrieved from the registry. I'm not sure why you see Bluetooth ports in a different way. Did you install a proper COM port driver for the Bluetooth device? Do you see the Bluetooth ports in a program like Hyperterminal?
Hi Bruno,
I have looked at 2 different PCs, one Desktop without Bluetooth and one Laptop with Bluetooth. The bluetooth was not built -in but a USB dongle added after purchase. I can't remember if the drivers were added from a CD or auto installed. The OS is Vista x64 in both cases.
On the desktop all lists of ports are the same and match that in RegEdit: computer\HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM.
On the laptop, the list in Device manager is the same as that in the Bluetooth section of the Registry (computer\HKEY_CURRENT_USER\Software\Toshiba\BluetoothStack\V1.0\LocalCOM), 11 items
The list of ports returned by VaComm is the same as that in the HARDWARE section of the Registry (computer\HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM), 28 items.
The Bluetooth items in this list have a Registry name \Device\porteXX with Data of COMXX, the other items are named \Device\VComXX for Data COMXX. In once case the Name is \Device\SmSrl with Data COM3
The VaComm list is the same as that returned by a Terminal program (Real Term)
David.
Hi Bruno,
I am afraid this question remains open... I have done some more research on it. I uninstalled the Bluetooth stack on the laptop and some of the 'extra' ports disappeared, but not all of them. Device Manager now reports just one port (COM3) while GetComPortNames reports 15 (4, 5, 8, 9, 15, 16, 17, 18, 19, 23, 24, 25, 26, 27 + 3). I found a short blog on a similar situation which in their case was blamed on a "Nokia Communications Framework" and the Windows Mobile SDK.
I have also had complaints from customers which seem to point to similar situations on their PCs.
The bottom line seems to be that the GetComPortNames function can return a different list to that in the Device Manager. This then makes it possible to try to select a com port that does not exist. Though this is not a good situation I will admit that it is not an Async32 only problem. All programs return the long list, it is only Device Manager that does not (the blog mentioned the same on that PC).
It's unclear what different APIs might have to be used to display the list of devices in Device Manager versus the API we're using now. We've added it on the todolist for deeper investigation.