[X2Go-Dev] Bug#566: 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

[Michael DePaulo]

Control: severity 566 grave

Dear George,

Thank you for your research.

Over the next day or so, I will apply bug566.test.v2.patch, which will
then be included in both the MinGW 4.4 and the MinGW 4.8 nightly
builds. Once you (or someone else) confirms that the patch fixes this
bug for said installations, I will mark this bug as fixed. I've
already cloned this bug. The clone will be for handling languages
other than the "Language for non-Unicode programs"; i.e., using
Unicode.

I am marking this original bug as severity "grave" because it "makes
the package in question unusable or mostly so"[1] for a significant
number of users. Getting this original bug fixed for x2goclient
4.0.3.0 will be a high priority for me.

Also, I tried to shorten the title of this bug (and correct a typo:
cannon -> cannot) but I ran into a bug with the debbugs software. I'm
trying to correct the title.

-Mike

[1] http://bugs.x2go.org/Developer.html#severities

On Mon, Sep 15, 2014 at 1:26 AM, George Trakatelis
<trakatelis at uom.edu.gr> wrote:
> 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:mikedep333 at gmail.com]
> Sent: Tuesday, September 9, 2014 4:16 PM
> To: 566 at bugs.x2go.org
> 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
>