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: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows
Date Mon, 19 Dec 2016 03:45:45 GMT
On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov <ivan@visualsvn.com> wrote:

> On 17 December 2016 at 21:47, William A Rowe Jr <wrowe@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.

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.

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

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.

View raw message