David Heffernan

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?

How?????

It's odd that the emba tool won't work directly with platform standard import libs. You'd think they'd find a way to do that.

All the details we'd need to say anything about your program.

I have never tried to allocate such enormous amounts of memory using Delphi's heap manager (Fastmm4), I really don't know how it behaves if you try to allocate one huge chunk that is bigger than what the machine has physically. These huge blocks won't be allocated by fastmn. They will be passed through to VirtualAlloc. But we aren't talking about a chunk of memory greater than what the machine has physically anyway. I'm rather sceptical that MMF would ever be appropriate here.

Doesn't memory already handle all of this? I mean, the paging system does all of this already surely?

They control the code for all processes involved. That's the crucial difference.

Why would a memory mapped file be remotely helpful here?

No. I have classes that have similar methods. For example, my reader class can be used with while/readln pattern, or a for in loop.

You can add buffers wherever you like. I have line based text file readers and writers that buffer actual file access.

Read the code of an open source project that does this and work out what they do

You don't need to use these apis to have buffers

One was mentioned above. But there are lots. This looks solid https://github.com/vilya/miniply

Does the C library handle binary format?

Clearly it's a procedure not a function though.