Making a Pre-Vista Application Vista Compliant

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

1. 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.
2. 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.
3. 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.

   
   
   Click here for a larger image.

   A good walkthrough in placing the manifest file into your application can be found here.

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

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

Determining Where the Guidelines Turn Into "Gotchas"

You should now be armed with the "why" of the changes that are necessary when moving legacy applications to be Vista compatible. The tricky thing with legacy applications though is "where" and "how" you make the changes. I am going to leave the "how" up to you because development can take on an almost infinite set of paths. The "where," and by this I mean where in your code changes are needed, can be a bit like finding a needle in a haystack. Development teams dismantle and move on, documentation is lost (or never created), large applications tend to get complex, and technologies change. Shy of trying to resurrect the original development team, you could be up against quite a challenge finding all locations where changes are needed. This is where the Application Compatibility Toolkit (ACT) 5.0 comes in to save the day.

ACT 5.0 is Microsoft's toolkit for testing most aspects of your application from installation to process monitoring. The toolkit also includes tools to test future Vista updates as well as compatibility with the UAC and Internet Explorer 7. These tools and their capabilities will help you determine the "where." The toolkit as a whole is too complex and deep to cover in this article, but I recommend starting with this Microsoft TechNet site and demo (bottom of the page) if you want to learn more about the toolkit.

One tool I will recommend as a good starting point is the Standard User Analyzer. The SUA gives you options on how you want to launch your application and then monitors several key data points. It monitors access and write issues, UAC issues, and your application's use of Virtualization. As for the launch options, you have the ability to control Virtualization, elevated privileges, and run time command arguments.

Putting It All Together & Starting Down the Road to Vista Compliance

Each application is sure to present its own unique set of challenges and for that reason there is not a one approach answer. I will offer my suggestions and you can supplement them where needed by tools, specific knowledge, and personal experience. Keep in mind that size, complexity, and dependencies on third parties can greatly increase or decrease the challenge.

First, to get the obvious out of the way, install (or try to) the application on Vista. That sounds simple, but I often hear that developers spend hours analyzing their application to see what could go wrong before ever knowing whether anything will go wrong. You could be pleasantly surprised that, despite the horror stories you hear, your application runs fine as is. That same pleasantness could also be replaced by quick disappointment if you find Vista blocking your installation due to a "Known Compatibility Issue" (advance warning for those of us who have used MSDE).

From a tool standpoint, start with the Standard User Analyzer and work from there. Information gained from this tool can help you determine quite a bit about the type and magnitude of changes needed. After your incompatibility issues have been identified and organized, you can start the process of planning. Determining whether Virtualization will work for your application can save you costly redevelopment time, but you have to keep in mind that Microsoft does not plan to keep the feature in future versions of Windows. Also, determining how UAC-friendly you want to make your application will impact time and cost. Zero unexpected prompts are desired, so making use of the 'Shield UI' graphic or manifest changes are some quick hitting items to accomplish this.

Whether you are working on a small standalone legacy application or a complex multi-tiered monster, these several basic concepts should help you get jump started down the path of Vista compliance. Trying to cover all of Vista's new features and guidelines in a single article would be impossible, so this article's intent is only to help you down the start of the path. I strongly recommend following up in more detail on any of the topics, such as UAC and Virtualization, before undertaking your upgrade.

About the Author

Matt Goebel is a Solution Developer and Project Manager at Crowe Chizek in Indianapolis, Indiana. He is a thought leader focusing on Smart Client architecture. He has a B.S. Degree in Computer Technology from Purdue University and is certified in MCAD and MCSD.

Article edited by Rachel Wireman