If you know how much memory you need, you can just have a section of zero-initialized-data for that, which the allocator then handles. The allocator serves also as a proxy, as in: only the allocator needs to know how to request heap space. Portable in that case probably means that you have little to no code change required for a port.

Something else to consider is that there may not even be an operating system the program was run on.

You don't need to avoid _all_ system calls. Just call sbrk/VirtualAlloc/vm_allocate once and then dole out smaller chunks yourself.

That way if you need to add new platform, it's only one place; you're shielded against weird platform bugs (Apple goes one way, Microsoft the other), so the app behaves the same; you can tweak system to your particular use.

I suppose if you're willing to malloc big chunks and then potentially never have them released until the process terminates (as free often doesn't do this), one might call that writing one's own memory allocator despite not using mmap / VirtualAlloc.

https://www.hboehm.info/gc/ is a windows+linux+unix allocator implementation - it uses VirtualAlloc on Windows and mmap or sbrk on Unix.

For performance reasons (avoiding a syscall) almost all malloc implementations only use sbrk / mmap occasionally and keep the malloc calls in userspace.