David Heffernan

No. That's a library for creating unmanaged exports from a managed library. So you take a C# library and use DllExport attributes to allow unmanaged code, like Delphi, to consume that C# library with LoadLibrary, GetProcAddress, etc. The question being asked here is very different. It asks if it is possible to make a managed library with Delphi. And that isn't possible.

I'm betting that improving the performance of InRange has no impact on the performance of these reports.

Use a SAX style parser rather than DOM style parser is sometimes an option

Step 1 is to inspect the state of the floating point exception masks while your program is executing. Use trace debugging to do that. Check whether or not my hypothesis is correct.

It's a helper for TArray, not for TArray<T>, by necessity. I think spring4d has something similar.

If you aren't going to reuse existing delphi code then you should also evaluate other tools.

How would you handle non ANSI input?

It's all proscribed by ieee754.

Are you talking about maths, or talking about ieee754?

Well, this depends on whether or not exceptions are masked.

I'm not recommending anything. I'm just stating how ieee754 defines these operations.

Well, for ieee754 the former is NaN and the latter is +inf.

Do yourself a favour and check whether exceptions are masked in the two programs at the point where exveptions are raised.

Probably you are calling some code, typically in a DLL, which changes the floating point control status to mask exceptions. Delphi default is for them to be unmasked, but most other Windows dev tools mask them.

Well, Delphi's floating point library isn't threadsafe so they can have a party together!!

Reading Marco's article on the recently released patches for 10.4.2 I noticed this text: Is that right? If you don't keep an active update subscription, you aren't entitled to bug fixes?

The code fails to compile in XE7 with the same E2512 error. I consider a set type to be a non-nullable value type so this must be a defect.

SetWindowDisplayAffinity(Application.MainFormHandle You really need to be calling this method from CreateWnd because of VCL window recreation. Also it's kinda odd that you would use MainFormHandle from a method of the main form. Why not use Handle? But it's important to move that code to CreateWnd.

You are on subscription when 10.4.2 lands, and then the subscription expires a month later.

Neither is more suited than the other for multi-threaded programs. I don't think your usage scenario is particularly challenging or unusual as you seem to think.

You have already had numerous suggestions that meet all your requirements.

Seems like a sound idea to me

Far quicker at this point to subtract $00401000 from the address (assuming it's an exe loaded at $00400000)

This is way more complicated than you might hope. Your VCL app will run a message loop that is designed for VCL. It's not going to be able to service your FMX form. I don't expect there is a simple solution. btw, INVALID_HANDLE_VALUE is for HANDLE types, i.e. THandle in Delphi. For an invalid HWND use NULL, which is 0 in Delphi.

EurekaLog and madExcept can both do this. It's no big deal at all.