DelphiUdIT

It's been slow for me since yesterday morning, with timeout as well.

@Anders Melander Your analysis is certainly more in-depth than mine, I agree with your assessments.

The posts don't appear aggressive, and the topic is interesting. It's obvious that, referring to a company, the purpose is subtly commercial. Furthermore, the link makes a clear request: it's not in any way blatantly disguised. If the forum administrators deem it appropriate, the link could be removed (as is standard practice), given that the topic hasn't been posted on the dedicated announcements page. Adding a note such as "link removed due to violation of terms" might be a good indication. But be careful, as many other posts contain references to commercial sites as a guide for users... you need to think carefully and act transparently.

Over the years, we've all had more or less the same problems, although Delphi certainly has fewer issues than other competing languages. I port all "maintained" projects—those that customers pay for maintenance—and active ones to the latest version of Delphi/Rad Studio. And I always have a single version (the latest) of Rad Studio in production. My porting efforts are primarily prevention: I only use third-party products with source code; I don't use the latest developments without thoroughly testing them; I comment on the source code with a lot of information, perhaps too much; I try not to use anything labeled "deprecated" or "obsolete"; I try to use proven technologies that I know work; Once a new technology is established and working, I gradually update my code (both old and new) so as not to be left behind in upcoming releases. I certainly don't have any problems with staff leaving: I don't have any. I have collaborators, but they always send me the source code, which I then verify and recompile myself (not just in Delphi). With these precautions, I've never had any major migration problems. N.B.: This doesn't just apply to Delphi, but also to other libraries (more expensive than Rad Studio) that generally require much more effort to update. Integration is certainly the most important part, but not for Delphi-related updates. Then come the components (especially the graphical ones), which can cause some problems if updated. Business logic has never been a problem.

You can download them form github. They have the "Install" utilities to simplify the installation in Rad Studio: https://github.com/project-jedi (Jedi, Jcl, Jvcl)

Assign it to a byte var for example, or try to use an helper (.toString) or ....

@Joined72 I tested it on old system and it's true that in Android 64 the app crash. But I tested various exceptions and only this particolar form of literal dereferencing crash the application. PByte(nil)^ //<---- this is what in Android 64 crash the app. Also other type of pointer like "PInteger(nil)^" do the same. var a: pointer; a := nil; PByte(a)^ //<---- this throw an exception If you dereference a normal variabile wich value is nil, an exception will throw but the application still run. If no other person on the forum can help, open an issue on QP. Even if that kind of "writing" doesn't make sense, it still shouldn't crash the program. P.S.: Try / except block doesn't work, the application crash inside.

Are you kidding me Why would you do something like this? It definitely crash the app. You deferencing a nil pointer (and this is already a mistake), and you write inside too.

You must give us more informations and you must try to debug the application to see where it crash. After that post some part of relevant source code. We do not have the magical globe.

I don't think it'a a viable solution for Delphi 7. But the last words belong to @Remy (Indy) and @Mugaas (TaurusTLS), of course. Try to open an ISSUE in their github repo (https://github.com/IndySockets/Indy) and ( https://github.com/JPeterMugaas/TaurusTLS)

For me too.

This is the new link for offline help chm updates. https://docwiki.embarcadero.com/docs/products/rad_studio/ The help published now works offline, the original released and the previous update didn't work offline. The help files are dated September 11, 2025.

For my tasks, "FreeOnTerminate" is always set to False in all my applications. There are a lot of reasons for that (I repeat, for my uses), one of them is that I need a waitable thread 99% of the times. If your thread release a resources, then you must use the "waitfor" or similar since the thread can be busy before free it or resuse it (and this is the real reason why I cannot use FreeOnTerminate). And even if there's no need to release resources, there's no way to know when a thread with FreeOnTerminate set to True will actually terminate. By running tests under load and in a 64-bit Windows environment (my applications generate an average load of around 75% on 32-thread Intel i9 processors), I found that low-priority threads take a long time to release. In some cases, it can take up to a few tens of milliseconds, so without a WaitFor, it's a risk.

Never had such issues. I use a lot of TThreads (form 5 to 50), all manually created and destroyed in my applications. But "FreeOnTerminate" is always set to FALSE. Never used it with True sets, except in anonymous threads. And I don't create and destroy most threads continuously, but leave them in a WaitFor state, until I use them again. I'll try to do some tests in one my application left them to "autofree" ....

If you want to use RDRAND and RDSEEK, I attach the sources so you can see how they works. These is another topic where we talked about: https://en.delphipraxis.net/topic/10271-getting-rdseed-with-delphi/?do=findComment&comment=81868 These two instructions works in Intel and Amd CPU only (x86 or x64). In Arm they were introduced recently and the behave in slightly different way. In the source there are some lines commented that you can delete. These have been in use for at least 4 years in all my production programs without ever having given me any problems. They have also been in use and constantly monitored for a year on a test web server (to check the workload and performance in a multithreaded environment). Unit11.zip