Slashdot It! As of the end of March, 2007, 129 applications were certified or designed for Windows Vista, and 922 applications worked or were compatible with Windows Vista. Think that's a lot? Well, it does add up to over 1,000 applications you can run on Windows Vista with few, if any, issues. But, given that there are tens of thousands of applications designed for Windows, this first thousand is just a drop in the bucket.
Making existing applications work for Vista is a big job. Microsoft is keeping track of each application that passes its bar and is providing weekly updates through its Knowledge Base. But this obviously doesn't suit everyone.
Besides grabbing attention, such a ban puts a focus on Vista's support of current and legacy applications. Vista contains a series of changes in the way it supports applications (after all, Microsoft performed a rewrite of all the Windows code for Vista). In some cases, these changes are system-wide -- in others they affect specific areas of application operation. In both cases, they can break applications.
Luckily, there are a number of solutions as well:
Problem: The version number for Windows has changed -- Vista is number 6. While this occurs each time a new version of Windows is released, it will affect applications because some apps check version numbers at installation, others during operation, and yet others during both installation and operation.
Solution: Installation logic is easy to modify if you have the right tools. Software packaging tools such as Altiris Wise Package Studio and Macrovision AdminStudio let you edit version numbers both in standalone installations and in installations which are integrated with the Windows Installer service. Changing the version numbers when an application is running is more difficult because you would normally need to modify the application's code, but you can also run the application in one of the many compatible modes Vista supports.
Problem: The 64-bit or x64 versions of Windows Vista don't support 16-bit code. In fact, while x64 editions of Windows support 32-bit applications as well as native 64-bit applications, they no longer support any 16-bit code at all.
Solution: Several 32-bit applications still rely on 16-bit installers; in these cases, x64 editions of Windows XP, Windows Server 2003, and Vista will automatically convert these installers to their 32-bit equivalents during installation.
(If an application is designed as a true 32-bit application, it will work well on x64 Vista and in many cases, work even better than on x86 or 32-bit editions of Windows. That's because Vista x64 breaks the 4GB memory limitation x86 systems face and grants more resources in general to applications.)
However, 16-bit applications will not install at all on x64 versions of Windows. Problem: The feature that will have the most impact on application compatibility is User Account Control (UAC).
When UAC is turned on, each user runs with a standard user token no matter what their normal privileges are. Standard user tokens use the "least user access principle," which means that each operation is performed with no administrative access rights. When an operation requires administrative rights, a special prompt is displayed to provide it. If you are an administrator, you simply click Allow or Disallow, but when you are a standard user, you have to provide the name of an administrative account as well as its password to authorize the operation.
This means that it is now much easier to run locked-down systems because everyone, even administrators, can work with a standard user account. When prompted, administrators can provide their high-privilege credentials -- whereas users will never see this prompt in the first place if you configure your settings properly. This helps keep systems secure at all times. But running without administrative rights will often break poorly-written applications, because they try to write in locations that are not available to users with standard access rights. This is the case for many legacy applications.
Solution: Several solutions exist. Vista's virtualization of both the file and registry may help by redirecting application components to user-writable areas of the system. Applications can be rewritten to correct their behavior. Applications can also be virtualized through third-party tools such as Microsoft SoftGrid Application Virtualization, Altiris Software Virtualization Solution, or Thinstall Virtualization Suite. This lets the application run in a sandbox, isolating it and preventing it from making changes to the system. Or the application can be supported by a tool such as Altiris Application Control Solution or BeyondTrust Privilege Manager. Both tools provide elevated access rights on the fly when users run a legacy application that does not work with UAC.
Incidentally, one great way to identify potential issues with UAC is to run the application through the LUA Buglight tool. LUA Buglight (LUA stands for "Limited User Access") is a free tool developed by Aaron Margosis, a senior consultant with Microsoft Consulting Services. Basically, LUA Buglight scans an application as it runs to identify any activities that require administrative rights. Once these activities are identified, you can correct the code, correct the application's configuration, or try running it in a compatibility mode. Aaron's blog also provides a lot of information on potential solutions for running applications in "non-admin" mode.
If you find this all really frustrating, you can, of course, disable UAC through the Group Policy settings, but we would certainly not recommend that you do so. Everyone should be running as a standard user -- even in Windows XP. It isn't always easy, but it is possible and definitely more secure.
Problem: Another change that will break some applications is Windows Resource Protection (WRP), which is Windows System File Protection on steroids. WRP protects both the file system and the registry from unauthorized changes to the system. When an application tries to write to protected areas of the system, it fails. Many legacy applications will do this because they were never written with system protection in mind.
Solution: Try running the application in compatibility mode or correct the application if you have access to the source code.
Problem: Session 0 is the core session the operating system kernel operates within. In previous versions of Windows, applications were allowed to operate in Session 0, but any application that would fail while operating at this level would cause the entire operating system to fail.
In Vista, Session 0 is now reserved for operating system functions only. Services that operate at this level and try to display user interfaces will fail because Session 0 no longer supports any such interfaces.
Solution: Vista will try to automatically redirect these interfaces to user sessions, but this may not work. The best way to correct these issues is to update the application to use global objects instead of local objects and display all interfaces in user mode.
Solutions Within Vista Given all these issues, you would think most applications fail on Vista, but this is not quite the case. Vista includes several features that try to mitigate application issues.
Like Windows XP, Vista includes compatibility modes which you can assign to different applications to have them run properly. In addition, Vista includes the Program Compatibility Assistant (PCA), which is a remake of the Program Compatibility wizard found in XP.
|The Program Compatibility Assistant is Vista's remake of XP's Program Compatibility wizard. It monitors applications for failures.|
The PCA monitors applications for failures and will automatically apply compatibility modes when they are detected. If an installation fails, the PCA will suggest that it be rerun with settings changes. Basically, the PCA modifies the compatibility settings in the application's properties. In most cases, the installation works correctly after this change. This can be done manually as well.
|Vista supports several compatibility modes.|
Along with the PCA, Microsoft has introduced a form of file and registry virtualization. This means that when it detects an application that would normally write to protected areas of the system, Vista will try to use its virtualization settings to redirect the application's output to unprotected areas. Vista's file virtualization will automatically redirect offensive file writes to a folder structure called C:\Virtual Store\SID\Program Files\... where the SID is the security identifier of the user running the application. Similarly, Vista's registry virtualization will redirect system-wide registry keys -- keys that would normally be stored within the HKEY_Local_Machine\Software structure -- to HKEY_Classes_Root\VirtualStore\Machine\Software.
This is nothing like true software virtualization, which provides complete protection from any application modifications for the operating system. Software virtualization systems such as those mentioned earlier provide the best ways to support application compatibility in Vista. These tools allow you to prepare an application on a previous version of Windows and then copy it to a Vista system where it will run in protected mode. You copy the application instead of installing it because the preparation process for software virtualization captures the running state of an application, not its installation process. This revolutionary process should take off as organizations realize the benefits of true software virtualization -- and as they migrate to Windows Vista.
Get Into The ACT If you're not ready for full-blown software virtualization, then you should look to a separate tool offered by Microsoft: the Application Compatibility Toolkit (ACT). ACT is designed to assist the identification and remediation of application compatibility issues. It does this in three ways:
- A collector package can be generated from the ACT interface to perform application inventory collections from client systems. This collector package requires administrative access rights for installation, so organizations wanting to use ACT will need to devise a method for deployment of this package if their systems are locked down.
- Once deployed, the package will run on client systems for a defined period of time. It will collect inventory information and report it back to the central ACT database. This information will include the name of the application, version number and manufacturer as well as some operational data such as whether it was used or not during the time interval you set the package to run for.
- After the information is collected, you can create shims (code snippets) to add to the application's installation logic to correct any known issues.
ACT provides a lot of information as it gathers inventory from your network. Of most value is the audit data telling you whether the application was used or not during the time period of the analysis. Many organizations find themselves in a situation where they have applications installed on systems but these applications are not used by the principal user of that system (systems are more often assigned to one single principal user). This can be caused by a number of factors, the most common being that very few organizations uninstall applications when they are no longer required.
|ACT provides a central repository of application compatibility data. (Click image to enlarge.)|
It's a common scenario: The system is built for user A who needs application X; user A moves to a new position and the PC is passed on to user B; User B needs application Y; IT deploys application Y but never takes the time to remove Application X. A Vista migration is the ideal time to reset the clock back to zero and perform a massive cleanup on all PCs. After all, why bother redeploying an application that is not used? ACT and other similar usage analysis or auditing tools can greatly help at this level.
ACT also lets you share application data with the Microsoft Compatibility Exchange, a central repository of data generated by IT pros as well as commercial application vendors. In return, you get feedback from others on the applications in your network. Of course, you choose to opt in or not as you wish, but building a community of application data is a good idea.
The problem lies with the validity of the data. Since it is shared mostly anonymously, this data can be questionable. In addition, you only get information on the applications you submit, so you can't delve into data on other applications. In addition, few organizations will choose to share data on their own internally-developed applications -- and these are often the cause of most compatibility issues.