Please do not use the registry on Windows if not explicitly selected to use that.

[xanderberkhout]

I saw that you are using the registry in version 2.8.5. Is that really what you want? My testers get all kinds of popups asking if it is save to use the registry editor or something like this. I think an application can use the registry, but a library should not do that and for sure not change that behaviour in a patch.

I think there are also too many patches in a short time. Every four days on average. That does not give a feeling of stability. For beta versions or release candidates I understand that, but once released. I was already surprised about the quick release after you absence.

The 2.8.5 more looks like a concept change (shouldn't it be 2.9?) than just a patch:

• Remove all FTDI native driver calls to FT_Open, FT_Close, FT_GetComPort, and FT_SetDriverLatency on Windows
• Update FTDI enumeration using registry keys directly on Windows
• Search for serial modem devices in addition to plain serial devices on Windows
• Set FTDI latency using the registry on Windows (requires admin first time)

Is there a way to turn off using the registry? I think I will stick with 2.8.4 for now.

[hedgecrw]

Regarding version numbering, the patch numbers in this library are used to indicate updates to existing functionality which do not change compatibility or add functionality from any other releases with the same minor version. In other words, if a user is using v2.8.5 right now, they should be able to drop-in replace it with 2.8.X without causing their own application code to require any rewriting. Since 2.8.5 meets this criteria, it does not get a minor version number bump.

Regarding the frequency of patches, I am far less concerned about the appearance of instability than I am about ensuring that the library functions as expected for the largest number of users. If someone opens an issue that is quickly fixable/addressable, then I will release that change as soon as it is tested to get it in peoples' hands as quickly as possible. I don't subscribe to the time-based release cycle (especially for an open-source convenience library like this), since it forces people to work around known bugs for longer than necessary.

Regarding use of the registry, I do 100% agree with you that it's not a very appealing solution, and I was hesitant to go that route. Unfortunately, the FTDI drivers are just not very stabile, and their use in this project has continued to introduce subtle, non-fixable issues for several users over the years. The biggest problem here is that FTDI devices have a built-in latency timer with a default value of 16 ms which causes all sorts of timing issues for serial port reading depending on the frequency of incoming data. Without use of the FTDI drivers, there doesn't appear to be any way to change that value without using the registry (that I could find). Moreover, using the direct drivers to set the latency (which requires fully opening and closing a device using that driver) does not work on all devices, because some devices revert to their registry-based settings after the FTDI-direct driver closes the port.

The only workaround I can think of right now (which I also don't love) would be to create a new method that specifically allows the library to request elevated privileges when opening. Thoughts?

[xanderberkhout]

Unfortunately, the FTDI drivers are just not very stabile, and their use in this project has continued to introduce subtle, non-fixable issues for several users over the years.

I am using the D2XX direct drivers via JNI when using an FTDI device so I need jSerialComm for the other serial ports (such as the ones from Silabs and the real RS232 ports). I have no specific issue with them. So what is the problem with 2.8.4 that you fixed in 2.8.5 exactly. I would prefer the native calls over the registry ones.

Nevertheless I am still waiting for FTDI to release a VCP or D2XX driver for Windows on ARM. Silabs already has a VCP driver and I am using Windows 11 on Arm on my new MacBook M1 Pro.

[hedgecrw]

The specific problem from 2.8.4 was Issue #393 whereby use of the direct drivers caused the user's computer to experience widespread USB issues outside of just the serial device they were trying to control. An additional issue that I found during that exploration was that some FTDI devices reset their latency timer back to the default value after the port is closed, so when I re-opened the port to use the Virtual COM Port drivers, the setting was simply reverted. FTDI themselves say that the only way to configure the latency timer when not using the FTDI direct drivers is through the registry, which is why I went that route.

I'm planning to make it so that, by default, the registry will remain untouched, but I will provide a method to allow a user's application to request the registry change themselves. I will also update the documentation explaining how an end-user can achieve the same result manually through use of either the registry or the Device Manager.

[hedgecrw]

Closing as resolved with today's release of v2.9.0. By default, nothing with elevated permissions is required. If the user wants to explicitly allow changing settings that require elevated permissions, they can call the new allowElevatedPermissionsRequest() method before opening the port. The Javadocs have been updated about usage of this function.