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

From: Eli Zaretskii <[email-masked]>
Date: Fri, 23 Jul 2010 21:06:01 +0300

> Date: Fri, 23 Jul 2010 18:35:40 +0300
> From: Laimonas Vėbra <[email-masked]>
> CC: [email-masked]
> 
> M-x grep
> test.exe "ĔĿİ" > out.txt
> 
> $ cat out.txt
> argv[1]: ĔĿİ

And what does that prove, exactly?  That MinGW programs can support
non-ASCII characters?  I never said they didn't.

> bzr log says that much of the active development of the w32proc.c and 
> others actually ended somewhere in the 2001-2003... ;-)

So what?

> 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“)...?

For the users who use Emacs in conjunction with native w32 programs.
Not every Windows program is necessarily available in Cygwin, you
know.  If you need to use Emacs in a non-Cygwin environment, the
native build will fit much better.

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

I don't know; why won't you ask on emacs-devel?

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

See above: same answer.