Early this month, Microsoft dropped something of a bombshell on Windows developers: the new Windows 8 touch-friendly immersive style would use a developer platform not based on .NET, which Microsoft has been championing for the past decade. Instead, it would use HTML5 and JavaScript. Since then, the company has refrained from making any further comment on the issue. In particular, the question that has many Windows developers particularly concerned—how can I make use of my existing skills and experience when developing these new applications?—remains unanswered; the company plans to reveal nothing until its BUILD conference in September.
But the situation probably won't be as grim as many developers fear. Early milestone builds of Windows 8 have leaked onto the Internet, and considerable effort has been put into figuring out how they work. Though officially tight-lipped, snippets of information have escaped Redmond's walls. So far, it appears that Windows 8 development doesn't just look not bad—there are signs that it will actually resolve many long-standing annoyances with writing Windows software. If Microsoft can pull off everything it's hoping to achieve with the platform, Windows 8 will be as important and radical a release as Windows Longhorn was going to be.
A little bit of history
Before we look at what Microsoft will be doing with Windows 8, a little context is necessary. To understand the vision and why it's such a break from the past, one first has to understand the current reality.
Prior to the introduction of .NET in 2002, Windows applications were written in two main ways. "Big" applications—think Office, or Photoshop, or Netscape Navigator—tended to be written using the Win32 API and C++. Win32 is a large API that covers a lot of ground. There's lots of "obvious" stuff, like graphics and user interface creation, network communication, and file system access, and there are also many more esoteric things, like backup creation, network configuration, and security.
It's big, and it does a lot, but there are important things that it doesn't do very well, and some things it doesn't really do at all. For example, although it includes an API for database access—several, in fact—it's rather fiddly to use plain Win32 for writing applications that use databases a lot. More problematically, even though it has all the basic tools you need for putting together a GUI, it sure doesn't make it easy. For example, it doesn't give you any assistance when laying out a user interface. Each button, text box, and toolbar must be positioned by the developer. If you want the positions to change when you enlarge the window, well, you have to do that all yourself. Many libraries were developed to act as a layer between the developer and the operating system to try to make this task easier, including Microsoft's own MFC, but all too often you have to delve into Win32 to get things to work just the way you want.
The other major way of writing Windows applications was Visual Basic. Visual Basic made some tasks really easy—in particular, talking to databases and creating user interfaces—and it became a staple of the business world. An awful lot of business applications out there do little more than pull information out of a database, show it to a user, and give the user a form so they can add data. At these tasks, Visual Basic excelled. What it wasn't so hot at was anything else. It had little good support for calling Win32 functions directly, especially those that used certain constructs that Win32 depends on.
Visual Basic also lacked support for the rather popular object orientation paradigm, being merely "object-based."
.NET came along and changed all that. .NET gave developers much of the ease of use of Visual Basic, but did so without the compromises that Visual Basic imposed. Similar to Visual Basic, it had good tools for building user interfaces and talking to databases, so it was eminently suitable for writing business applications. But, unlike Visual Basic, it also made access to Win32 an easy, if slightly awkward, option. The platform rapidly gained traction with business developers, and some new commercial projects also used it.
The Longhorn dream
Windows XP, released the year before .NET, unsurprisingly didn't use the technology. But as Microsoft announced at PDC in October 2003, that was due to change with the release of Windows Longhorn. Longhorn would integrate .NET into the core Windows platform. .NET FX, as it was known in the company (with "FX" standing for "framework") would give way to WinFX, a Windows Framework based on the same technology. Among other things, this would include a brand new way for writing user interfaces, codenamed Avalon, that would be thoroughly modern, vector-based, and hardware-accelerated. Windows itself would be written to use WinFX for its user-visible programs—Explorer, calculator, and so on—and, going forward, .NET would be the way to write Windows applications. Win32 would still exist for backwards compatibility, but it would be frozen and left static.
Longhorn would have been the end of the old ways of writing Windows programs, and the dawn of a new era of modern Windows development, one that was not hamstrung by design decisions made ten or fifteen years prior.
As we all know now, Longhorn never shipped as such. The project grew enormous, unmanageable, and broken. Around the same time, Windows XP, on which Longhorn was based, was being ravaged by hackers. Microsoft poured its resources into making Windows XP and Windows Server 2003 tolerably secure—an effort that culminated in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1—then, for the most part, started development of its next operating system, the one eventually to ship as Windows Vista, all over again.
One of the biggest losers in this developmental reboot was .NET. Windows Vista, though radical in some ways, abandoned the entire "WinFX" concept. Avalon did ship—it's now known as Windows Presentation Foundation (WPF)—but as an add-on to the operating system, not a core part. The only significant piece of .NET code in Windows Vista and Windows 7 is Media Center (and that doesn't even use WPF). Everything else is plain old Win32. More significantly, the Win32 API itself was updated and extended. Numerous low-level features were added, and support for GUI changes, like Windows Vista's taskbar thumbnails and the Aero Glass theme, were added to Win32. None of these GUI changes worked especially well with WPF.
There were a few factors that led to this decision. Part of it was simply expediency; there wasn't time to rewrite everything to use .NET. But perhaps the bigger factor was internal divisions within Microsoft. Windows is from the Windows division (WinDiv); .NET is from the Developer Division (DevDiv), which in turn is part of the Server and Tools business. Although one might think that these groups were aligned in their objectives, this was not the case. Not necessarily out of any malice—just that the groups had different priorities.
Fractured development
Some of these priorities made sense at the time. WPF, for example, can only be used by .NET programs, and it only works well with ones written in C# and Visual Basic.NET at that. The entire API, from top to bottom, is off-limits to native C++ programs, making it a significant effort to migrate existing programs to use WPF. This made sense when all future development was meant to use .NET, but when that plan changed and native code regained its position as the preferred development environment, it was a big problem. Microsoft couldn't use the clean, vector-based, resolution-independent, hardware-accelerated, WPF library to build any of the core operating system applications.
Others priorities were simply a result of the different purpose of the groups. So, for example, DevDiv's priorities were to make .NET a credible platform developers; this meant adding new core functionality and developing libraries and tools such as Silverlight. WinDiv's priorities were the aforementioned C++ compatibility, robustness, and fixing certain technical issues. All the objectives were sensible, but because DevDiv didn't answer to WinDiv, not as much weight was given to the things WinDiv wanted. The result was that WinDiv management wasn't happy with .NET and was happy to ignore it.
Subsequent releases of .NET have improved the situation, with all but the C++ issue now resolved. The damage had already been done, though; WinDiv, dissatisfied with DevDiv, ignored its work, and Windows 7, just as its predecessor, uses .NET only for Media Center. Windows 7's new APIs are all native C++ APIs, with no ready access from .NET programs, and native C++ programs still have no access to a resolution-independent, vector-based, hardware accelerated framework for building user interfaces.
Windows 8 will put an end to that.
reader comments
220