Re: [PATCH] system-type cygwin with window-system w32

[Eli Zaretskii]

> Date: Mon, 18 Jul 2011 00:01:30 -0700
> From: Daniel Colascione <address@hidden>
> CC: address@hidden
> 
> > AFAICT, to_unicode encodes the file name in UTF-16.  If so, this will
> > not work in the native Windows build, because it does not use Unicode
> > APIs for file names.
> 
> Not today, no.
> 
> > In the original code, ENCODE_FILE would use the
> > ANSI encoding, not UTF-16.  So, unless I'm missing something, the
> > replacement is not equivalent to the original, and could break the
> > native build.
> 
> Yes, the change would make Emacs Unicode-only --- but every Windows OS
> in common use supports unicode.  Why would requiring unicode support be
> a problem?

Two reasons: (1) we still support running Emacs on Windows 9X, where
the Unicode file APIs are (AFAIK) not supported, even if unicows.dll
is installed; and (2) going Unicode means that all the existing APIs
used by Emacs will have to be switched to Unicode.  The latter part is
a formidable job, involving at the very least reviewing all the
file-related code in w32*.c for compatibility.  I'm quite sure a large
part of that will break, e.g. because it uses `char *' instead of
`wchar *' or TCHAR etc.  In addition, Posix-like interfaces will need
to be amended to use their wide-character counterparts, or emulated
with low-level Win32 APIs.  Non-file APIs are likely to need similar
changes as well, because file names are sometimes read or written from
and to other kinds of objects, such as the Registry.

I'm all for such a migration, but it's a very large job, and making
the change in some small part of the code will simply break Emacs,
rather than improve it.

> The change needed to be made anyway --- we need to translate between NT
> and Cygwin paths now --- so why not transition to unicode at the same
> time?

See above: it's a much larger job than that.  Witness how much time it
took Cygwin, with dedicated developers, to make this migration.