Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Is it possible to use new version of Indy 10
#1
I have a couple of large applications developed in C++Buiilder 2007 that use Indy 10.1.15.  They do work fine and I'm not interested in converting them to a newer version of Rad Studio.  One of the owners wants to change from using his current mail host to G-Suite, which puts me in a bit of a pickle.  The old embedded email part of the program was just plain.  No TLS/SSL.  I'm having the problem that many others faced with the program not being able to load SSL libraries.  I did put the appropriate dlls for OpenSSL 1.02 in the programs folder.  The program does seem to try to use these dlls, but something else is getting in the way. 

I've used WhichFailedToLoad() and get a strange response whether the dlls are in my program directory or not.  Here's what WhichFailedToLoad() returns

SSL_CTX_set_info_callback_indy
X509_STORE_CTX_get_app_data_indy
X509_get_notBefore_indy
X509_get_notAfter_indy
SSL_SESSION_get_id_indy
SSL_SESSION_get_id_ctx_indy
SSL_CTX_get_version_indy
SSL_CTX_set_options_indy
des_set_odd_parity
des_set_key
des_ecb_encryp

The IdOpenSSLSetLibPath isn't available in the Indy 10.1.15 to force the program to use the dlls from a specific directory.  It is available in the the version in Seattle, which I have.  But, I need to solve this problem with the code base that I have in BCB2007 ... it's a pretty big program.   I have thought of updating to a later version of Indy, but don't know what the effect would be on the overall program, or even if it is possible given that it's unicode.  The only part of Indy 10 that I'm using is the units related to sending mail. 

Other than that, I do need to solve the inability to load the OpenSSL dlls.    Can now load the dlls, but had to use dlls  from 096.  They worked, but I did have to tag the gmail account I was using as an insecure app.  I don't know how well that will work for G-Suite.  The G-Suite account is ready for use, but the customer is still trying to get a master password to their current webhost that will allow them to transfer their MX records.
Reply
#2
(06-26-2018, 11:30 PM)OldBob1938 Wrote: I've used WhichFailedToLoad() and get a strange response whether the dlls are in my program directory or not.  Here's what WhichFailedToLoad() returns

SSL_CTX_set_info_callback_indy
X509_STORE_CTX_get_app_data_indy
X509_get_notBefore_indy
X509_get_notAfter_indy
SSL_SESSION_get_id_indy
SSL_SESSION_get_id_ctx_indy
SSL_CTX_get_version_indy
SSL_CTX_set_options_indy
des_set_odd_parity
des_set_key
des_ecb_encryp

All of those "..._indy" functions are used only by Indy 9, not Indy 10.  So your app is actually using Indy 9.  Your issue is similar to this one:

Which is current correct indy and open ssl versions to use with delphi2007

(06-26-2018, 11:30 PM)OldBob1938 Wrote: I have thought of updating to a later version of Indy, but don't know what the effect would be on the overall program, or even if it is possible given that it's unicode.

Indy 10 supports Delphi/C++Builder all the way back to v5 (though there are some known compiler issues with v5 specifically).  Indy will handle non-Unicode versions (though Unicode versions is preferred).  Depending on what your code looks like, you *might* need some tweaks, as there are additional properties/parameters available in various classes/procedures for handling ANSI strings.

(06-26-2018, 11:30 PM)OldBob1938 Wrote: Other than that, I do need to solve the inability to load the OpenSSL dlls.    Can now load the dlls, but had to use dlls  from 096.

That is because you are actually using Indy 9, not Indy 10.  Indy 9 does not support OpenSSL versions above 0.9.6 (and even then, it requires custom OpenSSL 0.9.6 DLLs, not the standard DLLs).  Indy 10 supports up to OpenSSL 1.0.2, using standard DLLs.

(06-26-2018, 11:30 PM)OldBob1938 Wrote: They worked, but I did have to tag the gmail account I was using as an insecure app.

