Hacker News Reader

Comment by delta_p_delta_x | Hacker News Reader

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.

View on HN

> 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.

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

> no, you can also call ntdll (or even syscalls although those aren't stable), there's plenty of documentation on the internet

I mean officially. Yes, you can find some on the internet, but nothing on the official MSDN.

> but also why would you, not much point except for very niche functionality

Exactly. Using system DLL API is backward and forward compatible, and just as standardized and well-documented as the POSIX API. I see no problem relying on it.

(Sidenote: as a bonus, MSDN is surprisingly good, understandable, well organized, lots of examples. I rarely say this, but well done MS, that's how a dev doc should be.)

>> no, you can also call ntdll (or even syscalls although those aren't stable), there's plenty of documentation on the internet

> I mean officially. Yes, you can find some on the internet, but nothing on the official MSDN.

It seems that changed. https://learn.microsoft.com/en-us/windows/win32/devnotes/ntq... says

  [This function may be changed or removed from Windows without further notice.]

but it on the official MSDN site, and it does document a call in Ntdll.dll.

It’s easy to find many more examples such as https://learn.microsoft.com/en-us/windows/win32/api/winternl..., so I don’t think that’s an accident.

> but it on the official MSDN site, and it does document a call in Ntdll.dll.

Does it? What's FILE_BASIC_INFORMATION? Link gives me 404. How do you replace kernel32 API with this?

> It’s easy to find many more examples such as https://learn.microsoft.com/en-us/windows/win32/api/winternl..., so I don’t think that’s an accident.

Again, how do you replace kernel32 API with this?

> In addition a bunch are documented in the driver docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/d....

This has nothing to do with ntdll at all.

I still don't get it, what's wrong with using the user32 and kernel32 APIs? It's stable, well-documented, and is the official API on Windows. So why not use it?

> This has nothing to do with ntdll at all.

I can only wonder where `NtMapViewOfSection` could be exported from...

Yeah, but the link talks about `ZwMapViewOfSection`. From that page:

> For calls from kernel-mode drivers, the NtXxx and ZwXxx versions of a Windows Native System Services routine can behave differently in the way that they handle and interpret input parameters.

How "differently" exactly? That's undocumented. And lots of other small (but very important) details are undocumented as well.

> PS C:\Program Files\Microsoft Visual Studio\18\Community> dumpbin.exe /EXPORTS C:\Windows\System32\ntdll.dll | rg ZwMapViewOfSection

       2072  80F 001612B0 ZwMapViewOfSection

       2073  810 00163160 ZwMapViewOfSectionEx

> PS C:\Program Files\Microsoft Visual Studio\18\Community> dumpbin.exe /EXPORTS C:\Windows\System32\ntdll.dll | rg NtMapViewOfSection

        425  1A0 001612B0 NtMapViewOfSection

        426  1A1 00163160 NtMapViewOfSectionEx

> How "differently" exactly? That's undocumented.

https://learn.microsoft.com/en-us/windows-hardware/drivers/k...

In addition a bunch are documented in the driver docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/d....

> If the call to this function occurs in user mode, you should use the name "NtMapViewOfSection" instead of "ZwMapViewOfSection".

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

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

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.

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.

Reply on news.ycombinator.com