the motivation behind zig#1840 is that while the functions in ntdll aren't as well documented as the kernel32 functions, theyre not unstable and not having our binaries depend on kernel32.dll would lead to faster startup times as well as allow us to do things like use more performant algorithms for UTF-8 <-> UTF-16 conversion. on top of the things mentioned in the issue like having APIs with more powerful features.
For Bun's shim, it is linking against kernel32 anyways. And there is nothing special about it's use of NtCreateFile, NtReadFile, NtWriteFile, and NtClose that would preclude it from using the standard functions.
I'm not sure it's possible to not have kernel32 loaded into your process anyways. Even if you create an EXE that imports 0 DLLs, kernel32 gets loaded into the process by NTDLL. The callstack from main:
There are valid reasons to use APIs from NTDLL. Where I disagree with zig#1840 is the idea that it is always better to use NTDLL versions of API. Every other software ecosystem uses the standard Win32 APIs and diverging from that without a good reason seems like a good way to have unexpected behavior. One concrete example is most users and programmers expect Windows to redirect some file system paths when running on WOW64. But this is implemented in Kernel32, not ntdll.
