Interesting to bypass CRT and work directly against the Windows API. That said, these rely on USER.32.DLL and KERNEL32.DLL to do the majority of the heavy lifting.

It's a bit like 'smallest hello world in assembly' but the code is just setting up the calling convention and then passing the zero-terminated character string into `write`. Cool, but that could be done a bit more straightforwardly in C, too. A lot of assembly (including in the linked repository) is book-keeping for the platform's calling convention.

▲

skrellm 6 hours ago | parent | next [-]

> That said, these rely on USER.32.DLL and KERNEL32.DLL to do the majority of the heavy lifting.

Since the low-level Windows kernel API is undocumented and non-public, using these system DLLs is your only option on Windows.

It's just like linking against libc.so on any POSIX systems.

	▲	Pannoniae 3 hours ago \| parent [-]
		no, you can also call ntdll (or even syscalls although those aren't stable), there's plenty of documentation on the internet but also why would you, not much point except for very niche functionality

▲

munchler 5 hours ago | parent | prev [-]

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

▲

actionfromafar 5 hours ago | parent [-]

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

▲

delta_p_delta_x 5 hours ago | parent | next [-]

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.

▲

neonz80 5 hours ago | parent | prev [-]

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

	▲	actionfromafar 5 hours ago \| parent [-]
		Yes, you are right, must have been thinking of ntdll.