The compatibility problems are usually caused by some of Windows Vista's new security features. Prior to the release of Vista, most software developers wrote applications under the assumption that the application would have free reign on?? the system. But that wouldn't happen in Vista. Windows Vista locks down a lot of the areas of the operating system that were once freely accessible. As a result, applications that depended on being able to access those operating system components no longer work correctly.
Now that Windows Vista has been around for a while, most software publishers have released patches that allow their applications to be Vista compatible (or they have released entirely new versions of their products). In some cases, though, either a patch isn't available or a company does not have the budget for the necessary upgrade. Either way, in such cases companies have to find a workaround that will allow the application to function in Windows Vista.
The good news is that Windows Vista provides a number of mechanisms for allowing otherwise incompatible applications to run. Unfortunately, these mechanisms have no guarantees, and there are still some applications that won't work in Vista no matter how much tweaking you do. With that said, let's take a look at some of the compatibility mechanisms that are available to you.
You can access Windows Vista's compatibility settings by right-clicking on an executable file that you want to make compatible and choosing the Properties command from the resulting shortcut menu. When you do, you'll see the application's properties sheet. You'll find the compatibility settings on the properties sheet's Compatibility tab, as shown in Figure A.
Most of the settings found on this tab have been around for a while now. The first available setting is the Run This Program in Compatibility Mode check box, which lets you choose a version of Windows that the application is compatible with. After you choose, Windows will basically lie to the application and tell it that it's running on the version of Windows that you have specified. Keep in mind that although this setting does provide some backward compatibility, it does not cause Vista to completely emulate the version of Windows that you have specified.
The next section you will encounter is the Settings section. It allows you to force the application to run in a way that it might have run an older version of Windows. For example, just last night I downloaded a remake of a video game that was originally written in 1984. Although the remake supported VGA graphics, it was still limited to running at a resolution of 640 x 480. When the default settings were in place, the application would not run under Windows Vista. However, when I used the Compatibility tab to limit the screen resolution to 640 x 480 and to use the compatibility mode for Windows 95, the application worked.
The last section on the Compatibility tab is the Privilege Level section. As you can see in Figure A, this section contains a check box that can be used to run the application with administrative privileges. According to Microsoft, you shouldn't use this setting unless you absolutely have to because running applications with administrative privileges violates a number of security best practices. Even so, it has been my personal experience that using this setting corrects more compatibility problems than any of the other settings.
Again, there are still some applications that you cannot force to run on Windows Vista no matter which of the compatibility settings you implement. Fortunately, when you run into these types of problems, you may still have a couple of options available.
One option that works particularly well for me is to run the application in a virtual machine. When I deployed Windows Vista on my primary workstation, I downloaded a copy of Virtual PC and created a virtual machine that was running Windows XP. I try to run the majority of my applications natively through Windows Vista because applications will perform better in a native environment than they will in a virtual machine. Still, my virtual machine gives me the ability to run otherwise incompatible applications.
Another option is to run the incompatible applications in a Terminal Services environment. This option tends to be more expensive and complicated than implementing a virtual machine, but it can be very effective. A while back, I discovered an application called 2X Application Server that allows hosting individual applications on a terminal server without forcing the end users to work in a thin client environment. The result is that the user can run otherwise incompatible applications because the applications are actually running on a terminal server. Just remember that the way the 2X software works is that it provides the illusion that the application is running natively on the desktop alongside applications that really are running natively. The user has no idea that some applications are running locally while others are hosted.
Windows Server 2008 offers a similar feature, but the problem is that Windows Server 2008 is built on Windows Vista code. Therefore, most of the applications that won't run on Windows Vista won't run in Windows Server 2008 either.
|Brien M. Posey, MCSE, has received Microsoft's Most Valuable Professional Award four times for his work with Windows Server, IIS and Exchange Server. He has served as CIO for a nationwide chain of hospitals and healthcare facilities, and was once a network administrator for Fort Knox. You can visit his personal Web site at www.brienposey.com.|
This was first published in May 2008