Bypassing Kernel32.dll for Fun and Nonprofit

[andrewrk@mastodon.social]

Bypassing Kernel32.dll for Fun and Nonprofit

https://ziglang.org/devlog/2026/#2026-02-03

[joe@f.duriansoftware.com]

@andrewrk RIP zig on windows 95

[joe@f.duriansoftware.com]

@andrewrk less unseriously, how do you handle the eldritch abomination of Win32-to-NT path mangling

[wolf480pl@mstdn.io]

@andrewrk
> If you pass an APC routine here then some old bitrotted 32-bit code runs and you get garbage results.

but the function that takes an APC routine is the ntdll one? I thought only kernel32 was supposed to have bitrotten stuff...

[paranoiq@witter.cz]

@andrewrk can't you skip also the ntdll and go directly for the syscall? : P

[andrewrk@mastodon.social]

@wolf480pl APC routine is valid if the file is asynchronous

[mlugg@fosstodon.org]

@andrewrk @wolf480pl as far as we can tell, passing an APC to NtReadFile of a non-overlapped file handle probably worked (or at least was intended to?) many moons ago, but there is no wrapper exposed from kernel32 which triggers that code path, so it bit-rotted probably in the transition to the 64-bit NT kernel. This is one of the things you need to take care of when using ntdll: documentation is even more nonexistent than normal, and code paths which kernel32 doesnt take are sometimes broken!

[mlugg@fosstodon.org]

@andrewrk @wolf480pl for the record, this hypothesis is based on the fact that *often*, this particular usage of NtReadFile works as expected, but in *some* cases, it will:
* fail to write the APC arguments to the right registers; this could be relevant to the 32-to-64-bit transition because the x86 calling convention passes arguments on the stack rather than in registers
* write the "Information" field of the IO_STATUS_BLOCK at the wrong offset (4 bytes instead of 8 bytes)

[mlugg@fosstodon.org]

@andrewrk @joe I mean, it's *annoying* (particularly since NT -> DOS path conversion is kinda heuristic-based, i.e. "let's hope paths don't go through a weird path to \??\"), but at the end of the day it's just some hacky string conversion! And here's the thing: given that the conversion happens in kernel32, can you guess how well that code is written in the first place? Yeaaaah, so it's not actually too hard to write something with equivalent quality :P

[fmn@mastodon.social]

@andrewrk well, sounds like a profit to me, after all.

[patrick@retro.social]

@andrewrk "Using ntdll functions feels like using software made by senior engineers, while using kernel32 functions feels like using software made by Microsoft employees." You don't take prisoners, do you?