Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[William A Rowe Jr]

On Thu, Dec 29, 2016 at 9:34 AM, Branko Čibej  wrote:
> On 26.12.2016 19:16, William A Rowe Jr wrote:
>> 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.
>
> Ah indeed; not that I'm aware of.
>
>> The Apr ucs2 utf8 logic is used for speed because it happens so often.
>> Slower alternatives always existed in the win32 API.
>
> Win9x and NT at least up to 4 did not have a UTF-8 "codepage".

That was also true, I think all supported flavors, including Server 2008
are now all supporting 65001.

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[Branko Čibej]

On 26.12.2016 19:16, William A Rowe Jr wrote:
> 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.

Ah indeed; not that I'm aware of.

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

Win9x and NT at least up to 4 did not have a UTF-8 "codepage".

> 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"  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
>>
>>

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[William A Rowe Jr]

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"  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
>
>

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[Branko Čibej]

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

RE: Supported Windows versions for APR 2.0 (was Re: [PATCH]Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[bert]

I miss the very popular Windows 7 in this list. (And Windows 8 R2, but Ivan 
already added that one)

Bert
(Sorry for the html mail and top posting)
From: William A Rowe Jr
Sent: donderdag 22 december 2016 18:21
To: Steffen
Cc: APR Developer List
Subject: Re: Supported Windows versions for APR 2.0 (was Re: 
[PATCH]Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

On Thu, Dec 22, 2016 at 3:13 AM, Steffen <i...@apachelounge.com> wrote:
Below is stated:  .. to make Windows Vista/Server 2008 minimum supported...

But.. Windows Embedded POSReady 2009 (It is basically XP SP 3) has updates till 
May 2019.

That one doesn't matter to us, any embedded software vendor can continue to 
patch APR 1.x forever if they like. We have no reason to support this as a 
volunteer-driven charitable software project.

Just to summarize MS dates;

* Windows XP was EOL Apr '09, entirely out of support Apr '14
* Windows 8 was EOL Oct '12, entirely out of support Jan '16
* Windows Vista is EOL since Apr '14, Extended support ends Apr '17
* Windows 8.1 EOL Jan '18, Extended ending Jan '23

* Server 2003 was EOL Jul '10, entirely out of support July '15.
* Server 2008 is EOL since Jan '15, Extended support ends Jan '20
* Server 2012 is supported EOL Jan '18, Extended ending Jan '23
* Server 2016 is supported

* CE 6.0/Embedded 8.1/Embedded 6.5 EOL Jun '18/Jun '19/Jan '20
  AIUI there is no 'Windows' thing replacing them in this space?

The concept behind extended support is *not* provisioning brand new software, 
there is no new IIS available to already beyond EOL versions of Windows during 
their extended support period. Extended support is the hobble-along period for 
commercial users who aren't in a position to migrate software. In other words, 
not targets for any enhancements.

>From an APR 1.x perspective, we should keep alive any functionality that 
>exists today, and retire functionality we don't want as of APR 2.0. I see us 
>offering some security and bug fix patches to APR 1.x for quite a while after 
>the release of APR 2.0. I'd simply expect new APR 1.next minor releases to 
>fall off in favor of emphasizing APR 2.0 and encouraging rapid adoption.

For APR 2.0 perspective, that means ending everything other than Windows Server 
2016, Windows Server 2012, Windows 10 and Windows 8.1 support.

It is debatable whether we should actively support Server 2008 with the next 
major version of APR; if it doesn't hurt us to support it, fine. But if there 
are 2008 API quirks that make this impractical, we should avoid explicitly 
targeting it in this next major version. Even if we had APR 2.0 ready in 
January, Vista would be off the radar by April anyways. Why would anyone be 
doing new deployment to Vista? That would be foolish.

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.


--- Original message --- 
Subject: Supported Windows versions for APR 2.0 (was Re: [PATCH] 
Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows) 
From: Ivan Zhakov <i...@visualsvn.com> 
To: William A Rowe Jr <wr...@rowe-clan.net> 
Cc: APR Developer List <dev@apr.apache.org> 
Date: Tuesday, 20/12/2016 08:59

On 19 December 2016 at 06:45, William A Rowe Jr <wr...@rowe-clan.net> wrote:

On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov <i...@visualsvn.com> wrote:


On 17 December 2016 at 21:47, William A Rowe Jr <wr...@rowe-clan.net>
wrote:


As 1.6 is unreleased, whatever goes in trunk that does -not- break
backwards
binary compat can go right into 1.6 as well.
The problem that currently it's very hard to find minimum Windows
version that support particural API, because MSDN lists Windows XP as
minimum version for almost all APIs. Even for function that existed in
Windows 4.0. See GetProcAddress() for example [1]

As far I understand minimum supported Windows for APR 1.6.x is Windows
95. Is it correct? Anyway I don't have even Windows NT 4.0 test
environment. Even more: Windows 95, 98, NT 4.0 and 2000 is cannot be
legally downloaded due Java settlement [2].

[1]
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/subscriptions/ff723773.aspx


Because Microsoft no longer issues security patches to NT 4 or Win9x
or even Windows 2000 or 2003 and now - even XP, the httpd project's
perspective is that connecting these machines to the internet is very
unwise, and no further httpd support should be directed to those OS
revisions. This eliminates the ANSI/8-bit-only APIs, and lets us put all
attention and effort and FooFunctionW() wide-char equivalents.
Agree. Btw VisualSVN Server dropped support for Windows older than
Vista/Server 2008 in September 2014.

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[Ivan Zhakov]

On 22 December 2016 at 20:21, William A Rowe Jr  wrote:
> On Thu, Dec 22, 2016 at 3:13 AM, Steffen  wrote:
>>
>> Below is stated:  .. to make Windows Vista/Server 2008 minimum
>> supported...
>>
>> But.. Windows Embedded POSReady 2009 (It is basically XP SP 3) has updates
>> till May 2019.
>
>
> That one doesn't matter to us, any embedded software vendor can continue to
> patch APR 1.x forever if they like. We have no reason to support this as a
> volunteer-driven charitable software project.
>
> Just to summarize MS dates;
>
> * Windows XP was EOL Apr '09, entirely out of support Apr '14
> * Windows 8 was EOL Oct '12, entirely out of support Jan '16
> * Windows Vista is EOL since Apr '14, Extended support ends Apr '17
> * Windows 8.1 EOL Jan '18, Extended ending Jan '23
>
> * Server 2003 was EOL Jul '10, entirely out of support July '15.
> * Server 2008 is EOL since Jan '15, Extended support ends Jan '20
> * Server 2012 is supported EOL Jan '18, Extended ending Jan '23
> * Server 2016 is supported
>
> * CE 6.0/Embedded 8.1/Embedded 6.5 EOL Jun '18/Jun '19/Jan '20
>   AIUI there is no 'Windows' thing replacing them in this space?
>
> The concept behind extended support is *not* provisioning brand new
> software, there is no new IIS available to already beyond EOL versions of
> Windows during their extended support period. Extended support is the
> hobble-along period for commercial users who aren't in a position to migrate
> software. In other words, not targets for any enhancements.
As far I understand MS provides security fixes for all customers when
OS in extended support state. They just stop providing bug fixes for
ordinary customers.

> From an APR 1.x perspective, we should keep alive any functionality that
> exists today, and retire functionality we don't want as of APR 2.0. I see us
> offering some security and bug fix patches to APR 1.x for quite a while
> after the release of APR 2.0. I'd simply expect new APR 1.next minor
> releases to fall off in favor of emphasizing APR 2.0 and encouraging rapid
> adoption.
>
> For APR 2.0 perspective, that means ending everything other than Windows
> Server 2016, Windows Server 2012, Windows 10 and Windows 8.1 support.
>
> It is debatable whether we should actively support Server 2008 with the next
> major version of APR; if it doesn't hurt us to support it, fine. But if
> there are 2008 API quirks that make this impractical, we should avoid
> explicitly targeting it in this next major version. Even if we had APR 2.0
> ready in January, Vista would be off the radar by April anyways. Why would
> anyone be doing new deployment to Vista? That would be foolish.
>
Sure, Vista usage is declining, but Windows Server 2008 R2 is actively
used in production. It's standard option in many virtual hosting
providers and there are still reasons to use WS 2008 R2: it's very
stable and proven.

> What I'd like us to consider is to rip out all FooFnA() ASCII calls, and
> shift entirely to the Unicode mapping, [..]
I'm +1 to move APR to Unicode only and remove FooFnA() calls.

> 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.
>

-- 
Ivan Zhakov

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[William A Rowe Jr]

On Thu, Dec 22, 2016 at 3:13 AM, Steffen <i...@apachelounge.com> wrote:

> Below is stated:  .. to make Windows Vista/Server 2008 minimum
> supported...
>
> But.. Windows Embedded POSReady 2009 (It is basically XP SP 3) has
> updates till May 2019.
>

That one doesn't matter to us, any embedded software vendor can continue to
patch APR 1.x forever if they like. We have no reason to support this as a
volunteer-driven charitable software project.

Just to summarize MS dates;

* Windows XP was EOL Apr '09, entirely out of support Apr '14
* Windows 8 was EOL Oct '12, entirely out of support Jan '16
* Windows Vista is EOL since Apr '14, Extended support ends Apr '17
* Windows 8.1 EOL Jan '18, Extended ending Jan '23

* Server 2003 was EOL Jul '10, entirely out of support July '15.
* Server 2008 is EOL since Jan '15, Extended support ends Jan '20
* Server 2012 is supported EOL Jan '18, Extended ending Jan '23
* Server 2016 is supported

* CE 6.0/Embedded 8.1/Embedded 6.5 EOL Jun '18/Jun '19/Jan '20
  AIUI there is no 'Windows' thing replacing them in this space?

The concept behind extended support is *not* provisioning brand new
software, there is no new IIS available to already beyond EOL versions of
Windows during their extended support period. Extended support is the
hobble-along period for commercial users who aren't in a position to
migrate software. In other words, not targets for any enhancements.

>From an APR 1.x perspective, we should keep alive any functionality that
exists today, and retire functionality we don't want as of APR 2.0. I see
us offering some security and bug fix patches to APR 1.x for quite a while
after the release of APR 2.0. I'd simply expect new APR 1.next minor
releases to fall off in favor of emphasizing APR 2.0 and encouraging rapid
adoption.

For APR 2.0 perspective, that means ending everything other than Windows
Server 2016, Windows Server 2012, Windows 10 and Windows 8.1 support.

It is debatable whether we should actively support Server 2008 with the
next major version of APR; if it doesn't hurt us to support it, fine. But
if there are 2008 API quirks that make this impractical, we should avoid
explicitly targeting it in this next major version. Even if we had APR 2.0
ready in January, Vista would be off the radar by April anyways. Why would
anyone be doing new deployment to Vista? That would be foolish.

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.


--- Original message ---
> *Subject:* Supported Windows versions for APR 2.0 (was Re: [PATCH]
> Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)
> *From:* Ivan Zhakov <i...@visualsvn.com>
> *To:* William A Rowe Jr <wr...@rowe-clan.net>
> *Cc:* APR Developer List <dev@apr.apache.org>
> *Date:* Tuesday, 20/12/2016 08:59
>
> On 19 December 2016 at 06:45, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
> On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
>
>
> On 17 December 2016 at 21:47, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>
> As 1.6 is unreleased, whatever goes in trunk that does -not- break
> backwards
> binary compat can go right into 1.6 as well.
>
> The problem that currently it's very hard to find minimum Windows
> version that support particural API, because MSDN lists Windows XP as
> minimum version for almost all APIs. Even for function that existed in
> Windows 4.0. See GetProcAddress() for example [1]
>
> As far I understand minimum supported Windows for APR 1.6.x is Windows
> 95. Is it correct? Anyway I don't have even Windows NT 4.0 test
> environment. Even more: Windows 95, 98, NT 4.0 and 2000 is cannot be
> legally downloaded due Java settlement [2].
>
> [1]
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85
> ).aspx
> [2] https://msdn.microsoft.com/en-us/subscriptions/ff723773.aspx
>
>
>
> Because Microsoft no longer issues security patches to NT 4 or Win9x
> or even Windows 2000 or 2003 and now - even XP, the httpd project's
> perspective is that connecting these machines to the internet is very
> unwise, and no further httpd support should be directed to those OS
> revisions. This eliminates the ANSI/8-bit-only APIs, and lets us put all
> attention and effort and FooFunctionW() wide-char equivalents.
>
> Agree. Btw VisualSVN Server dropped support for Windows older than
> Vista/Server 2008 in September 2014.
>
> That's the perspective looking from a server project. APR was never
> constrained to only server applications. There might be other APR
> c

Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimizeapr_file_info_get(APR_FINFO_SIZE) on Windows)

[Steffen]