Changes to Shim Global Exclude in Windows 8

Lex III: Actioni contrariam semper et æqualem esse reactionem: sive corporum duorum actiones in se mutuo semper esse æquales et in partes contrarias dirigi.

I remember a time when all bugs were bad, and it was my job to find and destroy them all. That, of course, was when I was a developer. My perspective is quite different now that I am an app compat guy. You see, fixing a bug eliminates that bug, but technology is sufficiently complicated these days that fixing a bug often has unintended consequences. In other words, it creates new bugs, which may actually be worse than the one you fixed.

That’s the challenge we face in all of app compat – fixing something breaks other things. It happens all the time. It’s the reason why we introduced Switchback in Windows 7.

The single biggest impact of a bug fix I’m aware of is the DOCTYPE bugfix we put in for IE7.

And we fixed another bug in Windows 8 which may impact you if you are currently holding your busted apps together with some shim duct tape on Windows 7, and choose to update to Windows 8 (or if you are hoping to transition your skills to that).

What is the bug fix?

The shim infrastructure supports includes and excludes for particular modules at multiple levels. We can include and exclude modules at the individual shim level. We can do so at the application level. And the platform also supports doing so at the global level.

Except … there was a bug in the global exclude. We never applied it. (Well, except the System32 directory exclude.)

How might that affect you?

Well, we applied the global exclude to managed code. You see, there is no way for the shim infrastructure to differentiate between the framework and your app when running managed code. And shimming the framework can have many unintended consequences which leads to mysterious, difficult to troubleshoot failures. So, rather than create an even worse situation, we excluded it and you would have to consider alternatives (or work a little harder to override that with an include).

But since we never applied it, you could very easily shim managed code. (Except, as many have noticed when first experimenting with shims, version lies.)

And if you migrate that shim database forward to Windows 8, then some apps will no longer be shimmed without an include. For example, for anyone demonstrating shims, Stock Viewer needs includes to fix most of the issues (unless the shim itself has an include, like ForceAdminAccess does).

So far, the biggest audience I’ve seen impacted in practice are those using Stock Viewer, but I wanted to point out the bug fix – the solution being to simply add includes when you need to shim managed code, or to consider other alternatives. Happy shimming!

Comments (2)

  1. cjacks says:

    Minor correction: what we did specifically is mark everything in the Microsoft.NET directory as a system module, just like we do for System32.

  2. XavierEncrypt says:

    Hi Chris,
    I’m having an issue with creating my first shim to elevate a basic user’s permission to apply a plugin for WebEx to enable the user join a meeting through IE11 on Windows 8.1 tablets. The WebEx plugin is enabled successfully on Windows 7 32 bit & 64bit.
    Do you have any suggestions?

Skip to main content