Programming Windows: A Lap Around Longhorn (Premium)

At the conclusion of Bill Gates’ exciting PDC 2003 opening keynote, which featured Hillel Cooperman showing us Microsoft’s proposed Longhorn user experience for the first time, Microsoft’s chairman ceded the stage to Jim Allchin, the amiable and soft-spoken engineer who led the Windows team. Where the Gates keynote focused on the flash, the Allchin keynote—which was called “a lap around Longhorn”—focused instead on the nuts and bolts of Longhorn app development. And to understand that, Allchin explained, he would start with the following “eye chart,” a detailed architectural representation of the .NET-based WinFX APIs.

PDC 2003 was flush with these types of diagrams, which were handed out to eager showgoers in poster form around the convention hall in addition to being available digitally in our welcome packages. The density of these diagrams was a form of “shock and awe” for developers, they were specifically designed to highlight how dense and technical these APIs were, and how much work that Microsoft’s architects had put into them.

But as Allchin explained, you could also look at the Longhorn software architecture from a higher level, which provided a simpler view in which there were just four key areas: Fundamentals, which included the base operating system services and then the Avalon, WinFS, and Indigo SDKs on top of that. Microsoft was trying to distance itself from .NET at this time, but Fundamentals represented the services we would have previously (and have since) associated with the .NET Framework, while Avalon, WinFS, and Indigo were managed code SDKs that built on top of the .NET Framework, as had other SDKs in the past, like Windows Forms.

In a sign of Microsoft’s ambivalence about .NET during this time, Allchin referred to WinFX as “the next step beyond Win32,” positioning it as a successor to Microsoft’s classical Windows app development technologies. That said, he did at least mention that it “builds on the .NET Framework.” In reality, it was the .NET Framework, a new version of it, and as history will show us, Microsoft eventually brought it to market as such. But on that day, it was clear that the software giant was moving past .NET, at least from a marketing perspective.

“It’s very well structured,” Allchin noted of WinFX, correctly. “This is something we expect to last decades, and so we spent a lot of time thinking about how the classes, the types, the methods, the properties, the events, all fit together so it’s a holistic environment. Actually, every time a new extension is put into this system, it’s reviewed by a set of system architects, and then it’s usability-tested by a set of developers. We think we’re doing a good job. We’re interested in what you provide to us as feedback about this.”

Be still my heart.

WinFX, Allchin explained, would dramatically expand the capabilities available to Windows app developers while doing more on behalf of developers, thus reducing the amount of code they would need to write. He also promised that WinFX would give developers a way forward, whether they were focused then on Win32 or the .NET Framework, two very different environments. (If you’re familiar with Microsoft’s current developer story, this seems more than vaguely reminiscent of the promises for the Windows App SDK/Project Reunion today.)

Allchin then launched into the lap. Starting, of course, with Fundamentals. This was an area in which Microsoft was making deep investments, though they were not as flashy or fun as the UI and WinFS stuff that Cooperman had previously wowed the crowd with. Longhorn was being architected with sandboxes between applications and drivers, Allchin said, to create a more resilient Windows. It would include new app deployment via a technology called Click Once. Servicing improvements that would lead to fewer reboots, and when rebooting was necessary, it would be faster. Security improvements, including Software Updates Services (SUS), driver signing, biometrics, Digital Rights Management (DRM), and much more. And performance improvements, of course, thanks to technologies like SuperFetch and the ability to take advantage of the PC’s graphics processor in ways that only games did before.

The next part of the lap dealt with Presentation, or what most people think of as user interface or user experience. “Today, there are basically two [presentation] models, the Windows app and the web app,” Allchin began, touching on a central ongoing battle internally at Microsoft. Both have great characteristics, he said, but both also had their pros and cons. Web apps, for example, provided great text reflowing capabilities that could adapt to a resizing browser window on the fly, and simpler deployment. But fundamentally, Windows apps and browser-based web apps were two different worlds.

The solution, Allchin said, was “one world.”

And in keeping with his earlier victory over Brad Silverberg for control of the Windows user interface, that one world would be based on proprietary Microsoft technologies, and not on web standards. A new technology codenamed Avalon would give developers a unified presentation model for Windows apps and web apps. “This is a big step forward,” he said. “We’re going to take the best of both worlds and create one programming model that you can count on.”

Avalon would use a vector-based compositing engine, and while Allchin didn’t call this out—Microsoft at that time publicly ignored the competition—it was specifically designed to leapfrog the technical advances that Apple had delivered in Mac OS X. In Longhorn, Microsoft would replace the separate 2D and 3D graphics engines in previous Windows versions with a single graphics engine, and it would handle everything—text, media, animations, graphics, whatever—while offering better performance. Avalon was designed for the high DPI displays of the future, and it would provide native support for natural inputs like remote control, Digital Ink, and speech, consolidating previously separate efforts.

