Shims - those nasty bits

I have been asked a number of times about application compatibility fixes overt the past few weeks and the role of Microsoft's Shims.

As brief description of Microsoft's Shim technology; here is a snippet from the Microsoft Technet Shim article;

"The Shim Infrastructure implements a form of application programming interface (API) hooking. Specifically, it leverages the nature of linking to redirect API calls from Windows itself to alternative code—the shim itself."

To find out more about the Microsoft Shim technology, please have a read here;

Understanding Shims;

http://technet.microsoft.com/en-us/library/dd837644(WS.10).aspx

Or, Managing Shims in the Enterprise

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=F3B46BA6-0EF2-47DB-AAEC-ED786109E030&displaylang=en

After reading these links and documents, I have a number of problems with Microsoft's Shim approach including;

• Microsoft owns the Shim database  and may update the database at anytime
• No published API’s for the Shim Database
• No published documentation for the Shim Database schema
• No tools for managing the Shim Database in an enterprise environment
• No Active Directory integration
• No native integration with 3rd part deployment tools
• No central management and control of the Shim Database
• No centralized reporting mechanism’s available (from MS or ISV’s)
• Any update to the Shim Database requires a complete re-compile of the database
• No transparency or “accounting” of changes or updates to a Shim database
• No “back-out” or roll-back facilities for the Shim Database
• Limited Multi-Platform Support

To support these points, Microsoft has outline an additional scenario referenced in the Managing Shims in the Enterprise document which includes;

"It is possible that you will eventually find that the shims assigned to resolve a set of compatibility issues in an application are not comprehensive and that later you will need to deploy an updated version of the custom shim database that resolves the additional issues your organization later discovered. If you deployed the original custom shim database as part of the installation package, you will need to locate each client that has installed this application and the original custom shim database for it to replace it with the new version."

So, I am recommending that our customers do not use Shims but employ the Best Practices offered by Microsoft through;

• Elevation Manifests
• Updating the source application package (MSI Installers)
• Creating Side-by-Side (Sxs) Isolation manifests

Hope that all this makes sense.... and, that I will be posting more on this topic soon...