Understanding application compatibility
Applies to: Windows 7, Windows 8, Windows 8.1, Windows Server 2012
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.
Why do applications break when you migrate to a more up-to-date operating system? Sometimes it’s because an application was taking a dependency on undocumented behavior of the operating system, either because the developer intentionally used an undocumented API, or because the developer accidentally relied on a behavior that turned out to be a coincidence rather than a promise. (With the Microsoft Developer Network, or MSDN, documentation as massive as it is today, it is arguably pretty hard to completely understand all possible behaviors of the operating system!) Sometimes, features and behaviors are retired, which is often due to security concerns, but can also be the result of a lack of market adoption or replacement with a superior technology. Frustratingly, the most frequent cause of application compatibility failure is a version check. That is, the application is checking the version of the operating system, and then choosing to intentionally fail if it discovers any version other than the ones it chooses to run on. Basically, the application is refusing to let you try to run it on the new operating system, even if it would otherwise work perfectly!
If you are interested in specific details, we provide the Windows 8 and Windows Server 2012 Compatibility Cookbook to help explain changes in compatibility. However, the target audience of the Cookbook is the developer who is writing code. Instead, this article takes the perspective of IT professionals who are trying to migrate their organizations to Windows 8. Here, we discuss the motivation behind the changes made in Windows 8, as well as the potential impact of these changes.
In this article:
- Increasing reliability
- Enhancing security
- Improving performance and capabilities
- Advancing usability
- Removing legacy components
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.
In Windows Vista, we introduced the User Account Control (UAC) feature to finally break the cycle of local administrators driving applications that depended on local administrator rights, and therefore required more local administrators. Finally, customers could realize a significant reduction in total cost of operations (TCO), along with the superior security posture of a standard user environment. This feature, first and foremost, was a compatibility feature. It provided automated solutions to a number of compatibility challenges, such as file and registry writes to protected locations, or failure of setup applications that rely on administrator permissions to install to global locations. It also provided additional remediation options that could be manually applied to applications to resolve additional compatibility issues that came with running applications under standard user permissions.
In addition to remediating third-party applications, UAC also improved the experience of standard users in several ways. For example, we added the ability for standard users to change their time zone when travelling (a very common complaint for those customers who succeeded in deploying standard users on Windows XP or earlier). We also introduced a new security infrastructure, based on application trust in addition to user identity, which allowed us to implement sandbox behavior. Software such as Internet Explorer and Microsoft Office 2010 applications leveraged these sandboxes to enhance their security defense-in-depth. Windows 8 extends this trust-based security infrastructure even further with app containers.
Note that, because UAC provides the security infrastructure for app containers, if you disable UAC then you will not be able to run Windows Store applications. Because of this, customers who chose to disable UAC for either Windows Vista or Windows 7 should now strongly consider enabling it for Windows 8, and resolving the compatibility issues with standard users that most likely caused them to disable UAC originally.
UAC provides tangible benefits even for local administrators. By running local administrators with security credentials that are very similar to standard users most of the time, the users who most frequently have a legitimate need to retain local administrator rights—developers and IT administrators—can have an environment in which the software and scripts they create don’t create additional accidental dependencies on local administrator rights. This change has already had a significant impact on independent software vendors (ISVs), who are now creating software that almost always runs perfectly well with standard user rights thanks to UAC. It has the same impact within the enterprise.
In Windows Vista and later, we also added a feature called Windows Resource Protection (WRP), which leverages another extension to the Windows security infrastructure: the ability to secure resources for access only by a particular service, rather than to the identity of the account under which the service is running. This makes it particularly difficult for an application (nearly always an installer that included every DLL dependency when it was created) to accidentally write a copy of a very old version of a system DLL from Windows NT 4.0 (e.g. shell32.dll) on top of the copy used by Windows 8, which, as you might imagine, has a fairly catastrophic outcome! Instead, only the service that handles Windows Update (the Windows Modules Installer service) is able to modify these files by default. And, of course, we also provided remediation options for those applications, so the failure to write to these files doesn’t cause irreparable failure of your applications!
Back to top
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.
Internet Explorer protected mode, for example, provides a security sandbox that greatly restricts the ability of ActiveX controls hosted on a page from accessing the operating system. Beginning with Internet Explorer 8, protected mode is enabled by default in both the Internet and Restricted Sites zones. Many customers who have a dependency on ActiveX controls discover that their internal sizes are not zoning correctly to the Local Intranet zone (which disabled protected mode by default) and therefore find these applications to be less compatible.
Microsoft introduced operating system support for Data Execution Prevention (DEP) with Windows XP SP2. DEP is a memory protection feature, supported in both software and hardware, which significantly reduces the ability of malware to attack the system using techniques such as buffer overflows. It helps to protect against malicious code being injected through data entry points of an application. However, Windows 8 still leaves DEP configured to be opt-in to maximize compatibility. New Windows Store applications will opt in to DEP, but existing desktop applications will only have DEP restrictions applied if they opt in to this feature. Internet Explorer had DEP opt-in capability beginning with Internet Explorer 7, and enabled it by default beginning with Internet Explorer 8. This means that ActiveX controls that are dynamically generating and executing code but that have failed to mark their memory as executable will have an exception generated (which, if not handled by the application, will cause the application to crash) any time it attempts to execute this code.
For customers still migrating from Windows XP or earlier versions, Session 0 Isolation may still present a challenge in moving to Windows 8. A Windows service has historically run in Session 0, and continues to do so today. In Windows XP and earlier, the first user to log on to the computer would also run in Session 0. When computer resources were far more limited, this was a more efficient approach. However, despite being parsimonious with resources, this exposed quite a bit of security surface area, as applications that typically run with Local System privileges cohabitated with other applications running with significantly fewer privileges—providing a tempting opportunity for elevation of privilege. As a result, we no longer log users on to Session 0; this session is for services only. Service applications that expect to be able to communicate with the user or their programs directly often have to find new mechanisms for this communication.
We continue to add security features to Internet Explorer, since it is the portion of the operating system that most frequently connects with potentially malicious agents. For example, the Tracking Protection feature in Internet Explorer 9 and Internet Explorer 10 helps users protect their privacy by blocking enumerated tracking agents. However, many of the same sites that are tracking online behavior are also providing web application functionality, so many scripts can fail to load and execute when they live in a domain blocked by one of your Tracking Protection Lists.
Similarly, the SmartScreen Filter feature in Internet Explorer helps protect you from malicious downloads. In Internet Explorer 8, SmartScreen Filter safeguarded you from a list of known malicious downloads. Beginning with Internet Explorer 9, SmartScreen Filter was enhanced to add reputation, which required downloads to build a reputation before they would be marked as good, and otherwise generate a warning that the download was new and therefore not yet known to be good. Windows 8 takes this concept and brings it to the operating system, helping to protect you from downloads that have not established a positive reputation regardless of the browser you use to obtain them. This can, however, cause failure in some scenarios in which you download frequently changing but unsigned executable files, or only have occasional downloads of insufficient quantity to have developed an application reputation yet.
Back to top
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.
Another possible impact to the enterprise of running 64-bit Windows is the impact on .NET applications that interoperate with native code, either through COM Interop or P/Invoke Interop. The default compiler setting for .NET applications is called “Any CPU,” which means that these applications will become 64-bit applications on a 64-bit operating system, but they will become 32-bit applications on a 32-bit operating system. If they are calling in to native code, the native code needs to be of the same type (64- or 32-bit) as the calling application. So, when the application is calling in to native code, and that native code is compiled as 32-bit code, this call will fail to load that DLL. Fortunately, this is a relatively straightforward problem to fix, either by changing the compiler setting or by modifying the executable directly using the CorFlags utility, but it bears mentioning because of the frequency with which we have found this impacts enterprise customer applications.
Windows Vista introduced a new display mode, called Desktop Window Manager (DWM). DWM changed the historical model, in which applications would render directly to on-screen memory, and instead caused applications to render to off-screen bitmaps, which would then be composited by the DWM to create the display that users see. There are significant benefits both for performance and user experience in taking this approach. However, several types of applications were incompatible with the DWM. For the enterprise, the largest impact was in remoting applications, which would often use mirror drivers to redirect the display. Beginning with Windows 8, it is no longer possible to disable the DWM, as it is now core and central to the operating system experience. While we have done our best to keep most applications working, applications that continue to use historical approaches may not always work.
A key aspect of performance for mobile users is battery life. With the new model for Windows Store applications in Windows 8, applications are not only full-screen and immersive, they are also suspended when they are not visible. As a result, they are not consuming CPU cycles and, therefore, not draining the battery. However, historically, existing applications have always been running, consuming both CPU and battery, from the time you start them until the time you close them. To help facilitate the longer battery life that users hope for (and expect), even with existing desktop applications, Windows 8 takes steps to throttle existing service applications—gating the amount of CPU they are allowed to use—and to suspend interactive applications when they are not in use and the screen is shut down. While this meets with user expectations (when you hit the power button on your mobile device, you expect that your application won’t continue to run at full throttle), it may cause an issue for applications that aren’t anticipating being suspended. Fortunately, this impact is relatively minimal.
Back to top
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.
Back to top
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.
Beginning with Windows Vista, we removed support for kernel-mode printer drivers. This is for reliability reasons—a failure in a kernel-mode driver leads to a blue-screen crash of the entire system, while a failure in a user-mode driver leads to a driver crash only. In general, we have been moving as much functionality out of kernel-mode as possible—particularly when reliability is an issue—without compromising our ability to deliver against performance objectives. While most customers no longer have printers that only supply kernel-mode drivers, we do run across them from time to time on particularly high-end printers and plotters that, due to their price, have a longer-than-average lifespan. More often, we run into challenges with virtual printers, such as printers that generate PDF files; older versions of these printers often leverage kernel-mode drivers which will no longer run.
We have also gradually retired WinHelp files as a help file format. This file format was introduced in 1990 for Windows 3.0. We provided its successor, HTML Help, in 1997 with Internet Explorer 4.0. While we continued to support WinHelp files, with Windows Vista the concern for the additional security surface area drove us to remove WinHelp from the operating system proper. Help file contents were so powerful in this format that they were equivalent to an executable file. However, given the massive volume of WinHelp content generated over more than two decades of support, we continue to provide downloadable support for Windows Vista and Windows 7, and will provide the same for Windows 8.
The means by which you log on to Windows has long been extensible, but the mechanism we used historically only allowed one provider to be operating at a time. This mechanism also required that providers develop all of the code and create the entire user experience for the logon process. Beginning with Windows Vista, we replaced this model with the Credential Provider model, which only requires developers to implement the portion of authentication that differs from that provided already, and also affords the ability for multiple providers to work in unison. However, this architecture change does require any application that provided an alternate means of log on for Windows XP or earlier to be rewritten.
Back to top
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.
While the transition to Windows 8 from Windows XP or earlier can often see a failure rate of 20 percent or higher (if you are using particularly old software and running local administrator desktops today), there are a number of remediation options available to quickly remedy the vast majority of these failures and free up your time to focus on those applications that require more significant interventions. The failure rate from Windows Vista or later to Windows 8 is thus far proving to be in the very low single digits (with the primary culprit being those pesky hard-coded version checks!). So, you should be able to extend and maximize your software asset investments even longer with Windows 8. Good luck in your application compatibility efforts!
Back to top
- Five things every IT professional should know about application compatibility
- Five steps to Windows 8 application readiness
- Get started with application compatibility in a Windows deployment
- Manage shims in an enterprise
- Windows Assessment and Deployment Kit
- Windows 8 compatibility cookbook
- Windows 8 compatibility center
About the author
Chris "The App Compat Guy" Jackson is a Principal Consultant and the worldwide lead for application compatibility at Microsoft, specializing in Windows, Internet Explorer, and Office internals. Jackson is a widely recognized expert in the field of application compatibility, creating technical documentation, training, and service offerings used inside and outside of Microsoft and based on years of real-world experience with enterprise customers and independent software vendors. Author or co-author of numerous technical papers and articles, he is also a featured speaker at major industry conferences around the world and publishes a popular blog.