apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)
Date Mon, 26 Dec 2016 18:16:50 GMT
Unfortunately Windows doesn't in any sensible way... AFAIK and please
correct me if I'm wrong, there is still no strateful/resumable stream
oriented win32 charset conversion API.

The Apr ucs2 utf8 logic is used for speed because it happens so often.
Slower alternatives always existed in the win32 API.

And of course with FnA() it was always fun speculating if that call used
OEM CP or locale CP. :)



On Dec 24, 2016 02:52, "Branko ─îibej" <brane@apache.org> wrote:

> On 22.12.2016 18:21, William A Rowe Jr wrote:
> > What I'd like us to consider is to rip out all FooFnA() ASCII calls, and
> > shift entirely to the Unicode mapping, perhaps with some support of
> > alternate operating charsets for the non-httpd consumer. Would like to
> hear
> > of folks deliberately building the ANSI flavor of APR on modern OS's and
> > see if we can address any concerns.
>
> I have always assumed that APR's "internal" encoding on Windows is
> UTF-8, and that on any less than decrepit version of Windows it always
> calls the FooFnU() variants directly. I'd hate to see these assumptions
> broken, if only because Subversion would fall flat on its face. :)
>
> In other words, +1 to making APR 2.0 talk to Windows only in UTF-16-LE.
>
> Apropos, I believe said less than decrepit versions of Windows know how
> to convert to and from UTF-8, so we may find that misc/win32/utf8.c is
> no longer needed.
>
> -- Brane
>
>

Mime
View raw message