> From: LM <lmems****@gmail*****> > Date: Thu, 7 Oct 2021 08:41:39 -0400 > > libraries seem to keep using later and later Windows features. For > instance, libressl is looking for bcrypt.dll and using > BCryptGenRandom. Previously, the library used > CryptAcquireContext/CryptGenRandom/CryptReleaseContext. I intend to > patch libressl to try to get it to continue to build with MinGW. I'm > attempting to go through pros and cons of how best to do this and > would appreciate suggestions. Was wondering if I should try to > generate a MinGW compatible library to access bcrypt.dll or whether I > should add code to try to do a LoadLibrary and check if the function > is available that way. If the function isn't available, I can fall > back on the old method. Another option would be to code something > with a similar API to BCyptGenRandom and use that as a fallback. The usual method is the one with LoadLibrary and GetProcAddress. > Any > ideas which version of Windows added the bcrypt.dll? According to the MS documentation, it was Vista. > Would be very curious to know how others are using common libraries > when the Windows APIs keep changing and the FLOSS libraries keep > trying to use the newest features. Anyone else trying to build > programs and maintain backward compatibility for older Windows > versions? If so, any tips on how you're handling these types of > situations? Thanks. GNU Emacs still supports Windows 9X, so yes, it's possible, at least as long as you use mingw.org's MinGW, the one which is supported by this forum. (MinGW64 tossed even XP long ago, let alone 9X, and that's why many FOSS projects drop those old versions as well.) Emacs uses the LoadLibrary/GetProcAddress method, and it works very well in practice.
Fork