For those unclear on what the large pile of .doc and .pdf files are, it appears to be some revision of the design documents for "NT OS/2", which then turned into just NT. This appears to be the Smithsonian description of their physical copy: https://www.si.edu/object/microsoft-windows-nt-os2-design-wo...
That was back when there was "real" UNIX around, as well as a number of clones, including Microsofts own Xenix (maybe they had offloaded that to SCO by then). So UN*X was one way to indicate that it meant UNIX-like OSes.
It is a generic way to refer to unix and unix-like systems. It is still in use today, e.g. to indicate Linux as part of the set. For this document most likely it refers to Xenix (MS's unix).
IIRC Microsoft's internal email still ran on Xenix at the time (until Exchange betas got good enough for internal use c. 1995?), so perhaps more trademarks than some sort of absolute hatred of Unix. Also note that one of the two APIs that NT OS/2 was initially going to support was POSIX, albeit perhaps more because the US government wanted that than a true love of UNIX. Although the design rationale document (ntdesrtl) does lament that existing POSIX test suites tend to also test "...UNIX
folklore that happens to be permissible under an interpretation of the POSIX spec".
This is giving me flashbacks to the times when I had to implement systems based on big, verbose specification documents like this. Horrible.
If you really want to understand Windows, skip this and check out Windows 2000 Internals by Solomon and Russinovich (Win2k is a good middle-ground where Windows had matured a bit).
For more modern Windows, Windows Internals Parts 1 and 2[1][2], and Windows 10 System Programming Parts 1 and 2. Basically anything by Yosifovich, Russinovich, Ionescu et al.
Yeah this is definitely a hell of read which probably has more historical values than real ones. The book "Inside Windows NT" also gives a good overview about Windows NT 3.1. There is another one called "Understanding Windows NT File System" which talks about the fs I think.
The biggest problem is NT is not open-source, and while there are leaked copies posted online, there is no "official" build guide so people have to try their luck.
I have a hot take. manpages are really bad for noob examples, or if you actually want to learn how to use something. They are great references if you already know 95% of the tool, but for the most common use cases, they completely lack any sort of examples.
In this sense, LLMs (as much as I am sceptical about them) are much more useful.
Yeah I agree, TBF I rarely found man-pages to be useful to me, while so far LLM is pretty good at bash scripting, at least at the level that I need. But of course still wants to learn this stuffs in depth.
This mostly describes stuff to do with the [Windows] NT [OS][/2] (delete as appropriate) kernel layer, which normal mere mortals aren't supposed to interact with. You're supposed to use stuff like the Win32 KERNEL32.DLL not the more direct DLL, NTDLL.DLL (a DLL). Of course, true hackers scorn such abstractions.
Microsoft's eye wasn't on open sourcing their OS and describing the deep internals. They still don't want you to develop against the NT API, even though developers certainly do (and Microsoft makes compatibility shims for applications which do, when required).
My favorite part of NT is the Local Procedure Call (now obsoleted by ALPC): https://computernewb.com/~lily/files/Documents/NTDesignWorkb...
Very cool to be able to read the original design instead of just reverse-engineered ones. Thanks for posting!
For those unclear on what the large pile of .doc and .pdf files are, it appears to be some revision of the design documents for "NT OS/2", which then turned into just NT. This appears to be the Smithsonian description of their physical copy: https://www.si.edu/object/microsoft-windows-nt-os2-design-wo...
Yeah I think this is the original design doc for NT.
> The first release of NT is planned as a workstation product that will provide a strong competitor to UN*X based workstations.
UN*X spelling for trademark reasons or a joke that UNIX is verboten at Microsoft?
That was back when there was "real" UNIX around, as well as a number of clones, including Microsofts own Xenix (maybe they had offloaded that to SCO by then). So UN*X was one way to indicate that it meant UNIX-like OSes.
Turns out SCO bought Xenix in 1987, but Microsoft was just a couple of years removed from being the biggest Unix vendor around at this point.
It is a generic way to refer to unix and unix-like systems. It is still in use today, e.g. to indicate Linux as part of the set. For this document most likely it refers to Xenix (MS's unix).
IIRC Microsoft's internal email still ran on Xenix at the time (until Exchange betas got good enough for internal use c. 1995?), so perhaps more trademarks than some sort of absolute hatred of Unix. Also note that one of the two APIs that NT OS/2 was initially going to support was POSIX, albeit perhaps more because the US government wanted that than a true love of UNIX. Although the design rationale document (ntdesrtl) does lament that existing POSIX test suites tend to also test "...UNIX folklore that happens to be permissible under an interpretation of the POSIX spec".
I think trademark, I remember Bill Gates referring to Windows NT as "a better UNIX than UNIX".
OS/2 is likely where that came from - https://www.theregister.com/2024/02/21/successor_to_unix_pla...
This is giving me flashbacks to the times when I had to implement systems based on big, verbose specification documents like this. Horrible.
If you really want to understand Windows, skip this and check out Windows 2000 Internals by Solomon and Russinovich (Win2k is a good middle-ground where Windows had matured a bit).
For more modern Windows, Windows Internals Parts 1 and 2[1][2], and Windows 10 System Programming Parts 1 and 2. Basically anything by Yosifovich, Russinovich, Ionescu et al.
[1]: https://www.microsoftpressstore.com/store/windows-internals-...
[2]: https://www.microsoftpressstore.com/store/windows-internals-...
[3]: https://leanpub.com/b/windows10systemprogrammingP1and2
Yeah this is definitely a hell of read which probably has more historical values than real ones. The book "Inside Windows NT" also gives a good overview about Windows NT 3.1. There is another one called "Understanding Windows NT File System" which talks about the fs I think.
The biggest problem is NT is not open-source, and while there are leaked copies posted online, there is no "official" build guide so people have to try their luck.
I think this is the only place that hosts a (hopefully) full electronic copy of the book.
So.. you had _all_ this.. and for some reason just didn't want turn it into a useful set of "man" pages in your OS?
If they had their eye on the actual ball they wouldn't need to write Halloween memos and rant about developers on stage.
I have a hot take. manpages are really bad for noob examples, or if you actually want to learn how to use something. They are great references if you already know 95% of the tool, but for the most common use cases, they completely lack any sort of examples.
In this sense, LLMs (as much as I am sceptical about them) are much more useful.
Yeah I agree, TBF I rarely found man-pages to be useful to me, while so far LLM is pretty good at bash scripting, at least at the level that I need. But of course still wants to learn this stuffs in depth.
I think Windows and DOS do have good documents. I actually think they had way better ones than Linux at the time. But I could be wrong.
For reference:
https://jacobfilipp.com/msj-index/
And also MSDN.
This mostly describes stuff to do with the [Windows] NT [OS][/2] (delete as appropriate) kernel layer, which normal mere mortals aren't supposed to interact with. You're supposed to use stuff like the Win32 KERNEL32.DLL not the more direct DLL, NTDLL.DLL (a DLL). Of course, true hackers scorn such abstractions.
Microsoft's eye wasn't on open sourcing their OS and describing the deep internals. They still don't want you to develop against the NT API, even though developers certainly do (and Microsoft makes compatibility shims for applications which do, when required).