Does not detect virtual ports

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use VSPE to create a port splitter
2. Connect to the virtual port created
3. Enumerate ports

What is the expected output? What do you see instead?
I expect to see the virtual port enumerated, but that doesn't happen. Tera
Term and other terminal programs are capable of enumerating them.

What version of the product are you using? On what operating system?
Current hg clone (as of 08/Apr/2010), on Windows 7 32-bit.

Please provide any additional information below.
This is probably related to the method used to enumerate ports on Windows.
There are many ways to enumerate them.

Original issue reported on code.google.com by ronanpaixao@gmail.com on 9 Apr 2010 at 2:38

[GoogleCodeExporter]

The same with Null-modem emulator (http://sourceforge.net/projects/com0com/)

Original comment by Zeo...@gmail.com on 15 Jun 2010 at 10:01

[GoogleCodeExporter]

I think I might be onto something for enumerating virtual ports with com0com:

In qextserialenumerator_win.cpp I've added another GUID for enumeration (I 
found the GUID in the .inf file used when installing the virtual ports; 
oem52.inf), and then I also enumerate using the new GUID.

See attached .cpp file for details (search for Arne Kristian to see where I've 
added some code).

I'm still looking into getting better portNames etc.

Original comment by arne.kri...@gmail.com on 18 Mar 2011 at 11:57

Attachments:

• qextserialenumerator_win.cpp

[GoogleCodeExporter]

What I currently use on my apps is querying a key in the register that has the 
ports' small names (COM#), but not the full name. At least for now that's 
enough for me.

If not, maybe TeraTerm has the key, since it knows how to obtain full port 
names, but I think it uses multiple methods, including MFC classes.

Original comment by ronanpaixao@gmail.com on 18 Mar 2011 at 5:18

[GoogleCodeExporter]

I had an issue which seems similar to mentioned above:
On windows COM 13,14, 15 or all above were not working by mentioning them 
directly as "COMx" but by writing them as "\\\\.\\COMx" worked fine. hopeam not 
wrong.

Original comment by sourav.s...@gmail.com on 27 Apr 2011 at 6:28

[GoogleCodeExporter]

This solution worked great for other virtual serial ports software! Thank you 
so much! :)

Original comment by tiago.gr...@gmail.com on 6 Dec 2011 at 9:01

[GoogleCodeExporter]

Hi,

Sorry to bring this up again. I just tested device enumeration on Windows 7 
(32bit) Pro using the 1.2 Beta 2 download.
Basically, USB com posts using an FTDI chip works fine.
However, neither my modem COM port nor my Bluetooth COM ports are enumerated 
when running the enumeration example.

I figure this might be related to Issue #20, where apparently a change of GUID 
was tracked down.

My Bluetooth Adapter has
Bus Type GUID {9d7debbc-c85d-11d1-9eb4-006008c3a19a}
Device Class GUID {e0cbf06c-cd8b-4647-bb8a-263b43f0f974}

My Modem has
Bus Type GUID {bbd1a745-add6-4575-9c2e-9b428d1c3266}
Device Class GUID {4d36e96d-e325-11ce-bfc1-08002be10318}

Whereas my USB Com Port using FTDI has
Bus Type GUID {00000000-77d8-8d91-0000-0000081189a0}
Device Class GUID {4d36e978-e325-11ce-bfc1-08002be10318}

Basically, I found this 
<http://www.qtcentre.org/threads/32759-QextSerialEnumerator-can-not-get-modem-po
rt> thread, found Issue #20 and tried the proposed other GUID, but without any 
luck...

So is there still something wrong with enumeration, or might it be fixed 
already in latest trunk?

Original comment by freak...@gmail.com on 20 Oct 2012 at 11:31

[GoogleCodeExporter]

Fixed in qesp1.2 rc1

Thanks.

Original comment by dbzhang...@gmail.com on 11 Dec 2012 at 5:12

[GoogleCodeExporter]

Original comment by dbzhang...@gmail.com on 11 Dec 2012 at 5:13

• Changed state: Done

[GoogleCodeExporter]

Just found some more useful GUIDs:
    // Eltima Virtual Serial Port Driver v4 GUID
    {0xCC0EF009, 0xB820, 0x42F4, {0x95, 0xA9, 0x9B, 0xFA, 0x6A, 0x5A, 0xB7, 0xAB}},
    // Advanced Virtual COM Port GUID
    {0x9341CD95, 0x4371, 0x4A37, {0xA5, 0xAF, 0xFD, 0xB0, 0xA9, 0xD1, 0x96, 0x31}}

Original comment by AtomicHa...@gmail.com on 7 Feb 2013 at 6:10