And then Allchin moved into what I think to be the central developer innovation in Longhorn from a presentation perspective, the ability to use “declarative programming” techniques to describe application user interfaces. Instead of the hard-coded, pixel-specific UIs of the past—which would not scale well on those new high DPI displays—this new style of programming would instead let developers describe a user interface in terms of how different elements were positioned in relation to each other, similar to how HTML works for web pages and web apps.

“Through the ages, as we’ve moved from Assembly Language to C to [Visual Basic], we’ve made steps up in the capability of what you can do,” Allchin said. And declarative programming was the next step in this evolution. Using a new HTML-like markup language, based on XML and called XAML (and pronounced “Zammel”), developers would be able to build Longhorn apps using simple declarative sentences that were “easy to learn, write, and read.” XAML would work in tandem with programming languages like C# and Visual Basic .NET, separating the presentation from software logic. And because it was XML-based, XAML would lead to a new generation of tools that could easily read and generate it on behalf of developers. There would be visual designers, like those we had used previously in Visual Basic and Windows Forms. But they would spit out clean, human-readable XAML code.

Looking back on this now, it’s hard not to see XAML—which is still in use today in modern app frameworks like the Windows App SDK and .NET MAUI—for what it really was: an attempt to embrace and extend the web but using proprietary Microsoft technologies. Instead of using HTML, CSS, and JavaScript to create web applications that could work anywhere, developers would use XAML, C#, and WinFX to create Windows applications and web applications, the latter of which would only work in Microsoft’s web browser unless rivals supported it too.

But XAML was still an incredible innovation, a big leap forward for Windows app development. And its continued use by Microsoft in several developer frameworks in the intervening years speaks to its power and versatility. It would make it easier for teams to hand off UI work to designers, and the underlying logic to developers. It also let people play to their strengths: with Avalon, a developer could write an entire Windows app using just software code if desired. And designers would even integrate software code into XAML—though this is rare in real-world terms—if needed. But the real power of this environment came from its duality, with front-end presentation separated from the back-end logic.

“XAML gives us the ability to separate what’s called ‘code-behind’ from the design,” Allchin said, using a then-unfamiliar term that today is very familiar to .NET developers. “So you can have collaboration between designers and developers.”

In a very quick example, he showed how one might create a button for a Longhorn app declaratively, using XAML, or using straight C# or VB. NET code, where either approach would result in the same control. But then he brought out the big guns—Longhorn architects Don Box and Chris Anderson—to provide a series of live coding examples showing just how fast, easy, and even fun that Longhorn app development could be.

This segment of the PDC 2003 keynote remains a personal favorite among all of Microsoft’s many developer shows, and while there have been ever-weaker attempts to copy its style at Microsoft developer events in more recent years, I’ve never seen anything quite like it.

Box and Anderson had finetuned this presentation for some months, and you can see evidence of that in a very similar MSDN TV video, also called A Lap Around Longhorn, that they produced internally. But it’s also obvious from their casual closeness and familiarity that these two had spent most of their time doing little other than honing the Longhorn developer story. They were masters of both the content itself and how to explain it to others. And their playful joking and playing off each other is clearly natural and not forced. This is the bar by which all such demos must be compared.

Put simply, what Box and Anderson showed developers that day was how to create Longhorn apps. But it is how they did so that is most interesting to me. Eschewing modern toolsets like Visual Studio, Box and Anderson used the Windows command-line console and plain text editors like Emacs to create, edit, and then compile C# files into running Longhorn graphical applications. This was a clear nod to Charles Petzold, who had made a career out of ignoring high-level tools out of a belief that developers need to know what’s going on under the hood. But unlike Petzold’s C-based Win32 applications, which are ponderous and code-heavy by comparison, the code that Box and Anderson wrote live, on stage, clearly demonstrated how far things had advanced with WinFX and Avalon.

“All of the functionality that you’ve seen today are exposed by a simple set of managed APIs,” Anderson explained while Box, coding, imported the various WinFX namespaces that developers would need to write a basic Longhorn app. “The key thing to remember here is that, in Longhorn, this isn’t creating some wrapper that is calling [the Win32 API] CreateWindow under the covers. This is instantiating the real code that’s going to execute this app.”

The inference there is that WinFX wasn’t a “thing on a thing,” like Visual Basic or the Microsoft Foundation Classes (MFC). It was, instead, “native” code, and thus on par with the C-based Win32 API. Strictly speaking … that wasn’t true, as the .NET-based WinFX libraries were managed code, not native code; in fact, the compiler spit out Microsoft Intermediate Language (MSIL)/ Common Intermediate Language (CIL) code, not native code, and that was translated at runtime into something the underlying platform could understand. But again, a big part of the messaging at PDC 2003 was around making WinFX seem like the next Win32.

