This is why memory allocators should be linked into applications and should not be considered operating system components.

▲

GuB-42 2 hours ago | parent | next [-]

If an OS update gives me a better allocator, I want every app to take advantage of it. Same idea with other libraries, if I update a library for reading zip files to make it go faster, or to fix a vulnerability, I want every application that uses that library to take advantage of it.

This is a debatable position. Linux distros usually do this, but a lot of modern applications ship with all their dependencies. I'd say the former is more efficient and generally better from a user perspective and the latter is more stable and is generally better from a developer/maintainer perspective. Open source encourages the former, proprietary software encourages the latter.

▲

fredoralive 2 hours ago | parent | prev | next [-]

How does the memory allocator statically linked into the application request a new memory allocation into it's address space (sbrk or VirtualAlloc etc.)? Allocating memory will in most cases involve calling into the kernel, it's kinda a core function of a kernel. It has to have some link externally to the programme, directly or indirectly.

	▲	simonask 9 minutes ago \| parent [-]
		The smallest amount of memory you can request from the OS is a page (typically 4K, sometimes 16K), and there’s a lot of additional stuff that goes on in malloc().

▲

pcwalton 4 hours ago | parent | prev | next [-]

Userland system DLLs need to allocate memory too.

▲

irishcoffee 3 hours ago | parent [-]

Whenever I write I library I don't allocate memory. If memory needs to be allocated, the program calling into the library allocates memory and passes a pointer (or reference I suppose) into the library call.

Clearly this can't be enforced, but I've always found it bad practice to allocate memory inside a library.

▲

jz391 an hour ago | parent [-]

How to you manage the API when caller doesn't know the right size to allocate? I mean you could pass an allocator object (ala zig/C++ stdlib etc), though I'm not sure I like the extra arg on functions... I guess a quasi-global-variable approach (e.g. a "context" object, passed to all functions, which can hold an allocator, or equivalently implicit arguments in a functional language) would be one way to achieve that without the "noise" of explicit allocators passed everywhere.

	▲	okanat 31 minutes ago \| parent [-]
		You can also design a "dual-pass" API. Basically you have an API call to estimate or calculate the memory usage needed and then another parameter / API call to actually do the operation. For example the WideCharToMultiByte [1] function of Win32 handles UTF-16 to UTF-8 conversion. If you pass your destination pointer as NULL, then it purely calculates the number of bytes you'll need in your buffer. Then the main program actually allocates the memory and calls it again with the populated destination pointer. [1]: https://learn.microsoft.com/en-us/windows/win32/api/stringap...

▲

rowls66 4 hours ago | parent | prev | next [-]

And when you are running more than one application at the same time how is that supposed to work?

▲

hyperhello 4 hours ago | parent | next [-]

It works fine. The processes get a fenced off piece of memory and are allowed to portion it out to themselves any way they prefer. Syscalls are designed to be mostly neutral about how the app wants to proceed.

▲

bigfishrunning 4 hours ago | parent | prev | next [-]

On a system with an MMU, applications have their own address space that the allocator draws from; pages need to be centrally allocated, but individual allocations can be handled in userspace

▲

hypercube33 an hour ago | parent | prev [-]

Windows NT (NT - Windows 11) keeps applications in their own private memory space by design. Windows 1,2,3,95,98,Me didn't do this which is why it was more prone to blue screens.

	▲	jz391 an hour ago \| parent [-]
		True, but this design decision (to include memory allocation API in the OS) predates the process separation/MMU.

▲

Spivak 3 hours ago | parent | prev [-]

In 20 years we'll have finally reached the logical conclusion to all of this that there shouldn't be separate os components you link against and your "OS" will just be manager of lightweight VMs.

Now you can just ship the user your machine and software can theoretically be immortal.