Programming Windows: Windows API Wrap-Up (Premium)

At Build 2019, I surmised that Microsoft had killed the Universal Windows Platform (UWP), its most recent application development framework for Windows. And then I found out how right I was: A source high-up in Microsoft’s Windows developer business said privately, point blank, that Microsoft had literally killed UWP. We can speculate about what happens next. But UWP’s fate is not speculation. It’s real.

Despite having figured this out on my own, the news hit me pretty hard: UWP is basically the second-generation version of the Metro app platform that debuted with Windows 8 in 2012, but it has its roots in the Windows Phone app platform, also called Metro, which had debuted two years earlier. Had Microsoft really just wasted the previous decade? My head was spinning.

But as I know all too well, Microsoft has bounced from developer framework to developer framework over the years, responding to both industry and software development trends each time. This is something I’ve thought about a lot. And I’d likewise been thinking about a series of articles about these topics, too. I just wasn’t sure whether this would resonate with readers. Non-programmers, I felt, would find this topic a bit too dense. And actual developers would likely mock my surface-level understanding of their careers. And so I waffled.

But with my declaration that UWP was dead—a fact that Microsoft has never publicly acknowledged—readers and podcasts listeners began doing some thinking of their own. And I started getting the same questions again and again. Since UWP is dead, does that mean that it would rewrite the in-box apps that come with Windows 10 as “Win32” apps? After all, the firm shouldn’t be promoting a dead technology.

These questions made me realize that most people don’t quite understand what terms like Win32 even mean. And that killing off a developer framework like UWP doesn’t mean that Microsoft can take a Magic Eraser to existing products and just remove anything and everything UWP-related from existence. Software code, like the life in Jurassic Park, continues. It has a life cycle and, in many cases, a support life cycle that corporate customers rely on as well. In some ways, it never dies.

And I thought, what the heck. Maybe it was time for a little bit of history.

As I noted previously, Windows was a reaction to two things: Microsoft’s secret involvement with the development of the first Macintosh and a related and broader industry adoption of graphical user interfaces (GUIs) and other windowing solutions, many of which on MS-DOS were initially text-based. The earliest GUIs didn’t technically provide true multitasking capabilities. But one could run two or more applications side by side in floating windows and could, in some cases, even exchange information between them. The future was suddenly very clear.

In the early 1980s, Microsoft co-founder Bill Gates was seduced by the GUI as quickly as was Steve Jobs before him, and he immediately pledged to fully support the Macintosh with Microsoft’s then-growing line of productivity applications. As this work started, however, a firm called VisiCorp, of VisiCalc fame, announced a product called VisiOn. It was described as an “application manager” for MS-DOS that provided a GUI, mouse support, and its own collection of applications software. Gates, who was spearheading Microsoft’s Macintosh applications push at the time, first became aware of it during its first public demonstration at Fall Comdex 1982.

“There it was, actually running—well, demoing—on an IBM PC, the platform Gates thought he owned,” authors Stephen Manes and Paul Andrew write in Gates. “It was all there, everything he’d dreamed about putting on the PC himself. The Apple Lisa hadn’t been introduced, the Macintosh was over a year away, and yet there was VisiCorp chairman Dan Fylstra grinning broadly, calling the thing the ‘metaphor for the desktop,’ crowing that this ‘operating environment’ sitting between the operating system and applications would offer what ‘no operating system had provided’ before—‘a machine-independent way of interacting with the user’.”

VisiCorp had invented … Windows. So, Gates did what Gates always did. He copied it. Microsoft went into “hardcore planning mode” and assembled a team to create something he initially called Interface Manager and then tell the world that it was coming. “Microsoft was working on something as good as, no, better than, anything VisiCorp could ever hope to accomplish,” Gates continues. Microsoft would tell IBM about it, they would tell PC clone makers about it, and they would tell any developers about it.

That it didn’t even exist hardly mattered.

By April 1983, a Microsoft programmer named Rao Remala had assembled the first Interface Manager demo, which consisted largely of a screen containing multiple overlapping application windows. None of them did anything, but it looked like they were all running at the same time. GUI, check. Device independence, check. Multitasking, check! Internally, it was called a series of “Macintosh knockoffs.” But it worked. Microsoft was moving quickly into this brave new world. (It also developed and released its first mouse in the following year.)

