All about Longhorn

COMMENTARY--I had this crazy idea that I might write somethingabout the Microsoft Professional Developer’sConference (PDC) while the PDC was actually going on. However, between 9-hour jetlag, the all-day trainingsessions, the Irish contingent who ensured that Inever got to bed before 2 a.m. each night, the mysteriousblue liquid that turned a bunch of jetlagged geeksinto disco-dancing, cigar-chomping, shop-talking(heck, we’re still geeks) party animals, and otherevents I’ll leave to your imagination, I’m lucky I’mnot dead.

The PDC is a bit like sticking your brainin a taffy pull, both in terms of knowledge absorbedand the unnatural things you do to it. I’ll leavemeeting deadlines to people who actually get paid towrite this stuff.

A PDC is where Microsoft tends to announce thetechnology that will shape development within thecompany for the near to medium-term future. In 2000,the PDC was all about .NET, at the time a productabout as far from release as Longhorn, the next majorversion of Windows and the subject of this year’s PDC,is from its shipping date.

Longhorn beta 1 is slated to appear in summer of 2004,which means a release version won’t see the light ofday until at least early to mid-2005. Releasing thecode early, however, is particularly important for aproduct as ambitious as Longhorn. Not only is it amassive upgrade on core Windows technologies, such asuser interface rendering and access to data on a filesystem, but it is the culmination of the .NETintegration I’ve discussed in past articles.

In short, Longhorn is the .NET version of Windowswhich finalizes the replacement of the WIN32 API witha managed system, as well as a massive rethink as tothe way developers write applications for Windows andconsumers interact with their computers.

.NET, .NET and more .NET
A year ago, I wrote a three part series (part1, part2 and part3) where I argued that one of the reasons .NETwould conquer the world was that Microsoft wouldconvert its entire product library into .NETapplications. Well, based on the PDC roadmap, itturns out I was right, so ha, ha, ha, ha.(Pay no attention to that, it’s my jetlagged alter-egotalking.)

Longhorn will be the first operating system where ALL functionality is designed to be accessed through managed code. WIN32’s reign as the Windows API has ended, replaced by managed .NET APIs.

Such a move is unique in the industry. No one,including Sun Microsystems, has made Java THE API for programming a particular OS, much less declared that, going forward, all new features would be offered through Java. Microsoft’s decision to do that with .NET is an important advance, as it FORCES developers to write more secure code, simply because they can’t make some of the coding errors (such as bufferoverruns) that form the lion’s share of securityflaws.

WIN32 will still exist for backwards compatibility, ofcourse, and native access APIs will exist for those applications which need it (though I suspect that many of them will call the managed APIs through COM Interop). However, Microsoft intends to ensure that all Longhorn functionality is accessible from a 100% managed program.

A side benefit of the transition to .NET is that ithas given Microsoft an opportunity to revisit allaspects of the Windows API. The new "refactored"Windows API is more internally consistent than WIN32,an API that still bore the legacy of design decisions10 to 15 years out of date, and felt strongly like anAPI built by many different groups within Microsoft(which it was). The new, cleaner Longhorn APIsimplifies development considerably, and makes theplatform much more approachable to new and existingWindows developers.

Returning to the point I made at the start of thissection, where Longhorn leads, the rest of Microsoft’s application library will follow. If the Longhorn API is .NET, then it doesn’t take a rocket scientist to figure out that a sizable percentage of Microsoft’s applications released in Longhorn timeframes will largely be built with .NET. That’s a large amount of code transitioned to a particular managed runtime environment, and will pull even more developers down the .NET path (that is, those not already pulled by the higher rates offered to .NET programmers).

The New Graphical Interface: Avalon
I’ve noticed before that it is much easier to createreasonably complex user interfaces in HTML than inWIN32. For instance, it’s far easier to write a"skinnable" web site than it is to write a "skinnable"WIN32 application. Granted, you could do practicallyanything you wanted in WIN32, but if you wanted toescape the look and feel imposed by WIN32 controls,you had to perform a bunch of programming gymnastics.

Avalon is a complete upgrade to the process of writingWindows applications. In a way, Avalon turns Windows development into a more advanced and feature-rich version of web-style development. This constitutes more than just a conceptual similarity. One of the means by which Longhorn applications can be consumed is by accessing them from a web server using a browser (obviously, Internet Explorer), causing them to run within a "sandbox" managed by the .NET runtime. These downloadable applications act like more functional web pages, as they have access to the full set of rich user interface controls offered as part of the Longhorn operating system. Longhorn also makes it easy to integrate common web-paradigm concepts into desktop applications, such as page forward / page back logic, and "page history" functionality.

