[barrkel]

VirtualAlloc is a better base for a custom memory allocator. It's closer to mmap + mprotect in functionality.

There's also CoTaskMemAlloc (aka IMalloc::Alloc). And COM automation has a bunch of methods which allocate memory for dynamically sized data, which could be abused for memory allocation - SafeArrayCreate, SysAllocString.

[astrange]

It sounds like they've invented 15 different ways to allocate memory rather than have malloc. What did they do that for?

(Not to say malloc is a perfect API, it’s definitely oversimplified, but they probably didn’t solve any of its problems.)

[barrkel]

The latter three are for RPC / interop / automation scenarios, simplifying the programming model for things like Visual Basic.

HeapAlloc (and legacy routines GlobalAlloc and LocalAlloc which wrap it) is mostly a relic of 16-bit Windows.

VirtualAlloc is the one that matters for language runtimes on Windows since Win32 API in the 90s, and it's designed to allocate slabs which are suballocated by more sophisticated code.

[qsdf38100]

malloc is just a C api, it’s not a syscall, and Linux is no different. malloc/free on Linux is probably using mmap under the hood, and doing some bookkeeping to decide when to decommit memory to give it back to the OS.

[astrange]

When did I say anything about syscalls or Linux?

[qsdf38100]

You said "they invented 15 ways instead of having malloc". By "they" you mean Microsoft right?

Windows does have malloc as a C api for programs using the C runtime library. Same as everywhere else.

Then, at the OS api level, there are indeed several memory management functions. But you usually don’t need them. Except if you are writing a custom memory allocator for instance. Also same as everywhere else.

So saying Windows has X memory management functions instead of malloc is incorrect.