Understanding WinFX in Longhorn

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. 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.

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).