Deciding When to Use Shims as a Compatibility Mitigation
When Microsoft consultants work with customers on using shims to resolve compatibility issues with Windows 7, they begin the conversation with an overview of how shims work, ensuring that people at various levels in the organization understand the technical implications of using shims for mitigations. However, the decision is more than a technical one.
An application vendor is unlikely to support an application on Windows 7 when there are known compatibility issues. Application vendors cannot distribute shims to fix their application, so every enterprise must independently validate and deploy shims that mitigate these issues. Consequently, most vendors will not provide support for shimmed applications, either.
Vendor support is typically a critical business issue for Information Technology (IT) departments, especially for any software deemed either business critical or important to the operation of the business. While some customers have negotiated with vendors to have support extended to shimmed versions of their software on Windows 7, most vendors will wait to release either an update to the existing version or a new version, offering support on this new version.
If your organization is like most, you are likely to decide not to shim your most important off-the-shelf applications for this very reason: support.
Scenarios in which customers decide to use shims
The scenarios in which Microsoft consultants have assisted customers in using shims to mitigate application issues include:
You acquired the application from a vendor that is no longer in business. Several applications Microsoft consultants have worked with have been from vendors that have since gone out of business; so clearly, support is no longer a concern. The application is nice to have if the consultants can keep it working, because it prevents you from having to implement the software yourself (as frequently there are no vendors offering a competing offering). However, because the source code is not available, shimming is the only option for compatibility mitigation.
You developed the application internally. While most customers would prefer to fix all their applications to be natively compatible, there are some scenarios in which the timing does not allow for this. The team may not be able to fix all of them prior to the planned deployment of Windows 7, so they may choose to shim the applications that can be shimmed and modify the code on the ones where shims are insufficient to resolve the compatibility issue. Alternately, you may already be at work on a long-term project to replace the application with a new one, and does not wish to invest further in the existing version, instead using shims to resolve compatibility issues until the new application is completed. Then, the customer deploys the natively compatible version upon completion, without having to delay the deployment of Windows 7.
You acquired the application from a vendor that will eventually be releasing a compatible version, but support is not critical. When an off-the-shelf application is neither business critical nor important, some customers use shims as a stopgap solution. Users could theoretically wait until a compatible version is available, and its absence would not block the deployment, but being able to provide users with a shimmed and functional version can bridge that gap until a compatible version is available (or budget to acquire it becomes available).
In general, Microsoft consultants have found that good communication and collaboration among technology owners (“do the shims succeed in making the application sufficiently compatible”) and business owners (“can I accept the support terms of using a shimmed version of this incompatible application”) helps the decision process.
Deciding which versions of an application to shim
While a thorough description of applying a shim to a particular application is outside the scope of this white paper, one aspect that is important to note is that shims can be applied to particular versions of applications, either as “up to or including” or just a particular version. Either one ensures that the next version of the application that is released will no longer have the shim applied.
This is important to many customers. They want to ensure that they can fix the incompatible application for a particular version but still encourage the vendor (whether an internal development team or a vendor) to fix the application by having the shim no longer apply the next time the version number is incremented.
Support for shims
While support policies for applications made compatible with Windows 7 using shims is up to each software vendor, another frequent question is, how is the code for the shims themselves supported?
Shims ship as part of Windows 7 and are updated through Windows Update. Consequently, they fall under the same support terms as the rest of the Windows operating system.
You can apply shims that the Windows product team creates to your own applications, but Microsoft does not provide the necessary tools for you to create your own shims leveraging the Shim Infrastructure.