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...
In the early 90s Microsoft distributed the full Win32 API documentation as a WinHelp file. It felt very much as hyperlinked man-pages. Super fast too, even on machines of the time. WIN32.HLP can still be easily found, but modern Windows versions no longer ship WinHelp :(
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).
The section coding.pdf has their code style guidelines, colloquially known as Cutler Normal Form, CNF for short. I'm conflicted on it. Definitely overly verbose, but you can't argue with the results of the NT team. Such a rigid style guide almost feels like the technical version of a dress code. And there's an idea called "enclothed cognition" which is like, if you wear a business suit to work, it exerts a subconscious influence that results in you taking the work more seriously, focusing your attention, etc: https://en.wikipedia.org/wiki/Enclothed_cognition
It's also important to remember that a ton of things we take for granted now simply didn't exist (source code control was in its infancy, merging was shit, syntax highlighting was minimal at best, compiling took time, etc).
Our initial OS/2 API set centers around the evolving 32-bit Cruiser, or OS/2 2.0 API set.
(The design of Cruiser APIs is being done in parallel with the NT OS/2 design.) In some respects, this standard is harder to deal with than the POSIX standards. OS/2 is tied to the Intel x86 architecture and these dependencies show up in a number of APIs. Given the nature of OS/2 design (the joint development agreement), we have had little success in influencing the design of the 2.0 APIs so that they are portable and reasonable to implement on non-x86 systems. In addition, the issue of binary compatibility with OS/2 arises when the system is back-ported to an 80386 platform.
This may involve 16-bit as well as 32-bit binary compatibility."
Very "professional" coded writing that expresses a frustration with the need to collaborate with IBM that could have been more succinctly written if they had the option to use a few choice four letter words.
The layout it's close to /sys/doc for 9front/plan9 with guides for Acme, Sam editors (the guide to structural expresions as a tutorial and a guide), the Rc shell, the kernel, the ACID debugger, FS' (several, fossil/venti, cwfs and now GeFS), the security, the compilers, the Rio window system, namespaces, processes and channels, plumbing (something like xdg-open but far easier and more powerful), ... much more than a closed source and propietarty NT implementation, as you get the source for free too under libre licenses. Thus, it makes debugging the system a far easier task. And it's far simpler than Unix itself too.
17 comments
[ 6.1 ms ] story [ 44.3 ms ] threadUN*X spelling for trademark reasons or a joke that UNIX is verboten at Microsoft?
If they had their eye on the actual ball they wouldn't need to write Halloween memos and rant about developers on stage.
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).
Very cool to be able to read the original design instead of just reverse-engineered ones. Thanks for posting!
> Note that the NT OS/2 system does not use the Hungarian naming convention used in some of the other Microsoft products.
"6.1 OS/2 Standards
Our initial OS/2 API set centers around the evolving 32-bit Cruiser, or OS/2 2.0 API set.
(The design of Cruiser APIs is being done in parallel with the NT OS/2 design.) In some respects, this standard is harder to deal with than the POSIX standards. OS/2 is tied to the Intel x86 architecture and these dependencies show up in a number of APIs. Given the nature of OS/2 design (the joint development agreement), we have had little success in influencing the design of the 2.0 APIs so that they are portable and reasonable to implement on non-x86 systems. In addition, the issue of binary compatibility with OS/2 arises when the system is back-ported to an 80386 platform.
This may involve 16-bit as well as 32-bit binary compatibility."
Very "professional" coded writing that expresses a frustration with the need to collaborate with IBM that could have been more succinctly written if they had the option to use a few choice four letter words.
Who says college interns don't do real work?
I remember when he told several other interns that they had got "Hello World" to run on the nascent Windows NT.