David Heffernan

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.

That's Embarcadero's fault. They've known how to fix this for at least 10 years, and my patched version of the RTL fixes it. That said, the real issue isn't really a language issue. It's a platform issue. It all stems from the way floating point is implemented on x86 and x86-64 hardware.

Clearly the OP is using short string because the compiler says so. My question is to the OP. Why use short string?

Is there a reason to use shortstrings? It's 2024 now....

Does it even compile, and if so what does it mean?

What problem does this solve?

Delphi doesn't know that you want [] to be an array rather than a set. Because the language has been designed iteratively and there is ambiguity. Delphi literals are a bit of a mess. In any case are you sure that you want to use = with a reference type? That's reference identity and not value identity. You will need to test for Length(a)=0 or not Assigned(a) or a = nil

Top down memory allocation, which is what I presume this setting is, was how I found most pointer truncation bugs back in the day. It also broke just about every anti virus software that we tried, until I settled on the MS tool!

It's just that the reason isn't to do what you did

Please provide a link to this post and if it's wrong then we can correct it. Or perhaps you didn't interpret it correctly.

Hmm, maybe it's not fixed .....

Well, good, they fixed that one!

FWIW this is what I see with Delphi 11.3, and toolbar drop downs. I'm actually at 175% dpi, and running Delphi DPI aware. If I click on the left hand side of the drop down button next to the open icon, I get a file dialog. If I click on the right hand side of the drop down button I get the menu dropped down. I think that the same happens in my app if I use the VCL menu code, although it's so long since I looked that I don't remember the exact details. I'd be interested to know if the latest versions of Delphi IDE manage to handle this drop down hit detection correctly. Other problems I saw with VCL styles drawing menus was failure to scale check marks in high dpi scenarios. I ended up patching Vcl.Menus so that it uses Windows to draw the menus rather than VCL styles which even for the standard Windows theme is what you get for menus. This was gnarly with high DPI because I need to create and cache PARGB32 bitmaps, because that's how you get alpha blended menu icons in system drawn windows: Themed menu’s icons, a complete Vista and XP solution (updated) - nanoANT

Maybe they fixed it. My experience has been that every time they fix one bug, there's another one around the corner.

I tried recently and the toolbars still aren't right. Classic example is the behaviour of drop down buttons which open menus in high DPI. Try the file open drop down in, say 250 or 300%. You have to click on the very right hand side of the drop down. Context menus are a mess too. Coming up on the wrong screen. It mostly works, but there's just enough that doesn't for it to be no good. I'd like to offer my clients a dark mode but cannot.

VCL styles are still not fit for purpose and probably never will be

That's evaluated to a quietnan at compile time, just as it has always been