Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows

[William A Rowe Jr]

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.

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.

Re: svn commit: r1773931 - in /apr/apr-util/branches/1.6.x: ./ crypto/ crypto/crypt_blowfish.c

[Yann Ylavic]

On Sun, Dec 18, 2016 at 2:04 AM, Gregg Smith  wrote:
>
> This makes testpass fail.

Thanks Gregg, reverted in r1774976 (trunk) and r1774975 (1.6.x).
This was really not appropriate :/

Regards,
Yann.

buildbot success in on apr-trunk

[buildbot]

The Buildbot has detected a restored build on builder apr-trunk while building 
. Full details are available at:
https://ci.apache.org/builders/apr-trunk/builds/78

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: orcus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1774976
Blamelist: ylavic

Build succeeded!

Sincerely,
 -The Buildbot

buildbot success in on apr-trunk-fbsd

[buildbot]

The Buildbot has detected a restored build on builder apr-trunk-fbsd while 
building . Full details are available at:
https://ci.apache.org/builders/apr-trunk-fbsd/builds/91

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: bb-fbsd2_64bit

Build Reason: The AnyBranchScheduler scheduler named 'on-apr-commit' triggered 
this build
Build Source Stamp: [branch apr/apr/trunk] 1774976
Blamelist: ylavic

Build succeeded!

Sincerely,
 -The Buildbot

Re: svn commit: r1733684 - in /apr/apr/branches/1.6.x: ./ include/ include/arch/netware/ include/arch/os2/ include/arch/unix/ locks/beos/ locks/netware/ locks/os2/ locks/unix/ locks/win32/ test/

[Yann Ylavic]

On Sat, Dec 17, 2016 at 6:48 PM, Rainer Jung  wrote:
> This commit introduced a new dependency on pthread_mutex_timedlock. Although
> its presence is detected by configure and locks/unix/thread_mutex.c checks
> HAVE_PTHREAD_MUTEX_TIMEDLOCK and provides an alternative implementation if
> it is not defined, file locks/unix/proc_mutex.c uses pthread_mutex_timedlock
> unconditionally.

Thanks Rainer for noticing, hopefully fixed in r1774973.

I wonder if we could fall back to using pthread_cond_timewait() like
we do for thread_mutex, but that'd require
pthread_condattr_setpshared() to be available on the system.
Is it the case at least on this older Solaris?
It's possibly not worth it too, thoughts?

Regards,
Yann.

Re: [PATCH] Use CreateFileMappingW on Unicode capable Windows

[Ivan Zhakov]

On 12 August 2016 at 22:46, Ivan Zhakov  wrote:
> Hi,
>
> Some ANSI APIs like CreateFileMappingA is not available on Windows
> Nano Server, while APR code in mmap/win32/mmap.c use
> CreateFileMappingA unconditionally. Attached patch fixes this problem.
> APR already has similar code in shmem/win32/shm.c.
>
Committed in r1774923.


-- 
Ivan Zhakov

Re: [PATCH] Optimize apr_file_info_get(APR_FINFO_SIZE) on Windows

[Ivan Zhakov]

On 17 December 2016 at 21:47, William A Rowe Jr  wrote:
> APR is C-T-R. If it is larger or significant change/addition, discussion on
> list first is great, but most of APR has been JDI.
>
OK/

> 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

-- 
Ivan Zhakov