Re: Gmake UTF-8 Support?

[Kaz Kylheku (gmake)]

On 2021-09-30 00:37, Eli Zaretskii wrote:
> > Date: Wed, 29 Sep 2021 12:43:57 -0700
> > From: "Kaz Kylheku (gmake)" <729-670-0061@kylheku.com>
> > 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.
>
> That is simply incorrect.  The CRT functions are fully documented, and
> Microsoft at some time even published the source code of MSVCRT.DLL (I
> still have it on my machine) as part of their SDK, so this stuff is
> well documented, no secret to anyone who wants to know.

I don't have anything to add or subtract, just these remarks.

Yes, the above may have been the situation a quarter century ago,
when the library in the Windows system folder was actually a copy of
some then-current MSVC run time.

(Raymond Chen's insider article, which I already cited, explains
the whole history and the status quo. The library used in Windows
became a separately maintained fork, which was turned into a system
component which is not documented (a claim explicitly made in the
article, using that wording, pretty much!) But here, I entirely
repeat myself.)

Without a question, ancient sources and documentation from ancient
versions of the SDK will likely closely match what is in the MSVCRT.DLL
binary of old versions of Windows from around the same time.

> Ha-ha, very funny.  I guess there's then a lot of us "unprofessional"
> types that do that.  Look around for native Windows ports of GNU
> software, and you will find that they all were compiled by MinGW and
> link against MSVCRT.DLL.  Starting with Git for Windows, for example.

Yikes! I installed this on a Windows box just to take a look. Even
though Git for Windows is now based on the newer MinGW-W64, I see with
the help of the Dependency Walker utility that, indeed, this newer
incarnation of MinGW is still linking the executables to
C:\Windows\System32\MSVCRT.DLL.

I don't rely on this stuff myself, phew!

Its existence isn't so much a problem as, I suspect, that
the majority of the user base is not informed about the issue.