On Wed, 15 May 2019 at 15:25, Ivan Zhakov wrote:
>
> On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov wrote:
> >
> > On 19 December 2016 at 06:45, William A Rowe Jr wrote:
> > > On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov wrote:
> > >>
> > >> On 17 December 2016 at 21:47, William A Rowe Jr
> > >> 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].
>
Done in r1859584.
> 2. Use SetThreadErrorMode() [4] instead of SetErrorMode() because
>SetErrorMode() is not thread safe.
>
>This new API is available since Windows 7.
>
Done in r1859519.
> 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.
>
Done in r1859608.
> 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.
>
Done in
