Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by munchler | Hacker News Reader

Parent Full thread

munchler·

It’s a minimal Windows app, so the whole idea is to rely on Windows DLLs as much as possible.

View on HN

Officially, one should not use KERNEL32.dll for instance but go via crt. In practice, most interfaces are stable.

kernel32 is an official API, you're probably thinking of ntdll. CRT is the C-runtime. Not everything is written in C.

Yes, you are right, must have been thinking of ntdll.

KERNEL32.DLL (in spite of the name) provides user-mode system services for the Windows API. The CRT provides the C99 API. There are many entry points to the same thing on Windows; you can do any of `malloc`/`HeapAlloc`/`new`/`VirtualAlloc` to get a void* memory buffer. `malloc` is from the CRT; `HeapAlloc` is from KERNEL32.DLL, and `new` is from the C++ runtime.

Many many different ways to allocate memory. malloc, new, HeapAlloc, LocalAlloc, GlobalAlloc, CoTaskMemAlloc, etc. GlobalAlloc and LocalAlloc are pretty much obsolete. "malloc" sometimes redirects to HeapAlloc with the default process heap, but only sometimes, it depends entirely on which compiler and CRT is used.

It just causes one big headache that a DLL can't simply return a pointer and have the caller use "free", because malloc/free can be incompatible across modules.

This just led to the COM standard, featuring reference-counted objects that don't care what underlying way was used to allocate the memory. For the situations where you do need memory buffers, COM enforces the use of CoTaskMemAlloc/CoTaskMemFree.

Reply on news.ycombinator.com