On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov <i...@visualsvn.com> wrote:
>
> 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
>

Returning to the topic of the minimal supported Windows version, I have
been thinking about upgrading APR to use the modern native Windows APIs.

More specifically, I would like to:

1. Use native Slim Reader/Writer (SRW) locks [1] for apr_rwlock.

   Windows SRW locks are extremely performant (100x times) and also the
   current APR implementation has known bugs [2].

   Although the basic SRW API is available since Windows Vista, the Try*
   functions that required for the implementation are only available since
   Windows 7 [3].

2. Use SetThreadErrorMode() [4] instead of SetErrorMode() because
   SetErrorMode() is not thread safe.

   This new API is available since Windows 7.

3. Use BCrypt API instead of CryptoAPI as an entropy source.

   Although the BCrypt API by itself is available starting from Windows Vista,
   an important `BCRYPT_USE_SYSTEM_PREFERRED_RNG` flag can only be
   used on Windows 7 and later.

4. Use native one-time initialization [5] for apr_thread_once_t.

   The current Win32 implementation has a problem that it can return before
   the other thread completes initialization.

   This particular API is available starting from Windows Vista.

While some of the changes can be implemented using LoadLibrary/GetProcAddress,
that would require maintaining multiple implementatations, would make the
testing harder and etc.

I would like to propose making Windows 7 / Windows Server 2008 R2 the minimum
supported Windows version for APR 2.0.

This means that for APR 2.0 we would drop the support for Windows Vista and
Windows Server 2008 (not R2), although in my opinion that shouldn't be much
of a problem, because Windows Vista is no longer supported by Microsoft, and
the extended support for Windows Server 2008 will end on January 14, 2020 [6].

Would there be any objections to this?

[1] 
https://docs.microsoft.com/en-us/windows/desktop/Sync/slim-reader-writer--srw--locks
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=45455
[3] 
https://docs.microsoft.com/en-gb/windows/desktop/api/synchapi/nf-synchapi-tryacquiresrwlockexclusive
[4] 
https://docs.microsoft.com/en-us/windows/desktop/api/errhandlingapi/nf-errhandlingapi-setthreaderrormode
[5] 
https://docs.microsoft.com/en-gb/windows/desktop/Sync/one-time-initialization
[6] 
https://azure.microsoft.com/en-us/blog/announcing-new-options-for-sql-server-2008-and-windows-server-2008-end-of-support/

--
Ivan Zhakov

Reply via email to