Hi Bruno,

I have a few updates on this topic.

First, a couple weeks ago I posted a message[1] on mingw-w64 list which 
summarizes behavior and formats supported by CRT's [_w]setlocale functions. I 
don't know if gnulib attempts to support anything other than msvcrt.dll and 
UCRT, but there may be some useful points if you want to support pre-Windows 
2000 versions of msvcrt.dll and pre-msvcrt.dll CRTs: crtdll.dll, 
msvcrt{10,20,40}.dll.

Second, I have mentioned that I was working on an implementation, and a few 
days ago I finally uploaded the library to GitHub. The library is still to be 
considered WIP, but what it provides should be working as expected (with C, at 
least). Since I mentioned using _configthreadlocale as a way to implement 
uselocale and friends, you may want to take a look at library's locale.c[2], 
which implements locale.h functions.

I take my words back about _configthreadlocale making it easier to implement 
uselocale. Juggling _configthreadlocale around with [_w]setlocale (which is 
used to set both global and thread locales) makes things only harder. *sigh*

There is also locale_string.c[3] which implements logic to format locale 
strings which are passed to CRT's [_w]setlocale/_[w]create_locale functions. 
This is what some information in [1] is based on.

The library is under Apache-2.0 license, so I assume it should not be an issue 
if you decide to copy/adapt some if its code to gnulib.

- Kirill Makurin

[1] https://sourceforge.net/p/mingw-w64/mailman/message/59266372/
[2] 
https://github.com/maiddaisuki/posix32/blob/master/lib/posix32-crt/src/locale/locale.c
[3] 
https://github.com/maiddaisuki/posix32/blob/master/lib/posix32-crt/src/locale/locale_string.c
________________________________
From: Bruno Haible <[email protected]>
Sent: Thursday, September 18, 2025 4:32 PM
To: Kirill Makurin <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: native Windows locale topics

Kirill Makurin wrote:
> _configthreadlocale only affects the thread-locale setting of the thread that 
> calls it. It does not affect all threads in the process.

Ah really? That isn't clear to me from the documentation.
Have you tested it?
(I have not tested it; I have only read the documentation.)

Bruno



Reply via email to