Microsoft also engaged in an interesting effort to undercut the competition. Where VisiOn required a hard drive, for example, Interface Manager would work on dual floppy-based PCs. VisiOn required 450 KB or more of RAM, so Interface Manager would work with just 192 KB. And where VisiOn and other similar products like DESQ, announced the following year, would be very expensive ($200 to $1000), MS-DOS licensees could acquire Interface Manager for “peanuts.”

(Fun aside. Real-world prices ended up being $8 to $24 per PC, based on volume and up-front commitments. It was not originally going to be sold at retail.)

To appease Apple—Steve Jobs was furious when he heard about Microsoft’s Interface Manager plans—Gates promised that he would not release his own GUI until 1984 at the earliest, assuring him that the Macintosh would arrive in the market first. It was an easy promise, given that the resulting product barely shipped by the end of 1985, and the first version was still terrible.

By mid-1983, Microsoft had changed the name from Interface Manager to Windows—oddly, most at the firm preferred the old name—just in time for its June 1983 announcement; a victory for marketing. By that year’s Fall Comdex, Microsoft had a demo of actual applications running in windows. The interface was clunky, but it had dozens of PC clone makers and application makers signed up. IBM, interestingly, was not among them, but I’ll discuss that—and its relationship with Microsoft—in a coming article about IBM and OS/2.

VisiOn finally shipped at the end of 1983, but it sold poorly, in part because it couldn’t even run MS-DOS applications. That it was slow, buggy, and expensive didn’t help either, and the firm essentially disappeared by 1986.

1984, of course, was the year of the Mac. But at Microsoft, Windows was coming together slowing and with lots of complications. Microsoft’s software development teams were tiny—fewer than 10 people created Windows and defined what it was—and limitations of the x86 architecture used by PCs made such a system challenging. Worse, the technical requirements of a task-switching GUI were still very poorly understood, even at Microsoft.

Scott McGregor, the developer in charge of Interface Builder and the creator of Microsoft’s Comdex 1983 demo, had decided to use a complex but sophisticated “push” model for handling events, which could be triggered by the user (like a mouse click) or by the system. Under this model, the system “pushes” messages about events to the relevant application, which then processes (some of them), at which time the system “pulls” the response from the application. I described this system from the application developer’s perspective in Programming Windows: Windows Application Basics (Premium), and we saw it in play in Programming Windows: Hello, Windows (Premium).

Using push was probably the right call as it would enable Windows to implement real multitasking. By comparison, the Macintosh used an inferior “pull” model by which applications were in charge. This system would bog down the Mac technically until Apple purchased NeXT and replaced Mac OS with the NeXT-based Mac OS X in 2001.

But Microsoft also limited Windows—in part to appease Apple, ever-nervous about this new threat—to tiled windows. So instead of the overlapping windows found on the Mac, Windows 1.0 could only display applications and other windows side-by-side, or in grids, on the screen.

As with the Interface Manager name, some inside Microsoft—including McGregor—felt that tiled windows were superior because overlapping windows could get lost, and their data was hidden. And the performance was much better. But Gates wanted Windows to fully copy the Macintosh. “I want Mac on the PC,” Gates repeatedly told McGregor.

He would eventually get it. But first, Windows 1.0—OK, Windows 1.03—had to ship. And that took over two more years, with Microsoft continuously missing publicly promised deadlines and delaying the release by months each time. During this time, Microsoft decreed internally that it would no longer “invest significant development” in applications based on character-based environments like CP/M, Apple II, or MS-DOS. Its plan? Implements new applications and upgrades first on the Macintosh and then “port them to Windows.” The design of Windows was dictated such that this porting would be “as easy as possible.” As correctly noted in Gates, “Gates was betting the company on GUIs.”

But Microsoft also designed Windows, even the first version, to be superior to the Macintosh in some key areas.

“Windows goes beyond Mac in several areas, including support for multiple active applications and variable [screen] resolution[s],” internal Microsoft documentation noted at the time. “Over time, Windows systems will dominate since they will have more software than any other. It is crucial to our future to establish Windows as THE STANDARD graphics interface for microprocessor software by the end of 1984.”

Windows wouldn’t arrive until 1985 and it wouldn’t achieve any measure of success until the release of Windows 3.0 in 1990. But in the interim, the x86 world wasn’t standing still. Intel pushed past the 8088 and 8086 processors with the 80286, a truly innovative processor that finally broke through the limited and limiting 640 KB segmented memory model used by previous x86 chips. Thanks to its new protected mode, the 80286 could access 16 MB of RAM, a 16x improvement, albeit it in 256 KB segments. It also supported virtual memory, paging, and protected multi-tasking, features that would prove critical to Windows.

