• Illustration: WinFX Namespaces Organize APIs

The next version of Windows, code-named Longhorn, will offer a new set of APIs called WinFX. Designed to replace the aging Win32 APIs that have been in use since the introduction of Windows NT in 1992, WinFX is built around the .NET Framework, meaning that developers will access the new features of Longhorn, such as the new graphics engine and Web services systems, primarily through the Framework and managed code. WinFX could make Windows simpler and more relevant to developers, but tools that help make the leap to WinFX could be slow to arrive.

Why Replace Win32?

Although it has been extended many times, Win32 is essentially the same API set that was introduced with Windows NT. In fact, it is largely the same API set that was introduced with Windows in 1985, although it wasn’t called Win32 until Microsoft moved to 32-bit Windows and extended the APIs to follow suit. With WinFX, Microsoft hopes to ease several problems that have grown steadily worse, such as the following:

Close the "tools gap." While Win32 has remained largely the same, the world around it has changed dramatically. Win32 is not directly relevant to a large number of developers who rely on tools such as Visual Basic to provide them with APIs for building applications. This has sometimes lead to a "tools gap" in which Microsoft adds APIs to the OS but many developers, particularly corporate IT developers who rely heavily on tools such as Visual Basic, are unable to access the new APIs until their preferred developer tools incorporate them. Microsoft hopes that by making an OS API that is directly usable by both commercial ISVs and corporate IT developers, it will reduce the time between development of a new feature and its actual use by developers.

Difficult to learn. Because they are based on the C programming language, the Win32 APIs are difficult to organize in any meaningful way (except perhaps to sort them alphabetically). This has made learning Win32 a daunting task for new programmers, and it has only gotten worse as the APIs have grown. The relatively small set of APIs offered by Windows 1.0 might have been manageable for developers, but by some accounts, Windows now offers over 15,000 APIs—a number that is simply too large and cumbersome to be managed effectively as a single list. Because the .NET Framework organizes APIs into logical namespaces, it will make it easier for developers to easily locate specific WinFX APIs. (For an illustration of this organization, see "WinFX Namespaces Organize APIs".)

Easy to make errors. Programming in C can be an error-prone process because developers must manage almost every aspect of their program, including how it allocates and releases memory. By moving to the .NET Framework and managed code, Microsoft hopes to relieve developers of such housekeeping tasks as memory management to make them more productive and reduce errors, while still providing access to all of the OS features they are accustomed to.

.NET Framework Moves Center Stage

Late in its development cycle, Microsoft started to promote Windows Server 2003 as the first version of Windows to integrate the .NET Framework, which shipped with and installed alongside the OS so users and developers did not have to install it separately, as they did with Windows 2000 and XP, to run managed code applications. However, in terms of OS functionality, the .NET Framework running on Windows Server 2003 is not dramatically different from the Framework running on Windows 2000 Server.

With Longhorn and WinFX, the relationship between the .NET Framework and Windows changes. Underlying OS features (such as the Avalon graphics and user interface subsystem and the WinFS file system) are at least partially implemented as managed code, and the .NET Framework, along with programming languages such as C# and VB.NET, is the primary method developers will use to access them. Although developers will still be able to access these features by writing native code, written in languages like C and C++, such code will travel through an "interop" layer that translates between the native code application and the managed code API, and that will add overhead.

Microsoft has said that WinFX will be an easy migration for developers already using the .NET Framework. The new Avalon graphics APIs, for example, are designed to resemble as closely as possible the Windows Forms APIs of the .NET Framework. Similarly, the base class libraries that are part of the .NET Framework are expected to be largely unchanged in the move to WinFX.

Not Just for IT Anymore

The .NET Framework (and most notably ASP.NET) has been more popular among corporate IT developers than commercial ISVs. This is partly because the Framework hasn’t yet achieved widespread distribution, but it's also because ISVs haven’t yet seen a compelling reason to switch. Commercial software developers already have teams of Win32 experts, so the learning curve for Win32 hasn’t been a barrier, and the productivity benefits of managed code are often outweighed by better performance when using the Win32 APIs directly.

With WinFX, Microsoft hopes to change this habit by giving developers more and better access to OS features via managed code than they have through native code.

One significant roadblock, however, is the lack of backward compatibility with previous OSs. WinFX will only be available on Longhorn, but large ISVs have large installed bases of users and are unlikely to start writing major applications that are compatible with only a small portion of total Windows users . These ISVs will face the choice of ignoring WinFX or maintaining two separate code bases, one for Longhorn and one for older versions of Windows.

Tools Still Matter

Although WinFX is designed to remove the "tools gap" that has made the Win32 APIs somewhat irrelevant to corporate IT developers, tools still matter. Visual Basic offers more than a simplified API for developers: it also lets them graphically create user interfaces, construct database queries, and debug applications.

Microsoft says a future Longhorn-oriented release of Visual Studio .NET (VS.NET), code-named Orcas, will incorporate the WinFX APIs.

But at the recent Professional Developers Conference, the entire focus for Microsoft’s developer tools division was on the more immediate release of SQL Server "Yukon" and the corresponding "Whidbey" release of VS.NET. With so much effort devoted to Yukon and Whidbey, Microsoft’s developer tools division may have little time to focus on Longhorn and the tools that developers will need to exploit its capabilities.

Resources

For an overview of Longhorn, see "Longhorn Preview Focus on Developers" in this issue of Update.

The Longhorn Developer Center at msdn.microsoft.com/longhorn includes sample code and information on WinFX.