The imminent arrival of Windows Vista is a mixed blessing for developers. The good bit is lots of new features to play with, along with better security and an updated user interface. The downside is compatibility problems, and with the challenge of meeting expectations for well-behaved, good-looking Vista applications. There is going to be some pain.
Tripping up over UAC
At a developer-focused press briefing last week, Microsoft assured us that Vista is the biggest release of Windows ever. Perhaps it is; but the most basic question is this: will your existing applications run on Vista
They may do; but if they trip up, it will most likely be over UAC or User Account Control, Microsoft's attempt to bring Unix-like user security into Windows. There is a fair amount of confusion over UAC, which is mainly famous for perplexing the user with numerous permission prompts. These have been tamed in the latest Vista Release Candidate, but the fundamentals of UAC remain.
By default all users run without administrator rights, even administrators. Applications that require additional permissions must be started as an elevated process, hence the prompts. But how will Windows know what permissions your application requires? The answer: only by reading a manifest resource embedded in the executable.
Pre-Vista applications will not have one, so they might crash or behave strangely. The strange behaviour is because of a UAC feature called virtualization. The idea is to accommodate legacy applications that write to protected locations such as Program Files, or registry keys in HKEY_LOCAL_MACHINE.
This is so common that Microsoft devised a mechanism that allows these applications to work. When they write to the protected location, Windows redirects the write operation to a user-specific location. The application thinks it is writing to Program Files, but in reality a file gets written to a second Program Files directory in the user's Virtual Store. In some cases this works fine, but it is far from perfect. Data which the application thinks is globally accessible silently becomes private to the user, and near-invisible to other applications unless they also have virtualization enabled; and typically only legacy applications will use virtualization.
You are also likely to get unexpected behaviour. Imagine that your application modifies a file that already exists in Program Files. It will succeed, but in reality Windows will make a copy and put it in the Virtual Store. Now there are two different versions of that file. Some applications will see one, and some the other. Next, imagine that the application tries to delete the file. The delete appears to succeed, yet the file still exists in Program Files and remains visible to the application. If it retries the delete, an access denied exception is thrown. This is going to cause some perplexing bugs. Virtualization is one feature of UAC that administrators may want to disable.
Programming the new API
Vista introduces a hugely expanded Windows API, some of which is also available as an add-on for Windows XP. These XP-compatible elements will be initially more interesting to developers, and include Internet Explorer 7, the XML-based GUI called XAML, the distributed computing libraries called Windows Communication Foundation, the Windows Workflow Foundation, and the XML Paper Specification. Parts of IE 7 are relevant even to FireFox diehards, particularly the RSS Platform, a centralized store for RSS feeds.
Many other parts of the new API are exclusive to Vista, including the shell and desktop APIs to support translucent glass effects, live thumbnails that show your running application in miniature, and new task dialogs that include features such as progress bars, hyperlinks and expandable text. The idea of task dialogs is to enable richer dialogs and message boxes without forcing developers to built custom forms. These are unmanaged, C++ APIs, and to use them in .NET applications you need to use Platform Invoke, which lets you call native DLLs from .NET code.
If you want your application to look like a true Vista citizen, some conditional code to call these APIs when running on Vista is the way to do it. Another handy newcomer is called Application Recovery. The idea is to enable your application to crash gracefully, saving critical data as it fails, and firing up again automatically. Apparently the feature was designed for Windows Explorer in XP, for which it works some of the time, but has now been opened up for any application. While on the subject of crashing applications, it is worth mentioning that any developer can register with Microsoft to get access to crash reports uploaded by users for their application, for the cost of a digital certificate.
A two-tier API?
The extent of Microsoft's commitment to .NET has often been debated. At one extreme, .NET managed code is presented as the future Windows API. In the other corner are the sceptics who observe that most of Vista and Office remains native code. If .NET is really the future of Windows, it is disappointing to discover that Microsoft has not yet wrapped some key Vista features in official .NET libraries.
On the other hand, the Windows Presentation Foundation, the new declarative programming model for Windows, is a .NET API. In truth these two streams will continue for the foreseeable future. Both COM and native code remain in heavy use at Microsoft. Nevertheless, for enterprise developers who want to keep pace with Microsoft’s platform, .NET is the only sane choice, supplemented by native code where necessary. Essential platform technologies like Windows Communication Foundation depend on it.
What you need to know about Vista
Vista enthusiasts have plenty to explore; but what is the minimum that hard-pressed developers and admins need to know? The big one here is UAC, and the best single source of information is the white paper aimed at developers, which you can find here:
In particular, everyone needs to understand virtualisation, which is enabled by default but can be disabled through security policy. There are going to be hassles for any application that does not follow best practices, and developers will be hastening to fix any features that require local admin rights, signing their applications, and adding UAC manifests. It will be painful, but this is excellent news for Windows users and long overdue. ®
Vista developer center: http://msdn.microsoft.com/windowsvista/ “Certified for Windows Vista” requirements: http://microsoft.mrmpslc.com/VistaPlatformAdoption/Overview/CertifiedFor.aspx
Vista RC1 and SDK download links: http://msdn.microsoft.com/windowsvista/downloads/products/getthebeta/default.aspx
Kenny Kerr on Windows Vista for developers: http://weblogs.asp.net/kennykerr/archive/2006/07/12/Windows-Vista-for-Developers-_1320_-A-New-Series.aspx
Official site for info on what works in Vista and what does not. http://devreadiness.org/default.aspx