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

[Laimonas Vėbra]

Eli Zaretskii wrote:
> > Date: Fri, 23 Jul 2010 15:57:46 +0300
> > From: Laimonas Vėbra<laimonas.vebra@gmail.com>
> > CC: 6705@debbugs.gnu.org
> >
> > It's not the problem to pass utf-8 arguments to natvive (mingw)
> > apps.
>
> If these MinGW applications use Unicode (UTF-16) APIs, that's true.
> But if they use the ANSI APIs (and most of them do), then you simply
> cannot pass to them command-line arguments encoded in any encoding
> other than the current codepage.

It's not true when we're launching subprocess using CreateProcessA()
and passing args to it, i.e. like Emacs does). Try:

#include <stdio.h>
int main (int argc, char ** argv) {
        printf("argv[1]: %s\n", argv[1]);
        return 0;
}

gcc.EXE (GCC) 3.4.5 (mingw-vista special r3)

gcc -o test test.c

M-x grep
test.exe "ĔĿİ" > out.txt

$ cat out.txt
argv[1]: ĔĿİ


> In my view, users of the w32 build of Emacs who use Cygwin tools
> outside Emacs are a minority.  There are native w32 ports of most of
> the tools you have in Cygwin, and there is the Cygwin build of Emacs.
> I don't see why the handful of Emacs developers who contribute to the
> w32 port should invest a significant part of their scarce resources on

bzr log says that much of the active development of the w32proc.c and 
others actually ended somewhere in the 2001-2003... ;-)
On the other hand -- why when you think w32 developers should invest 
their time developing w32 stuff at all (if we have cygwin build which 
works „pretty well“)...?

> fixing incompatibilities between the w32 Emacs and Cygwin, when a
> Cygwin build of Emacs is available and works pretty well, judging by
> the few of its users who are active on the emacs-devel list.  I don't

Are they using it in unicode aspect/context? It's the most important 
question, because many people don't get any problems if their are not 
dealing with unicode (or at first/least with non english 
ansi/multilingual aspects).


> know why you say it's "potentially" more buggy -- it uses mostly the
> same code that runs on GNU/Linux, so actually it should be _less_
> buggy than the native w32 build, because it is used by a larger number
> of users.  Did you even try to switch to the Cygwin build?  If not,
> perhaps you should.

Same question -- why when bother with w32 development at all?