On 2024-12-24 Bruno Haible wrote:
> Lasse Collin wrote:
> > (1)
> > In 9f7ff4f423cd ("localename-unsafe: Support the UTF-8 environment
> > on native Windows."), the N(name) macro is used with strings that
> > include @modifier. For example, N("az_AZ@cyrillic") can expand to
> > "az...@cyrillic.utf-8". Similarly in 00211fc69c92 ("setlocale:
> > Support the UTF-8 environment on native Windows."), ".65001" is
> > appended after the @modifier. However, the typical order would be
> > az_AZ.UTF-8@cyrillic.
>
> Good point. Fixed through the patch below.
Thanks. Isn't there a similar issue in setlocale.c after the commit
00211fc69c92?
/* llCC_buf now contains
language[_territory][@modifier]
*/
if (strcmp (llCC_buf, locale) != 0)
{
if (is_utf8)
{
char buf[64+6];
strcpy (buf, llCC_buf);
strcat (buf, ".65001");
result = setlocale (category, buf);
}
else
result = setlocale (category, llCC_buf);
> > I suppose you had a reason to use .65001 instead of .UTF-8 or .utf8.
> > I expect identical behavior from those.
>
> Yes: There was some period (ca. 5 years ago) when Windows supported
> the .65001 suffix but not the .utf8 suffix. The ability to use .utf8
> to denote code page 65001 was added a bit later.
[...]
> Yeah, the docs don't tell you everything (as usual with Microsoft).
Makes sense. Thanks for the explanation.
> > (2)
> > In 2f4391fde862 ("setlocale tests: Test in the UTF-8 environment on
> > native Windows."), the condition
> >
> > (strlen (name) > 6 && strcmp (name + strlen (name) - 6,
> > ".UTF-8") == 0)
> >
> > matches the two long strings below it too, making those two extra
> > strcmp calls redundant.
>
> Correct. Still, it's useful to have a writedown of what the output in
> the legacy mode is. (Unit test code is not optimized for performance.)
I agree it's a fine way to document things. It could be useful to have
a comment saying that those conditions are there for documentation
purposes.
> > (3)
> > When a manifest is added via a resource file, a possible default
> > manifest from the toolchain is replaced; they aren't merged. For
> > example, on MSYS2, the mingw-w64-ucrt-x86_64-gcc package depends on
> > mingw-w64-ucrt-x86_64-windows-default-manifest. The manifest comes
> > from Cygwin:
> >
> >
> > https://sourceware.org/git/?p=cygwin-apps/windows-default-manifest.git;a=blob;f=default-manifest.rc
> >
> > Omitting the <compatibility> section makes the application run with
> > Vista as the Operating System Context. Omitting the <trustInfo>
> > section makes Windows treat the application as not UAC compliant,
> > that is, a pre-Vista app that needs compatibility tricks.
> >
> > Probably these don't matter with the current tests. I suggest
> > changing it still because it's still an odd combination to have
> > UTF-8 without marking the app compatible with recent Windows
> > versions.
>
> I picked the smallest XML file that has the desired effect.
>
> Also, I don't like enumerating Windows versions in this way because
> it's not future-proof: Since Windows 11, 12, 13, etc. are not listed,
> it would only be matter of time until the test breaks in a new Windows
> version.
It's only a test program which doesn't affect the binaries being
installed. As long as it works for testing I guess it's fine enough.
One clarification though: If one omits <compatibility>, Win10 behaves
as if you had put only Vista compatibility in the manifest: Task
Manager shows Vista as the Operating System Context for the program.
That is, one is sort of requesting "emulation" of Vista in that case.
There is no separate entry for Windows 11 because Windows 10 and 11 use
the same entry. What will happen with Win12 is unknown, of course.
> > (4)
> > The output from windres goes to a file with the .res suffix but the
> > format is overridden with --output-format=coff. This looks weird
> > because windres defaults to --output-format=res for files that use
> > the .res suffix. For coff, the .o suffix would be logical, and
> > --output-format option wouldn't be needed.
>
> Maybe it looks weird, but IIRC it's the best way that I found that
> does not run into 32-bit / 64-bit problems. For example, if 'windres'
> is 64-bit but I'm compiling with a 32-bit targetting gcc. (Some
> toolchain installations have a <triple>-windres program, but some
> other toolchain installations have only one windres program for all
> targets.)
OK. It was only the .res suffix that looked weird because windres
already recognizes .res for a different file format than COFF.
--
Lasse Collin
