Can shims be used to change Windows version number?

Solution 1:

I was wrong on my first answer. My first suggestion to you was to make a "version lie" shim for your application. But you can't, because you're using a managed code application. I'm not saying you can't write API hooks for .NET applications, but appcompat shim support seems to be a lot spottier for managed apps.

Application shims implement API redirects so that when the application makes a certain API call, it gets intercepted or 'hijacked' and some other data is returned to the application from the shim.

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

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.

Most of the time, you can cook up your own shims with the Application Compatibility Toolkit:

http://blogs.technet.com/b/askperf/archive/2011/06/17/demystifying-shims-or-using-the-app-compat-toolkit-to-make-your-old-stuff-work-with-your-new-stuff.aspx

And doing a "version lie" where the shim lies to the application about what version it's running on is the most common use case for appcompat shims.

Because developers insist on doing version checks in their code, which is wrong. Microsoft tells you it's wrong. Do not do version checks in your code. (Instead, check for the existence or lack thereof of a particular feature you intend to use.)

But developers still do version checks every day. What's worse is they do '==' version checks where the app simply won't work unless you're running an exact version of Windows, which is arbitrary and stupid.

Sigh... developers.

Chris Jackson of Microsoft has worked on the application compatibility stuff for many years, and his attitudes are similar:

One of the classes of shims that people find the easiest to understand are the version lie shims. In essence, we have shims that can compensate for the fact that so many developers' keyboards were shipped with a defective > key (and the failure rate of this key on developer keyboards is astonishing). They work by just returning a different value from the GetVersion(Ex) APIs, depending on which operating system you selected.

But unfortunately in that same article, he gives us what I believe is the critical piece of information here:

OK, so now that you have CompatAdmin started, under the System Database, expand the Compatibility Fixes list. With the /x switch, you'll notice that the WinXPSP2VersionLie now has a plus sign - if you expand this, you'll see a list of modules that have a red diamond next to them. These are modules that this shim specifically excludes. Among these? The .NET Framework modules.

You see, the .NET Framework doesn't take too kindly to being lied to. They do version checks to determine how to implement certain things, and thinking they're running down-level isn't so great. So, we intentionally exclude these modules, and, consequently, we intentionally exclude the code that you're writing that these modules are JITting and executing. Not that we wanted to do so, but the infrastructure didn't give us a great way to separate these out. We either lied to everything, or we lied to nothing. It was worse to lie to everything, so we didn't.

Hehe, that's kinda' funny that .NET is doing version checks too when I just said how bad of an idea it was...

For real-life applications that need a version lie, well, if the application is managed, you'll have to change the code. This is something you can't, and shouldn't, shim up.

So, if you notice the version lie isn't working, and the application is managed, then my spidey sense tells me you're trying to shim it up with an XP version lie - and that's not going to work.

From MSDN:

Generally, apps should not perform operating system version checks. If an app needs a specific feature, it is preferable to try to find the feature, and fail only if the needed feature is missing.