Improve Windows port string parsing to prevent "R"-style ports

[PropGit]

It has been noted that on Windows computers with an "Intel(R)... "-based COM port, the port is listed as simply "R" instead of "COM#". This appears to be because the parsing mechanism is just grabbing whatever string appears within parentheses (and there's a pair in parentheses near the front of the string that is found first) and is assuming that it contains the friendly name for the port.

Must fix this.

The parsing mechanism should:

1. Determine if it's running on a Windows computer, and if so...
2. Do a reverse search looking for "(COM" followed immediately by at least one numeric digit
   • If the above is found, extract starting from "COM" and up to the first non-numeric digit or end of string.
   • Return the extracted string as the port name
   • If the reverse search fails, skip the port (don't add anything to the list).

[dbetz]

How do I reproduce this? I've never seen this. Are you saying you see this if you type "proploader -P"?

[PropGit]

Yes, proploader -P reports "R" as one of the COM ports on this Windows machine that has an Intel-based USB port.

The Windows system lists the port as something like: "Intel(R) blah blah blah (COM1)"

I've seen this before, many years ago, and wrote an algorithm similar to that listed in the first post to solve it in old software.

This only applies to Windows, as Linux/Mac report the /dev/... string rather than any branded names+port mix.

Windows serial ports are always in the form COM# and the pattern always seems to be listed in parentheses near or at the end of the string.

[dbetz]

Okay, thanks. I'll try to duplicate it on one of my machines.

[dbetz]

I modified the code to look for the final '(' instead of the first one. This should work with the string that was causing this problem. If for some reason there are other variants I can add the code described above to look for "(COMn".

[PropGit]

Tested on the known-bad machine. Works properly! We'll stick with this solution for now unless we find other cases where it doesn't work.

[PropGit]

Tested v1.0-32 on known-bad machine. Still works great!