Understanding WinFX in Longhornby 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.
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. 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. Windows development in Longhorn.
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. 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.
The Primary Application Models describe the type of applications you can build, which include:
As shown in Figure 4, the Client Applications model contains two main namespaces,
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
Figure 4. Namespaces for client applications.
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. Namespace for web applications and web services.
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. Namespaces for WinFS and SQL Server 2005.
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. Namespaces for mobile applications.
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. Namespaces for console and Windows Services.
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
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
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 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
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.
System.Collaboration namespace is used for building collaborative applications in Longhorn.
System.MessageBus provides functionality for Indigo. Indigo is the technology for building Service Oriented Applications (SOA).
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. Namespaces for Base and Application Services group.
Figure 13. Namespaces for Security group.
Figure 14. Namespaces for Configuration group.
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) http://weimenglee.blogspot.com is a technologist and founder of Developer Learning Solutions http://www.developerlearningsolutions.com, a technology company specializing in hands-on training on the latest Microsoft technologies.
Return to WindowsDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.