Windows applications still follow the same model seenin .NET WinForms and even Java’s JFC, wherein controlsare constructed within a class and laid out on screeneither manually or through some programmatic layout functionality. However, the goal of Avalon is to make it possible for many user interfaces, even complex ones with a custom look and feel for individual controls or dynamic background content, to be defined in eXtensible Application Markup Language (XAML). XAML (pronounced "zamel", and sounding like "camel")is an XML grammar oriented around painting userinterfaces and laying out controls that maps directlyto the Longhorn application object model. XAML isn’tjust an updated version of a Windows resource file,however. XAML enables the creation of complex userinterfaces. You can define the drawing of polygons onthe screen, and alter the rendering behavior of thosepolygons by applying transformations to them. You canspecify video that will be used as background to aparticular control, and alter the display of thatbackground video, again, using transformations. Youcan specify layout rules for controls within aparticular container. In short, XAML is a completeXML grammar for user interface rendering that goes farbeyond anything seen in old-fashioned WIN32 resourcefiles.

The XAML approach to user interfaces creates a morecomplete separation of look and feel from code thatmakes the user interface functional (business logic,etc.) than was possible with WIN32. User interfacesdefined in XAML can be generated using design tools,such as a future version of Adobe AfterEffects demoedat the opening keynote. The output of these tools canbe passed to programmers responsible for hooking intoevents generated by the Avalon object model in orderto make the user interface dynamic.

The traditional model seen in WinForms and JFC, though necessary, places too much responsibility for layout in the hands of the programmer. With a cleaner separation between layout and code, a clearer division of labor arises which leverages what designers and developers individually do best.

Avalon works best with fast graphics accelerators, asit takes hardware acceleration deep into the heart ofthe Windows rendering system (better leveraging of DirectX/Direct3D). With GDI, only text rendering benefited from hardware acceleration, according to one of the session presenters. With Avalon, the whole windowing system will rely heavily on hardware acceleration to enable rapid construction of dynamically-generated and complex user interfaces. Certain amounts of performance tuning between now andthe final release will certainly ameliorate things forthose with older graphics cards (in such cases, theCPU will have to work harder), but people withhigh-end video cards will have the best experience ofLonghorn.

The Object File System: WinFS
The notion of files and folders as a manner in whichdata is logically organized on a disk is an oldconcept in computing. Data blobs constitute what are understood as "files," and these files are categorized into hierarchical folders. This model works well when you don’t have too much data on your system. As hard drives and the amount of data we store on them grow inexorably larger, however, the model shows signs of strain. I am something of a data packrat, and quite literally, there are files squirreled away somewhere on my hard drive that I have not seen in years simply because I have forgotten they exist.

A better approach comes from an analysis of how userstend to access their file system. Usually, users huntfor specific categories of data. For instance, youlook for all the audio media on your system,irrespective of folder or specific audio type, becauseyou want to play them. You might look for alldocuments, regardless of type (Word, WordPerfect,etc.), that are "word processing" files. The foldermodel can be a hindrance in this case, unless you makethe effort to properly categorize folders to ensurethat all your media files and documents are in oneplace.

Furthermore, what if you wanted to look for all files associated with a particular court case regardless of folder location OR media type, or wanted to locate all the files (jpg images, text files, movie files, audiofiles) associated with a particular music group? Doing this is much harder in the file/folder model,and the "contains text" search that currently existsfor folder searches is only an inexact approximationof what we are trying to do.

Enter the notion of schema-based data objects. Aprogrammer defines a schema for the data he or she isgoing to store which details what kind of propertiesand operations it will support. He or she thenregisters this schema with the system, which enablesthe creation of objects of that type in WinFS. Schemas for audio files, word processing documents,and others will ship as a standard part of theLonghorn WinFS system, which programmers can reuse intheir own applications.

Any kind of value can be associated with a schemaobject, including objects which adhere to anotherschema, leading to object relationships. Forinstance, a custom object type of "PDCAttendee" can becreated and registered with the system, enabling alist of PDCAttendee objects to be created on disk. This list can be retrieved and displayed, and thoseindividual PDCAttendees can be associated with other schema-based objects on the system, enabling searches that retrieve objects based on their association with a particular PDC Attendee.

This search capability is important given thereplacement of the notion of a "folder" into whichdata is categorized with the WinFS concept of "views." Views are displays of data retrieved from the WinFSfile system based on the result of a particularsearch. Data relationships can be used in searches,which are composed using a new, object-based, SQL-style search language for accessing these objects(users likely won’t see this language, but developerscertainly will). These views are updated as the data underlying the elements gets updated. Standards sets of views exist on the system, but the ability exists for custom views based on custom searches to be created by end users.

