> Date: Wed, 5 Jun 2024 11:45:07 -0700 > Cc: bug-gnulib@gnu.org > From: Paul Eggert <egg...@cs.ucla.edu> > > On 2024-06-05 09:22, Bruno Haible wrote: > > > why not choose the Gnulib approach, namely to let the 'locale' > > module provide the replacement if this header file is missing? > > Because that would drag in a bunch more Gnulib modules. Eli would rather > minimize that, as he reimplements Gnulib both for ancient (so old that > Microsoft stopped supporting it many years ago) MS-Windows and for > not-so-ancient MS-Windows. Not my cup of tea, but not my decision either.
Since this was brought up (and comes up from time to time), and since Collin here is listening as well, let me explain the issues we have with Gnulib in Emacs on MS-Windows. The main point to keep in mind is that Emacs is still striving to support very old Windows systems, including Windows 9X. I know that Gnulib decided to drop support for those some time ago, and will probably drop XP as well in some not-too-distant future, but Emacs didn't and probably won't. In addition, Emacs on Windows supports accessing files whose names cannot be expressed in the current system codepage. It does that by pretending that the locale's codeset is UTF-8, and by wrapping C APIs like 'open', 'opendir', 'stat', 'rename', etc., which accept file names, with code which converts UTF-8 to UTF-16 and calls the corresponding "wide" function (like '_wopen', FindFirstFileW, etc.). Gnulib doesn't current provide this functionality. On Windows 9X Emacs loads the UNICOWS.DLL shared library at startup to be able to use some functions required for using wchar_t data type and the "wide" APIs. What this means is that Emacs cannot use any Gnulib modules that do one or more of the following: . access files passing 'char *' file names to libc functions or Win32 APIs . invoke Win32 APIs not available on Windows 9X directly by name (as opposed to checking at run time with GetProcAddress if they are available and if so, calling them through a function pointer) . use any functions that accept wchar_t arguments that are not available in UNICOWS.DLL When any of the Gnulib functions that do the above are imported into Emacs, we must disable their use in the MS-Windows build (via the OMIT_GNULIB_MODULE_* trick in gnulib.mk), and instead provide our own implementation that avoids those pitfalls. As an example, this discussion mentions _wsetlocale, which according to my records is not in UNICOWS.DLL, and so Emacs will not be able to use nstrftime if its Gnulib implementation will call that in the MinGW case. (AFAIU, this is not currently your plan, but I thought I'd mention that for you to be aware of the caveat. Currently, the MS-Windows build of Emacs does use nstrftime.c from Gnulib, and we'd prefer to keep using it.) We also sometimes provide our own implementations when we need Emacs-specific features that are not appropriate for Gnulib. A notable example of this is 'select'/'pselect' and the related 'waitpid', whose implementations are tightly coupled with what Emacs expects from sub-processes and network connections. I hope I made the situation and our logic behind it clear, but feel free to ask any followup questions, and thanks for listening.
