PizzaProgram

I've finally finished to rework all my codes, so it works both with old Indy OpenSSL 1.0.2 and latest ICS 9.1 (OpenSSL 3.2) by setting a simple checkbox (UseSSL3?) But when I test it, it gives odd results, because it takes 3x so much time to download a simple XML with ICS now. Old Indy download time = 560 - 570ms New ICS download time = 1560-1580ms I have tested it many many times, same results. - Both components running in background thread. - BasicAuth (username + password) is used. - Indy component is getting created each time before download. But ICS (+SSL initialization) is done only once before thread start. The code I use is very simple: function Get_with_SSL3(const url: string; SslHttpCli3: TSslHttpCli; var Data:TMemoryStream; var error: string; timeOut: integer): Boolean; var size: Int64; begin Result := False; if Data = nil then Data := TMemoryStream.Create; SslHttpCli3.URL := url; SslHttpCli3.Timeout := timeOut; try try SslHttpCli3.Get; except on E:Exception do // 400 error := E.Message; end; finally Result := (SslHttpCli3.StatusCode = 200) or (SslHttpCli3.StatusCode = 400); size := 0; try if Assigned(SslHttpCli3.RcvdStream) then begin SslHttpCli3.RcvdStream.Seek(0, soFromBeginning); size := SslHttpCli3.RcvdStream.Size; end; if size > 0 then begin Data.Clear; Data.LoadFromStream( SslHttpCli3.RcvdStream ); end else error := 'ERROR! 0 byte answer. ' + error; except on E: Exception do hiba := '! Stream read error: ' + CRLF + E.Message; end; if Assigned(SslHttpCli3.SendStream) then SslHttpCli3.SendStream.Size := 0; if Assigned(SslHttpCli3.RcvdStream) then SslHttpCli3.RcvdStream.Size := 0; end; end; Is this "normal" ?

What I still don't know: Should I set myGlobalMainCLIcomponent.MultiThreaded := TRUE; for the Main thread's component too ? Or only for those running in the background thread ?

Well, I'm shocked. You were right! I've moved the creation of the components from the initialization part to the Execute procedure and It's the same fast now as Indy. Also this will probably explain WHY my application crashed always ... (link to prev. topic about this problem) Thank you very much for the help! I truly recommend, the future versions of the component should check, and raise an error if: The creation and running thread are not the same? The first initialization (of loading SSL DLLs) and final destruction is not running in the main thread! Property of .Multithreaded is True while running in a background thread? (Can be automated too.) It's not just me, who recommended that:

Thanks for all the answers ! To clarify things: Yes, I create those components in the background threads. Each thread = each separate http component. 👼 No, it would be a big mistake to put everything in the main thread. 🤯 This is a POS program with a max user-response time of 50-100ms of the Main thread. (And there are 4-5 background threads doing different things, like DB-locking, DB-searching, DB-executing+ commiting + order cashing, menu-syncing, Logging, CallerID, Syslog, etc. So blocking the main thread would be more than problematic.) Seriously, I do not try to blame anybody, both components are excellent works ! Congrat to both of you and I'm really glad I can still use my old delphi7 for such complex things, like web-server + https. But that time increase from 580ms to 1560 is not normal, and I'd like to dig to the bottom of it. - Is there something maybe misconfigured? - Why does the 2th, 3th, etc call of ICS taking the same time as the 1th? I do not destroy the component, do not tell it to disconnect, so the socket should be established to the same domain, only some sub-parameters of the URL is changing ! So theoretically the speed should shorten after the first connection. - Opening the URL in a browser: Firefox time measure shows = 560ms too, so that is the standard server response time. - (Ping to the server is constant 2ms)

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!

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)

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

Thank You very much for trying to help, but I'm talking about hundreds of PCs, that needs to use this exe every few year once to generate new keys. Deploying all those missing DLLs by hand to every each PC one by one would be an insane big task. If there are 32 bit normal DLLs present in the same directory, the EXE should have had recognise and use those, just like it did before this new version. Of course, as a programmer myself, I can make some "dirty hack-solutions" to circumvent the problem, (which will probably cause other problems,) but it's just not the way it should work! 😞

