a tiny part of points that come to my mind:
- education
- iteration on writing simple functionality
- loading and trying out several APIs to see what's possible (I use it frequently with Elixir / Erlang for example)
It makes life easier for newcomers to wrap their head around something and produce a good solution rather than a "working" one
https://learn.microsoft.com/en-us/windows/win32/api/heapapi/...
> HEAP_CREATE_ENABLE_EXECUTE
> 0x00040000
> All memory blocks that are allocated from this heap allow code execution, if the hardware enforces data execution prevention. Use this flag heap in applications that run code from the heap. If HEAP_CREATE_ENABLE_EXECUTE is not specified and an application attempts to run code from a protected page, the application receives an exception with the status code STATUS_ACCESS_VIOLATION.
I think POSIX has equivalent memory protection calls, but no equivalent to HeapCreate
I don't think Windows provides a mechanism to disable creating any further executable pages, although I've seen Chrome do it by hooking those functions (and I know it because I've had to bypass it :)).
>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 advantage of a lot of scripting tech is some form of REPL, which is really just a super-fast code-compile-run loop. In your example, "why?" boils down to how useful/painful those five seconds-per-change are. Maybe that adds up and slows the coder down, or maybe it's no big deal. It all kind of depends on the workflow and how fast you need to be able to iterate on code changes. Moving to a scripted interpreter would eliminate that wait period at the cost of runtime performance, which might be a valuable business tradeoff.
FWIW, that "script" solution sounds awesome for the time. I'll add that five seconds to build a hot-loaded DLL in the 90's is really, really good performance for that solution, regardless of its role as a scripting alternative. Today, that would probably be mere milliseconds to compile - impossible to distinguish from an embedded LUA or JS solution.
Borrowed this idea from Nothing Real, the developers of Shake, the video/film compositing system.