One of the advantages of the WinFS approach to datamanagement is that data formats are completelytransparent. A schema defines the characteristics ofthe data, making it available to anything on thesystem that wants to talk to it. If other emailclient providers such as Eudora decide to adhere tothe "Mail" standard schema, that data will beaccessible from Outlook Express, and vice versa.

In short, WinFS replaces the notion of opaque datablobs that contain an unknown "something" with aricher model wherein data conforms to a particularschema type, enabling easier location and moretransparency in data formats.

The Longhorn Communications Stack: Indigo
The PDC broke the essential advances of the LonghornOS into UI (Avalon), Data (WinFS), and Communications(Indigo) in reflection of the importance that eachrepresents to Longhorn. Indigo’s centrality of placeshows the importance Microsoft ascribes to network communications.

Indigo, however, does not involve as great a leapphilosophically as Avalon and WinFS. Microsoft’sIndigo communications stack will include libraries forbuilding Peer to Peer networks and constructing secureand encrypted web services on both server AND clientsystems, among other things. Such technology isalready common, both upon Windows and other platforms.

Indigo, however, is a refactoring of Windowscommunication technology as it currently exists,designed to create a system that is less fragmented,more extensible and more standardized from an APIstandpoint. This is in keeping with the greaterflexibility and consistency already present intechnologies such as .NET Remoting or in ASP.NET’s webservices architecture.

Indigo also represents a move away from the notion ofremotable objects. In a presentation of the designphilosophy followed by the Indigo development team(PDC attendees might remember it as the one where Mr.Box wrapped his legs around a hapless volunteer fromthe audience), Don Box declared that web services area better manner in which to exchange informationbetween machines than remotable objects. Forcingprogrammers to think of inter-machine communicationsas truly a call to a SEPARATE machine (and not just toa local object in your namespace that looks, for allintents and purposes, like a local object) preventsbad inter-machine communication design decisions.

For that reason, Indigo will operate along the webservice model seen in ASP.NET .asmx files (which areASP.NET’s web service definition files), and not theobject remoting model seen in DCOM, CORBA or even .NET Remoting.

Why is Longhorn code being released soearly?
There are a number of features I don’t have time todeal with here, such as Microsoft’s new XML-basedbuild tool (msbuild) that will be common across alltheir SDKs and integrated into Longhorn, the new NGSCB/ DRM functionality that will make Longhorn a moresecure platform and open up new revenue-generation possibilities for small ISVs, the new controls that will ship with Longhorn, and a host of details relating to Avalon, WinFS and Indigo.

Likewise, there are a number of questions I have yetto answer, such as how they are going to handle interoperability between other systems (Pocket PC devices, or older versions of Windows) and WinFS, or how WinFS objects can be copied to another machine (remember, those schema objects have linkages to other pieces of data on the source system).

This explains, however, why Microsoft chose to releaseLonghorn so early. The large feature set and the new approaches to application development offered by Longhorn will take some time to digest. Every PDC attendee walked away with a working copy of Longhorn, even if pre-alpha, allowing them to start writing experimental applications today (and, I might add, negating claims of the vaporware status of Longhorn). This allows information about Longhorn to flow out ofMicrosoft into the developers that will write productsfor it, as well as allow developers to influencethe final features that will exist in the releasedproduct.

Longhorn at this point is not a product that is set instone. Developers can influence the final shape ofLonghorn, a fact hammered home multiple times over thecourse of the PDC. This, to my mind, is the numberone reason to release code so early. Open sourceprogrammers have access to the latest build of Linux. Programmers of proprietary operating systems haveaccess to early release versions of next generationoperating systems. The two are flip sides of the samecoin. Which you prefer depends on your programmingphilosophy.

Parting Thoughts
In closing, I offer a warning to fans of otheroperating systems. If history is any guide, mucheffort will be expended trying to downplay theimportance of Longhorn, if not suggest that no onewill, in fact, buy the product. Besides the fact thathistory seems to counter such naysayers (.NET ispopular, as is PocketPC, XBox, SQL Server, Windows XPand the various components of Office), it provides arationale for a lot of people to do nothing torespond.

Consumers don’t tend to be privy to the ideologicalwarfare that shapes so much of the dialogue betweenprogrammers in the various programming domains, andare thus unlikely to be swayed by such arguments. Mark my words, Longhorn will be immensely popular onceit is released, because Longhorn is revolutionarytechnology that makes desktop computing better.

Proper competition demands that you reject thecomforting fantasy that Microsoft never does anythingright, and deal with the reality of what theirtechnology offers consumers. So, as a final point (inthe "sharp stick in the backside" sense), it’s time tostart learning from Longhorn so as to plan an adequateresponse to it.

biography
John Carroll is a software engineer now living in Geneva, Switzerland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.