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 551]

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 551]

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 551]

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 14]

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

{$DEFINE OpenSSL_Resource_Files}

 

 

[Angus Robertson 551]

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 14]

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 551]

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 551]

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

 

[DarkDucke 2]

Hello, ICS components don't work with FMX Linux? I put a tsslHttpServer in the form, tried to compile for linux and [DCC Fatal Error] F_Prin.pas(16): F2613 Unit 'Ics.Fmx.OverbyteIcsWndControl' not found.

 

thanks!

[Angus Robertson 551]

ICS has never been supported on Linux. 

 

There is preparatory work for Linux work, I created a new SSL sample PemTest last month which works on Linux, but socket based components don't work yet, this will be fixed soon by replacing the old MacOS event engine in WSocket with a new version that supports all platforms, a test version is currently in the ICS V10 SVN repository, no SSL.

 

Angus

 

[StefandB 1]

On 3/21/2024 at 11:11 PM, w0wbagger said:

I'm going to add what I've found here. The IcsVCLCBNewRun.cpp currently includes a #pragma link "IcsCommonCB110Run.a" and a #pragma link "IcsCommonCB110Run.lib"

(I think?) these should be changed to "IcsCommonCBNewRun".  

IcsVCLCBNewDesign.cbproj has "IcsCommonCB110Run.bpi" under "Requires". I'm assuming that this should be removed and replaced with "IcsCommonCBNewRun.bpi". 

IcsVCLCBNewDesign.cbproj also has "IcsVCLCB110Run.bpi" under "Requires". I'm assuming also that his should also be removed and replaced with "IcsVCLCBNewRun.bpi"

 

Made these changes but it still doesn't work. There are a lot of references to 110 in the various project files (vs 22.0). 

 

When I install the components in "IcsCommonCBNewDesign", no component tab gets generated, but if I look at the components from the "Components->Install Packages" screen, I see them all there.

However, when I install the components from "IcsVCLCBNewDesign", it says they're installed, but there are no components showing when I click on the "Components" button from the "Components->Install Packages" screen when highlighting the VCL Design-Time Package. I'm at a bit of a loss, now. 

I have the exact same issue. Tried removing IcsCommonCB110Run.bpi from required in IcsCommonCBNewDesign

Updated #pragma link "IcsCommonCB110Run.lib" to IcsCommonCBNewRun290.lib in IcsVclCBNewRun

Getting link error : [ilink32 Error] Fatal: Unable to open file 'ICSCOMMONCBNEWRUN290.LIB

 

This is C++ Builder 12

[Angus Robertson 551]

All the old references to specific Delphi versions like 110, 104, 120 etc should be replaced by New. 

 

I thought I'd done that, but seems I missed a few, and since I don't do C++ it needs to be tested by someone else.

 

Angus

 

[w0wbagger 0]

On 8/30/2024 at 7:41 AM, StefandB said:

I have the exact same issue. Tried removing IcsCommonCB110Run.bpi from required in IcsCommonCBNewDesign

Updated #pragma link "IcsCommonCB110Run.lib" to IcsCommonCBNewRun290.lib in IcsVclCBNewRun

Getting link error : [ilink32 Error] Fatal: Unable to open file 'ICSCOMMONCBNEWRUN290.LIB

 

This is C++ Builder 12

I think we made more progress attempting to get 9.2 installed and working on C++ Builder 12, but we're not quite there yet. Something about the way it's linking means it doesn't create the .lib file. I'd start there first, instead of 9.1.

[Angus Robertson 551]

I'm planning the V9.3 release this month, so really would appreciate users trying to get the C++ packages installable.

 

I spent a lot of time fixing the Mscrypt problems so C++ does not use it. 

 

Angus

 

Edited September 6 by Angus Robertson

[StefandB 1]

3 minutes ago, Angus Robertson said:

I'm planning the V9.3 release this month, so really would appreciate users trying to get the C++ packages installable.

 

I spent a lot of time fixing the Mscrypt problems so C++ does not use it. 

 

Angus

 

I'd be happy to help. I do have to maintain code though, so can try and just revert back to an earlier version if I am not successful as I run C++ Builder XE3, 10 Seatle, 10.2, 10.4 and 12.

[Angus Robertson 551]

Quote

I'd be happy to help.

Thanks, please try to get the IcsCommonCBNew and IcsVclCBNew packages in SVN to build in 10.4 or later, not concerned about fixing older packages now.  Then please email them to me with any other units that need fixing, hopefully none.

 

Angus

[w0wbagger 0]

Just installed 12.2 and pulled the most recent build, and nothing compiles/builds/installs properly in C++ Builder. I guess I'll have to start from scratch again trying to get this compiled and installed.  Sorry, Angus. Does Embarcadero not offer any support for stuff like this? I'd think if they're willing to put a Delphi installation in GetIt, they'd be willing to help create a C++ installation, esp. given their work on C++ for this version of Rad Studio.