PizzaProgram

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)

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" ?

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