Leaderboard

In case anyone is interested, and better, want to contribute, I've upgraded THunSpell which was originally written by Stefan Ascher to support Unicode Delphi and created a github repository. Attached Demo screenshot.

You signal the thread to terminate, and then you wait for the thread to actually terminate right then and there, before you exit from the OnStop/OnShutdown event handler. The service enters a StopPending state before triggering the event, and then it enters the Stopped state once the event exits (or, in the case of the OnStop event, it enters back into the Running state if you set the event's Stopped parameter to False). Note that using TThread.WaitFor() in this situation is not a good idea, since the service still needs to report status back to the SCM at regular intervals while the SCM is waiting for the service to stop itself. If the thread takes a long time to terminate, the SCM will fail after some time if the service doesn't actively tell the SCM that the stop is taking a long time. What I do instead is use TThread.Handle with WaitForSingleObject() (or equivalent) in a loop, using a timeout calculated from the TService.WaitHint property (usually WaitHint-100). When WFSO reports the thread has fully terminated, I break the loop and move on. When WFSO times out, I call TService.ReportStatus() and keep looping.

Keep a reference to the thread when you create it. Use TThread.Terminate to terminate it and use TThread.WaitFor to wait for it to actually terminate.

The easiest way to use it: ShowMessage(WhichFailedToLoad()); I am not sure that those dlls are shipped with Delphi. There are some old threads about this error like

You can try WhichFailedToLoad from IdSSLOpenSSLHeaders to see which dll failed. Maybe a dependency on the dll. From where did you downloaded the open SSL dlls?

Okay so I've looked into this some more and I've got good news and bad news: The bad news is that this is probably "as designed". The good news, well I lied; There isn't any good news. If we look at other thread pool implementations "properly designed by skilled practitioners", the old Win32 thread pools also had a hard upper limit on the number of threads in a pool and suffered from the exact same problem. The newer Vista thread pools are a bit more clever but it still has an upper limit (I believe the default max is 500 threads) and suffered from the exact same problem. Same with .NET thread pools (which are a rewrite of Win32 thread pools); For CLR 2.0 the max is 25 threads per core and for 2.0SP1 the max is 250 per core. The reason for this tenfold increase in default max is actually to avoid experiencing deadlocks caused by running out of threads quite so often. Thus .NET too suffers from the exact same problem. See Concurrent Programming on Windows, chapter 7 for a discussion on all this. So the problem is that the RTL thread pool imposes a hard upper limit on the number of threads in it and that the limit is way too small. Ideally what we'd like, in this case, is for the growth algorithm to be a bit more intelligent and flexible but I doubt that will happen. The easy solution is probably to just increase the max and hope for the best 😕 . I still believe that the library should detect (and fail on) the simple case when all threads are blocked waiting for a thread to become available. It's relatively unlikely that this will occur in real code (there are many other things, not controlled by the PPL, that a thread can wait on) but it's so simple to implement that I believe it's worth the effort.

have you tried changing the file encode to UTF8 instead of ANSII, before insert the char? Despite being something quite peculiar and perhaps something to create future problems with the use of exotic characters, especially when this can bring inconvenience between platforms and editions of the IDE, since the RAD from time to time crashes due to a malfunction in the Editor of Code.

REST is just standard HTTP, usually with JSON data. Indy doesn't have any REST-specific components, but pretty much anything you can with other REST components can also be done manually with TIdHTTP. You use the token pretty much the same way you use any other SASL credentials with TIdSMTP: Add TIdSASLXOAuth2 to the TIdSMTP.SASLMechanisms collection, and set the TIdSMTP.AuthType property to satSASL. Assign a TIdUserPassProvider to the TIdSASLXOAuth2.UserPassProvider property, and then assign the retrieved token to the TIdUserPassProvider.Password property. Alternatively, use the TIdSASLXOAuth2.OnGetAccessToken event to retrieve the token on-demand. Use TIdMessage and TIdSMTP as needed (fill out email, configure Host/Port, UseTLS, etc, and then call TIdSMTP.Connect(), TIdSMTP.Send(), TIdSMTP.Disconnect(), etc).

I wish them the best of luck. I hope the product is not of vital interest to the company. They were somewhat between a rock and a hard place, having a legacy Delphi application with a sub par engineering team. But rewrites (in a completely new technology) rarely go well. (At least in time and in budget). Does your company already work with react or are they going to build a completely new engineering team, or even outsource the development?

They are trying. But - unfortunately they are trying the marketing way, not the grassroot growth way.

Good luck to them. Managers don't realize what they do. The problem is not only a "Delphi is old idea" but also "Internet is beautiful, you can do anything with React" marketing.

OpenSSL has released quarterly updates for the two supported branches, 3.0.1 and 1.1.1m, Windows binaries are available from http://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp . OpenSSL 3.0.1 fixes a medium security risk relating to clients verifying X509 certificates from the server, a malicious server could potentially send a bad certificate that caused the client to hang or misbehave during verify. https://www.openssl.org/news/secadv/20211214.txt Now OpenSSL 3.0 has been available for three months, updated the main supported OpenSSL release to 3.0.1. The samples SslInternet directory now has both OpenSSL 1.1.1m and 3.0.1, ICS will try and load OpenSSL 3.0 first, then 1.1.1 if not found, unless the global variable GSSLEAY_DLL_IgnoreNew is set true before OpenSSL is loaded. Likewise GSSLEAY_DLL_IgnoreOld may be set true to ignore 1.1.1 and fail unless 3.0 is available. This is available from SVN and the overnight zip. Note the binaries are now digitally signed by 'Magenta Systems Ltd' instead of 'Open Source Developer, François PIETTE' due to the massive cost of renewing the open source certificate. Developers can always resign the DLLs with their own signing certificate to remove the Magenta name. Separately YuOpenSSL has released both these versions as commercial DCUs allowing applications to be used with OpenSSL without needing separate DLLs. Angus