GNU bug report logs - #6705
w32 cmdproxy.c pass args to cygwin; erroneous charset conversion (problem description, solution/suggestion)

Previous Next

Full log

Message #14 received at 6705 <at> debbugs.gnu.org (full text, mbox):

From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6705 <at> debbugs.gnu.org
Subject: Re: bug#6705: w32 cmdproxy.c pass args to cygwin;	erroneous charset
	conversion (problem description,	solution/suggestion)
Date: Thu, 22 Jul 2010 23:59:09 +0300

Eli Zaretskii wrote:

> Sorry, I cannot understand your comments.  You talk about corrupted
> conversion, but never add any detailed explanations, just examples.
> Could you please elaborate?

That was supposed to be detailed explanations through the detailed 
examples. It is the way it happens. I did check/investigate; args that 
comes from Emacs (w32proc.c) #1, which are passed to cmdproxy #2 and -- 
after all -- what subprocess/app receives #3. Have you read that 
explanation? What part of the explanation of the corrupted conversion is 
unclear (i'll try to explain; sorry, my english is not so fluent)?

>
>    . did you try setting up your Windows to use the UTF-8 codepage
>      65001?

Well, i could switch to Linux instead...
(it is definitely not the solution or at least the same "solution" as 
not to use unicode at all; windows locale settings is what it is set (be 
it Lithuanian, Cyrillic, Italian, whatever) and is not going to be 
changed nor it needs to be for the correct behavior.

>
>    . since Cygwin 1.7 switched to using UTF-8, it parted itself even
>      further from native Windows applications, so you now have one more
>      reason to use the Cygwin build of Emacs instead of the native one

Well ok, but it (cygwin) work pretty well under/with utf-16 API layer...
(IMHO it's not the problem)

> The Windows build of Emacs doesn't yet use the UTF-16 APIs.  Doing
> that is a large job; volunteers are welcome, of course.  However,

In the context of external communication with cygwin -- it doesn't need 
to use (everywhere), but it needs to convert its output to utf-16 
explicitly and call CreateProcessW().

mingw and (possibly) other applications receives args (main(): **argv, 
GetCommanLineA()) unchanged (the same as they were passed from Emacs).
So, it (passing arguments in whatever encoding, except utf-16 and 
others, with NULL values) just works without any changes.

cygwin applications, on the other hand, receives unchanged arguments 
only through WINAPI GetCommandLineA (which is almost never used...); 
**argv args are transcoded as i explained.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.