[libav-devel] [PATCH] use bcrypt instead of the old wincrypt API

Martin Storsjö martin at martin.st
Fri Mar 30 20:13:33 CEST 2018


On Fri, 30 Mar 2018, Diego Biurrun wrote:

> On Fri, Mar 30, 2018 at 04:58:29PM +0300, Martin Storsjö wrote:
>> On Fri, 30 Mar 2018, Diego Biurrun wrote:
>> > On Fri, Mar 30, 2018 at 12:38:05PM +0200, Steve Lhomme wrote:
>> > > Le 30/03/2018 à 10:46, Diego Biurrun a écrit :
>> > > > On Fri, Mar 30, 2018 at 09:36:05AM +0200, Steve Lhomme wrote:
>> > > > > --- a/configure
>> > > > > +++ b/configure
>> > > > > @@ -4581,6 +4582,7 @@ check_lib ole32    "windows.h"            CoTaskMemFree        -lole32
>> > > > >   check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
>> > > > >   check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom       -ladvapi32
>> > > > >   check_lib psapi    "windows.h psapi.h"    GetProcessMemoryInfo -lpsapi
>> > > > > +check_cpp_condition Vista+ windows.h "_WIN32_WINNT >= 0x0600" && check_lib bcrypt "windows.h bcrypt.h" BCryptGenRandom  -lbcrypt
>> > > > Do you really need to check the Vista condition? What about using bcrypt
>> > > > unconditionally if available?
>> > > 
>> > > Yes, you need to use it only on builds that won't run on XP. Otherwise it
>> > > will fail to load the bcrypt.dll and the whole libavutil DLL (or whatever
>> > > its form) will fail to load. It would be possible to do it dynamically but
>> > > IMO it's overkill. It's not really a critical component.
>> > 
>> > Is bcrypt available on XP? If no then the CPP condition check would seem
>> > unnecessary. You could just check for bcrypt and bcrypt being available
>> > would imply Vista. I think I'm missing something.
>> > 
>> > > But with time if XP support is dropped this check can go and wincrypt
>> > > dropped entirely.
>> > 
>> > Is it maybe time to consider dropping XP support?
>> 
>> I wouldn't mind.
>
> Let's go ahead then.
>
>> See e.g. 9b121dfc32810250938021952aab4172a988cb56 in ffmpeg; dropping XP
>> support simplifies the w32pthreads wrapper and allows using better
>> synchronization primitives, that allow e.g. static initialization of
>> mutexes.
>
> Do we need to do more changes apart from importing that commit?

Don't think so, except for whatever configure differences there are.

// Martin


More information about the libav-devel mailing list