But now I have found a new problem with latest release: openssl.exe is not running on Win10 64bit PC, if only the 32bit DLL-s are present ! (This problem did not occure on prev. versions.) - What can I do? - Is there any "command line switch" to force search for the 32 bit DLLs ? (My app is 32 bit, I have now all the 32bit DLLs embedded into into, taking already lot's of space.)

... fixing the PATH problem was easy, ... p := exe_path + c_my_SSL3_base_dir; OverbyteIcsSSLEAY.GSSL_PUBLIC_DIR := p; OverbyteIcsSSLEAY.GSSL_DLL_DIR := p + '\2301'; // 'e:\myApp\Bin\SSL\202xxxxx\2301'; // add version number // GSSL_SignTest_Check := True; try OverbyteIcsLIBEAY.IcsLoadSsl; Result := True; except on E:Exception do logme('Failed to initialize SSL3 DLLs. Error message: ' + E.Message); end;

Yes, I fully understand all of it now. Thanks for the replay! The only 4 things are not yet clear to me: 1.) What is the command I can force this "unpacking" (+ initialization) of the resource-embedded DLLs ? 2.) Can I set a path before where is should happen? (I like to put those to my own APP's dir, like: MyExePath\Bin\SSL\20240205\dll ) 3.) ... If I want to do that, should I disable: {DEFINE OpenSSL_ProgramData} ? 4.) After resource unpacking / before each initialization if these DLL files: - Is ICS checking the file's integrity? (CRC32 or at least the size?) (Because I could list many cases when it does not succeed. (Write error, bad Antivirus program, modified by a malware, ... )

... hmmm that's interesting: Since the upgrade from v9.0 -> to v9.1 My EXE file (compiled under Delphi 7 ) increased from: 15.5 MB -> to 20.5 MB I'm using MPress to self-compress it, and it also shows a +21% size increase: 7.1 MB -> 8.6 MB That's a huge difference if we count that only pure code happened. (No new pictures added or similar, which would explain it) Well, it is not a very big problem, but there are still some restaurants having only 30-60Kbit internet max. (3G) ... and also a memory consupmtion on a Win32 tablet is +25% more. ... Investigating it further I've realized, there are new huge .RES files in the source directory. LibV32OpenSSL32.RES And so I've realized what all that means: I have red about in the 9.1 " what changed " topic, but did not comprehend, that the section: "Distribution of the ICS OpenSSL files has changed " is an extreamly cool upgrade Maybe re-writing it using my own words can help others too: The new 9.1+ ICS will force-include OpenSSL DLL files inside the compiled EXE by default. - It will extract these DLL files from the EXE on first run / initialisation to a common directory. - This behaviour can be turned off by editing the ...\ICS\Source\Include\OverbyteIcsDefs.inc file. - But it's not recommended because some features will fail to work.

Great 😉 I'd just like to report that: - it WORKS ! Both TSSLContext + JOSE + SuperObject + Utils. (Just made my first attempt to communicate with the government test server to send/receive some data.)

Hi, Thanks for the continuous update of this component package 🙂 I'm trying to update from 9.0 to 9.1 under Delphi 7 , but it won't compile: [Error] OverbyteIcsSslBase.pas(494): Undeclared identifier: 'TBytes' Is there a quick-fix for that ? EDIT: [SOLVED] Just added this line: unit OverbyteIcs....; interface ... OverbyteIcsTypes, { V9.1 } To these files: OverbyteIcsHttpAppServer.pas OverbyteIcsIpUtils.pas OverbyteIcsSslBase.pas OverbyteIcsUrl.pas

I've searched 2 hours long for an answer: - What is the main difference between OpenSSL 3.0.x / 3.1.x / 3.2.x / 3.3.x ? Here is what I've found: The main difference is the support time vs. speed issues vs. new features. 3.0 was reported to be slow, but it will get the longest support (LTS): 2026-09-07 3.1 is a "middle solution", much faster but shorter support: 2025-03-14 3.2 is currently the recommended version, (but it has shorter support time than the LTS): 2025-11-23 1.1.1, 1.1.0, 1.0.2, 1.0.0 and 0.9.8 are now out of support and should not be used 3.3 is only at alpha state yet.

Please advice me where I could find a "simple download" example of ICS v8.70 ? I'm still using Delphi7, so I was told it is not recommended to update to the new 9.0 version. With Indy10 it was extremely simple to do: IdHTTP1.ConnectTimeout := 2000; try FS := TFileStream.Create(save_path, fmCreate); except Exit; end; try //'http://...' IdHTTP1.Get(theURL , FS); if IdHTTP1.ResponseCode = 200 then ... ... Also I was able to update the request status + the progress: function get_httpStatus(const AStatus: TIdStatus; const AStatusText: String): string; var s: string; begin case AStatus of hsResolving : s := 'Webszerver (DNS) keresése...'; hsConnecting : s := 'Kapcsolódás a webre...'; hsConnected : s := 'A kapcsolódás sikeres.'; hsDisconnecting : s := 'A kapcsolat bontása'; hsDisconnected : s := 'A kapcsolat BONTVA.'; hsStatusText : s := 'Állapot:'+AStatusText; ftpTransfer : s := 'Adatáttöltés...(FTP)'; ftpReady : s := 'Készen áll az adattöltésre (FTP)'; ftpAborted : s := ' ! MEGSZAKÍTVA !'; end; Result := s; end; procedure TFrm_myDownload.IdHTTP1Status(ASender: TObject; const AStatus: TIdStatus; const AStatusText: String); begin lbl_status.Caption := get_httpStatus(AStatus, AStatusText); lbl_status.Repaint; end; So how do I do the same with ICS? - need timeout - need progress update (not the ICS progress bar, but my own) - need status update (localized!) PS: I've spent ca. 30 hours so far reading FAQ + Getting Started + opening and analysing the examples inside ..\ICS\Samples\Delphi directory, but found nothing, except: - the "OverbyteIcsHttpMultipartDownload.dpr", which ended up with catastrophe: PS2.: [edit] Also used "search" on this page with multiple keywords, checking 200+ topics, but found no answer.

Hmmm... that's interesting and promising, because I have compared: OverbyteIcsHttpsTst1.pas with OverbyteIcsXferTst examples and maybe my problem is, that I'm using TIcsHttpMulti component instead of a simple TSslHttpCli. It seems that the "multi" version calls SSL initialization automatically inside .Download() method. (I'm not calling it from anywhere before starting the download.) So the solution seems to be to get rid of this nice "multi-download" component and use a simple CLI. Thank you VERY VERY much for all the time You have invested to test it for me and to write it down in this topic! :-)))) Good Night!

Sorry for disturbing You guys, just forget about my question, I'll stay with Indy, it works as expected, and Indy will keep downloading the DLLs for ICS, where TLS 1.3 is needed. Thanks for trying to help ! Bye.

They are already distributed everywhere all over the country. Some of them 3, 5, 10+ years ago !!!!!!!!!! Also there are "ready to use" windows-backup image files that contain all necessary setup and the windows itself, without those DLL we are missing now. It is already built-into my own exe. But my Exe needs to DOWNLOAD automatically the necessary "setup updater" ! Normally that would be a great idea, but it would increase the 7MB exe file to double size. Some regions have 20-50Kbit internet only and it's already taking 2+ minutes! to download that 7MB. I worked very very hard for years to keep it that small, while the "whole program" with all the pictures and DLLs and everything else is 150MB, which is normally "static data", so only the 7MB needs to be downloaded, sometimes daily.

Of course I did ! Also I have replied to it. I don't know how to explain it better: 1. I have and EXE on hundreds of PCs, that needs to communicate with both http and https endpoints. 2. ICS can not start, because some necessary SSL DLLs are missing. 3. ICS is trying to download those DLLs from a non-SSL server via http://... , but can not !!! 4. GOTO: #2.

No, it is impossible to do this manually on hundreds of PCs one by one. My EXE is auto-updating itself, no user action is necessary. If the new EXE needs some extra/updated DLLs, it must download them automatically and put them in the right subdirectory. Until now, Indy10 component did this completely automated. It has a simple way to check if http:// or https:// is necessary, and if no SSL is needed, it can work "alone" without any necessary extra DLLs. I was trying to get rid of Indy, (because it is 10+ years old and has some memory leaks,) and rewrite the whole auto-download system based on ICS. But it seems to be impossible. 😞

Yes, I NEED SSL, that's why I'm trying to download the necessary SSL DLLs first (from a non-SSL server). So it seems to me it's a 22's trap. Without those DLLs ICS is not working at all, but to download them, I need those DLLs first.

Sorry, need a bit more help, because it's not working as I've expected. (Still trying to solve it with ICS v8.70 yet.) The first step for this component to work, to download the necessary 3 files of SSL3 DLLs, so it can communicate with TLS1.3 servers via httpS . I've uploaded those files to my own http:// (no SSL!) server. But TIcsHttpMulti.Download() can not start, because it gives the error: Project ....exe raised exception class EIcsLibeayException with message 'Failed to load OpenSSL file libcrypto-1_1.dll'. Process stopped. Is it possible that ICS can not work without extra DLLs at all? Not even communicating with simple non-SSL http:// servers using the OS's built-in dll? (Only worked until now, because I've downloaded those DLLs with an Indy10 component, but now I've tried to update this part of my code to replace Indy everywhere.)

I have a huge app (pizzaprogram) running for 20+ years rock stable on hundreds of PCs, written in Delphi7, using: AlphaSkin + Indy + UIB + TVirtualStringTree also had 5 background threads running without any problems. (Some of them are using UIB.) This year I've started to work with `OverbyteIcsSslHttpRest, OverbyteIcsLogger, OverbyteIcsSslJose, OverbyteIcsSslX509Utils, OverbyteIcsWSocket, OverbyteIcsSuperObject, OverbyteIcsHttpProt, OverbyteIcsUtils, OverbyteIcsSSLEAY` units, running in a 6th separated thread. Since then, every 1-6 hours my program is crashing with EOutOfResources whenever AlphaSkin is trying to create or resize a bigger Bitmap. I've upgraded AlphaSkin from 2019 version to latest, but it did not help. (Actually it made it even worth, because the new version is generating 32bit bitmaps for every form and panel and button forehead.) The private memory consumption of my EXE is always under <150MB , usually 75MB Peak Virtual memory size < 300MB GDI number < 900 Please give me some hint / advice, how could I solve this mystery?