Programming Windows: A Timeline (Premium)

After obsessing over the idea of an open-ended “Programming Windows” series for months, I finally took a chance and published the introductory article last week with no real expectation of whether this would resonate with readers. So, I’m pleased with the positive response. This is something that I care about deeply, and while I understand that developer topics are somewhat esoteric to some, I really do believe that understanding these topics, even at a high level, is key to a better understanding of the platform.

Expanding on what I wrote last week, this series will proceed in no particular order, though this entry is a logical follow-up to the introduction because it spells out the major milestones that I’ll be covering, each with multiple articles, in the months ahead. Future entries can and will appear out of order, however, and I will maintain and eventually publish an index so that you can view them as a whole in chronological order. (Currently, I’m thinking about covering the .NET announcement next, for example.)  In short, this will proceed a bit like a book, but online and publicly, and it will evolve and change over time, I’m sure.

I will get things wrong*. My personal experiences with Microsoft’s developer tools and technologies were deep from roughly 1993 until roughly 2001/2002, and while I’ve kept up with the company’s strategies since then, I have my blind spots. I’ll do what research I can, talk to experts whenever is possible, and fix any mistakes so that this series is as accurate as possible. But I’m excited by this challenge and I hope the series meets and exceeds your expectations.

Ultimately, I see this series as an explanation for why things happened. The history of Windows can be seen as a series of reactions, to competitors, to market trends, and to internal forces that were seeking change. Along the way, Microsoft has worked to improve and adapt Windows to an incredible variety of scenarios and form factors. And there were many side-trips, too, from Windows for Pen Computing in the early 1990s to Windows CE in the late 1990s to Windows Mobile and Windows Phone to various embedded products, Server variants, and more. While most of those are not part of the main narrative—for now, I’d like to focus largely on what I think of as “Big Windows,” or Windows for PCs—they all impact the story in some way. Again, we’ll see where this takes us.

From a milestone perspective, most normally think of the history of Windows as a series of product version releases starting in 1985. That history is well-documented, I think, but since it’s important to our alternate history of application development technologies, it’s perhaps worth thinking about briefly. In fact, it can be done very briefly if you just consider the technological eras more broadly.

I think of them like so:

Presentation manager for MS-DOS. The initial releases of Windows were “a thing on a thing,” as Andrew Schulman noted in Unauthorized Windows 95: A Developer’s Guide to Exploring the Foundations of Windows “Chicago,” a graphical presentation manager that ran on top of the MS-DOS operating system. Windows during this era relied on DOS for file management and other technical needs and it was not itself a true operating system. Releases included Windows 1, Windows 2, Windows/286, Windows/386, Windows 3.0, Windows 3.1, and Windows for Workgroups.

Windows 9x. While still technically a “thing on a thing,” Microsoft added 32-bit support to Windows and minimized the reliance on MS-DOS while hiding it from the user. Releases include Windows 95 (including various OSR updates), Windows 98 (and SE), and Windows Millennium Edition (ME).

Windows NT. Concurrent to Windows 3.x, Microsoft hired Dave Cutler and a team from Digital to create a next-generation 32-bit, platform-agnostic operating system which it eventually named NT. Over time, compatibility with Windows became key, so it was renamed Windows NT and its Windows “personality” became the dominant interface. Releases include Windows NT 3.1 (the first version, so named to match Windows 3.1), NT 3.5/3.51, NT 4, and 2000 (which was originally named NT 5.0).

Modern Windows. Starting with Windows XP, Microsoft merged its codebases to create a single product line that combined the stability and security of Windows NT with the driver and application compatibility of the DOS-based versions of Windows. Releases include Windows XP (multiple versions), Windows Vista, Windows 7, Windows 8, and Windows 10 (multiple versions).

There is, of course, another way to view this timeline, and it’s a bit more complicated than the list above. If you examine the primary application programming models—the “native” way to create Windows applications at any given time, though the term “native” is not strictly true for most of this list—you will see the following major milestones (with a few important digressions noted).

Windows Application Programming Interface (API). In the beginning, there was Windows, and you wrote Windows applications to the Windows API using the C programming language. This was true of Windows 1.0 through Windows 2000 (!). The name changed when Microsoft adapted Windows for 32-bit platforms starting with Windows NT; at that time, the 32-bit APIs were renamed to Win32 and the previous 16-bit versions were retroactively renamed to Win16. Oddly enough, Win64 was never really a thing because the flat memory model used by both made the transition easier than the Win16-to-Win32 transition. So we still use the term Win32 today, though Windows API is technically the correct term again.

