App Sandboxing and VBS enclaves go onto that direction.

I wouldn't expect windows to prevent creating further executable pages; there are legitimate use cases for creating dynamically allocated executable memory. It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)

There are legitimate uses, but the point would be that the process could ask the system to lock it down with whatever executable code is already present. This could be used to prevent already running code from tampering with the process' behavior by loading new code, or to thwart code injection.

>It just means that whatever foreign data you load into those pages can't execute, which is a security mechanism (for example, game save data can be loaded into these heaps so that you can load all game state but without the save file potentially running foreign code)

But malloc() and all the other standard memory allocation functions already return pointers into non-executable pages, anyway. Perhaps those functions call into this one internally, but using this over whatever your language offers by default offers no additional protection.

The benefit of heapalloc and heapcreate is that it makes serialization of data simpler because you can define the bounds of the heap so you can easily save pointer offsets. There are other flags available as well. It's a win32 feature so you would only use it if windows is your target platform (and then write other bindings for other platforms)

I still don't get it. Why can't you do the same with a regular buffer?