From unknown Fri Mar 29 16:00:26 2024 X-Loop: owner@bugs.x2go.org Subject: Bug#566: [X2Go-Dev] Bug#566: X2Go Client for Windows 4.0.2.1 cannot create C:\Users\\ssh\known_hosts file when the local Windows account username has non-Ascii characters Reply-To: "George Trakatelis" , 566@bugs.x2go.org Resent-From: "George Trakatelis" Resent-To: x2go-dev@lists.x2go.org Resent-CC: X2Go Developers X-Loop: owner@bugs.x2go.org Resent-Date: Mon, 15 Sep 2014 05:30:01 +0000 Resent-Message-ID: Resent-Sender: owner@bugs.x2go.org X-X2Go-PR-Message: followup 566 X-X2Go-PR-Package: x2goclient X-X2Go-PR-Keywords: Received: via spool by 566-submit@bugs.x2go.org id=B566.141075880627962 (code B ref 566); Mon, 15 Sep 2014 05:30:01 +0000 Received: (at 566) by bugs.x2go.org; 15 Sep 2014 05:26:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=no version=3.3.2 Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 2CF5D5DB54 for <566@bugs.x2go.org>; Mon, 15 Sep 2014 07:26:45 +0200 (CEST) Received: by mail-wg0-f46.google.com with SMTP id n12so3297285wgh.5 for <566@bugs.x2go.org>; Sun, 14 Sep 2014 22:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uom.edu.gr; s=google; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=GwA8kb8U7yYec1YJTYXAfCnzwRhG00DnhFGWYGFfthg=; b=Yoi4BAqIVJVJsZcAsIahBvqLAq1swZSMjddr1oYnijtB/rUgog/wv1d59kmgQQzF9K uYT/evCcdeSP1bX91wzJ+IcT7oNVHAm/sKZW2IYQs/3illhbkCGtgFP4ulX0ozjdIgPx UqXTVKg8XGTqvHuny9g/z0uNBZFrVV583WooU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=GwA8kb8U7yYec1YJTYXAfCnzwRhG00DnhFGWYGFfthg=; b=SHwTbFifGU2XVbzoHDkyfVhHKjtfYr3d7nEWXn89Tg1S6A9/2dPCNeED6OkYDrr42y lGzFfnbiEYWcvja6Np/p3eY+B7e5AfP+KO/by43lkduXvQ3P06Owj4q/6v+8WFDAuvf9 XhHp1b/5hf9zrkIrktkw+aW1p/k1Ia8it+E/BZiRMLTnhTdTuTIQZx7TPcEoci7JAuow LF9NGjfD4HgVqarAopUddQVLn8UBr57sLJDuelEbQRUKfg6LSALkDq0wV3k/czz/xmv6 0fXMoDAPXQd0EOZAvwq6l6pVfAAlhk6LwailO324yr+hIq9ojWwsd6+kQx+0ZomTisyH LBLA== X-Gm-Message-State: ALoCoQkc8wrkYWlZUMbtKGWG6kUb06VqffuPpGlw3fwQAN8dEEqy/rNg7Kgp/IWzNWPQgJdcPf5w X-Received: by 10.180.20.40 with SMTP id k8mr20732140wie.54.1410758804733; Sun, 14 Sep 2014 22:26:44 -0700 (PDT) Received: from HomePC (46-4-59.adsl.cyta.gr. [46.103.4.59]) by mx.google.com with ESMTPSA id cy10sm13473117wjb.21.2014.09.14.22.26.43 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Sep 2014 22:26:44 -0700 (PDT) From: "George Trakatelis" To: <566@bugs.x2go.org> Cc: "'Michael DePaulo'" References: <000001cfb552$3193a8a0$94baf9e0$@gr> <000001cfc60a$32831de0$978959a0$@gr> <20140901195103.Horde.HOAd34FDzvE7MwwNBCtaAg1@mail.das-netzwerkteam.de> <000001cfca83$2b11d830$81358890$@edu.gr> <20140908085833.Horde.1KVN9LjgQ3GOkz4EX-JZjA1@mail.das-netzwerkteam.de> In-Reply-To: Date: Mon, 15 Sep 2014 08:26:40 +0300 Message-ID: <000001cfd0a5$a1fe42d0$e5fac870$@edu.gr> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/MMC6jHzgvB33DQx6TGc5i6muTwgEbj8hw Content-Language: el 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(),=20 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=20 "Language for non-Unicode programs" to that particular foreign language. -George -----Original Message----- From: Michael DePaulo [mailto:mikedep333@gmail.com]=20 Sent: Tuesday, September 9, 2014 4:16 PM To: 566@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\\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=3D-municode CMAKE_MODULE_LINKER_FLAGS:STRING=3D-municode CMAKE_SHARED_LINKER_FLAGS:STRING=3D-municode CMAKE_STATIC_LINKER_FLAGS:STRING=3D-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