philipp.hofmann

Same effect with Version 8.68, so again I assume there is some additional piece of code necessary to initialize the MacOS-version of ICS but both of us don't know this part.

I've found only one difference here and this could not be an issue for MacOS: {$IFDEF ANDROID} {$MESSAGE 'TODO processmessage loop'} Result := False; // Error { V9.1 } {$ENDIF ANDROID} But I've checked the reason for the blocker in function TMultiReadExclusiveWriteSynchronizer.BeginWrite: Boolean; is the line as here it's not coming back: WaitForWriteSignal; P.S.: TIcsMessagePump.ProcessMessage is not reached under MacOS, if this could be an issue here. P.P.S.: I assume it's an initialisation issue if such a central functionality as WaitForWriteSignal is not working and processMessage is not requested at all. But I don't know what to test further.

It's 100% fine with the Windows sample with the same code.

I have deactivated GlobalSync now first. That's fine for me. But can you fix also the "SSL handshake faild - No error returned, State: SSLv3/TLS write client hello, connection closed unexpectedly" issue? This is currently my blocker.

Now my problem is the request TSSLSmtpCli.create(nil); or also TSSLSmtpCli.create(mainForm); freezes in procedure TIcsMessagePump.AfterConstruction; with the following request: GlobalSync.BeginWrite; But even if I remove GlobalSync.BeginWrite at all SSLSmtpCli.connect is not reacting as expected as "SSL handshake faild - No error returned, State: SSLv3/TLS write client hello, connection closed unexpectedly" is raise after 60 seconds. The same implementation works fine under Windows. P.S.: I was misleading by https://wiki.overbyte.eu/wiki/index.php/ICS_Download as there is a MacOS support mentioned for ICS-V9.

Now my problem is the request TSSLSmtpCli.create(nil); or also TSSLSmtpCli.create(mainForm); freezes in procedure TIcsMessagePump.AfterConstruction; with the following request: GlobalSync.BeginWrite; But even if I remove GlobalSync.BeginWrite at all SSLSmtpCli.connect is not reacting as expected as SslSmtpClient.OnRequestDone is never reached.

