Programming Windows: Windows 95 (Premium)

The success of Windows 3.0 and 3.1 had catapulted one of Microsoft’s biggest embarrassments into a worldwide success the likes of which the personal computing industry had never seen. But the next release, called Windows 4.0, and expected in late 1993, would be even bigger. Indeed, by the time it hit the market in August 1995 as Windows 95—the name was changed in July 1994 as part of a company-wide product naming revision—it was clear that this launch would mark the apex of Microsoft’s success.

“Microsoft’s goal for Windows 95 are the same goals we’ve had for every release of Windows,” Microsoft executive vice president Steve Ballmer wrote in the foreword to Adrian King’s Inside Windows 95 in mid-1994. “We want to make computing even easier. We want to provide a development platform for the desktop. We want to provide a high-volume, low-cost operating system that will spur industry growth and innovation. We believe that Windows 95 will accomplish these goals and that Windows 95 will be even more important to the PC world than Windows 3.1, which now has over 60 million users.” (It would have over 100 million users by the time Windows 95 finally shipped.)

Windows 95 represented a major step forward for the creaky, MS-DOS based operating system that Microsoft had first released a decade earlier. It hid, but did not remove, its MS-DOS underpinnings, making the system appear more cohesive and less like “a thing on a thing.” (And despite some internal debate on this topic, Microsoft would no longer sell MS-DOS separately.) It shipped with a new and more consistent desktop-based user interface that we’re still using today in Windows 10, and it supported long file names in the file system. It adopted networking technologies from Windows for Workgroups, enabling Windows 95 to work with the emerging Internet of the day. And it adopted the Win32 application runtime from Windows NT, allowing developers and users to transition to the 32-bit world.

Windows 95 also offered new technologies of its own. It was the first version of Windows to support Plug and Play (PnP), a much simpler way to connect and configure hardware peripherals, erasing one of the few remaining Mac advantages. It was the first version of Windows to explicitly support the unique needs of portable computers, including power management, docking and undocking, and file synchronization via a Briefcase application. It was the first to offer integrated multimedia capabilities which had debuted previously as add-ons. And it provided the WinG graphics library for games, a predecessor to DirectX that allowed MS-DOS game makers to port their titles to Windows.

The benefits of Windows 95 to end users are probably well-understood, given that the basic user interface remains in Windows 10, almost 25 years later. But the benefits of this system to developers are perhaps less well-understood. As is the relationship between Windows 95 and a fully 32-bit platform like Windows NT.

Thanks to its legacy underpinnings, Windows 95 was a 16/32-bit system, like Windows 3.1 and Windows for Workgroups 3.1x. As such, it could run 16-bit MS-DOS and Windows applications unchanged, a huge boon for application developers and their customers. But as noted, it was also the first DOS-based version of Windows to support the Win32 application runtime that had debuted in Windows NT two years earlier. Major new application development would shift to 32-bits going forward as a result and developers would benefit from the clean 32-bit memory model and from Windows 95’s more sophisticated preemptive multitasking.

Microsoft’s decision to base the Win32 API on the older, poorly designed 16-bit Windows APIs, retroactively renamed to Win16, was a well-intentioned mistake. The goal was to make it as easy as possible for developers to port their Win16 code to Win32, and so Win32 included the same basic syntax, function names, and functionality; in fact, they were identical where possible. But in doing so, Microsoft would only ensure that native Windows application development would never be clean and sophisticated, and that it would always need to create more modern frameworks on top of that.

That said, Windows 95 also marked a period of stability for the Win32 API. New functions would be added to address new OS features, of course. But the core of the API remained mostly unchanged for decades to come. The shift to 32-bits was dramatic and painful. But that was the last time such major changes were made to Win32.

Which is good, because by the time the Windows 95 version of Win32 arrived, the Windows API had grown over five-fold: There were now over 2200 interfaces in the API, up from about 400 in the first version. It included support for complicated technologies like OLE and COM, and it supported all the new user interface controls and objects (see below) that Microsoft provided in Windows 95. And it fully supported all of the networking, communications, multimedia, and pen features in Windows 95 as well. (Windows 95 would not support UNICODE, as did NT, thanks to its ANSI character set roots, so that was another issue that developers had to deal with.)

From a configuration standpoint, Windows 95 formalized the use of the Registry, which was created for Windows 3.1 but wasn’t widely used at first. Implemented initially in NT, the Registry was a response, of sorts, to the plain text files that Unix used to store configuration information. With the Registry, there would be a central interface for configuration, not dozens or hundreds of text files scattered throughout the file system. It would be logical and well-organized (in theory), and it would be available to all Windows applications. It seemed to make sense at the time.

The Windows 95 user interface had originally been designed by Jim Allchin’s Cairo team for a future version of Windows NT called Cairo, which subsequently never came to market. Their original design was “completely object-oriented,” but it required computing power that simply wasn’t available in that day, especially in the low-end mainstream PCs that would run Windows 95.

