8 ms·
It’s a minimal Windows app, so the whole idea is to rely on Windows DLLs as much as possible.
by munchler 23d ago
It’s a minimal Windows app, so the whole idea is to rely on Windows DLLs as much as possible.
- actionfromafar 23d agoOfficially, one should not use KERNEL32.dll for instance but go via crt. In practice, most interfaces are stable.
- neonz80 23d agokernel32 is an official API, you're probably thinking of ntdll. CRT is the C-runtime. Not everything is written in C.
- actionfromafar 23d agoYes, you are right, must have been thinking of ntdll.
- delta_p_delta_x 23d agoKERNEL32.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.
- Dwedit 22d agoMany 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.