Re: [Emacs-diffs] master 085c7f6 2/2: Test format-time-string with zone arg

[Eli Zaretskii]

> From: Bruno Haible <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Date: Tue, 02 May 2017 23:55:50 +0200
> 
> The patch is fine with me: it has no drawbacks for other packages.

Thanks.

> However, it would be good to know what qualms you have with the msvc-nothrow
> module. Should Emacs be built with mingw, not MSVC?

Emacs dropped MSVC support a few years ago.  Only MinGW, with its 2
flavors, is currently supported, in addition to Cygwin.  Emacs might
still build with MSVC, but I don't think anyone tried in a long while,
and if they do, they will be in for a ride, because we require the
MSYS tools to run the configure script and the Makefiles.

> Is an EBADF situation never going to occur in Emacs anyway?

It can occur, but AFAIK it cannot cause an exception, since the only
supported runtime is msvcrt.dll.

> Are the portability efforts for mingw and MSVC
> in Gnulib useless for Emacs, because on native Windows Emacs uses its own 
> w32.c
> instead anyway?

Many features available from Gnulib are indeed independently
implemented in w32.c and other Windows-specific files in Emacs.  The
reasons vary -- some are of historical nature, others because the
Emacs implementations are "better" in some sense.  The support for
non-ASCII file names outside of the current system codepage is a good
example of the latter.

> Does Emacs have other requirements I don't know about?

Some.  For example, Emacs cannot use the C runtime functions that
manipulate non-ASCII characters, because those are limited to the BMP
on Windows, and don't support UTF-8.

> Eli Zaretskii wrote:
> > That "other way" is the implementation of fdutimens in Emacs's w32.c.
> > Perhaps Bruno could look at that implementation and comment on its
> > merits and demerits vs the Gnulib implementation
> 
> 1) The Emacs w32.c ports to Windows98 as well, whereas Gnulib currently 
> assumes
> Windows XP at least (and will soon move to Windows 7, I guess - namely when
> no one has a test machine with Windows XP any more). Merit or demerit? 
> Opinion?

Emacs still tries to support Windows 9X and the NT family members
older than XP, yes.  But AFAICT, the APIs used in the Gnulib
implementation of fdutimens are all supported on Windows 9X.

> 2) The Emacs w32.c has an option to use the "W" suffixed Windows APIs by 
> default.
> Clearly a merit, because it allows to use file names that are not contained in
> the "ANSI codepage". Nowadays users can use (type, display, manipulate) such
> file names in the cmd.exe windows; any program which is not on par with this
> ability is deficient.

In a GUI session, Emacs supports all the Unicode characters, so
limiting file names to the current codepage makes even less sense than
for console programs running in the cmd window.

> 3) The Emacs w32.c fdutimens function handles only 1 second resolution; the
> Gnulib fdutimens supports sub-second resolution.

I guess we should plan on reimplementing the Emacs version using the
more flexible Win32 APIs, to support sub-second resolution.

> Can you tell me how to provoke a ERROR_INVALID_DRIVE, ERROR_BAD_NETPATH, or
> ERROR_DEV_NOT_EXIST error code?

I don't remember.  It's entirely possible that I just looked at the
textual representation of these errors and matched the errno values
without actually creating the situation.

Thanks for the detailed analysis.