Implement support for Windows

[ezramorris]

There is keen interest in having Windows support, so this Python module can work cross-platform.

In #3, I determined the best course of action was to use com0com, and write a Python wrapper for it.

Once written, we can provide implementations for Windows and *nix, with auto-detection in place.

[Robolightning]

Are you planning to implement full-fledged bindings to COM0COM or work through subprocess with its exe via console commands?

[ezramorris]

CLI is the only documented interface unfortunately

[Robolightning]

CLI is the only documented interface unfortunately

There is also the source code :)

[Robolightning]

CLI is the only documented interface unfortunately

I'm currently writing a Python package for direct access to com0com. Would you use it when I'm finished?
I think it might take another 1-2 days, but all I have to do now is format the code and test everything again. Everything works so far. I'm communicating with the DLL via ctypes.

[ezramorris]

I'm currently writing a Python package for direct access to com0com. Would you use it when I'm finished? I think it might take another 1-2 days, but all I have to do now is format the code and test everything again. Everything works so far. I'm communicating with the DLL via ctypes.

Yes please, would love to have a look when you're done.

[ezramorris]

There are a couple more considerations I would need to take before using that option.

com0com is GPL2, and my understanding of it means that even when dynamically linking, you would need to release your code as GPL2, and so would I. Whereas calling through subprocess I wouldn't. I'm not a huge fan of GPL for libraries, and this is already licensed under MIT, so I would have to consider whether a license change was worth it.

Secondly, as far as I'm aware, the DLL is undocumented, therefore it would be considered an implementation detail, which could change in future com0com releases. That said, I think this point is fairly insignificant, since the last release was 7 years ago...

[Robolightning]

There are a couple more considerations I would need to take before using that option.

com0com is GPL2, and my understanding of it means that even when dynamically linking, you would need to release your code as GPL2, and so would I. Whereas calling through subprocess I wouldn't. I'm not a huge fan of GPL for libraries, and this is already licensed under MIT, so I would have to consider whether a license change was worth it.

Secondly, as far as I'm aware, the DLL is undocumented, therefore it would be considered an implementation detail, which could change in future com0com releases. That said, I think this point is fairly insignificant, since the last release was 7 years ago...

Okay, then I'll create a separate private package. I was thinking about using this library, but I decided to write my own

[ezramorris]

@Robolightning, I did read your deleted comment and look at your previously published package.

I was working on a generic com0com wrapper (https://github.com/ezramorris/pycom0com) but I do think your implementation is better as a general com0com wrapper, and do not see value in continuing to develop mine if you will release yours. If you think be useful for others (I do), you should release it, not just for this project's benefit.

As for this package, as mentioned I need to weigh up using your library vs direct call via subprocess. It's not necessarily a "no", but I need to consider the pros and cons (licensing, dependencies, reliability etc.).

Your deleted comment questioned whether there was a difference between license conditions for calling via subprocess, my understanding is based on this: https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#MereAggregation i.e. I would not be distributing com0com but rather calling it on the same computer.

[jacopoabramo]

I'm interested in this feature as well. @Robolightning FYI, in the past I attempted to use COM0COM locally with my own implementation of a serial package and I found out that to make it properly work it actually requires to manually install a driver update on Windows 10/11, otherwise any serial port created from COM0COM won't be detected (this is visible by simply inspecting the device manager). I've been trying to figure out a way to automate the installation on a CI/CD workflow but the tricky part is the driver update - maybe you'll have more luck than I had in figuring that out.

EDIT: I would also be interested in having a look at @Robolightning wrapper for COM0COM, will you be able to make it public soon?

[Robolightning]

I just decided to make the repository (pycom0com) private for our team.
I originally thought I'd make it public, as I was hoping it would become part of this virtual ports library, but honestly, after reviewing the current library's code, I realized it would be easier for me to completely rewrite it for our team, which is what I did.
So, I'll keep my library private for our team only. I apologize for any confusion and inconvenience.