David Heffernan

EndDialog does it exactly the same way as Delphi does it, we already established that.

No, that call to Close should never be made. No ifs and buts. Stop guessing at how the system works. Really, how ?

Windows API can't expose a flag directly so has to provide a function to set it. You are incapable of learning, no wonder this is so hard for you.

Imagine if you would read documentation. Like that for EndDialog. And imagine if the documentation for EndDialog said this: EndDialog does not destroy the dialog box immediately. Instead, it sets a flag and allows the dialog box procedure to return control to the system. The system checks the flag before attempting to retrieve the next message from the application queue. If the flag is set, the system ends the message loop, destroys the dialog box, and uses the value in nResult as the return value from the function that created the dialog box. So yeah, it's exactly the same as the Delphi mechanism. Because that's how modal dialog are implemented in Windows.

Actually the Delphi approach is just the same. You just don't understand how EndDialog works.

Instead of ranting, perhaps you should take the opportunity to learn something and take advantage of it in the future. We all make mistakes. Failing to accept the is how people don't develop.

Wow. This is so wrong. That call to Close is definitely getting executed. Setting ModalResult doesn't raise an exception. Which would be the only way to avoid Close getting called.

yeah, global variables in your GUI, great idea!

As stated in the OP this is already being used. Virtual mode is the only answer.

I mean, the memory can get paged out again so it's not that terrible. Another issue is that the paging system can't share the memory between processes if it's in memory rather than loaded off disk. I still don't understand what actual problem people who want to make their executables a few mb smaller are trying to solve.

Even if you don't use a debugger, get your program to print out the intermediate values in the function square. Then compare it to your expectation.

Read the section on index specifiers https://docwiki.embarcadero.com/RADStudio/Sydney/en/Properties_(Delphi)

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.