ICS V9.1 announced

[PizzaProgram 9]

4 minutes ago, Angus Robertson said:

This has been the case for 25 years.

I know! That's why do not understand, why this new openssl.exe is behaving differently?

[Angus Robertson 529]

No idea how that screen shot error is relevant to ICS, we don't use openssl.exe. 

 

Our openssl zips have a different versions of openssl.exe in the Win32 and Win64 zips, you have mixed therm up.

 

Angus

 

[PizzaProgram 9]

Thank you very much for the quick replay!

I've double checked, and triple checked, and realized, you where right!

 

About the problem, why I was mislead:

On this site: https://wiki.overbyte.eu/wiki/index.php/ICS_Download

There is only one ZIP available of 9.1 download for Delphi7.

Inside that ZIP there is only one ICS-OpenSSL folder. (Containing both 32bit and 64bit DLLs.)

Inside that folder there is only one openssl.exe file. (No separate 32/64bit versions of it.)

 

I've also checked, who made the digital signature for DLLs and the EXE:

 - They are signed by the same company (Magenta Systems Ltd) nearly the same time. (21 sec. difference)

 

I've also checked the other ZIP made for new Delhpi versions: https://wiki.overbyte.eu/arch/icsv91-new.zip

But there is exactly the same structure.

 

So basically NOTHING IS INDICATING, that this exe is only for 64 bit !

 

 

But if I scroll down to the bottom of the page and download the binary file separately :

https://wiki.overbyte.eu/arch/openssl-3.2.1-win32.zip

 

That openssl.exe has a smaller size! (814k)

[PizzaProgram 9]

A Solution would be in the next release: (9.2 ?)

 - Please rename that openssl.exe to: openssl-64.exe

 - and include the 32bit exe in the component-pack-ZIP too please ! 

 - Even better, if both EXE files would be also auto-embedded, just like the DLLs. They are small compared to the whole directory combined.

 

Thank You all for the help!

[Angus Robertson 529]

Still got no idea why are distributing openssl.exe and why this is a problem.  The directory your screen shows has the correct DLLs for the EXE. 

 

We don't need two separate openssl.exe files since we don't use them.

 

The only problem here is you decided to change the way OpenSSL is distributed for your own reasons.

 

Angus

 

[PizzaProgram 9]

Dear @Angus Robertson , 🙂

 

Where You able to fix the problem by:

 - Renaming the openssl.exe to openssl-x64.exe for the 64 bit version

 - Leaving openssl.exe for 32 bit. (because it's compatible with both)

 

This way even if you copy the content of the 32 + 64 bit ZIP files together, the one will not overwrite the other!

 (As it happened during preparing this 9.1 ZIP file on your PC.)

 

Re-creating the v9.1 ZIP would be nice too, but at least prepare the: v9.2+  please, (so such overwrite never happens again.)

Calling a 32bit exe on a 64bit OS is not a problem. (But the other way around it is bad.)

 

TODO:

 - Copy both EXE files (openssl.exe + openssl-x64.exe) to the (next) ZIP files, you release.

 

Thank You in forward!

[Angus Robertson 529]

No, ICS will never contain an openssl-x64.exe file, since ICS does not use openssl.exe. 

 

Our OpenSSL zip distributions are separate for Win32 and Win64, so it is up to end users to do something if they want to combine them. 

 

SVN and the overnight zip do now correctly have the Win32 version of openssl.exe, the Win64 version was an error.

 

Angus

 

[EugeneK 12]

I think this should be commented out by default, I want to use OpenSSL version that I control.

{$DEFINE OpenSSL_Resource_Files}

 

 

[Angus Robertson 529]

If you undefine {$DEFINE OpenSSL_Resource_Files}, ICS will look in the ICS-OpenSSL directory for the DLLs, so how does make you in control? 

 

If you want to load the DLLs from your own specified location, like the application directory, you need to add extra code, as has always been the case with ICS, but you'll need to change other defines as well since OpenSSL is now loaded by default before any code is run.  This is explained in depth in readme9, and other places. 

 

Angus

 

[EugeneK 12]

8 hours ago, Angus Robertson said:

If you undefine {$DEFINE OpenSSL_Resource_Files}, ICS will look in the ICS-OpenSSL directory for the DLLs, so how does make you in control? 

 

If you want to load the DLLs from your own specified location, like the application directory, you need to add extra code, as has always been the case with ICS, but you'll need to change other defines as well since OpenSSL is now loaded by default before any code is run.  This is explained in depth in readme9, and other places. 

 

I understand this, I changed it. I'm talking about default value, good that I noticed it, if someone won't notice it can be unpleasant surprise if people rely on using specific OpenSSL version.

[Angus Robertson 529]

The default defines are designed so that users get new applications working easily and safely, without them failing immediately because the OpenSSL DLLs can not be found.  Or needing to copy those DLLs into every single different directory to which modern versions of Delphi build by default.

 

Angus

 

[PizzaProgram 9]

OFF: 📴

 

I absolutely agree, that it is very hard to apply new features, while maintaining backward compatibility.

 

@EugeneK I was also freaked out from this change, took me 40+ work-hours to realize, debug, understand and adapt my code to it.

It would have been nice, if it would have appeared first only as an OPTION, (disabled by default,) with a big fat red warning on the main page, that the next release will be default to this behaviour, so all of us could have been prepared...

 

But now I like it. It's a great new feature. Resolves a huge problem:

 - "How to download DLLs from internet from a https site, without SSL DLLs present."

 

So I'm very grateful to the developer maintaining and improving this component, and sharing it with us! 🌞

[Angus Robertson 529]

Quote

How to download DLLs from internet from a https site, without SSL DLLs present

That was fixed in V9.1, or at least there are now settings that allow the HTTP clients to be used without SSL being available, for http:// only.

 

I go to extreme lengths to keep ICS backward compatible, I know how horrible it is updating to new compilers and components when you get blizzards or IDE error messages on opening old projects, it's why some of my projects are still Delphi 2007. 

 

Rarely backward compatible is not possible, but I did spend a week or two writing documentation and updating samples explaining how to update to V9.1. 

 

Angus