Bug 7435 - broken system error messages in Russian on Windows
Summary: broken system error messages in Russian on Windows
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.12.0
Assignee: Alex Tanskanen
Keywords: ossman_tester, prosaic, upstream
Depends on:
Reported: 2019-11-13 12:26 CET by Pierre Ossman
Modified: 2020-06-18 10:28 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2019-11-13 12:26:37 CET
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 (�).
Comment 2 Alex Tanskanen cendio 2020-03-09 14:13:30 CET
This bug isn't only for russian but every language that is using ASCII as encoding.
Comment 3 Alex Tanskanen cendio 2020-03-09 14:24:28 CET
Once my pull request gets merged, SystemException() should be able to handle Unicode encoding. So this bug will be fixed with a vendor drop.
Comment 4 Alex Tanskanen cendio 2020-03-09 14:42:03 CET
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.
Comment 7 Alex Tanskanen cendio 2020-03-18 17:06:35 CET
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.
Comment 8 Pierre Ossman cendio 2020-03-24 09:31:15 CET
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.

Note You need to log in before you can comment on or make changes to this bug.