From lmemsm at gmail.com Thu Oct 7 21:41:39 2021 From: lmemsm at gmail.com (LM) Date: Thu, 7 Oct 2021 08:41:39 -0400 Subject: [MinGW-Users] bcrypt.dll related questions Message-ID: I've been trying to build the latest version of libressl with MinGW since OpenSSL seems like a nuisance to build and libressl offers the same features I need. Last version I built was 3.0.2. I'm trying to upgrade to the latest version 3.3.5. I'd like to maintain compatibility with older versions of Windows so the libraries and applications I build can work on systems like ReactOS. Open Source 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. Any ideas which version of Windows added the bcrypt.dll? Any suggestions on best ways to replace missing functions/libraries like these? 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. From eliz at gnu.org Thu Oct 7 22:17:12 2021 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 07 Oct 2021 16:17:12 +0300 Subject: [MinGW-Users] bcrypt.dll related questions In-Reply-To: (message from LM on Thu, 7 Oct 2021 08:41:39 -0400) References: Message-ID: <83y275ynxj.fsf@gnu.org> > From: LM > 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.