Intel then followed up the 80286 with the 80386, which provided a full 32-bits of address space, good for up to 4 GB of RAM. Better still, that address space was non-segmented, or flat, with none of the address limitations imposed by previous designs. So, Microsoft eventually evolved Windows 2 into two separate versions, Windows/286 and Windows/386, that addressed (ahem) the unique capabilities of the respective Intel processors. Previously, Windows only supported real mode with its 640 KB/1 MB memory limitations.

From an application developer’s perspective, the underlying improvements in Windows were transparent. As the operating environment gained overlapping windows in Windows 2.0 and supported the 286 and 386 protected mode functionality and thus PCs with more and more RAM, their applications would continue to just work. Would, in fact, work better as users upgraded. This was the promise of device and machine independence realized, and it made the pain of working with the obtuse Windows API a bit more bearable. Especially when Windows finally reached mass appeal starting with version 3.0.

Windows 3.0 was an important milestone and not just for the users who appreciated its more sophisticated user interface and support for windowed MS-DOS applications. Windows 3.0 combined the functionality of Windows/286 and Windows/386 into a single product and automatically supported whatever processor the user’s PC contained. (And Windows 3.1, released two years later, would cut support for real mode and the 8088/8086 processors entirely.)

Between Windows 1.03 in 1985 and Windows 3.1 in 1992, the Windows API exploded in size, from having about 450 function calls in the initial version having over 1000. The additions were mostly related to new Windows features that developers could target, and Windows was getting pretty sophisticated over this time period, adding support for such things as inter-app data sharing, first through Dynamic Data Exchange, or DDE, and then through Object Linking and Embedding, or OLE. Microsoft also standardized such things as dialog boxes and application models, including multi-document applications.

During this time, the Windows API was just, well, the Windows API, something that we would today refer to such a thing as an application framework. But as Microsoft started to push towards its 32-bit future—first via OS/2, and then via NT, which evolved into Windows NT, another topic for future articles—it needed to evolve the Windows API as well, since it wanted to use a Windows user interface as one of several OS “personalities” for NT. (Eventually, it became the primary and then sole user interface.) And thus Win32, a 32-bit version of the Windows API, was born.

Win32 was an important milestone. In NT, it was supported by 32-bit versions of the core Windows files, Kernel, GDI, and User. (Windows 95, which arrived in 1995, included both 16- and 32-bit versions of these files, since it was built on 16-bit MS-DOS but also supported 32-bit Win32 features and 32-bit applications.) And it was the source of some weird renaming and confusion.

