Re: Gmake UTF-8 Support?

[Kaz Kylheku (gmake)]

On 2021-09-29 11:34, Eli Zaretskii wrote:
> > Date: Wed, 29 Sep 2021 11:15:40 -0700
> > From: "Kaz Kylheku (gmake)" <729-670-0061@kylheku.com>
> > Cc: nobozo@gmail.com, help-make@gnu.org
> >
> > > Cygwin is not MS-Windows, it provides a rich layer of Posix
> > > functionality, including UTF-8 support, above Windows. Try the native
> > > Windows build of GNU Make instead.
> >
> > Which build is this?
>
> The one produced by build_w32.bat.
>
> > > Because Cygwin converts UTF-8 into UTF-18, the so-called "Unicode
> > > encoding" that is native to MS-Windows.  It's an illusion.
> >
> > Well, yes; it's the run-time library doing the right thing with
> > UTF-8 in path names in file-related functions.
>
> Yes, but which run-time library?  Cygwin adds a special, very large,
> run-time library on top of the C runtime that comes with Windows.

[Hopefully, I have all the straight dope here; bear with me.]

Cygwin isn't on top of any other C run-time; it is based on something
called Newlib: a BSD-licensed library. (Google's Bionic is based on
Newlib, I think; or so I guessed when looking at some of the sources
at one point.)

No C run time for application use comes with Windows; only operating
API DLL's like kernel32, user32, ...

Windows provides no stdio, no malloc, nothing: or none that are
documented for developers to use.

> > Every program on Windows must bring its own run-time library;
> > Windows doesn't provide one.
>
> That's incorrect.  Windows does provide a stock runtime library, it's
> called MSVCRT.DLL.

Right, but that is undocumented for application use which makes it
de facto off limits to anyone who knows what's good for them.

It's a C library that some programs that are part of Microsoft Windows
use.

See here: https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273

If you link to this, you're sticking a fork into Windows.

No professional grade application for Windows should be doing this,
so for most practical purposes, it should be regarded as nonexistent.

> > Different libraries have different
> > capabilities. For instance, programs compiled with Microsoft tools 
> > carry
> > the MSVC redistributable run-time DLL (or else have it statically
> > linked).
>
> The redistributables only add newer functions above the default, so
> that your program could run on older versions of Windows and still use
> functions added in later versions.

The redistributable run-time from Microsoft Visual C is a complete,
self-contained library. It's own malloc, stdio, and everything else;
it does not rely on the MSVCRT.DLL in the system folder.

> > However, a port of GNU Make using that particular run-time would be
> > GPL-violating, so we may safely regard that as not existing.>
> Which is why ports of GNU software to native MS-Windows, in particular
> those using the MinGW development environment, link only against

Programs built using that environment do this; not those which are
part of that environment.

The MinGW make and shell themselves link to something called MSYS.DLL.

What is that? It's a fork of an ancient version of Cygwin!

(Therefore, it's possible that UTF-8 might work with the MinGW make,
but I have no desire to  blow the dust off that obsolete cruft to
test this. It perhaps depends on how good the UTF-8 support
was in the old version of Cygwin from which it was forked, and
whether that support was preserved in the fork.)

(Speaking of Cygwin and MinGW: Cygwin has MinGW compilers as a
package. If you think building programs in the MinGW way is
a good idea, you can use Cygwin for that: just install the MinGW
compiler package(s) and refer to those. You will have a much
better environment with more up-to-date tools, for which it is
much easier to build new tools.)

> MSVCRT.DLL, which is part of the OS and thus does not cause violation
> of the GPL.

While that is true, it causes a violation of your contract with
MS Windows.

There is no documented requirement anywhere about what is in this
library, or what will be in it in the next version of Windows, or
whether it will exist at all, under what name, with what calling
conventions, etc.