Hello, I would like to share some updates if anyone here is interested in using this library.
On Wednesday, December 17, 2025 1:09 AM I wrote: > I have mentioned a few times that I've been working on a library which > implements POSIX functions for native Windows. A few days ago I got it to the > point when I felt confident enough to publish it in its current state: > > https://github.com/maiddaisuki/posix32 > > Here's a summary of what the library currently implements (mostly > locale-related stuff): > > - locale.h functions > - langinfo.h (nl_langinfo function) > - ctype.h and wctype.h functions > - string.h functions and their wchar.h equivalents > - strings.h functions (str[n]casecmp) and their wchar.h equivalents > - uchar.h functions (including c8rtomb/mbrtoc8, with both MSCVRT and UCRT) > - stdlib.h/wchar.h C89/C95 conversion functions > > Notably, it still does not implement: > > - stdlib.h string-to-number conversion functions (which are locale-dependent) > - time.h functions (strftime/wcsftime, tzset) > - stdio.h functions and their wchar.h equivalents The following are the goals I'm currently working on. 1. Using dynamic lookups Currently, the library uses _WIN32_WINNT for conditional code compilation. For example, this influences which Win32 locale APIs are used - `LCID` locales or locale names which were introduced in Windows Vista. As the result of this, for example, configuring with UCRT for Windows XP will result in always using only `LCID` APIs; this still provides decent locale support when running on any later Windows version, but it prevents applications from setting locales which cannot be represented by `LCID` mechanism. I'm working on adopting the library to use dynamic lookups and choosing most appropriate implementation at runtime. Once finished, configuring posix32 with UCRT for Windows XP will use `LCID` locales when running on Windows XP and locale names on any later version. On the other hand, configuring with UCRT for Windows Vista and later will only use locale names. 2. Porting back to Windows NT 3.1 I'm working on changes which would allow to build posix32 to run on Windows versions as old as NT 3.1; using dynamic lookups is part of this work. Since initial goal was to support at least Windows XP, the library is using APIs which may not be available before Windows XP, these include: - It calls `HeapSetInformation`, which is available since Windows XP, to create low-fragmentation heaps for internal usage. - `GEOID` APIs, which are available since Windows ME and Windows XP. The library does not currently call `GetGeoInfo`, but it obtains `GEOID` objects. - Calendar APIs, which are available since Windows 98 and Windows 2000. Most importantly, `GetCalendarInfo` function which is used to obtain locale information for LC_TIME locale category. Most, but not all of this information can be obtained using `GetLocaleInfo` function. - `GetLocaleInfo` only supports `LOCALE_RETURN_NUMBER` since Windows 98 and Windows NT 4.0. This constant allows to obtain locale information for `LOCALE_I*` constants as a `DWORD` value instead of a string. For Windows versions which do not support it, the obtained string has to be converted to a number by the caller. - `AreFileApisANSI` and friends, which are available in all Win9x and since Windows NT 3.5. It is used to determine code page used by ANSI versions of Windows functions which return/accept file names. 3. Maybe porting to Win9x The main challenge is that Win9x (95/98/ME) systems lack Unicode support ("Unicode" -W versions of functions); they are present in system DLLs but always fail. This makes functions such as `strcasecmp` and `strcoll` properly functional only as long as they contain characters which can be represented by locale's default ANSI code page. For most locales this is an SBCS code page with up to 256 assigned code points. 4. Providing UTF-8 supports for pre-XP systems The library implements its own UTF-8 conversion functions, which are independent of Win32's `WideCharToMultiByte` and `MultiByteToWideChar`; this will allow to create `locale_t` with UTF-8 on all systems supported by posix32. As mentioned, Win9x systems lack Unicode support which makes UTF-8 locale support, other that character conversions and basic string operations, very limited. 5. Static mingw-w64 code in a separate DLL When the library is configured with mingw-w64 (it supports mingw-w64 and MSVC as build environments), it will create an extra DLL which contains mingw-w64's static functions. Since posix32 is configured to work with a specific CRT, this DLL also contains only static mingw-w64 code which is used with that specific CRT. This DLL has several important usages: First, this allows to not link the same static code in multiple images, reducing overall size. Second, posix32's DLLs export functions with their "posix32" names and standard names; for example, it exports both posix32's `p32_setlocale` and standard `setlocale` as an alias for `p32_setlocale`. Static mingw-w64 code may behave in unexpected way if it end up using posix32's functions instead of CRT's ones; having it in a separate DLL ensures that it always references CRT's version of those functions. Note that this DLL will contain only replacements/emulations for CRT functions and will not include POSIX/GNU extensions and ANSI stdio functions provided by mingw-w64; those are to be provided by posix32 itself. I wonder if it would be useful to have such DLLs as a separate project, which could also include mingw-w64 extensions mentioned in the previous paragraph. - Kirill Makurin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
