(01-17-2024, 06:24 PM)rlebeau Wrote:(01-17-2024, 03:58 AM)cpstevenc Wrote: BTW I do see what you mean about the ssleay32 dll ... it loads any Libeay32.dll it can find it seems as i found in the loaded modules.
...
And because of this, ssleay32.cmrs.dll actually loaded a libeay32.dll from a 3rd party program installed on my system.
Exactly. And you can't be sure that the DLLs from two separate app installations are compatible with each other.
I couldn't figure out the side-by-side assemblies / activation contexts. Just couldn't find exactly what to do or how it would fix my problem. Google / ChatGPT / Ect... couldn't put it together enough for my chimp brain.
I was able to just check out the OpenSSL source and compile it myself in Visual Studio 2022. Using Strawberry Perl / NASM. Just followed the instructions and it worked.
Then made a batch file to zip through files to fix the naming convention from libeay32 to libeayCM32 and ssleay32 to ssleayCM32 for the file names and the internal refernce to libeay from ssleay.
And this worked like a charm. So now just a batch script to take a clean OpenSSL 1.0.2 source and "fix it up" and compile it all down.
Only other change for this to work is the edit the Indy source code on what DLL name to look for.
I tried this on our two problem child programs having this OpenSSL fight with what it wants vs the InterSystems Cache Drivers loading their flavor and wanting that old version to work.
And things are working. HTTPS Client and server /FTPS/SMTP/DataSnap REST/ect/ect which all use INDY is working like a charm now. And the ODBC drivers are doing its thing.
I don't 100% like this, but its my only hope and only solution i've gotten to actually work.