David Heffernan

What actual problem does this cause? How does this affect what you do?

I personally want my program to run on Wine. Seems like Crowdstrike is the problem. Do you sign your executables?

No, they are fundamentally different things in terms of implementation.

You might want to start with a beginners book to learn C++ that will take you through all of this learning. And you definitely don't want to be using character arrays when strings exist.

Your job is to gradually remove code from your app until the behaviour is the same as a simple example. Good luck.

Probably the benchmark code is not telling you anything useful

Imagine we are starting at the beginning of this post. What are we to make of what is in this page alone?

Remove packed and it's probably alright.

The OP

Recurring theme here is that you think that everything else is at fault when you can't achieve things that others can. Perhaps you need the curiosity to ask why this is.

Doesn't always exit with a Break

I actually don't know how that is interpreted by the compiler

This is a really good point, and very nicely expressed. Essentially the whole thing boils down to Delphi literals having ambiguity of type. Sets and arrays use the same syntax. For integers, what type is 1, how can I make sure that it is signed or unsigned, 8 bit, 16 bit etc. And 1.0, is that single or double? Why can't I state this explicitly. Other languages have these facilities, Delphi lags behind in this area.

Not sure who Dave is.... Delphi doesn't know that the type of the thing to the right of the equality operator is an array, it thinks it is a set. That's why you get the error. You might not like this, but this is just how it is right now. From the language perspective, there is clearly some magic disambiguation applied in the case of the assignment operator that isn't applied elsewhere. As Remy says, all you can do is to open a ticket. Shooting the messenger isn't going to get you anywhere. But even if the code did compile, what would you want it to do? For dynamic arrays, like other reference types, the equality operator = means reference equality. But I suspect that you would want value equality. So even if this code ever compiled, I don't think it would do what you want to do. In which case you will need to implement a method or function to perform value equality testing, and so the topic becomes somewhat moot.

I don't think your expectations are reasonable. You can't expect to mix and match Delphi versions like this. When you are ready to upgrade, do it in a coordinated and unified manner.

Try calling BringToFrontNoCap()

Hardly. It's possible, indeed common, for one person to be working on multiple branches

Use names. The performance issue you describe doesn't exist.

If the OP would explain the original motivation behind this, then we could propose proper solutions to the actual problem. This is a canonical XY question.

You can add to a counter when allocating new blocks, and decrement when deallocating, and then you find bleat if the counter is non-zero on exit

Rather than re-compile the RTL you can register a custom memory manager, which is very easy to do backed with MSHeap. And then you can add simple memory leaks on shutdown reporting. I actually do use the MS heap for my MM because I want to implement a per thread MM so that I can get decent performance on NUMA systems.

I'd definitely not be using Shortstring for that. But the asker has talked about the usage being for database. So RS232 not pertinent.

Same as always. Numerical programming. And when there exists huge amounts of code in a language, it can be hard to leave. A phenomenon well known to us Delphi programmers!

Different use cases will suit different libraries. You gave no indication of what your motivations and goals are.

Or when calling into a Delphi DLL.