When 2-factor authentication is enabled in a Google account, you do not need to configure the account to allow insecure apps.  You can instead generate an app-specific password to use in Indy (only because Indy does not support Google's OAUTH authentication yet, but that is in the works).  Indy works fine with GMail when using an app-specific password.

Reply
#3
(06-27-2018, 08:04 PM)rlebeau Wrote:
(06-26-2018, 11:30 PM)OldBob1938 Wrote: I've used WhichFailedToLoad() and get a strange response whether the dlls are in my program directory or not.  Here's what WhichFailedToLoad() returns

All of those "..._indy" functions are used only by Indy 9, not Indy 10.  So your app is actually using Indy 9.  Your issue is similar to this one:

Which is current correct indy and open ssl versions to use with delphi2007

Indy 10 supports Delphi/C++Builder all the way back to v5 (though there are some known compiler issues with v5 specifically).  Indy will handle non-Unicode versions (though Unicode versions is preferred).  Depending on what your code looks like, you *might* need some tweaks, as there are additional properties/parameters available in various classes/procedures for handling ANSI strings.

(06-26-2018, 11:30 PM)OldBob1938 Wrote: Other than that, I do need to solve the inability to load the OpenSSL dlls.   Can now load the dlls, but had to use dlls  from 096.

That is because you are actually using Indy 9, not Indy 10.  Indy 9 does not support OpenSSL versions above 0.9.6 (and even then, it requires custom OpenSSL 0.9.6 DLLs, not the standard DLLs).  Indy 10 supports up to OpenSSL 1.0.2, using standard DLLs.

Remy, thanks for responding.

I am really surprised that I'm using Indy 9.  When I right click on the Icons (such as IdSMTP)  that I've dragged from the tool palette, they all show that they are for 10.1.15.  I tried to paste in the popup window that shows this, but that didn't work.    I do have folders for both Indy 9 and Indy 10 in the Program files(x86)\Codegear\Rad Studio\5.0\...subfolders.  Could the program be using code from the wrong folders?  Something must be wrong with my installation.  Project Options shows Indy 10 core design time and Indy 10 protocols design time are both checked.
Reply
#4
(06-27-2018, 11:56 PM)OldBob1938 Wrote: I am really surprised that I'm using Indy 9.  When I right click on the Icons (such as IdSMTP)  that I've dragged from the tool palette, they all show that they are for 10.1.15.

That is the version you have installed in the IDE, but clearly that is not the version that is getting compiled into your executable.

(06-27-2018, 11:56 PM)OldBob1938 Wrote: I do have folders for both Indy 9 and Indy 10 in the Program files(x86)\Codegear\Rad Studio\5.0\...subfolders.  Could the program be using code from the wrong folders?

Sounds like it, yes. Such as if Indy 9 is on your systems' search path before Indy 10, so the compiler is finding the Indy 9 binaries first instead of the Indy 10 binaries. Try uninstalling Indy 9, or at least remove it from the search path (or move it after Indy 10), or rename the Indy 9 folder while compiling a project to use Indy 10.

Reply
#5
This is getting ridiculous. I have renamed all 4 of the Indy9 Folders to _Indy9. I've checked BCBs search paths. I've checked the Windows WOW/system32 for anything like Indy*.* per the Indy Knowledge Base and there were none. I think that I remember doing that years and years ago. Once I've done all of this, done a clean on the project, recompiled and relinked, OPENSSL 1.02 files give me the original failures. The program's owner is sending a newsletter mailing this weekend, so will not be screwing with this in any major way until Monday just in case there is a problem with the current setup. Is there any solution to this without installing the newest version with whatever new problems that might bring?
Reply
#6
(06-29-2018, 07:06 PM)OldBob1938 Wrote: Once I've done all of this, done a clean on the project, recompiled and relinked, OPENSSL 1.02 files give me the original failures.

Which failures exactly? Because it CAN'T be the ones you originally mentioned here, as those errors only affect Indy 9, only Indy 10. Are you ABSOLUTELY SURE your code is compiling with Indy 10? Check the Version property of *any* Indy component at runtime, what does it actually return? When OpenSSL fails to load, what exact version does Indy's OpenSSLVersion() function return?

(06-29-2018, 07:06 PM)OldBob1938 Wrote: Is there any solution to this without installing the newest version with whatever new problems that might bring?

I can't answer that yet. If your project is still compiling with Indy 9 and not 10, you CAN'T use a newer version of OpenSSL past 0.9.6 with it. And if your project is compiling with Indy 10, you should not be getting the same kind of failures as before. I know *for a fact* that the latest SVN snapshot of Indy 10.6.2 (SVN rev 5462 at the time of this writing) works fine with the latest OpenSSL 1.0.2o DLLs.

Reply
#7
(07-01-2018, 03:10 AM)rlebeau Wrote:
(06-29-2018, 07:06 PM)OldBob1938 Wrote: Once I've done all of this, done a clean on the project, recompiled and relinked, OPENSSL 1.02 files give me the original failures.

Which failures exactly?  Because it CAN'T be the ones you originally mentioned here, as those errors only affect Indy 9, only Indy 10.  Are you ABSOLUTELY SURE your code is compiling with Indy 10?  Check the Version property of *any* Indy component at runtime, what does it actually return?  When OpenSSL fails to load, what exact version does Indy's OpenSSLVersion() function return?

Here's the status returns using 1.02
SSL_CTX_set_info_callback_indy
X509_STORE_CTX_get_app_data_indy
X509_get_notBefore_indy
X509_get_notAfter_indy
SSL_SESSION_get_id_indy
SSL_SESSION_get_id_ctx_indy
SSL_CTX_get_version_indy
SSL_CTX_set_options_indy
des_set_odd_parity
des_set_key
des_ecb_encryp
idssliohandlersocket status
Resolving hostname smtp.gmail.com.
idssliohandlersocket status
Connecting to 108.177.122.109.
smtp status
Connected.
idssliohandlersocket status
Disconnected.
IdMsg 10.1.5                   // these are the runtime versions
gSMTP 10.1.5
IOHandler 10.1.5

I couldn't figure out how to use the OpenSSLVersion() function.  I tried a number of things but just got errors.  The first 11 errors disappear when I use 096.  I really do appreciate your patience with my problem.

(07-01-2018, 03:10 AM)rlebeau Wrote:
(06-29-2018, 07:06 PM)OldBob1938 Wrote: Is there any solution to this without installing the newest version with whatever new problems that might bring?

I can't answer that yet.  If your project is still compiling with Indy 9 and not 10, you CAN'T use a newer version of OpenSSL past 0.9.6 with it.  And if your project is compiling with Indy 10, you should not be getting the same kind of failures as before.  I know *for a fact* that the latest SVN snapshot of Indy 10.6.2 (SVN rev 5462 at the time of this writing) works fine with the latest OpenSSL 1.0.2o DLLs.

Something seems to be really screwed up with my system.
Reply
#8
(07-01-2018, 04:36 AM)OldBob1938 Wrote: Here's the status returns using 1.02
SSL_CTX_set_info_callback_indy
X509_STORE_CTX_get_app_data_indy
X509_get_notBefore_indy
X509_get_notAfter_indy
SSL_SESSION_get_id_indy
SSL_SESSION_get_id_ctx_indy
SSL_CTX_get_version_indy
SSL_CTX_set_options_indy
des_set_odd_parity
des_set_key
des_ecb_encryp

IdMsg 10.1.5                   // these are the runtime versions
gSMTP 10.1.5
IOHandler 10.1.5

That is a VERY old version of Indy 10.  The current version is 10.6.2.

I did some background checking, and it turns out that Indy 10 was still looking for those "..._indy" functions up until sometime after 10.1.5 was released and before 10.1.6 was released.

(07-01-2018, 04:36 AM)OldBob1938 Wrote: I couldn't figure out how to use the OpenSSLVersion() function.

That is because it doesn't exist in Indy 10.1.5, it was added in 10.5.8.

(07-01-2018, 04:36 AM)OldBob1938 Wrote: I tried a number of things but just got errors.  The first 11 errors disappear when I use 096.

That is because Indy 9 and early Indy 10 relied on CUSTOM-MADE OpenSSL 0.9.6 DLLs that had those functions available.  The "..._indy" functions are NOT standard OpenSSL functions, and DO NOT exist in standard OpenSSL DLLs, like the ones that later Indy 10 versions use.

(07-01-2018, 04:36 AM)OldBob1938 Wrote: Something seems to be really screwed up with my system.

You need to upgrade to a more up-to-date version of Indy 10, as 10.1.5 is way too old.

Reply
#9
Remy

That's what I was afraid of.  I'm concerned about mating something that uses unicode to an ansi system.  I have had problems with that in the past.  However,
I've read some posts from Feb 2016 where you patiently explained that, at least up to that point, the Indy versions were still maintaining compatibility with the
ansi versions of CBuilder and Delphi.  Since I primarily use CBuilder, I'm anticipating some problems there.  

I'm starting the ground work toward uninstalling my current version (10.1.5) and moving to a much later version.  Since I'm really only interested in SMTP and OpenSSL I'd guess my exposure to problems is somewhat limited (I hope).  

Thanks for all of your help.  You've been most gracious.
Reply
#10
(07-01-2018, 11:20 PM)OldBob1938 Wrote: That's what I was afraid of.  I'm concerned about mating something that uses unicode to an ansi system.

Indy 10 has support for ANSI versions of Delphi/C++Builder and FreePascal.

(07-01-2018, 11:20 PM)OldBob1938 Wrote: I have had problems with that in the past.  However, I've read some posts from Feb 2016 where you patiently explained that, at least up to that point, the Indy versions were still maintaining compatibility with the ansi versions of CBuilder and Delphi.

For Indy 10, yes. Support for ANSI versions is being dropped in Indy 11 (see the "Restructure Lib" branch in Indy 10's SVN repository - that branch will become Indy 11 once everything is finalized and rebranded).

(07-01-2018, 11:20 PM)OldBob1938 Wrote: Since I primarily use CBuilder, I'm anticipating some problems there.  

Why are you anticipating problems with C++Builder?

Reply


Forum Jump:


Users browsing this thread: 5 Guest(s)