Understanding Application Compatibility
There are several reasons why an application that worked on previous versions of Windows might fail to work on Windows 8 until you take action to remediate the application. How many of these non-working applications you encounter depends, to a large degree, on which version of Windows you are using today. The transition from Windows XP to Windows Vista was, without a doubt, the most challenging in recent memory. Windows 7, by comparison, was highly compatible with Windows Vista, and Windows 8 is turning out to be highly compatible with Windows 7. So, if you are using Windows Vista or higher, chances are you are in luck, and you will have a much easier time migrating your applications to Windows 8! If you are still using Windows XP (or—gasp!—an even earlier version of Windows), you probably have a little more work ahead of you. But, as countless customers have demonstrated, this is a surmountable challenge that can be conquered when you take the right approach to application compatibility.
As Microsoft continues to improve the overall security and reliability of the operating system, we realized that none of these investments could be fully realized while the majority of users were running as local administrators. Of course, this was the case for historical reasons. MS-DOS, and then early versions of Microsoft Windows, had no concept of shared computers and security checks. While Windows NT introduced a robust security infrastructure, it also boasted compatibility with existing MS-DOS and Windows applications that were never designed for a secure, multiuser operating system. Many customers relied on these applications, and as a result left their users as local administrators. However, administrator users are significantly more expensive to manage than standard users, and customers worldwide were clamoring for a way to make a higher percentage of their users standard users. Of course, some did succeed—but it was nearly always an expensive and painful process, and more than a few holes had to be punctured in the security configuration of the operating system to support applications that relied on administrator privileges.
Almost by definition enhancing security entails preventing things from happening, and blocking bad guys from doing those things. However, it is possible for applications to depend on the ability to do some of these things—particularly with older applications that may have been developed before it was commonly known how bad guys might be able to exploit a capability in order to do evil. In some cases, we added a capability to block a behavior that never existed before. In other cases, we modified the defaults to block behavior by default when previously we allowed the behavior by default and required you to opt in to block it.
Improving Performance and Capabilities
One of the changes commonly cited by enterprise customers for migrating to the latest version of Windows is the ability to take advantage of the capabilities and performance of a 64-bit operating system. While the 64-bit version provides the ability to run applications that need access to huge amounts of memory, and gives you the ability to take advantage of a large amount of RAM, there is a potential compatibility impact. While 64-bit Windows can run your existing 32-bit applications, it cannot run your existing 16-bit applications. It also doesn’t support your existing 32-bit device drivers. If you have a device that does not have a 64-bit device driver, or if you have mission critical 16-bit applications, then you will need to run these on a 32-bit operating system.
As computer displays contain more and more pixels on smaller and smaller screens, changing the display to make everything larger while still running with the full, non-interpolated capabilities of the display is important. Windows has supported High DPI functionality for several versions, and the support continues to improve with each subsequent version. Beginning with Windows 7, the support for High DPI was robust enough to begin detecting and defaulting to more appropriate DPI settings based on the display. However, there remain some applications for which high DPI settings are an issue, and if a significant portion of the devices you intend to deploy would benefit from a high DPI setting, then testing your applications in this scenario is a worthwhile investment.
Removing Legacy Components
While we do our best to retain compatibility with legacy applications, there are some instances in which supporting a given feature is no longer feasible—either because it blocks our ability to provide a superior replacement or because the feature has flaws that prevent us from meeting our performance, reliability, or security goals. When this is the case, we deprecate the feature. While not an exhaustive list, there are a few deprecations that have caused some compatibility concerns in the enterprise and are worth mentioning here.
In this article, we explored some of the investments we have made in Windows that may have an adverse impact on compatibility of your existing applications. Compatibility has long been a tenet in the development of Windows, and we always take compatibility regressions very seriously. Hopefully, this article explains some of the motivation behind these changes and can help you understand the tradeoffs we and you have to make.
About the Author
Chris Jackson, aka "The App Compat Guy," is a Principal Consultant and the Technical Lead of the Windows Application Experience SWAT Team. A widely recognized expert in the field of Windows application compatibility, Chris has created technical documentation, training, and service offerings used inside and outside of Microsoft based on years of real-world experience with enterprise customers and independent software vendors.