Very cool to be able to read the original design instead of just reverse-engineered ones. Thanks for posting!
UN*X spelling for trademark reasons or a joke that UNIX is verboten at Microsoft?
It was an email system that ran on top of file system. If I recall, mail clients connected over a networked drive to access mailboxes. So it was never regarded as being very scalable.
The Workgroup Apps (WGA) divison ran MS Mail for PC Networks since they produced MS Mail. Gotta dogfood your product. The WGA email system used a Xenix gateway to connect with the rest of Microsoft.
The rest of Microsoft ran MS Mail for Windows with a Xenix email backend and address book, since MS was already using Xenix before MS Mail for PC Networks existed.
Windows for Workgroups 3.11 contained a one postoffice-version of MSMail, (which could be upgraded to the full version).
Some more Microsoft email-related history at https://en.wikipedia.org/wiki/History_of_Microsoft_Exchange_...
"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.
The Windows NT kernel had a better design than most contemporary and succeeding operating systems (including the various Unixes, Linux, BSD, plan9 etc.).
Modern kernel designs like Google's Fuchsia have more in common with NT than POSIX/Unix/Linux.
In particular, the NT object manager approach subsumes the Unix "everything is a file, well, not quite, oh... uhh.. let us slowly fix that by adding stuff like signalfd, memfd, pidfd etc. ahh hmm, these still do not exactly fit into a FS mold... ah crap, still missing a proper ptrace FS analogue" design approach that eg. Linux has taken in the last two decades.
It also had powerful primitives like eg. APCs that could be used to build higher-level kernel features elegantly.
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).
[1]: https://www.microsoftpressstore.com/store/windows-internals-...
[2]: https://www.microsoftpressstore.com/store/windows-internals-...
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.
(*cries in X12 270/271*)
If they had their eye on the actual ball they wouldn't need to write Halloween memos and rant about developers on stage.
For reference:
https://jacobfilipp.com/msj-index/
And also MSDN.
Part of the reason they did so well, companies could easily implement software using the new APIs.
Of course, they also had secret and undocumented APIs that people found and wanted to use ...
My preference was for a mid-tier subscription that provided a complete set of licensed-for-development-use Windows Server, and Microsoft Office and SQL Server ISOs, for ~$495/year.
Of course, you had no way of knowing that the truly eye-watering top-tier $2000/yr MSDN subscriptions were jam-packed with junky "Enterprise" tools that you would never actually want or need, without actually purchasing one. Nor would you know that the priority support credits bundled with top-tier MSDN support did not materially improve upon the "shouting into the void" nature of unpaid support, which in turn was not materially better than the No Support At All for U option that we currently have. Although my one experience with a paid priority support case did actually produce an actual fix three years later. So there is that, I suppose. :-/
If you just wanted to do c++ windows programming you can get visual studio which, I believe, did come with Win32 documentation (especially as CD roms became common distro methods).
The c++ software development kit itself (just libraries, documentation, and samples, no tooling) wasn't too expensive and was mainly material costs.
https://download.microsoft.com/download/1/6/d/16d24ada-5317-...
5,000+ pages...I think this is the FULL documentation for everything related to VB 2005.
In this sense, LLMs (as much as I am sceptical about them) are much more useful.
When I learned C more than 20 years ago, I found libc manpages a pretty good way to learn. For many functions in section 3, you can read the manpage and make an intelligent guess on how it's implemented, and write your own implementation. I did this as an exercise back in the day.
Software that is poorly documented, has no stable api, and no way of accepting extensions other than modifying the source, is not very 'free', in the sense, that if I have a good idea, I'll have crazy amounts of trouble getting the change to users even if I manage to decipher and modify the source appropriately.
This approach describes many software projects. If I wanted to change GCC in a way the original authors didn't approve of, I'd have to fork the entire project and lobby the maintainers to include my versions.
If I wanted to change most MS stuff, like Office, I could grab the COM object out of a registry, and override it with mine, just to list one example. Then I could just put the binary on my website, and others would be able to use it.
As for MS not publishing these particular docs - its not like MS doesnt publish tomes on everything, including the kernel. If you're interested in Windows Internals, I recommend the book series of the same name by Pavel Yosifovich, or really anything by him or Mark Rusinovich.
Its also a testament to the solidity of Windows' design that tons of stuff written decades ago is still relevant today.
This goes back a very long time -- at least to the Windows 3.0 timeframe.
The IBM-only 32-bit OS/2 2.0 came out around the same time as Windows 3.1.
OS/2 2 could run Windows 3 inside what was effectively a VM (a decade before true VMs came to the x86 platform), running the Microsoft code on top of OS/2's built-in DOS emulator.
I remember an IBM person objecting to a journalist saying "so you have access to the Windows source code, and you patch it to run under OS/2?"
Reportedly, the IBM engineer looked a bit pained and said "we don't patch it -- we superclass it in memory to make it a good citizen, well-behaved inside OS/2's protected mode."
(It is over 30Y ago so forgive me if I am not verbatim.)
This was subsequently demonstrated to be true rather than a marketing claim. OS/2 2.0 and 2.1 included a "WinOS2" environment. OS/2 Warp 3 made this an option: it was sold in 2 versions, one with a blue box which contained a Windows 3.1 environment, and one with a red box which did not contain WinOS2 but could be installed on top of an existing Windows 3.1 system and then took over the entire Windows environment, complete with all your installed apps, and ran that inside OS/2.
So you kept all your installed 16-bit apps and settings but got a new 32-bit OS with full memory protection and pre-emptive multitasking as well.
Bear in mind that Windows has not activation mechanism then, so you could copy a complete Windows 3.x installation onto a new PC, change some drivers and it just worked without complaint.
So you could buy a new high-end 486 PC, copy Windows off your old 386, install OS/2 Warp over the top and have a whole new OS with all your apps and their files still running.
This was amazingly radical stuff in the first half of the 1990s.
Complex merging as we're used to with git was unheard of.
> Note that the NT OS/2 system does not use the Hungarian naming convention used in some of the other Microsoft products.