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