Developers worldwide are eagerly awaiting the first public release of Longhorn’s Beta. Longhorn is signaling a drastic shift and realignment within the Windows world. With the launch of Win XP, we saw a minor shift in this alignment, where the desktop OS, hitherto harmless (in the Win 9x era), now suddenly became powerful and achieved workstation class. After Longhorn it would be sometime before another revolution comes by with the release of the server side codenamed Blackcomb, as late as 2010.

We have already talked about how the Longhorn OS itself looks and the concept of WinFS (Windows Future Storage) in previous issues. But what challenges does this OS, along with all its innovations and technologies, present to the developer? That is what we shall explore in this series.

New storage containers
In Win 98SE, Microsoft introduced the concept of performance monitoring and control classes with the WMI (Windows Management Instrumentation) classes. This allowed you to monitor and change some of the components in the system architecture. 

The year 2000 saw another radical concept called Active Directory. Daunting and difficult to comprehend and setup, it was supposed to contain all auxiliary information about your setup–software, hardware and users. You could also harness the Windows security model (via ACLs and NTFS) to restrict or delegate access to components stored in this directory. The Active Directory, compliant with LDAP, also allowed the publication of objects from other software. For example, Exchange Servers, SQL Servers, Printers, Scanners and Network shares could be published in the Directory. These features and more will be incorporated into WinFS. As we discussed in the earlier article on WinFS (September 2003), this new paradigm in how our information is stored, sorted and retrieved by the OS allows us both micro and macro control over the information itself. The underlying architecture, while stunningly similar to an SQL Server database and powered by a similar engine, allows us to store, query and manipulate information in a myriad ways. Therefore, it no longer matters where your information is stored; only that it is stored and WinFS knows about it. WinFS also no longer cares for file-extension names. True, it will continue to provide support to legacy files demanding it, for sometime to come. You will still see it recognize a .doc file as a word document. But this will soon become a thing of the past, where one type of information seamlessly flows into another.

For example, though I am typing this text into an MS Word document, on the layout team’s desk, it will flow into a DTP format and acquire graphics. A webpage designed in modern day software will contain static text, pictures, movies and sounds. It may even contain OLE, DirectX and other rich-media parts (like applets). It is not possible to store all of this in one type of file, without some form of information loss. Therefore, WinFS will recognize any form of information.
This makes enumeration of such information infinitely easier. With simple SQL style queries, you can quickly pull together information from a variety of sources and create a view of what you are looking for. To the programmer, this is infinitely easier than knowing where what is. You no longer need to hard-code paths or call complicated API to figure out the Windows’ System folder. Just SQL for it and it’s there.

New .NET Frameworks conspiracy
For the first time, Windows will be truly .NET. Windows Server 2003 (although codenamed as Windows .NET Server) did not fulfill the dream. All it managed to do in the end was carry .NET Frameworks v.1.1 by default. Longhorn on the other hand is coded from the ground up in .NET. This .NET is named WinFX. This presents new goals to programming. There will no longer be poor codes and hacks. When we create a WinForms application in the current environment, we do:

Dim F As New Form()

This is nothing but a wrapper to the underlying Windows API function CreateWindowsEx() with some default parameters. Not anymore in Longhorn, because CreateWindowsEx is no longer there. Instead, a traditional non .NET application will have to have a wrapper to make CreateWindowsEx call New Form().

What conspiracy? Well, there is one. .NET developers would have come across terms like managed and unmanaged code plenty of times. With a move to Longhorn, an update to the Framework sees a cent-percent move to unmanaged programming model. Ostensibly, this is because unmanaged code is more powerful and more object-oriented. Therefore, this is the way to go. Thus, developers still using the current Frameworks model (v1.1) are being threatened with the nickname of managed code developers. Yes, it is set to become a dirty word.

Build, Collaborate and Enjoy
With the Indigo component in Longhorn providing seamless communications between applications and services, collaboration tools get a much-needed shot in the arm. Now, applications can transparently transfer alerts and information through various transport streams – Windows Alerts, Messenger, custom pager APIs – without needing complicated functions for each. This also enhances the increasingly distributed workplaces where timely communication between campuses is of utmost importance. 

Distributed and partially (or fully) disconnected applications like Web services become easier to write with WinFS offering synchronization services.

Application Sharing
Yes, for the first time ever in any OS, an application can actually share another application’s files without access or sharing violations. Application data and file-system is partitioned into silos that both protect as well as share information in them in a controlled manner. Does this ring the final death knell for COM and ActiveX applications?

Widget UI, XAML and Avalon
No doubt you have been dazzled by the vector-drawn screens created by Avalon published in PCQuest January 2004 (page 60) and on the Internet (www.winsupersite.com). But, this look and feel translates very easily to your applications as well. With Longhorn, you can use the built-in XAML (eXtensible Application Markup Language) to write your applications in a way that would look very similar to a combination of XML, HTML and CFML. Avalon does the final rendering.
On the lighter side, this will create more jobs in the software sector because companies who choose to move to Longhorn will now need graphics designers to work with the Avalon rendered XAML pages.

In the next part, we shall examine the intricacies of WinFX and how you should prepare your existing code for easy migration to WinFX.

You can visit the following URLs for more information: 

http://msdn.microsoft.com/longhorn 
http://www.asp.net/whidbey 

Sujay V Sarma,  Developer Support .NET, EMEA Group