Certainly all systems have undocumented stuff that are left undocumented because the users are not supposed to use it. If they would, they couldn't change it.
Compare that with the man pages of some decent BSD. Or even Linux..
But yes. I have contemplated buying one of those windows internals. I will probably buy that book just because of your comment. It's not that expensive.
They all have files that end up as /usr/include/sys/syscall.h and define well-known numerical constants for each (documented!) system call.
Oh, look! They even share the exact same numerical values for the old school system calls. #1 is exit(), #2 is fork(), so on and so forth.
Gosh, on my linux laptop, here in /usr/include/asm/unistd_64.h is pretty much the same numbers, but objectively hidden a little bit more than in the direct Unix descendants. I interpret this as "less documented than in Unixes".
Wow, even Minix source code has the same numbers: https://minixnitc.github.io/posix.html
I wonder why that is? Maybe it's because the system call numbers are in fact documented, part of the POSIX API, and descend from Bell Labs Unix source code. Here's V7's list of system call numbers as proof:
OpenBSD deletes "relic from the past" syscall:
Solaris documenting deleted syscalls (note however the libc interface is guaruaneed):
MacOS X is so unstable that even go developers had to go through libSystem:
Just to be clear to anyone else, the Mac OS X syscall interface is guaranteed to be unstable by Apple. Going through libSystem is the only way.
Please educate yourself about the Windows architecture.