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

[Eli Zaretskii]

> Date: Thu, 22 Jul 2010 23:59:09 +0300
> From: Laimonas Vėbra <laimonas.vebra@gmail.com>
> CC: 6705@debbugs.gnu.org
> 
> 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;

I don't doubt that you checked, I just don't understand the
description of the problem.

Once again, if all you want to say is that you want to invoke external
programs with command-line arguments encoded in anything other than
the current locale's encoding, then this will not currently work in
the native Windows build.  But if you are trying to say anything else,
please elaborate.

> 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?

Yes.

> What part of the explanation of the corrupted conversion is unclear

None of it.  Perhaps instead of going by example, just describe what
encoding you used, in what Emacs command, and what was corrupted as
result.

> >    . 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...

I didn't try to imply that Cygwin was the problem.  I was suggesting
to use the Cygwin build of Emacs.  Why do you insist on using the
native w32 build, when it is obvious that the compatibility between
what it does and what Cygwin expects is marginal at best?

> 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().

Yes.  But it doesn't make sense to do this kind of surgery in Emacs
without benefiting from the *W APIs all over, does it?