Most technical books I have read during my career have had a positive effect in me, in the sense that they brought me enthusiasm and eagerness to learn more, and to understand better the platforms, programming languages, and technologies I wanted to discover. This month’s Library entry is probably the biggest exception to that rule; because as soon as I read it, I decided to drop out from the Windows galaxy altogether, and to never look back.
Of course, this has nothing to do with the author’s own storytelling capabilities, which are stellar no matter how you look at them. My reaction had more to do with the sense I got from opening the trunk of my Windows laptop and taking a look at the entangled mess of software wires that powered it. I did not like what I saw, and hence, I walked away, first becoming a die-hard iOS developer from 2008 to 2018, using macOS until Apple’s “courage” got the best of me, and finally jumping with both feet on the Linux bandwagon 7 years ago.
“The Old New Thing” is a compilation of articles published in 2007, extracted from the blog of the same name, started around 2005 by Raymond Chen, who has worked in the Microsoft Windows team for literally decades. The blog still gets new entries every so often as this article hits the press.
This book should be, in the opinion of this author, a mandatory reading piece for whoever has to earn a living writing code for Microsoft Windows, in whatever layer of abstraction they might be working on, but in particular for those working on the lower levels of the building, close to the basement kernel.
As I said, the book is a delight to read; there are discussions about UI design; the weirdness of various Windows 95, 2000 and XP shenanigans; the problems of making pretty much every DOS program 100% compatible with later versions of Windows; a myriad references to the almighty Registry; the differences among various allocators (SHGetMalloc vs SHAlloc vs CoGetMalloc vs CoTaskMemAlloc, anyone? And you thought that malloc, realloc, and calloc were enough already); lots of crunchy details about COM object layout and behavior; and even sections explaining why files on Windows end with CTRL+Z, why they use “carriage return plus line feed” as a line separator, or why they cannot have filenames such as CON or NUL.
The index at the end provides quick access to dozens of articles explaining the inner workings of quite a few Win32 API calls (CreateMenu(), GetVersion(), etc.) and messages (WM_PAINT, WM_MOUSEENTER, etc.), with the corresponding source code snippets. This book is not the Windows equivalent of the 2010 book “The Linux Programming Interface” by Michael Kerrisk, but feels more like watching a long documentary on National Geographic explaining the natural evolution and inner workings of a whole ecosystem.
To serve as an example, in chapter thirteen, “Backward Compatibility” (one of the most interesting of the book, by far) Raymond Chen explains how dealing with breaking software was a major priority for the team:
Why not just block the applications that rely on undocumented behavior?
Because every application that gets blocked is another reason for people not to upgrade to the next version of Windows. If you run the Registry Editor and look atHKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ WindowsNT\ CurrentVersion\ Compatibility, you’ll see a list of programs that would have stopped working when you upgraded from Windows 3.0 to Windows 3.1.
(I do not have a Windows machine at hand, so I will leave it as an exercise to the reader to verify that this is still the case in Windows 11.) Later in the same chapter, a visibly adamant author explains that
The LOB (line-of-business) application is the deal-breaker. If a Windows upgrade breaks a LOB application, it’s game over. No upgrade. No company is going to lose a program that is critical to their business.
(Emphasis in the original.)
This month’s Library book, in the sense of the excerpts shared above, is a concrete explanation of the various ways in which Microsoft embraced, extended, and extinguished the market for alternative PC operating systems starting in the 1990s. We owe the current state of the world of computers, to a large degree, to the stubbornness of the Windows team, who made sure that every single DOS and Windows app under the sun would work (or at least, launch) in later versions of the operating system. A certainly Herculean task, one that no other vendor ever attempted; but one that cost users and developers their sanity in the long run.
In terms of style, the book transpires the exasperation and contempt directed towards third party creators of Win32 apps, drivers, and components, who would bypass the APIs and rules put forward by the Windows team, watch their software crash miserably, and then complain to Microsoft, only to find the wrath of Raymond on the other side of the line. Examples abound all along the book, and they are seriously delightful.
The comments in this article, of course, should not detract from the notion of the insane amount of work that was required to make a single operating system work with the huge variety of software and hardware existing in the IBM PC ecosystem. From a purely technical and project management perspective, Windows was, and always will be, a groundbreaking and extraordinary achievement, held by a team of incredibly smart people who did their best. The point of this article is, rather, that human society in the 21st century, as a whole, might probably have been better off without Windows crashing around at every corner.
After its lecture, this whole book begs the question of the overall sanity and coherence of the Windows operating system, and quite simply provides a direct answer to the perceived brittleness of the ensemble since, well, always. To put it shortly, if you are person in need of actual reasons not to use Windows, this is definitely the book for you.
(The problem is, however, that most users of Windows will never read, let alone hear about this gem of a book, and that is a pity.)
Cover photo by the author.