Hacker News Reader

Comment by bediger4000 | Hacker News Reader

Windows NT has been around since what, 1993 or 94?

Why is this even news? Doesn't Microsoft document this stuff? How does anybody use a system that doesn't have this documented?

PS http://stratigery.com/nt.sekrits.html

View on HN

Because developers aren't supposed to to use them. The documented interface is ntdll or whatever.

I also ask myself this question. How can anyone use an OS where the creators deliberately hide some of the documentation?

I would love to read up on windows internals, but there are no real resources out there. A few books that at first glance appears to cover it, but then just deals with the application layer and up to point-and-click.

This is why I don't use windows anymore. I don't ever again want a job where I have to debug why old program P stopped working after an update. I prefer to be able to learn stuff.

Oh come on!

https://www.amazon.co.uk/Windows-Internals-Part-architecture...

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.

System calls seems like the very definition of what should be documented for users. Particularly if you want someone to write compilers for your operating system.

The stable program-kernel interface is not the kernel syscalls, but library API. That's exactly the same as every other non-Linux OS out there including other Unixes and other Free OSs.

Pretty sure that isn't true of FreeBSD, NetBSD or OpenBSD. It most certainly wasn't true of any Unix.

They all have files that end up as /usr/include/sys/syscall.h and define well-known numerical constants for each (documented!) system call.

https://github.com/openbsd/src/blob/master/sys/sys/syscall.h

https://github.com/lattera/freebsd/blob/master/sys/sys/sysca...

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/syscall.h?re...

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:

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/include...

Documenting syscalls does not mean a guarantee of stability. I can't recall any other Unixes except Linux which has committed to maintaining syscalls, which means this interface cannot be relied on.

e.g.

OpenBSD deletes "relic from the past" syscall:

https://cvsweb.openbsd.org/src/sys/sys/syscall.h?rev=1.199&c...

Solaris documenting deleted syscalls (note however the libc interface is guaruaneed):

https://docs.oracle.com/cd/E23824_01/html/E22973/gkzlf.html

MacOS X is so unstable that even go developers had to go through libSystem:

https://golang.org/doc/go1.12

> 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.

How exactly does the Windows design here prevent writing compilers? The API is stable, it just isn't on the syscall level.

Please educate yourself about the Windows architecture.

A book... That cost money.

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.

Reply on news.ycombinator.com