If you are a developer, and have been for longer than six months, there is a good chance you have written an application or two before Microsoft's latest creation, Vista, came onto the scene. If you are a perfect developer, one who has never strayed from all the coding guidelines, has never taken a short-cut in the name-sake of time, and never goes against Microsoft's published standards, you are in luck. Because you have walked the high road, there should only be minor UI changes, if any, to make your application Vista compliant. Now, for those developers like myself, ones who have not memorized all the guidelines and standards published by Microsoft, you could be in a slightly different situation.
It should not be a surprise that Microsoft has changed a lot in this latest version of Windows. Advertised as the "Most Secure Windows Ever," you are safe in assuming that the security and access control model has changed quite a bit. This new model, called User Account Control or UAC for short, will most likely cause the most pain in your application upgrade. The UAC is a big enough topic within itself to write a couple articles on alone, so I will not cover it in-depth here. What I will cover is the impact it will have on your architecture and UI design. UAC enforces what Microsoft has called the Standard User account, formally known as or referred to as the Limited User Account. As previously stated, for those that have been following the Limited User Account guidelines, the impact of the UAC will be minor if at all. I strongly encourage you to read up on the UAC if you are feeling lost or have no idea what a Standard User account is. There is a good article on here on Microsoft TechNet. Keep in mind that, although slightly annoying, the UAC serves a purpose and a well-written application will have little or no issues because of it.
Besides the addition of the UAC, there are also several changes in access control, the .NET Frameworks, and program interoperability that you will need to be aware of when moving your application(s) to Vista. The following sections of this article will explore the common pitfalls of Vista development, some quick workarounds, and best practices. I will cover, in slightly more depth, the UAC, Virtualization, pre-installed .NET Frameworks, common program compatibility issues, and guidelines for UI/UX design.
Common Pitfalls and Virtualization Vista Style
With the introduction of the UAC, you have also been presented with the "Consent UI" dialog. This dialog box will be displayed each time an application tries to perform an action that requires administrative privileges. Once that process is complete, the privileges are lowered back to Standard User, once again prompting the user with a "Consent UI" dialog should they need to perform the action again. This repeated interruption is alone enough to cause users a headache and possibly reduce productivity. That is why running as a Standard User is such an emphasized part of the UAC guidelines. Applications that run under a Standard User will not have this annoyance issue. There will still be circumstances when an application needs administrative privileges to carry out certain processes, especially if the application is written for administrator use. In these cases, there are a few simple guidelines to follow to make the user experience as pleasant as possible.
UAC User Experience Guidelines
- Move all processes that require administrative privileges to the installation of the application. Because installations require administrative privileges regardless, the user will only be presented with one consent UI dialog.
- If your application requires administrative rights to perform certain actions, try to move these actions to a separate part of the application, a part that is not executed on startup of the application. This will prevent the user from getting a consent UI each and every time they start your application.
- If your application requires administrative rights to perform most if not all of its not common actions, include a manifest file with your application to request elevated privileges upon startup. Your user will only receive one consent UI dialog upon startup, but will receive it each time they start the application.
This can be done by specifying the requestedExecutionLevel. There are three levels you can specify and they are "asInvoker", "highestAvailable", and "requireAdministrator". Below is a snippet from a manifest file that requests administrative rights to run, causing a consent UI to be shown only once to the user at startup.
A good walkthrough in placing the manifest file into your application can be found here.
- Use the 'Shield UI' graphic on buttons and links that will require administrative privileges. By placing administrative actions behind buttons and links that have this graphic, your user can expect the consent UI dialog. The 'Shield UI' is consistently used throughout Vista to mark actions that require administrative privileges. Below is an example of the 'Shield UI' on a button.
Besides the UAC guidelines, there are now access control rules in place in Vista. I use the word "rules" specifically here because, unlike previous versions of Windows where Microsoft set guidelines, they have now enforced those guidelines by making them rules. The following is a short list of places that now require administrative rights to write to and are some common pitfalls for pre-Vista applications.
Access Control Changes
These locations now require administrative rights for write access.
- C:\ (root)
- C:\Program Files
- \Windows directory and all sub directories
- HKLM registry writes
The UAC guidelines are simple enough if you are building new or have a small to medium sized application to upgrade to Vista. The UAC guidelines could prove challenging and costly in larger, more complex applications, but the rules around access control will most likely cause the most headache. The good news is that Microsoft has planned for this problem by adding a feature to Vista called Virtualization.
Virtualization, in this case, is not the same as what you would normally think of when talking about VMware, Microsoft Virtual PC, or any of the other virtualization software out there. Virtualization in Vista deals with data redirection for legacy applications attempting to write to those locations mentioned above, which are now restricted for Standard Users. This data redirection coupled with what is called the "per-user store" makes up the meat of Virtualization in Vista. In simple terms, Virtualization will auto-magically redirect restricted system location writes to the user's per-user store. This prevents pesky "Access Denied" error messages from popping up on those legacy applications that failed to follow all the guidelines about proper file I/O. Because there is at least one 32-bit application out there that might write to the Program Files directory or HKLM, this feature of Vista comes in very handy. So where is the catch, you ask? There are a couple I see, and they are important ones to be aware of when deciding to lean on Virtualization or not.
Important items to keep in mind about Virtualization
- Vista is going to be the only version of Windows to include the feature. Microsoft has only included it in this version because of the mountain of 32-bit legacy applications out there that would otherwise be "broken." Now that the old guidelines are rules, it does not seem Microsoft will be giving out any more "Get out of jail free" cards.
- The per-user store is just that, a user specific location, not accessible to other Standard Users. This could be problematic on shared PCs. If one user of an application saves setting changes or saves a file that gets written by Virtualization to their per-user store, other users of the application will not have access to those changes or the saved file. This can be especially problematic in applications that utilize the Updater Application Block, or UAB, to update themselves. The updated files could be redirected to the per-user store and future users will run an un-updated version of the application. There are methods of automatic update that do work with Vista, but that is a topic outside the scope of this article.