(01-15-2024, 07:59 PM)cpstevenc Wrote: I have to use an ODBC driver where the company the writes it... still uses OpenSSL from 2005.
In other words, likely OpenSSL 0.9.8.
Can't you get a newer ODBC driver? If not from this company, then from another company?
(01-15-2024, 07:59 PM)cpstevenc Wrote: When any program I have that uses Indy does any SSL work, OpenSSL DLL files are loaded up into memory. So new OpenSSL files.
In theory, Indy can use OpenSSL 0.9.8, although that hasn't been tested in many many years, so I don't know if it will still work.
(01-15-2024, 07:59 PM)cpstevenc Wrote: Well when that ODBC Driver loads, it appears to hook into the already loaded OpenSSL DLL files in memory.
Then the ODBC starts to fail left and right because "wrong" OpenSSL is running. Stack traces of memory dumps always lead back to this.
I am not sure if there is a way to prevent that or not.
2 things that immediately come to mind: side-by-side assemblies, and activation contexts. These were designed for this kind of situation, where some components in an app may need one version of a DLL, while other components may need a different version of the DLL.
So, for instance, you could put the 2 OpenSSL versions into separate assemblies, and then use a manifest to tell Windows which assembly to use when loading the DLL. This might require you to separate the ODBC and Indy codes into separate apps, I'm not sure.
Or, before loading up either library in the same app, you could first create an activation context that uses the old OpenSSL DLLs and then load up the ODBC driver under that context, and then create a new activation context that uses the newer OpenSSL DLLs and then load up Indy under that context.
Just food for thought. I don't have any practical hands-on experience using either approach. I just know they exist.