During this, Box created a very simple Longhorn application with just several lines of code. Compiling it into a running app from the command line required referencing three DLLs related to Longhorn (Windows) and Avalon and specifying that the target was a Windows app—features that are built into Visual Studio, of course—and there it was. “The first Longhorn application compiled at the PDC.”

It was, of course, just an empty window. But its appearance was, of course, met with applause. It could be resized, moved around, maximized, and minimized, all the things one would expect. “This is that Avalon thing you guys have been spending like three years on, right?” Box asked Anderson to laughter.

But there were many improvements to come. Box and Anderson moved from the command line C# compiler to Microsoft’s new unified build system, which provided some relief from the tedium of having to type in obscure commands each time. This new build system used XML-based project files in a preview of sorts to the XAML to come. Which is, of course, what they moved onto next.

“Jim talked about that great declarative programming language, that higher level of abstraction over vanilla C#,” Anderson said. “What we’d like to do is take that C# file (created for their first application) and convert it into XAML.” Box created a new XAML file in Emacs as he continued. “In XAML, the syntax is relatively straightforward.” They then explained and demonstrated how two source files—one XAML, one C#, in this case—would work together, each partially defining the window (class) used by their application. We’ll examine what this looks like in code soon, but for now, it’s just important to understand what an advance this was over previous Microsoft developer frameworks. Microsoft was making traditional software code and markup equals in WinFX.

The resulting app, of course, was identical. But that was the point. And in subsequent demos, Box and Anderson added controls to the application in XAML, event handlers in C#, and then started really pushing the Avalon composition engine by rotating these controls and then displaying a video over the background of the application window while changing its opacity to be more translucent. Everything worked, and the controls and background video would warp as required as the window was resized.

Allchin returned to the stage to discuss storage, explaining that data was, at that time, trapped within individual applications. And from a UI perspective, the shell was limited to folder hierarchy views only. To address these limitations, Longhorn would provide a new feature called WinFS that would “schema-tize” the data on PCs, providing a great “store”—that is, a data store, not an app store—that was extensible via XML and could provide logical views of related data.

Box and Anderson were on hand again for another coding demo, but this time they asked Allchin if he wouldn’t mind being the “code monkey” and typing the code for them. Allchin obliged, using his favorite text editor, Vi, instead of Emacs. And this time, they created a more technically advanced application using both XAML and C# that interacted with contacts on the PC and provided search functionality.

After that, Allchin turned to communications, which answered the limitations of traditional web services and were handled by a new WinFX technology called Indigo. Indigo would extend web services with transaction capabilities like those found in Microsoft Message Queuing and COM+, and it would greatly simplify how developers would create those services.

For this demo, Box and Anderson adapted their application to interact with web services to update a live website.

By this point, Allchin’s talk had stretched to almost 90 minutes, so he asked the audience whether they needed a break. After a resounding no, he moved from demo to demo, showing off previews of Longhorn applications from partners like Adobe, Merck, and Amazon.com, each of which had been given early access to the technologies and had already turned in impressive work.

Longhorn, Allchin said, was truly a milestone event for Microsoft and the industry, one that would in many ways make up for Microsoft’s slow embrace of the Internet. Early adopters would receive a disproportionate share of the rewards, he said. But there was a long way to go, too: Win32 apps would, of course, run fine on Longhorn, but those that wanted to fully exploit Longhorn would need to move to managed code. Those writing a new application “in the Longhorn timeframe”—as always, a moving target—were advised to adopt WinFX. “That’s the path that we’re on,” he said.

From a schedule perspective, things were moving slowly. Microsoft would deliver Windows XP Media Center Edition 2004 and the Longhorn Developer Preview that quarter (or that day, in the latter case). In the first half of 2004, it would ship Windows XP Service Pack 2 (SP2) and Windows Tablet PC Edition “Lonestar.” And then Longhorn Beta 1 and Windows XP 64-Bit Edition for AMD were due in the second half of 2004.

“Longhorn Beta 1 is where we will take it to the next level,” Allchin said. “We will be going bigger then, but we aren’t making any other commitments about when we’re going to be done with this product. We’re going to focus on getting to beta, and then you’ll have a pretty good idea, with the bits, about where we’re at. We still have a long way to go.”

He had no idea.

But before we can get to all that, before we can even move forward to 2004, we have a lot of ground to cover, from the reality of what Microsoft delivered to developers at PDC 2003 to what it looks like to try and revive that Avalon code that Box and Anderson wrote live on stage. So we’ll examine those topics next.