OverbyteIcsSSLEAY.pas: You should use the following file names for 300DLL_Name (so no /usr/lib-path in the filename plus adding version number): {$IFDEF POSIX}'libcrypto.3.dylib';{$ELSE} { !!!! not tested, unknown file name } {$IFDEF POSIX}'libssl.3.dylib';{$ELSE} OverbyteIcsLIBEAY.pas: It works if I uncomment @@RAND_screen in the table (and reduce the number by 1): GLIBEAYImports1: array[0..852] of TOSSLImports = ( // (F: @@RAND_screen; N: 'RAND_screen'; MI: OSSL_VER_MIN; MX: OSSL_VER_MAX), I saw afterwards the correct OpenSSL-Version number with OpenSSL_version(0) -> 3.2.1 But there is still a problem in initialization of TSSLSmtpCli.create(nil); It's working fine unter Windows again. So I will check this as the next point. So I'm not sure if my idea to replace Indy-TIDSMTP with ICS-TSSLSmtpCli to support MacOS64-ARM was so good because I can't find MacOS-ARM-Libraries for OpenSSL-1.0.x.

The first thing I found now, you need: GSSL_PUBLIC_DIR:=TPath.GetDirectoryName(ParamStr(0)); IcsLoadSsl(); And you need to deploy to Contents\MacOS\usr\lib But now I get the error Can not find: RAND_screen

Is your problem solved? I have the same problem but I assume it has to do with SSL initialization.

Hi, I try to use the TSSLSmtpCli component (created during lifetime) on MacOS 64 (x86 and ARM). The files libcrypto.3.dylib libssl.3.dylib are deployed to Contents\MacOS\ So FileExists(ExtractFilePath(ParamStr(0))+'/libcrypto.3.dylib') FileExists(ExtractFilePath(ParamStr(0))+'/libssl.3.dylib') is true. But OpenSSL_version(0) returns an exception. So I assume the shared libraries are not initialized. How I can do this? For Windows this process works without any special requests beforehand. Best regards, Philipp

Hi, my current Indy implementation sends email synchron, so my method is waiting until the mail is sent and then showing a result. It's not clear for me how I can achieve this with ICS-code as after I've requested connect, the app is frozen, even if I request connect within a thread. Is this achievable to avoid bigger changes on our code while migrating from Indy to ICS? class function TEMailUtils.sendEmail(receiver,subject,body,attachment:String;IdIOHandler:TIdSSLIOHandlerSocketOpenSSL;doNotReply:boolean):boolean; begin finished:=false; if (sslSmtpClient=nil) then begin sslSmtpClient:=TSSLSmtpCli.create(nil); sslContext:=TSSLContext.create(nil); sslSmtpClient.SslContext:=sslContext; SslSmtpClient.Host:='smtp.xxxxxx.de'; SslSmtpClient.Port:='465'; SslSmtpClient.AuthType:=TSmtpAuthType.smtpAuthLogin; SslSmtpClient.SslType:=TSmtpSslType.smtpTlsImplicit; SslSmtpClient.Username:='xxxxxxxx@xxxxxxxx.com'; SslSmtpClient.Password:='xxxxxxxxxxxxx'; SslSmtpClient.OnRequestDone:=SslSmtpClientRequestDone; end; if (doNotReply) then SslSmtpClient.FromName:='doNotReply (icTrainer)' else SslSmtpClient.FromName:='icTrainer'; SslSmtpClient.HdrFrom:=SslSmtpClient.FromName; SslSmtpClient.HdrTo := receiver; SslSmtpClient.RcptName.Clear; SslSmtpClient.RcptNameAdd(receiver,'',''); SslSmtpClient.HdrSubject := subject; SslSmtpClient.MailMessage:=TStringUtils.getTStringList(body,'|'); SslSmtpClient.EmailFiles.Add(attachment); mlog.info('start sendMail'); SslSmtpClient.Connect; while (not finished) do sleep(100); result:=resultVal; mlog.info('finished sendMail: '+TStringUtils.BoolToStr(resultVal)); end; class procedure TEMailUtils.SslSmtpClientRequestDone(Sender : TObject; RqType : TSmtpRequest; Error : Word); begin mlog.info('RequestDone Rq=' + IntToStr(Ord(RqType)) + ' Error='+ IntToStr(Error)); if (Error <> 0) then begin mlog.info('Can`t send mail: RequestDone Rq=' + IntToStr(Ord(RqType)) +' Error='+ SslSmtpClient.ErrorMessage); finished:=true; Exit; end; case RqType of smtpConnect: SslSmtpClient.Ehlo; smtpEhlo: SslSmtpClient.Auth; smtpAuth: SslSmtpClient.MailFrom; smtpMailFrom: SslSmtpClient.RcptTo; smtpRcptTo: SslSmtpClient.Data; smtpData: begin mlog.info('Send Mail and quit'); resultVal:=true; finished:=true; SslSmtpClient.Quit; end; end; end;

Hi, my app runs under Windows perfectly with two displays. With MacOS and one display everything is fine also. But my customer sometimes report the following error if they are using two displays: Zugriffsverletzung bei Adresse 0000000102C2CD7D beim Zugriff auf Adresse 0000000000000000 At address: $0000000102C2CD7D (Fmx.Platform.Mac.TMacMetalView.displayLayer(Macapi.Quartzcore.CALayer) + 173) Call stack: icTrainer $0000000102633E4D SignalConverter + 45 icTrainer $0000000102633E20 SignalConverter + 0 icTrainer $000000010399F2DF DispatchToDelphi + 209 QuartzCore $00007FF81E49363B -[CALayer display] + 184 QuartzCore $00007FF81E492E9D CA::Layer::display_if_needed(CA::Transaction*) + 867 QuartzCore $00007FF81E62BA24 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 758 QuartzCore $00007FF81E47401D CA::Transaction::commit() + 725 QuartzCore $00007FF81E490CEE CA::Transaction::release_thread(void*) + 206 libsystem_pthread.dylib $00007FF8159E526F _pthread_tsd_cleanup + 593 libsystem_pthread.dylib $00007FF8159E787B _pthread_exit + 71 libsystem_pthread.dylib $00007FF8159E4FDB pthread_exit + 42 icTrainer $000000010272F1A2 Classes.ThreadProc(Classes.TThread*) + 274 icTrainer $000000010261F587 ThreadWrapper(Pointer) + 55 libsystem_pthread.dylib $00007FF8159E7202 _pthread_start + 99 libsystem_pthread.dylib $00007FF8159E2BAB thread_start + 15 Is this a known problem? Best regards, Philipp

The first example works fine with SDK 14.2 generated and tested on MacOS 12.6 and MacOS 14.2.

Ok, thanks. Than I was only unable to find it with my keywords. But I'm still confused because it seems to be dependend on the SDK I'm using not the system the app is running on. I need to do more tests if the suggested fix is sufficient.

I found an older ticket for this here: But the creator didn't create a ticket on EMBT side. So it's still unsolved there. And I don't understand until now if the dependency if because of the SDK I'm using only or also dependend on the MacOS-version the app is running on.