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

[be...@qqmail.nl]

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 <in...@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 <iv...@visualsvn.com> 
To: William A Rowe Jr <wr...@rowe-clan.net> 
Cc: APR Developer List <de...@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 <iv...@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
consumers who take a different perspective on antique OS support.
Subversion currently supports Windows 2000+. There were suggestion to
drop Windows 2000 [1], but no decision was made.

TortoiseSVN minimum supported OS is Windows Vista. I don't about
other projects using APR.


From the APR 2.0 perspective I don't mind throwing these all out
from our forward-looking efforts. I suppose we can continue to not
break these older OS's on the 1.x maintenance branch, since it
generally isn't a lot of effort to offer a stub function where the
entry point is not present.
I'm big +1 (non-binding) to make Windows Vista/Server 2008 minimum
supported Windows for APR 2.0. In my opinion it would simplify
development and testing of APR. In this case we can use native
implemention read-write lock, APIs like
GetFileInformationByHandleEx()/SetFileInformationByHandleEx() etc. But
maybe requiring Windows Vista for APR 2.0 is too radical change.

What do you think about Windows CE support for APR 2.0? Can we drop it too?


FWIW, Windows 7 introduced the DisconnectSocket() API, which
was completely missing when we first designed the apr sockets
API, so we played games with TransmitFile instead to disconnect
and save a recyclable socket upon completion. Seems like we
could simplify this now that the right OS API exists.

I don't see DisconnectSocket() API. Do you mean DisconnectEx() [2] ?
DisconnectEx API is available from Windows Vista, not Windows 7
though.

[1] https://svn.haxx.se/dev/archive-2016-08/0013.shtml
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/ms737757

-- 
Ivan Zhakov