You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2016/12/20 07:58:37 UTC
Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
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
Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, 15 May 2019 at 23:07, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Wed, May 15, 2019 at 7:39 AM Eric Covener <co...@gmail.com> wrote:
>>
>> > 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].
>>
>> +1, Win 7 and 2008 R2 still seems pretty conservative for an APR 2.0.
>
>
> For APR 2.0 forwards, a hearty +1!
>
Thanks everyone for the feedback.
Now Windows 7/Windows Server 2008 R2 is the minimum supported Windows
operating system for APR 2.0.
I've made necessary changes in CHANGES in r1859474.
--
Ivan Zhakov
Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, May 15, 2019 at 7:39 AM Eric Covener <co...@gmail.com> wrote:
> > 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].
>
> +1, Win 7 and 2008 R2 still seems pretty conservative for an APR 2.0.
>
For APR 2.0 forwards, a hearty +1!
Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
Posted by Eric Covener <co...@gmail.com>.
> 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].
+1, Win 7 and 2008 R2 still seems pretty conservative for an APR 2.0.
Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Tue, May 21, 2019 at 2:32 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
> >
> > 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 r1859517.
Tremendous progress, thanks for all of your efforts! I just finished a
visual review yesterday.
I don't know whom of us will jump on removing the ANSI logic first, but
that's next on the chopping block with unanimous consent.
Again, thanks!
Bill
(And yes, I was referring to DisconnectEx() in the earlier dialog.)
Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Wed, 15 May 2019 at 15:25, Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov <iv...@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 <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
> >
>
> 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 r1859517.
--
Ivan Zhakov
Re: Supported Windows versions for APR 2.0 (was Re: [PATCH] Optimize
apr_file_info_get(APR_FINFO_SIZE) on Windows)
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov <iv...@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 <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
>
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