Applying Shims (Compatibility Fixes) to Child Processes Using Layers (Compatibility Modes)

A comment came up on a recent posting regarding modules, inquiring about processes. Specifically:

Do these included/excluded modules have to be in the same process, or can they include other processes too?  (I have an application that calls multiple child applications that all need to be shimed in the same way as the first process)

Ah, that is a subject I appear to have not touched on here.

Shims, you see, apply to the process you specify, and only that process. Layers, however, apply to that process and to child processes. So, if you have a main application that launches child applications, applying the fixes as a layer will help you achieve that (assuming they are always launched by the shimmed parent process).

Note that Compatibility Administrator uses slightly different terminology here. It refers to shims as Compatibility Fixes, and layers as Compatibility Modes.

Layers are also handy as a means of applying a collection of fixes. You can group several fixes together and call them a layer. But the fact that layers apply to child processes is exactly why we include a WinXPSP2VersionLie layer in the system shim database. A collection of one isn't that interesting, but a collection of one that gets the shim applied to child processes? That's very interesting, particularly for self-extracting setups that like to think they are installing on XP.

If the child applications can be launched directly by Explorer, then you'll want to shim them up separately and we can't save you the work by having you just leverage a layer.

Comments (6)

  1. Martin says:

    Hi Chris,

    this is very interesting information… I think that compatibility fixes and compatibility modes is quite confusing name, fixes and layers is much more descriptive (from perspective how these are applied)


  2. cjacks says:

    Hi Martin,

    Yeah – I don’t think anybody’s come across something that everyone loves yet. I don’t name, I just fix. 🙂


  3. ABC says:

    Hi Chris,

    As per my understandings, if we have more no.of issues, which will not be resolved by a single shim, Here we are applying the mode( including all the required shims). is it the correct ?

    But there are some MODES, which came along with the Tool, what is the purpose of those? and when exactly we can apply those?

  4. cjacks says:

    You can apply multiple shims without applying a mode. The checkboxes are multi-select.

    We have multiple pre-built modes, and you can create your own if you’d like to re-use them across multiple apps.

  5. ABC says:

    ya, I was thinking the same. But bit doubt was there. Now it’s clear.

    and one more doubt I am having is:

    When we are creating the new Application fix. At one palce we will get a wizard for selecting the Operating System Modes.

    1) Here do we need to select the None option or

    2) we should go with any one of the O.S. As per my knowledge if we select the OS here, it’s mean is we are guiding to the shim saying this application should work same like how it is working on the chosen OS, right?

    And in the Matching Information wizard

    1) is it necessary to click on Auomate or shall we click Finish button, without selecting any option on left side( Add file, Remove file,Remove all,…..)

    Pls calrify me on these 2 queries?


  6. cjacks says:

    1) An OS "mode" is just a collection of shims. I generally pick the specific shims I need rather than a complete mode, otherwise I end up with more shims than the app actually needs.

    2) Matching information – depends on how generic the app name is. You just want to provide enough information to uniquely identify it, but not so much that doing the match is unnecessarily processor intensive.

Skip to main content