So the Windows 95 shell team, led by Joe Belfiore, adopted the look and feel of the Cairo UI for their less sophisticated platform, leaving most of its OOP underpinnings behind. Yes, there were “objects” in the shell—icons, the taskbar, and so on—most of which could be right-clicked for options, including properties. But it was object-based, not truly OOP. The shell team also used a small subset of Microsoft’s component-based COM technologies to provide OLE 2 functionality and drag and drop capabilities.

Indeed, OLE 2 played an outsized role in the design of Windows 95. It was so important, in fact, that Microsoft moved COM and OLE out of its Application Division and into its Systems Division in late 1993 so that its work could be more deeply integrated into the company’s platforms. At the time, Microsoft saw OLE 2 as the first step toward implementing Cairo, and the Windows 95 shell as the second step. But for users of Windows 95, the biggest impact of this technology was the system’s support for document-centric computing.

Previous to Windows 95, Windows had been application-centric: In this model, the user found and then launched applications in order to get work done. If you needed to write a word processing document, for example, you would have to know which word processor was available on your PC—Microsoft Word, perhaps—and where it could be located in Windows; most likely in a Program Manager folder.

Document-centricity was based on OOP ideals. Under this model, users would not need to think about programs and files, but about documents. For this to work, Windows 95 needed to both support the application launching methods of the past—where Program Manager folders had evolved into Start menu folders—and new user document-centric interfaces. As important, Microsoft’s productivity applications, most notably in Office 95, needed to support document-centric technologies like compound documents. Among other advances, Office 95 provided a Binder application that let users combine multiple Office document types into a single unit.

This model failed for a variety of reasons: It was confusing to users, third-party developers never supported it in their own applications, and even Microsoft did little to further the technology beyond the basics in Windows 95 and Office 95. By the time the next major versions of both products—Windows 98 and Office 97—had respectively shipped, Microsoft had pretty abandoned this model and, perhaps not coincidentally, Cairo as well.

One Windows 95 user interface concept, called browsing, did have legs, however. And it coincidentally coincided nicely with the notion of web browsing, triggering a future effort to integrated web and Internet technologies more deeply into Windows. Microsoft included an application in Windows 95 called Explorer—later renamed to File Explorer and then Windows Explorer—that let users easily browse the file system, the local network, printers, and other objects. It replaced separate “manager” applications from Windows 3.x, like Program Manager, File Manager, Print Manager, and others, and is the reason that Microsoft’s web browser was named Internet Explorer: It would allow users to browse the Internet.

Windows 95 would not use Windows NT’s advanced file system, called NTFS; indeed, no version of Windows 9x was ever made compatible with NTFS. But the advent of 32-bit computing did allow Microsoft to advance its DOS-based FAT file system into something called VFAT. VFAT provided support for long filenames (where previous Windows and DOS versions supported only 8.3 names), and installable filesystem architecture for network browsing, and improved performance thanks to its 32-bit multithreading underpinnings.

As another first step toward the OOP-based Cairo, the Windows 95 shell also supported shortcuts, originally called links. Shortcuts were clearly the invention of a developer, as they were a way to create a reference to an object without having to create a duplicate of the original object. You could create a shortcut for an application, a document, or a folder and place it anywhere convenient, including your desktop. And when you double-clicked it, the original object would appear.

(Fun aside: Microsoft considered other names for shortcuts, including nickname, remote control, jump, and post it.)

The Windows 95 interface also arrived with a stunning new array of consistently-designed user interface elements, which included menus, icons, property sheets, common dialogs, and new controls, like the toolbar, button list, status window, column heading, progress indicator, slider, spin box, rich text, tab, list view, tree view, and others. Many of these objects had appeared in one form or another previously, but because they were improved and formalized in Windows 95, they could be used by any application developer.

Windows 95 was incredibly well-received by developers, users, and corporations. But its place in the Microsoft operating systems stable alongside Windows NT was the subject of some confusion. With Windows 95 adopting the Win32 API and other NT technologies, was it possible that Microsoft would one day combine the two product lines into a single platform?

At the time, Microsoft did not believe this would ever happen.

“We see forever having to maintain at least two implementations of Windows in order to be able to cover the broad spectrum of people use PCs,” Microsoft senior vice president Paul Maritz said about a year before Windows 95 shipped. “That’s been our strategy for the last three years, and I can see that as being our strategy in the future.”

Looking ahead, Microsoft acknowledged that there would be successors to Windows 95 that would incorporate technologies that were then only found in NT. But it felt that there would always be mainstream Windows versions targeting the installed base as well as new PCs, and a high-end product line, NT, where the focus was on “client-server computing, distributed computing, system administration” and more. The two lines would share technology—and in both directions, as Windows 95’s Plug and Play functionality would later come to NT—but would also remain separate.

This sounds somewhat unbelievable today, and most readers probably understand that Microsoft did eventually combine the two product lines with Windows XP in 2001. But Microsoft’s bet on NT was also a bet on portability, and that the Intel x86 platform might not scale to meets the computing needs of the future. NT, unlike Windows 95, could run on other platforms, including futuristic RISC chipsets that were all the rage in the 1990s.

That future would be written eventually. But in the meantime, Microsoft had Windows 95, a smash success with customers. And a pretty impressive advance over its predecessors, especially given its humble underpinnings.