Visual Basic. To appeal to beginners and capitalize on a then-new Rapid Application Development (RAD) trend, Microsoft adapted its DOS-based QBASIC and Quick BASIC languages to a more graphical approach involving forms (windows and other objects) and event-driven paradigm. This was not a native application platform: For most of its existence, Visual Basic compiled to an intermediary p-code (“pseudo code”) that required developers to ship a VB runtime with their apps. Releases include Visual Basic 1.0 (1991) through Visual Basic 6.0 (1998); after that, Visual Basic was adapted for .NET (see below) and became more complex and more powerful.

Microsoft Foundation Class (MFC) libraries. To capitalize on the popularity of C++, an object-oriented evolution of C, Microsoft created the MFC libraries as a supposedly thin wrapper over the native and C-based Windows APIs. MFC is widely regarded as one of Microsoft’s biggest blunders: It is big, heavy, and obtuse, and was inferior to competing C++ class libraries, like Borland’s Object Windows Library (OWL) and Visual Component Library (VCL). But its big claim to fame was its native support for multiple-document interface (MDI) applications, which are single application windows that can contain any number of child (“document”) windows. MFC was released with Visual C++ 7.0 in 1992 and was later adapted to 32-bits for Windows NT and 95. It’s still kicking around today for some reason.

.NET/NET Framework. In 2000, Microsoft announced a major if vague initiative to embrace and extend the Internet and Internet-enable its entire product line. Dubbed .NET, it failed to live up to the advance hype, but on Windows, it resulted in the .NET Framework, a managed code class library and runtime environment. Like Visual Basic apps, .NET apps were/are not “native” in that they didn’t compile to native application EXEs. Instead, .NET uses the Common Intermediate Language code (CIL) and a just-in-time (JIT) compiler, similar to how Java works. But .NET has several advantages over Java, including the ability to use any compatible programming language of your choice; Microsoft debuted C# as a modern C-like language at the time, and Visual Basic was adapted to Visual Basic.NET. The .NET Framework debuted in 2002 and will be evolved through next year, when it’s replaced by the next version of .NET Core (see below), which will be named .NET 5; the .NET Framework 4.8 was just released this past April.

Windows Forms. Debuting alongside the initial .NET Framework release, Windows Forms (WinForms) was Microsoft’s first stab at a cleaner (compared to MFC) and .NET-based abstraction of the native Windows APIs combined with the visual designers and event-driven programming model from Visual Basic. Windows Forms was quickly supplanted by the Windows Presentation Foundation (see below), but both environments co-existed together for many years and both are now open-sourced, suggesting that they will be around, and supported, for years to come. Basically, Windows Forms was the primary Windows application programming environment from 2002 through 2005.

Windows Presentation Foundation. Debuting with .NET Framework 3.0 and Windows Vista in 2006, WPF is essentially an evolution of WinForms that utilizes the XML-based Extensible Application Markup Language (XAML) to describe application user interfaces. The use of XAML marks a more major departure from previous application environments than is perhaps immediately obvious: XAML elements and attributes map directly to .NET CIL object instances, properties, and events, meaning that it can be used as a lightweight alternative to C# or VB.NET (or other languages) code. XAML still forms the basis for Microsoft’s application user experience creation tools today. (A WPF subset called Silverlight was created as a way to bring this technology to the web, similar to how Adobe Flash worked. Silverlight was briefly used as the programming environment for Windows Phone as well.)

Windows Runtime. For Windows 8 and its touch-first user experiences, Microsoft adapted the Metro environment from Windows Phone for the Windows desktop in 2012. (The two were never compatible, they just worked similarly; later, Windows 10 and Windows 10 Mobile were made compatible and then Windows Mobile was killed off.) After a trademark dispute, it was renamed to Modern, and then to the Universal Windows Platform, or UWP, in Windows 10 in 2015. While we once thought of these apps as Windows Store or Microsoft Store apps, the platform is technically referred to as the Windows Runtime, or WinRT (no relation to the ill-fated Windows RT). WinRT is cross-platform—it works on both Intel-type and ARM-based PCs—but is not native; developers still need to write to Win32 to achieve that in 2019. But WinRT is also not managed code, like the .NET-based WinForms and WPF. Instead, it is .NET-like, with a clean, logical set of object-oriented APIs and the ability to mix XAML and C#/VB.NET/C++/whatever code. (Windows 8 also allowed developers to create web-based Modern apps using HTML and CSS, but that model is now deprecated.)

Messy? You bet. It’s also incomplete, I know. In addition to other Microsoft developer environments and technologies, competing developer initiatives from Borland and others, there are probably all kinds of other things I’ve left out. But that’s the high-level view as I recall it.

More important, I think, are the reasons that each of these Windows releases and application programming models were created in the first place. That is, in addition to the “what” of each release—the component pieces that together constitute each—there’s a “why” to each of them, too. And that is the overreaching point of this series of articles, what I’ll be examining more as we move forward.

More soon.

* Find a mistake? Please leave a comment below, of course. Or email me at [email protected]. Thanks!