Write data to incbin?

Is it possible to write to a file which I have previously included in my binary with incbin?

Could I have a Data-File with player keys and stuff in my exe and change that file in some way after compilation from the program itself. I feels possible aslong as I don't change the length of the file. I simply change that data which already exists.

Can anyone explain, has anyone tried?

Or should I use incbin to store "Default" data only?

Something that is 'incbined' is no longer a file in it's own right. It's a data chunk (platform dependant?) in the main binary, and is as far as I can tell loaded into memory in it's entirety at runtime.

You can create a Bank from Incbined data, and access that if that's what you want to do.

There is a command, I forget what it's called, to get the address pointer of the start of the incbin'd data. I don't see why you couldn't then use that to modify the data, it should work at runtime. You'd just want to be sure that the CPU cache is flushed before reading it back, I've no idea if that is handled automatically or not.

It's a pity that incbin'ing data which then needs to be unpacked in some way, like an image, requires more memory - memory for the original file and memory for the unpacked version (e.g. image data).

Just wondering, if they allowed you to execute incbin data, you could incbin plugins and run them? Or at least, maybe there should be an "ExecuteAt BytePtr" command?

Or load them into a Bank. It wouldn't actually work though becuase PE32 (Windows binary format) has all kinds of junk as a header which will be executed first, probably crashing the machine. Only including an .o (object) file probably wouldn't work either as there are bound to be some unresolved symbols, and it'll have to be runtime-linked.

It would be cool tho'. That's for sure.

Aside from the general issues of executing code at a memory address, you will also start running into compatibility issues:

The later generations of CPU's have a No-Execute support, where they simply refuse to run programs that are located in memory addresses designated as holding "data". (To prevent many of the infamous buffer-overrun exploits)
So even if you could get this to work on your 'current' system, it wouldn't be future-proof.

Then I guess we'd need some way of loading a plugin to an appropriate type of memory.