David Heffernan

Yes. You have to declare a pointer type.

All I am saying is that you don't need to special case INFs for comparison.

You don't need to do anything with INFs, they compare exactly as you'd expect.

Not a bug. All comparison operators return false when one of the arguments is NaN. https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values Also, bug reports are best at Quality Portal. Although not this one, because it's not a bug.

That's exactly the error I'd expect and the debugger will break at the line of code that accesses the uninitialized pointer. None of these tools will make much difference to this sort of debugging. You just need a slightly better understanding of how memory errors manifest and how to let the debugger tell you what's wrong.

Well, how are you printing at the moment, if not using GDI? And GDI printing must be like 30 years old now.

Yes, this is precisely what I currently do

Encrypting the map file, and then decrypting on runtime doesn't add much security. Your map file would be readily reversible by any moderately skilled hacker. If you want to keep the map file private, don't add it to your exe and decode the stack trace addresses into method names when the bug report is sent to you.

Answer can be found in the documentation of Sleep. Sleep can only wait for multiples of system ticks. And your system appears to tick at a frequency of 15ms. Which is typical, that being the default tick frequency. There are many many discussions of this online. Here's one: https://stackoverflow.com/questions/3744032/why-are-net-timers-limited-to-15-ms-resolution

Yes, I understand the behaviour, but I just don't know the use case. I guess it just be some exception handling model that I've never used. Like Mathias I tend to raise a new exception, or re-raise. But obviously breaking language feature is not desirable.

I guess that like Mathias I don't understand the use case for the code which madExcept is making fail.

And what about Mathias' response in that thread?

madExcept does support nested exceptions.

That does sound funny. Is it true though?

Are you saying that it was in the end nothing to do with your SetLength calls and was just a defect somewhere else in your code that corrupted the heap?

That doesn't change anything. That is just wasteful. We know that dynamic arrays work correctly. If you really want to resolve the problem you need to clearly identify it first.

The code that we can see can't leak. There is likely a bug in some other code, probably your code. If you show a minimal repro we'll find it easily.

Using all your memory doesn't necessarily mean that your computer would be slower with less. It usually just means that your computer is making the disk cache as large as possible.

If running Delphi is the biggest concern that you have, as you stated above, then it looks like you are significantly over-speccing this machine.

I don't see l any good reason why the IDE stability would have anything to do with hardware. It's just bug ridden. Those AMD processors are pretty tasty. Gamers love them. But they are way over powered for Delphi. Most important thing you can do for Delphi IDE perf is have a good SSD.

I meant the startup cost for the developer to learn how to create and maintain and deploy com servers.

Whether you opt for pinvoke or a COM server depends very much on what the interface surface area looks like. I don't think anybody can give you a valid recommendation without knowledge of that. Broadly speaking, for more larger and more complex interfaces, then a COM server may be preferable. For simpler interfaces, then p/invoke may be preferable. It is more effort to setup a COM server (especially if you have to learn COM), but having done so the coding on both sides will likely be simpler. For larger and more complex interfaces the startup cost of a COM server will yield time savings to offset that. For an interface that can be represented by a small number of functions, then you will never recover that startup cost, hence why p/invoke would win. To my mind at least those are the main factors to consider in your decision.

What other tools use pdb? I think pdb files can be used to get stack traces in Process Explorer and Process Hacker 2. Obviously there is Visual Studio and there must be many others. I wonder if anybody has tried using the pdb files generated by map2pdb with other tools such as these.

Hope you and your family recover fully @Lars Fosdal.

The fact that the term "scalable memory manager" exists shows that heap allocation is a particular issue for multi-threaded programs. That's the same point that I have been making.