7 ms·

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 lifti

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 22d ago
> 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 22d ago
  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
  - skrellm 22d ago
    > 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.)
    - Someone 22d ago
      >> 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/ntqueryattributesfile 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/nf-winternl-rtlchartointeger https://learn.microsoft.com/en-us/windows/win32/api/winternl..., so I don’t think that’s an accident.
      - not_a9 22d ago
        In addition a bunch are documented in the driver docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwmapviewofsection 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".
      - skrellm 21d ago
        > 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 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 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?
        not_a9 16d ago
        > This has nothing to do with ntdll at all. I can only wonder where `NtMapViewOfSection` could be exported from...
munchler 22d ago
It’s a minimal Windows app, so the whole idea is to rely on Windows DLLs as much as possible.
- actionfromafar 22d ago
  Officially, one should not use KERNEL32.dll for instance but go via crt. In practice, most interfaces are stable.
  - neonz80 22d ago
    kernel32 is an official API, you're probably thinking of ntdll. CRT is the C-runtime. Not everything is written in C.
    - actionfromafar 22d ago
      Yes, you are right, must have been thinking of ntdll.
  - delta_p_delta_x 22d ago
    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.
    - Dwedit 21d ago
      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.

skrellm 22d ago

> 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 22d ago
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
- skrellm 22d ago
  > 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.)
  - Someone 22d ago
    >> 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/ntqueryattributesfile 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/nf-winternl-rtlchartointeger https://learn.microsoft.com/en-us/windows/win32/api/winternl..., so I don’t think that’s an accident.
    - not_a9 22d ago
      In addition a bunch are documented in the driver docs, such as https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwmapviewofsection 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".
    - skrellm 21d ago
      > 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 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 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?
      - not_a9 16d ago
        > This has nothing to do with ntdll at all. I can only wonder where `NtMapViewOfSection` could be exported from...

munchler 22d ago

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

actionfromafar 22d ago
Officially, one should not use KERNEL32.dll for instance but go via crt. In practice, most interfaces are stable.
- neonz80 22d ago
  kernel32 is an official API, you're probably thinking of ntdll. CRT is the C-runtime. Not everything is written in C.
  - actionfromafar 22d ago
    Yes, you are right, must have been thinking of ntdll.
- delta_p_delta_x 22d ago
  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.
  - Dwedit 21d ago
    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.