Remy Lebeau

Despite its name, UCS4String is not actually a native string type, like (Ansi|Raw|UTF8|Unicode|Wide)String are. It is just a dynamic 'array of UCS4Char', so a null UCS4Char is added to the end of the array to allow for null-terminated-string semantics, ie you can type-cast a UCS4String to PUCS4Char and iterate the string up to the null terminator, just like any other null-terminated P(Ansi|Wide)Char string. UCS4String was introduced way back in Delphi 6 (when UTF8String was first added as just an alias for AnsiString), so it couldn't be added as a true native string type back then. They never made UCS4String into a native string type, even though the RTL is now flexible enough to support a native string with 4-byte characters. All of the necessary plumbing was added in Delphi 2009 when UnicodeString was first introduced and UTF8String was turned into its own unique string type. UCS4String could easily be made into a native string type now, if they really wanted to. They probably haven't done so yet because UCS4String is very seldomly used by anyone, so they likely didn't want to waste development resources on it. Yes, because Length() is simply returning the full array length, which includes the null UCS4Char at the end.

It was introduced in Delphi 2007 for .NET, so it might not have been available on the Win32 side yet.

The TDictionary in question is the FFormRegistry member of the FMX.Forms.TApplication class. It is used internally by TApplication in its CreateForm(), CreateMainForm(), RegisterFormFamily(), and GetDeviceForm() methods. For what reason, I have no idea.

Yup, I've been in the exact same boat. That's why my big monolithic (C++Builder written) app still works fine for over 2 decades, and our .NET ported web-based app doesn't 🙂

That implies that a non-nil TObject is being released by ARC, and the TObject itself is likely invalid. That call stack shows the global TApplication object being destroyed, which in turn is destroying an internal TDictionary<String, TList<TFormRegistryItem>> object. Looks like perhaps the destruction of one of the stored TFormRegistryItem objects is what is crashing.

Because the error is happening inside the debugger itself, which is obviously written in C++. Maybe this will help you: 64-bit Debugger Assertion Failure lastErr == WSAEINTR Can't run new project in win64 mode, but win32 mode works fine

The List Separator is expected to be 1 character, but is documented to allow up to 3 characters: Doubtful, but the API is probably intended to handle MBCS characters, which I would expect the API to convert into proper UTF-16 characters when queried (and hopefully they fall into the U+0000..U+FFFF range so they fit into a single Char in Delphi 2009+).

On Catalina, you can use PAServerManager instead of PAServer directly, but do note that PAServerManager does have one known issue, at least: RSP-26374: PAServerManager on macOS Catalina don't store its config

Yes, WH_(SYS)MSGFILTER hooks are injected into every process that is being hooked, if hooking other processes than the one that is installing the hook.

Which specific environment variable are you trying to set?

I have seen many people report many problems with the PPL over the years. And for that reason, I REFUSE to ever use the PPL at all. I don't trust it. It hasn't worked right since day 1, and Embarcadero just can't seem to get it right. I prefer to stay in control of my own threads.

That leak report is suggesting that a UnicodeString allocated when the TCanvas.Font property creates its HFONT handle is being leaked. Why, who knows. The only UnicodeString I see allocated in TFont.GetHandle() is from a call to System.UTF8ToString(), and the compiler should be cleaning up that UnicodeString automatically when TFont.GetHandle() exits. That being said, do note that TBitmap and TCanvas ARE NOT THREAD SAFE. One thing I notice in your code is that you are unlocking the TBitmap canvases after drawing, but you said that the TBitmap objects are being "freed later". As soon as you unlock the canvases, the main UI thread is free to swoop in anytime and free the GDI resources behind the TBitmap objects' backs. That very well could cause race conditions that lead to problems. You have to keep the canvases locked for as long as you are using the TBitmap objects in a thread. Otherwise, don't use TBitmap in a thread at all, use straight Win32 API calls instead.

That should be using addFlags() instead of setFlags(). By using setFlags(), you are overwriting your FLAG_ACTIVITY_NEW_TASK flag. You can still use TJnet_Uri.JavaClass.fromFile() in earlier Android versions. You didn't need to change that part of the code to use TJnet_Uri.JavaClass.parse() instead.

Thanks, I'm already aware of that implementation. I had discussions with the author about it, I just haven't had a chance to incorporate it directly into Indy yet: #49 Create an SSL IOHandler for Win32 that uses Microsoft CryptoAPI instead of OpenSSL

Well, how do you expect people to help you when you don't show everything you are doing? How do you know the resources are even being leaked at all? Do you have a leak report from somewhere?