On Wed, 15 May 2019 at 15:25, Ivan Zhakov <[email protected]> wrote: > > On Tue, 20 Dec 2016 at 10:58, Ivan Zhakov <[email protected]> wrote: > > > > On 19 December 2016 at 06:45, William A Rowe Jr <[email protected]> wrote: > > > On Sun, Dec 18, 2016 at 11:30 AM, Ivan Zhakov <[email protected]> wrote: > > >> > > >> On 17 December 2016 at 21:47, William A Rowe Jr <[email protected]> > > >> 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
