Windows DevCenter    
 Published on Windows DevCenter (
 See this if you're having trouble printing code examples

Windows XP Unwired

Understanding WinFX in Longhorn

by Wei-Meng Lee, author of Windows XP Unwired

In this continuing series of Longhorn articles, I will talk about the APIs that developers will use to write the next generation of Windows applications.

By now you should have heard of several new acronyms and names that are usually mentioned whenever someone talks about Longhorn. These include WinFX (which is the topic of this article), WinFS, Indigo, and Avalon. In this article I will focus on WinFX and discuss briefly the rest of the technologies. I will give you a high-level introduction to WinFX and what it means to developers.

An Evolution of APIs

So what is WinFX? Put simply, WinFX is the set of APIs that you will use to write Windows applications in Longhorn. Windows programmers today use Win32; WinFX is the next generation of APIs for Windows. The "Win" in WinFX stands for Windows and the "FX" stands for .NET Framework Extension (think of WinFX as an extension of the .NET Framework in Longhorn).

WinFX is not a revolutionary set of APIs for programming Windows. Rather, it is an evolution. If you look back at the early days of Windows, we first had Win16 APIs, followed by Win32. When Windows 95 was launched in 1995, 32-bit applications were the de facto standard, even though DOS and 16-bit applications were still supported. Going forward, Win32 applications will still be supported, but WinFX is the way to go in Longhorn.

Today, programmers generally have two choices when they write Windows applications, Win32 or the .NET Framework.

In Longhorn, the Win32 APIs will still be supported, but the WinFX will contain the primary APIs to use for writing Windows applications. While Win32 APIs are C-styled, WinFX is designed to be used natively by .NET applications (which means that your Longhorn applications are now managed).

What does it mean to a .NET developer? It simply means that your .NET applications built today will be able to run without modifications in Longhorn. Of course, if you want to take advantage of the new features in Longhorn, you need to use the newer system namespaces in WinFX, which I will describe in this article.

Figure 1 shows how a developer can write a Windows application today. If he uses .NET, then most of the functionality can be found from the .NET Class Libraries. If there is a need, he can access the Win32 APIs through Platform Invoke. A traditional Windows developer uses C/C++ and accesses the Win32 APIs directly (the application is unmanaged). Of course, if there is a need, you can still access the .NET Class Libraries, but this is not common.

Figure 1
Figure 1. Current Windows development.

Figure 2 shows the development in Longhorn -- you can still write unmanaged Windows applications since Win32 is still supported. But the recommended way would be to write a managed application using WinFX. There are two types of managed applications that a developer can write in Longhorn -- Longhorn-specific Windows applications, or generic Windows applications that can run on all Windows platforms. If you want to write Longhorn-specific applications, use the extended APIs in WinFX. If you want to write a generic Windows application, use the classes in the .NET Framework (part of WinFX).

Figure 2
Figure 2. Windows development in Longhorn.

Understanding Managed Code

You've heard the term "Managed Code" many times. So what does it mean? Basically it means that a managed code is managed by a runtime environment (CLR in the case of .NET). And this runtime environment ensures that applications behave themselves. For example, in a managed code, the garbage collector will automatically manage the memory of a .NET application. It will automatically reclaim memory when an object is de-referenced or goes out of scope.

Contrast this to Win32 APIs, which is unmanaged. Unmanaged code means that the programmer has to explicitly take care of memory de-allocation, or else when the program exits it will result in memory leaks.

WinFX is a new .NET-based API that provides managed access to the three Longhorn pillars -- Presentation (Avalon), Data (WinFS), and Communication (Indigo). The more than 70,000 individual APIs in Win32 will be now be represented in about 529 .NET namespaces (at last count).

To give yourself a better idea of the functionality of WinFX, you can download a PDF copy of the WinFX namespaces chart given out at PDC 2003 (see Figure 3).

Figure 3
Figure 3. The WinFX namespaces chart.

The WinFX is divided into three layers each containing sub units:

In the following section, I will give you a brief introduction to the various layers and the functionalities available at each layer/unit.

Primary Application Models

The Primary Application Models describe the type of applications you can build, which include:

Client Applications

As shown in Figure 4, the Client Applications model contains two main namespaces, System.Windows and System.Windows.Forms. If you are a .NET developer, you should be familiar with the System.Windows.Forms namespace, which allows you to write generic Windows applications using Windows Forms. In Longhorn, you can leverage on the new presentation subsystem known as Avalon, through the System.Windows namespace.

Figure 4
Figure 4. Namespaces for client applications.

Web Applications and Web Services

For ASP.NET web applications and web services, you use the System.Web namespace (see Figure 5). In Longhorn, a new, web-services technology known as Indigo is available. Both types of applications share the same namespace.

Figure 5
Figure 5. Namespace for web applications and web services.

Data Systems

The next-generation Windows File System is known as WinFS and you can programmatically access the file system through the System.Storage namespace (see Figure 6). For database access, you can use the System.Data.SqlServer namespace to connect to the next release of SQL Server, code-named Yukon. (Yukon has since been renamed to SQL Server 2005 to better reflect its release date).

Figure 6
Figure 6. Namespaces for WinFS and SQL Server 2005.

Mobile Applications

For mobile applications, you can use the System.Windows.Forms namespace (.NET Compact Framework) for devices like Pocket PC (see Figure 7). You can also use the System.Windows namespace for special mobile PCs (such as the Tablet PC).

Figure 7
Figure 7. Namespaces for mobile applications.

Command Line and Windows Services

If you are writing console applications, you can use the System.Console namespace. For Windows Services (previously known as NT Services), you use the System.ServiceProcess namespace (see Figure 8).

Figure 8
Figure 8. Namespaces for console and Windows Services.

Three Key Pillars of Longhorn: Presentation, Data, and Communication

Longhorn is based on three key pillars -- Presentation, Data, and Communication. The following describes the responsibility of each pillar.


The Presentation pillar represents the way your application interacts with the user (see Figure 9). As mentioned, for Longhorn Avalon applications you should use the System.Windows namespace.

If you are developing applications for the various Windows versions, the Windows Form System.Windows.Forms is still available in WinFX.

For web applications, use the System.Web.UI namespace.

Figure 9
Figure 9. Namespaces for the Presentation pillar.


The Data pillar represents the different ways in which you can access data programmatically (see Figure 10). The familiar ADO.NET stack is still preserved in WinFX and is exposed via the System.Data namespace. A new namespace is added in ADO.NET in WinFX, ObjectSpaces. ObjectSpaces gives an objective view of data in your database server, allowing you to access data through objects.

For WinFS (a modernized version of the current Windows File System) access, use the System.Storage namespace. Notice that there is the System.Web namespace in this pillar, which is used for such features as ASP.NET personalization, caching, and session-state management.

For manipulation of XML documents and data, use the System.XML namespace.

Figure 10
Figure 10. Namespaces for the Data pillar.


The Communication pillar handles the details of communicating with the outside world (see Figure 11). For example, you use the System.Web.Services namespace for consuming and publishing web services. And you use the System.Net namespace for such tasks as network communications and sockets programming.

The System.Collaboration namespace is used for building collaborative applications in Longhorn.

The System.MessageBus provides functionality for Indigo. Indigo is the technology for building Service Oriented Applications (SOA).

Figure 11
Figure 11. Namespaces for the Communication pillar.


Beneath all applications are the fundamental namespaces that support basic functionalities such as string manipulation, security, globalization, etc. The Fundamentals layer is divided into four different groups: Base and Application Services (See Figure 12), Security (see Figure 13), Configuration (See Figure 14), and Deployment/Management (see Figure 15).

Figure 12
Figure 12. Namespaces for Base and Application Services group.

Figure 13
Figure 13. Namespaces for Security group.

Figure 14
Figure 14. Namespaces for Configuration group.

Figure 15
Figure 15. Namespaces for Deployment/Management group.


I hope this article has given you a better idea of what WinFX involves. In a nutshell, it is important to realize that the way to move forward is to get yourself acquainted with the .NET Framework. If you have not started on .NET development, now is the time to do so.

Wei-Meng Lee (Microsoft MVP) is a technologist and founder of Developer Learning Solutions, a technology company specializing in hands-on training on the latest Microsoft technologies.

Return to

Copyright © 2009 O'Reilly Media, Inc.