David Heffernan

The Delphi RTL can do this in multiple ways, as discussed here, and elsewhere, by me, ad nauseum.

Not strictly true. It depends on where they are coming from. It's much more complex than this blanket advice which I always regard as poor advice.

It's exactly as @Stefan Glienke said. The 32 and 64 bit hardware is different. On 32 bit there are 80 bit floating point registers used for intemediate values. On 64 bit there are not and all FP registers are 64 bit. Did you read the link I gave you? If you have not read that yet then this conversation is rather pointless? You first of all have to appreciate that these values cannot be represented exactly in binary floating point format. Perhaps your real problem is that you are using the wrong data types. Maybe you should be using a decimal data type so that you can represent these values exactly? What are these values? Sometimes floating point is correct, sometimes decimal is correct. Without context we can't know. Or perhaps you already know about floating point representability issues. Do you?

Here's some Python output that should help: >>> from decimal import Decimal >>> Decimal.from_float(1.015) Decimal('1.0149999999999999023003738329862244427204132080078125') >>> Decimal.from_float(3.015) Decimal('3.015000000000000124344978758017532527446746826171875') >>> Decimal.from_float(1.015*100) Decimal('101.4999999999999857891452847979962825775146484375') >>> Decimal.from_float(3.015*100) Decimal('301.5') And @Stefan Glienke explained why results differ on 32 bit because that uses an intermediate 80 bit extended register that will have different values for the closest representable value.

You are going to lose your mind when you learn that 1.015 is not representable, and when you write 1.015 in your delphi source code, the compiler turns it into the closest representable number which happens to be 1.0149999999999999023003738329862244427204132080078125 You might want to take a look at this famous question on SO: https://stackoverflow.com/questions/588004/is-floating-point-math-broken

Why should we do this?

You'd have the answer by now if you'd started stripping stuff out

What does the debugger tell you

There's also this technique

Simple. Develop in the lowest version that you wish to support.

That's not what AQtime does. Vtune is essentially analogous to AQtime but far more capable. You aren't going to find this magic solution that you want, whereby you wave a magic wand and your program is suddenly much faster. Optimisation though is going to take effort from you to understand your program. No shortcuts.

Buy a GPS watch. Or install strava on your phone.

I can't make any sense of this. Maybe an complete but minimal program would help, and knowledge of whether your process is 32 or 64 bit. Also, do you know about sysnative?

Well, true, but everything would break. So it's not going to change. And I think that's why it has been documented. I think it wasn't originally documented but at some point MS realised that this has become a contract that can't be broken.

I wish the language would require parens for parameterless calls.

An HMODULE has always been the base address of the module, as loaded into its process. And it's documented here: https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types#HINSTANCE

Stack location has never been repeatable. And as for the module, it starts at HInstance. As it always has. And DLLs have always needed to be relocatable. It's just Windows EXEs that previously could be relied upon to have a known start address. So yeah, change $00400000 to HInstance and it's all good.

Yeah, don't understand why you think that this is a Delphi issue. The executable that Delphi produces is fine. You then mangle it and it fails. Speak to the developer of the code that mangled your exe. It's common, and always has been, for such so-called protection schemes to fail. It's the risk you take on when you start mangling executable files like this.

Probably the issue is in your code to do this encryption. We don't know what that code is.

If you look at other IDEs that have console windows, they don't do cross process window parenting.

Why would we even need to call Update. I think I'd want to understand that first, because it's probably indicative of a design flaw.

There's literally one in this thread.

That's pretty funky. Sadly not practical for actual use.

It's obviously more complicated for the programmer to use MMF than plain memory. Unless there was a benefit to using MMF then there's no point in taking on that complexity.

If you simple want a block of bytes, just use memory. Why use MMF? Here’s an example of why you might use MMF, for cross process sharing. But that isn't what this topic is abkut. I can't see anything in this topic that suggests that MMF would add anything over plain memory. Or have I missed something?