David Heffernan

Well not necessarily. Typically you let exceptions float upwards to be handled by some high level exception handler.

Not obvious at all. Usually you allocated memory because you wanted to use it. If you've swapped the entire block to disk then bringing a couple of pages back is the least of your worries. Solve your problem by avoiding swapping in the first place. Nothing you have said, in my view, supports your claim that all allocation of huge blocks should be done using VirtualAlloc.

I don't see any benchmark to support the assertion that all allocation of huge blocks should be done using VirtualAlloc. Can you point to it.

A valid benchmark from a real world program would make me consider what I said.

Premature optimisation

Yes, that's what I envisage

Can't understand why you aren't calling GetMem.

Another option is to use a layered window to add the additional painting. This is very flexible, not limited to panels, doesn't require any changes to the implementation of the controls.

Two things can happen 1. The constructor succeeds and returns a valid object reference. 2. An exception is raised, propagates out of the constructor, and the assignment never happens.

The try finally here isn't protecting the execution of the constructor. It protects against exceptions in the code that runs after the constructor completes, after the try. Look at the code in your post. The try finally is not active when the constructor runs. If an exception is raised in the constructor then the try is never reached. So, yes, you do need the try finally.

I literally wrote class helpers. It will. That's a problem if you are using other helpers for the class. Are you?

This is what class helpers are for. Likewise.

It's possible that the changes you are making to the third party code should be made in your code instead, thus side stepping the problem.

A painful read from a development team that has bitten off way more than it can chew.

Doesn't seem plausible. FileExists doesn't care about spaces. You'll want to do some debugging on a machine that exhibits the behaviour.

could be a long wait

Replace that with AtomicIncrement or the Increment method from System.SyncObjs.TInterlocked

Problem could be how you call the function

It really makes not a lot of difference which vcs you use, compared to not using revision control.

If your program requires the covered code in order to function then I think your code needs to also be GPL. Worth talking to the developer of the code. Often they will dual license for such eventualities.

Probably it is mature now.

Not quite. The default initialisation is outside the function.

You don't get this because the return type is a managed type and so is actually passed as an extra var parameter. So the variable is assumed to have been default initialised outside the function. I'm not trying to defend the compiler design here. The handling of function return variables is a complete mess in my view. They should be passed by value from callee to caller. The whole hidden var param is a weird hack from the ancient past that should never have been done.

https://stackoverflow.com/questions/63111541/omnithread-delphi-many-calls-in-the-same-function For reference, here is the same Q on SO

Adding madExcept or EurekaLog or similar is the obvious way to find out what is going on here.