It seems there is something wrong with our handling of system error message (strerror() and such) on Windows. On a Russian system something gets garbled and we get mess like this:
> 2019-11-13T11:06:51: vncviewer[E]: CConn: unable connect to socket: Òðåáóåìûé àäðåñ äëÿ ñâîåãî êîíòåêñòà
The graphical dialog only shows the unicode replacement character (�).
This bug isn't only for russian but every language that is using ASCII as encoding.
Once my pull request gets merged, SystemException() should be able to handle Unicode encoding. So this bug will be fixed with a vendor drop.
I found a very similar bug to strerror() but with gai_strerror() for Exception() instead of SystemException().
For example if you tried to connect to a unknown host name on a Russian system, the exception that is thrown just prints unreadable text. On Windows we need to explicitly tell functions to use wide chars which, unlike chars, can handle Unicode characters.
gai_strerrorW() seems to solve this problem.
Fixed in upstream:
I tested this in the tlclient but I wasn't able to get the same socket error (10049) as the customer got. But I did, however, get another socket error (10061) by connection to the same server with the same user simultaneously.
The socket error message for 10061 was translated and displayed Unicode characters. The problem is that this error code among others were hard coded in English before fix, so it was impossible to get a translated Unicode message for 10061.
From my judgement this issue is resolved since at least one error message displays Unicode.
Seems to work well. Tested by having a manipulated tlclient.bin/tlclient.exe that sent bogus addresses to vncviewer.
I verified that 4.11.0 had the issue. I then tested a nightly build and saw proper error messages both for name lookup (non existant host) and connect (no route to host). Log file was also properly using UTF-8.
Lastly I verified the same thing on Linux to make sure there were no regressions there.