Subject: Bug#566: [X2Go-Dev] Bug#566: X2Go Client for Windows 4.0.2.1 cannot create C:\Users\<username>\ssh\known_hosts file when the local Windows account username has non-Ascii characters

From: "George Trakatelis" <[email-masked]>
Date: Mon, 15 Sep 2014 08:26:40 +0300

Dear Mike,

I have built libssh 0.6.3 in Visual Studio 2013 (with UNICODE and _UNICODE defined in all projects)
and debugged a tiny test app with function calls analogous to those used in x2goclient.
I'm afraid preprocessor definitions are not enough to make an application/program/library support Unicode.
One could migrate existing programs following a list of guidelines

http://msdn.microsoft.com/en-us/library/cc194801.aspx

For example, a function that fails in libssh (used in ssh_path_expand_tilde(), 
which is always called to replace a ~ with the actual home folder path in a string) is strdup.
To make libssh unicode-friendly strdup has to be replaced by _strdup

http://msdn.microsoft.com/en-us/library/y471khhc.aspx

_strdup would benefit from preprocessor definitions for Unicode support
as it would be converted to the proper Unicode function.

Imho, the only option for now is patch "bug566.test.v2.patch"
as it corrects the problem in the vast majority of Windows installations.
Remember that foreign Windows installations set by default the 
"Language for non-Unicode programs" to that particular foreign language.

-George

-----Original Message-----
From: Michael DePaulo [mailto:[email-masked]] 
Sent: Tuesday, September 9, 2014 4:16 PM
To: [email-masked]
Cc: George Trakatelis; Mike Gabriel
Subject: Re: [X2Go-Dev] Bug#566: X2Go Client for Windows 4.0.2.1 cannot create C:\Users\<username>\ssh\known_hosts file when the local Windows account username has non-Ascii characters

[...]

Hi Mike#1 and George,

1.

I believe the best approach is to try to compile libssh with unicode support, and pass unicode values to it. There is no guarantee that a user's username (and home dir path) is in the same language as the language that is set for non-Unicode programs. After all, the "Language for non-Unicode programs" is called the "system locale", it applies to all users on the system.

If we have to for the 4.0.3.0 release of x2goclient, we should fix this bug for the system locale only, and then fix the bug for all languages/locales later.

2.

See bug 474 for George's patch for compiling libssh with MinGW 4.8.2.
It worked :)

3.

I made some progress compiling libssh 0.6.3 with Unicode support.

With MinGW 4.4, when I specified the following values in CMAKE, libssh built successfully, but it did not seem to change anything.
CMAKE_EXE_LINKER_FLAGS:STRING=-municode
CMAKE_MODULE_LINKER_FLAGS:STRING=-municode
CMAKE_SHARED_LINKER_FLAGS:STRING=-municode
CMAKE_STATIC_LINKER_FLAGS:STRING=-municode

With MinGW 4.8.2, when I specify those values, libssh fails to build.
I've attached the output.

This is a positive sign because it implies that MinGW 4.8.2 supports -municode, whereas MinGW 4.4 did not.

I plan to try to resolve this build failure later tonight.

-Mike#2