In my original Longhorn build 4051 review, I focused on the events leading up to the Professional Developers Conference (PDC) 2003 and some of the more superficial changes Microsoft made between previous alpha builds and build 4051. I was originally going to follow that with an in-depth look at the various technologies exposed by Longhorn build 4051, but that portion of the review grew out of control. So here, a month later, I've reorganized. My full Longhorn build 4051 review will now be delivered in several parts, with the first two parts being made up of the original review.
In the subsequent parts, I am delving deeper into the technologies behind this build, and examining the crucial building blocks that will form the basis for the next Windows version. To understand or even discover some of these technologies requires experimentation with the Longhorn Software Development Kit (SDK), which exposes many of the features of this operating system programmatically, letting software developers create Longhorn compatible applications and services. So I've had to dust off some long-buried programming skills and get my hands dirty, so to speak, for the first time in several years. It's been an interesting exercise.
Longhorn is a confusing product. In many ways, it is a drastically revolutionary operating system, sporting a completely new .NET-based software development infrastructure that provides Windows with core presentation, storage, communication, security, and management features that would be difficult if not impossible to implement on previous Windows versions. On the other hand, Longhorn is very much an evolutionary improvement over Windows XP and Windows Server 2003, offering backwards compatibility with applications dating back to MS-DOS. One of the very real factors behind the success of Windows is Microsoft's dedication to not completely obsoleting previous technologies. That is, there is little distinction between a "real" Longhorn application--one that is written directly to Longhorn's new programming interfaces--and a "legacy" Win32-based application that runs today on Windows XP; instead, Microsoft actually provides developers with ways to easily add Longhorn-specific functionality to these legacy applications, without even requiring them to recompile, or recreate, the original application. I don't intend to delve too far into this aspect of Longhorn's programming interfaces in this review--after all, there's already enough ground to cover as it is--but this attention to developer needs is often overlooked, especially by Microsoft's critics.
Longhorn is a complicated product. Once you get past the immature veneer of the current alpha builds, you discover a wealth of new features, some of which are already implemented, some of which will arrive in later builds. And then there's the stuff we don't know about: With two years of development time, Longhorn will likely change dramatically between now and the final release. Fortunately, I think it's safe to assume that that many of the low-level technologies I present here are pretty much written in stone, and won't change that much at all.
So where do we start? All of the current Longhorn documentation is written for developers--heck, most of it hasn't even been written yet anyway--so that doesn't help much. Looking over my notes from PDC 2003, I've decided to break down my Longhorn 4051 review into some of the low-level building blocks that Microsoft used to explain the underlying system. That is, once we get past the introductory material, we'll look at the Avalon presentation system, followed by the WinFS storage subsystem, and then the Indigo communications technologies. After that, I'll examine other core Longhorn technologies, including security, help and support, management and administration, and some of the unique issues developers will face when they turn to Longhorn software development.
OK, let's get started.
Next: Introduction