First, the original 16-bit Windows API was renamed to Win16 to differentiate it from Win32. The Win32 API employed by Windows 95 was originally called Win32c (for compatibility. And Windows 3.11 and Windows for Workgroups 3.11 both stealthily supported the same 16/32-bit underpinnings of Windows 95 and would run yet another Win32 subset, called Win32s, and some small selection of 32-bit apps too. The Win32s and Win32c names were quickly dropped, however.

The transition from what we’ll now call Win16 to the 32-bit Win32 was a bit painful for application developers. 16-bit applications written to Win16 would still run in Windows NT and 95—natively in the latter and in emulation in the former—but new (or upgraded) 32-bit applications would require the more modern Windows versions. Microsoft had always designed the functions in the Windows API—now at “well over a thousand,” according to Charles Petzold in Programming Windows 95—such that data types passed as function parameters were essentially virtualized for the developer, easing portability.

Parallel to all this, the Windows software development market was expanding into two key areas: Object-oriented programming and RAD (rapid application development). Microsoft would field entries to address both market trends, but so, too, would its competitors.

Application generators like Caseworks Case:W 3.0 sought to overcome the most obvious limitation of Windows API development by providing programmers with simpler GUI-creation tools. Programming environments, including Microsoft’s, moved from MS-DOS to being fully Windows-based and eventually adopted sophisticated integrated development environments, or IDEs, ending the need to jump from tool to tool. And competitors like Borland’s Turbo Pascal outperformed Microsoft’s offerings, triggering a series of Microsoft Quick-branded releases for BASIC, C, and Pascal that eventually became Windows-based in some cases.

“Turbo Pascal for Windows is a hosted graphical interface for Windows,” Borland’s Gene Wang told Byte Magazine in late 1990. “It uses the Multiple Document Interface for handling multiple files, he said. While a demonstration program was running in one window, Wang compiled and ran a Pascal adaptation of Charles Petzold’s Hex Calculator application. The company will deliver Turbo Pascal for Windows sometime in the first half of [1991], according to Wang.”

But writing applications directly to the Windows API, whatever it was named at the time, was quickly being overshadowed by more modern and friendlier ways to create Windows applications.

“The Windows interface is not known for its friendliness to developers, and the standard Software Development Kit (SDK) offers no relief from the burden of laying out interfaces by hand,” Byte noted in March 1993. “Microsoft seems content to leave the simplifying of Windows development to third-party companies.”

At that time, Microsoft was already on its third revision of Visual Basic, an incredibly friendly and easy-to-use Windows application maker. And the firm was evolving its C++ class libraries into the Microsoft Foundation Classes, an application framework that sought to hide the complexities of the Windows API behind easier to maintain, object-oriented C++ code.

I will be examining both of those initiatives soon. But first, let’s wrap up the Windows API discussion by quickly examining its current state. After all, today’s PCs are 64-bit, not 32-bit. Is there a Win64 API now?

Not exactly. To avoid confusion, and in deference to the fact that most application developers today use more modern and high-level interfaces to create Windows applications, Microsoft never created a true Win64 API that is separate from Win32. Instead, Win32 was evolved to support both 32-bit and 64-bit systems. The only major impact was to C pointers, which are 64-bit in nature on 64-bit PCs, not 32-bit. Yes, 64-bit PCs can access far more RAM than is possible with 32-bit PCs. But because the memory address space is still flat, that’s transparent to developers.

(Fun aside. A 64-bit PC can theoretically address 16.8 million terabytes (TB), or 16 exabytes, of RAM. But we’ll never a see a PC with that much RAM, and not just because of physical space requirements. I believe that the most RAM that Windows 10 currently supports is 512 GB.)

Likewise, Windows 10 on ARM systems emulate the x86 processor architecture and can run 32-bit (but not 64-bit) applications that are written to the Win32 API or to a higher-level environment that uses Win32. This could present a problem for larger, commercial applications. But Microsoft has engineered its developer tools to support generating both 32-bit and 64-bit—and, for some modern environments, native ARM—applications. Unless 64-bits on the desktop is required, even ARM doesn’t present much of a challenge to application developers these days. (Drivers are a different story.)

But here’s the final irony. The Windows API, which evolved into Win16 and Win32 but not into Win64, has recently been renamed yet again. Today, it is called … wait for it… the Windows API. Again.

Looking back on the questions about whether Microsoft today will toss out its UWP apps and rewrite them in “Win32”—or, perhaps in a web environment like PWA—sort of ignores the fact that nobody—not Microsoft, not third-party developers—would actually start creating new Win32 (or Windows API-based) applications today. There’s just no point in doing so: The Windows API is a flat, non-hierarchical mess of C-based functions that doesn’t scale to meet today’s needs. It’s not a modern framework.

Instead, the application development world has long since moved on and, in the case of such once-legacy frameworks like Windows Forms and Windows Presentation Foundation, has actually gone back in time, with Microsoft calling for a do-over and making these frameworks viable once more. (That both have been open sourced as well is interesting for other reasons.)

Regardless, WinForms and WPF are both far more modern than the Windows API. And while we don’t know what will follow UWP, if anything, we do know that it won’t be the Windows API. That ship hasn’t just sailed, it’s gone past the horizon line, from the perspective of application developers. Win32 still exists, as it’s the foundation for these more modern frameworks. But it’s correctly regarded as plumbing today, a low-level environment akin to assembly language that is more a curiosity than an ongoing concern.

We are, of course, getting ahead of ourselves.

As the 1990s dawned, Microsoft had already figured out that Windows API programming was untenable for most and wouldn’t scale to the needs of application developers who wanted to address modern Windows features and technologies, more easily build application user interfaces, and utilize more modern programming languages, frameworks, and environments. And throughout that decade, it quickly escalated in all of these areas, evolving both Windows and its developer tools in tandem. So, I’ll look at those advances next. We are still very much at the beginning of this story.

More soon.