I don't know why you are being downvoted, you are completely right. The NT api function is NtWaitForMultipleObjects. The Win32 apis WaitForMultipleObjects and WaitForMultipleObjectsEx are thin wrappers over this.

Is this NT API actually possible to be called from userspace? Or even from drivers?

Yes of course, they are all exported from ntdll.dll (in userspace) and ntoskrnl.exe (in kernelspace). You may need to link dynamically or make your own import libraries for many of them though.

Sure, here's an userspace example: https://docs.microsoft.com/en-us/windows/win32/sync/waiting-...

Based on the docs kernel mode drivers would call KeWaitForMultipleObjects instead it appears. User space should just call WaitForMultipleObjects. While NtWaitForMultipleObjects and ZwWaitForMultipleObjects exist they seem to be undocumented which means they probably have funky behavior. Anything in KernelBase.dll is a pretty thin wrapper that I'd be hesitant to call Win32 so much as "really thin syscall wrapper"

think of it as like select and pthread_cond_wait rolled into one generic api for waiting on one or more things from the kernel.

it's actually pretty nice how generic they made it.

If we're being pedantic here, it's not Win32.

> (Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)

Though Win32 is going to stick around for a while as can be seen in the URL for the page that's quoted from: https://docs.microsoft.com/en-us/windows/win32/apiindex/wind...

i think it's still called win32 today because win32 was a massive overhaul. 16 bit windows was loaded with that far and near pointer gunk to stretch those 16 bit pointers which win32 was able to do away with thanks to larger pointer widths.

regarding win32 vs. the nt api. i'm not super familiar with the pedantic distinctions there, but i do know, much to the programmer's chagrin, the thousands of windows api functions have varying levels of kernel entry, where i always have appreciated the (relatively) small number of unix style syscalls and the clear delineation between kernel and userspace api. (although i suppose futexes blur that, in name at least!)

Well, since introduction of vsyscall and vDSO, the Linux syscalls too have varying levels of kernel entry.

NtXxxx or ZwXxxx