Remy Lebeau

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?

Are you ever Free()'ing the TBitmap that you Create()? The code above does not show that. If you are not, then not only is the TBitmap being leaked, but all of the resources associated with the TBitmap.Canvas (its Brush, Font, and Pen) are leaked as well. And in the code you showed, it is possible that those resources are not being allocated until the call to Canvas.CopyRect(), which is why you would think CopyRect() is the source of the leak.

You are simply not allowed to use `file://` URLs to share files via Intents anymore. Which means your call to Uri := TJnet_Uri.JavaClass.fromFile(AttachmentFile); Will still produce a valid 'file://' URL, you just can't use it in your Intent anymore. You need to add a FileProvider to your Android app and manifest, and then you can use 'content://' URLs serviced by that provider for any files you want to share access to. See Sharing files and Sharing files through Intents: are you ready for Nougat? for more details.

That hasn't been my experience in my 20+ years using (almost exclusively) C++Builder.

Because it still has access to the VMT of its own class type and its ancestors, so will still respect virtual dispatch for that part of the class tree. It just does not have access to the VMT of any derived classes. But, to be honest, in what use-case is it ever useful to call a virtual class method inside of a static class method in practice? The whole point of static is to ignore particular instances, and polymorphism is all about focusing on specific instances.

If you do that, you will need to use the 'delayed' keyword on those function declarations if you want your app to run on pre-W7 systems. Then you can use the functions on W7+ only, and fall back to SetThreadExecutionState() on pre-W7 systems. If you really wanted to be slick, you could then use SetDliFailureHook2() to detect when the Power...() functions are not available at runtime and re-map them to custom functions that allocate a memory object and pass its details to SetThreadExecutionState() as needed. Then your code could call the Power...() functions unconditionally on all Windows versions.

The *correct* way to block the screen saver on XP and later is to use SetThreadExecutionState() with the ES_DISPLAY_REQUIRED flag: PBT_APMQUERYSUSPEND is just a *request for permission* to suspend the system. The system is not actually suspended yet. So you should not be setting your SystemSuspended flag to True in reply to PBT_APMQUERYSUSPEND, only for PBT_APMSUSPEND. And then clearing the Flag in reply to PBT_APMRESUMESUSPEND and PBT_APMRESUMECRITICAL, not just for PBT_APMRESUMEAUTOMATIC. SC_SCREENSAVE and SC_MONITORPOWER are not window messages, they are flags of WM_SYSCOMMAND, so your 1st "If" block will never evaluate as True. Same with the last "If" block here, too. Also, per the WM_SYSCOMMAND documentation:

Note that CodeCentral is going to be shutdown soon, see The future of CodeCentral announcement in the Embarcadero community.

There used to be several in Quality Central, but they were lost during the migration to Quality Portal and the shutdown of Quality Central.

A Handler callback (what TService uses) can receive only the following control codes from the SCM: SERVICE_CONTROL_CONTINUE SERVICE_CONTROL_INTERROGATE SERVICE_CONTROL_NETBINDADD SERVICE_CONTROL_NETBINDDISABLE SERVICE_CONTROL_NETBINDENABLE SERVICE_CONTROL_NETBINDREMOVE SERVICE_CONTROL_PARAMCHANGE SERVICE_CONTROL_PAUSE SERVICE_CONTROL_PRESHUTDOWN SERVICE_CONTROL_SHUTDOWN SERVICE_CONTROL_STOP User-defined codes A HandlerEx callback can receive all of the above controls codes, as well as the following additional control codes: SERVICE_CONTROL_DEVICEEVENT SERVICE_CONTROL_HARDWAREPROFILECHANGE SERVICE_CONTROL_POWEREVENT SERVICE_CONTROL_SESSIONCHANGE SERVICE_CONTROL_TIMECHANGE SERVICE_CONTROL_TRIGGEREVENT SERVICE_CONTROL_USERMODEREBOOT In addition, when a service registers its HandlerEx callback, a user-defined context value can be passed to the HandlerEx whenever it is called by the SCM. That option is not available when registering a Handler callback. Also, there are newer APIs for apps to interact with the SCM, like ChangeServiceConfig2(), ControlServiceEx(), EnumServicesStatusEx(), QueryServiceConfig2(), QueryServiceStatusEx(), etc.

A long time ago, yes (amongst several others). BlueStacks "worked", but it was pretty slow and unstable at the time, though. Maybe that has changed over the years, I don't know.

Once upon a time, Indy had a larger dev team, but I suppose no-one ever had the time or opportunity to implement SSH. Not that it is a trivial protocol to implement, what with encryption and all. Now I'm the only dev left, and I definitely don't have the time to do something that large-scale on my own. I don't even have a working SChannel IOHandler working yet, and that is just using a few (albeit complicated) system APIs. I suppose someone could write an IOHandler wrapper for libssh or similar library, though.

The response's "Content-Type" header tells you the exact format of the data, such as " application/json", "application/xml", etc.

That is still the case. And that is my only complaint I have about TService - lack of access to newer SCM features introduced since Win2K (and I have complained about it for years, and posted several QC tickets about it, which are now lost and I don't care to repost them). Most things I can just work around in my own code by calling various APIs directly. But TService's use of an old Handler() callback instead of a newer HandlerEx() callback is still an issue for some features to work correctly.

Most of my services are written using the standard TService, with separate apps for their UIs. But I do have one service that runs in both service and app mode, and I use SvCom for that project.