Piero Bosio Social Web Site Personale

@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

@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)

@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!