Opt out of application compatibility mode on Vista?

[Jordan Russell]

Is there a way to prevent an application from running in compatibility
mode on Vista?

My application detects Windows Vista by calling GetVersionEx and
checking for a major version number >= 6. Most of the time this works
fine, however if my application is launched from another application
that is running in XP compatibility mode, the GetVersionEx call in my
application will return a major version number of 5, causing it to think
it isn't running on Vista.

Is there something I can stick in my application's manifest to tell
Windows "never run this application in compatibility mode"?
(Note: I already have a "requestedExecutionLevel" element.)

Failing that, what is the preferred method of detecting the true Windows
version? i.e. Is there a GetVersion-like API that will always return 6
on Vista, regardless of whether the calling application is running in
compatibility mode? (Currently I'm reading the version number on
kernel32.dll, but that seems like a horrible hack.)

Thanks.

[Jeffrey Tan[MSFT]]

Hi Jordan,

I have discussed this issue with the Vista compatibility team.

Based on the confirmation, if the app is already manifested for UAC it
should be opted out.

The only time the scenario you state would occur is if the versionlie shim
was applied as a layer. In most cases that shouldn¡¯t happen.

You should switch to using an API like VerifyVersionInfo and
GetProductInfo. You may refer to the link below for details:
"Determine Windows Version and Edition"
http://codeguru.earthweb.com/cpp/w-p/system/systeminformation/print.php/c897
3__2/

Internally, we don¡¯t actually fool the app into thinking it is running on
XP.. what we do is hook some api¡¯s and modify their return values. It is
only a very small level of emulation of some older behaviour.

Yes, I also agree that we shoul not read the binary version directly, that
would cause more appcompat pain later on.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Jordan Russell]

Post by Jeffrey Tan[MSFT]
I have discussed this issue with the Vista compatibility team.
Based on the confirmation, if the app is already manifested for UAC it
should be opted out.

Thanks for the response.

My application is manifested for UAC, but that apparently doesn't stop
GetVersionEx from returning a fake version number.

Version number mangling can be seen with UAC-manifested executables that
ship with the OS, too. Please try this:

1. Copy c:\windows\system32\cmd.exe to c:\testcmd.exe.
(Note: Be sure to put it in c:\, as files in c:\windows\system32
seem to be exempt from app compat.)
2. Right-click c:\testcmd.exe, click Properties, and on the
Compatibility tab, check "Run in compatibility mode". Click OK.
3. Double-click testcmd.exe.

Note the version number in the banner:

Microsoft Windows [Version 5.1.2600]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

You can see the same thing if, instead of setting compatibility mode on
c:\testcmd.exe itself, you launch c:\testcmd.exe from another EXE that
is set to run in compatibility mode. (i.e., child processes appear to
inherit the compatibility mode setting from their parents.)

This same issue affects my app: It sees the OS version as "5.1" if it's
running in XP compatibility mode (which can be because it was launched
by another app running in XP compatibility mode). I want it to see "6.0"
all the time when running on Vista. Thus, I'm looking for a way to
obtain the true OS version, or a way to prevent Windows from running my
app in compatibility mode.

Post by Jeffrey Tan[MSFT]
You should switch to using an API like VerifyVersionInfo and
"Determine Windows Version and Edition"
http://codeguru.earthweb.com/cpp/w-p/system/systeminformation/print.php/c897
3__2/

I suppose in specific cases those might work (assuming they don't lie
about the OS version as well). However, I would still like to be able to
obtain the true version number for use in log files, etc.

[Jeffrey Tan[MSFT]]

Hi Jordan,

Thanks for your feedback.

Yes, by searching in internal database, I find several records talking
about the same issue. For example, one record is indicating the .Net
Environment.OSVersion is returning incorrect string on Vista when
compatibility modes are turned on. Environment.OSVersion internally also
calls GetVersionEx to retrieve the information. I think this is the
behavior we got on Vista compatibility mode now.

Also, as confirmed by the compatibility team, there is ultimately no way to
prevent shims from being applied to the process, or else we wouldn¡¯t be
able to shim them. In this situation, if your application is getting
launched in that manner (as a child from another app marked by a compat
layer) then there is nothing we can do to change the behavior, as the layer
is designed to propagate to child processes.

I am not sure I understand your statement in the last paragraphy
completely. Can you tell me why you can not use VerifyVersionInfo and
GetProductInfo instead? Also, is there any particular reason they are
displaying the version number of the OS? Maybe we can find a workaround for
you task.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jordan Russell]

Post by Jeffrey Tan[MSFT]
Also, as confirmed by the compatibility team, there is ultimately no way to
prevent shims from being applied to the process, or else we wouldn¡¯t be
able to shim them. In this situation, if your application is getting
launched in that manner (as a child from another app marked by a compat
layer) then there is nothing we can do to change the behavior, as the layer
is designed to propagate to child processes.

That is unfortunate. I hope the compatibility team considers adding such
a capability in the future. My application is fully compatible with
Vista and does not depend on any shims to function properly. Thus, I
believe I should be able to totally opt out of shimming by adding
something to my EXE's manifest like:

<alwaysDisableShims ifWindowsVersionLessThanOrEqualTo="6.0.6000" />

which would disable shims when running on Vista, while still allowing
future versions of Windows to shim my application if necessary.

As mentioned before, EXEs in c:\windows\system32 already seem to be
exempt from shimming (at least, they never see a fake Windows version).
There just needs to be way for EXEs housed in other directories to opt
out of shimming as well.

Post by Jeffrey Tan[MSFT]
I am not sure I understand your statement in the last paragraphy
completely. Can you tell me why you can not use VerifyVersionInfo and
GetProductInfo instead? Also, is there any particular reason they are
displaying the version number of the OS? Maybe we can find a workaround for
you task.

To be specific, the application in question is an installer (Inno
Setup). For troubleshooting purposes, the installer has the ability to
create a log file. One of things included in the log file is the
user's Windows version. If the installer is running on Vista in XP
compatibility mode, the log file says "5.1.2600" for the Windows
version, which is undesirable as it gives the reader the impression that
the user is running Windows XP when they actually are not.

So VerifyVersionInfo may be useful in situations where I need to test if
the OS version is "at least" a certain number, but it can't completely
replace the functionality of GetVersionEx.

Is there really no way to get around the "versionlie" shim? I just need
something that will return "6.0.6000" all the time on Vista. It seems
hard to believe that the compatibility team wouldn't have made any
allowance for this (?).

[mayayana]

Post by Jordan Russell
Is there really no way to get around the "versionlie" shim? I just need
something that will return "6.0.6000" all the time on Vista.

I've been following this with interest. I wonder
about calling DLLGetVersion on Shell32.dll? The
last build for XP seems to be 3xxx, while the first
for Vista seems to be 6000. If that function doesn't
lie then one could just check for build > 5000.

[Jeffrey Tan[MSFT]]

Hi Jordan ,

Thank you for the feedback.

I have forwarded your suggestion to the compatibility team, I hope they can
file it for consideration. However, as you know, this type of decision
should be a big one and has gone out of my control. Anyway, I will feedback
here if I got any comment from them.

If your application is an installer, shouldn't the user be starting it? Can
you show me under what conditions is it launched by an application which is
in an XP layer?

If all you are using the version for is getting the OS version, and not
making a decision about it (ie: just printing it out) then I think you can
use GetProductInfo. Does this make sense to you?

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Jordan,

Sorry for letting you wait.

After the futher discussing with the compatibility team, one development
lead confirmed that we¡¯re considering adding a feature like that for
Windows7(the version of Windows after Vista), in that we might ask apps to
tell us what version of the OS they work with. If so, we¡¯ll quietly take
that as a given and never apply a layer to them if they¡¯re running on that
version of the OS (and always apply a layer to them on later versions of
the OS). Unfortunately there¡¯s nothing like that in Vista or SP1, and
we¡¯re never going to allow third-parties to completely opt out of being
shimmed.

For your specific issue, we think using GetProductInfo is a good solution.
Have you tried it? Does it make sense to you? Please feel free to tell me
your concern regarding it, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Jordan Russell]

Post by Jeffrey Tan[MSFT]
Sorry for letting you wait.

Ditto. Some things came up and I forgot about this thread. :-\

Post by Jeffrey Tan[MSFT]
After the futher discussing with the compatibility team, one development
lead confirmed that we¡¯re considering adding a feature like that for
Windows7(the version of Windows after Vista), in that we might ask apps to
tell us what version of the OS they work with. If so, we¡¯ll quietly take
that as a given and never apply a layer to them if they¡¯re running on that
version of the OS (and always apply a layer to them on later versions of
the OS).

Sounds like a good plan.

A "do not inherit parent process's compatibility layer" option would
also be helpful. (Just because the parent process is running in XP
compatibility mode doesn't mean my process requires XP compatibility
mode also.)

Post by Jeffrey Tan[MSFT]
For your specific issue, we think using GetProductInfo is a good solution.

Looking at the documentation, it appears that GetProductInfo cannot tell
me the OS *version*, only the OS *edition*, which isn't useful for my
purposes.

I ended up just using VerifyVersionInfo in places where Vista must be
detected 100% reliably.

[Jeffrey Tan[MSFT]]

Hi Jordan,

Thanks for your feedback and confirmation.

Yes, GetProductInfo will not provide the exact version number but the
information.

Ok, if you need further help, please feel free to post, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Jeffrey Tan[MSFT]]

Hi Jordan,

Have you reviewed my last reply to you? Does GetProductInfo API work for
you? If you still have any concern, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

[Skywing [MVP]]

Unfortunately, appcompat hacks kind of put you in a difficult position.
I've had a number of similar problems where somebody else's code caused my
code to get run under a Microsoft appcompat layer that broke things.
(Ironic, how the appcompat layers significantly complicate writing correct
code and necessitate ugly hacks to work around the appcompat layers. Hooray
for that.)

As far as the OS version goes, you can try and hack around the appcompat
layer induced breakages by going the undocumented route (in your case, the
OSVersion fields in PEB/KUSER_SHARED_DATA retain their true values),
although I am obviously fairly hesitant to recommend that as a first choice.

BTW, as far as I know, VerifyVersionInfo and friends also depend on the same
OS version information that the appcompat hack lies about. So, assuming
memory serves, that won't help you much either. You might try and see if
you can get a 'clean' app to launch your program to break free of the
appcompat layer inheritance problem.
--
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net

Post by Jordan Russell

Post by Jeffrey Tan[MSFT]
I have discussed this issue with the Vista compatibility team.
Based on the confirmation, if the app is already manifested for UAC it
should be opted out.

Thanks for the response.
My application is manifested for UAC, but that apparently doesn't stop
GetVersionEx from returning a fake version number.
Version number mangling can be seen with UAC-manifested executables that
1. Copy c:\windows\system32\cmd.exe to c:\testcmd.exe.
(Note: Be sure to put it in c:\, as files in c:\windows\system32
seem to be exempt from app compat.)
2. Right-click c:\testcmd.exe, click Properties, and on the
Compatibility tab, check "Run in compatibility mode". Click OK.
3. Double-click testcmd.exe.
Microsoft Windows [Version 5.1.2600]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
You can see the same thing if, instead of setting compatibility mode on
c:\testcmd.exe itself, you launch c:\testcmd.exe from another EXE that
is set to run in compatibility mode. (i.e., child processes appear to
inherit the compatibility mode setting from their parents.)
This same issue affects my app: It sees the OS version as "5.1" if it's
running in XP compatibility mode (which can be because it was launched
by another app running in XP compatibility mode). I want it to see "6.0"
all the time when running on Vista. Thus, I'm looking for a way to
obtain the true OS version, or a way to prevent Windows from running my
app in compatibility mode.

Post by Jeffrey Tan[MSFT]
You should switch to using an API like VerifyVersionInfo and
"Determine Windows Version and Edition"
http://codeguru.earthweb.com/cpp/w-p/system/systeminformation/print.php/c897
3__2/

I suppose in specific cases those might work (assuming they don't lie
about the OS version as well). However, I would still like to be able to
obtain the true version number for use in log files, etc.
--
Jordan Russell

[Jochen Kalmbach [MVP]]

Hi Jordan!

Post by Jordan Russell
2. Right-click c:\testcmd.exe, click Properties, and on the
Compatibility tab, check "Run in compatibility mode". Click OK.
3. Double-click testcmd.exe.

But this is a "permanent" setting and then it should run *always* in
this mode.

Post by Jordan Russell
You can see the same thing if, instead of setting compatibility mode on
c:\testcmd.exe itself, you launch c:\testcmd.exe from another EXE that
is set to run in compatibility mode. (i.e., child processes appear to
inherit the compatibility mode setting from their parents.)

That is interesting...
And indeed... this is exactly the case in vista...

Did the following Test:
#include <windows.h>
#include <tchar.h>
#include <conio.h>

int _tmain(int argc, _TCHAR* argv[])
{
// Try the old-style function:
OSVERSIONINFOEX vEx;
ZeroMemory(&vEx, sizeof(vEx));
vEx.dwOSVersionInfoSize = sizeof(vEx);
GetVersionEx((OSVERSIONINFO*) &vEx);

_tprintf(_T("dwMajorVersion: %d\n"), vEx.dwMajorVersion);
_tprintf(_T("dwMinorVersion: %d\n"), vEx.dwMinorVersion);

// Now try again with the "newer" function:
DWORDLONG dwlConditionMask = 0;
int op=VER_GREATER_EQUAL;
ZeroMemory(&vEx, sizeof(vEx));
vEx.dwOSVersionInfoSize = sizeof(vEx);
vEx.dwMajorVersion = 6;
vEx.dwMinorVersion = 0;
VER_SET_CONDITION(dwlConditionMask, VER_MAJORVERSION, op);
VER_SET_CONDITION(dwlConditionMask, VER_MINORVERSION, op);
BOOL bVistaOrGreater = VerifyVersionInfo(&vEx, VER_MAJORVERSION |
VER_MINORVERSION, dwlConditionMask);
_tprintf(_T("bVistaOrGreater: %d\n"), bVistaOrGreater);

_tprintf(_T("Press any key to continue..."));
_getch(); // wait for key...

#ifdef TESTAPP2
HINSTANCE hInst = ShellExecute(NULL, NULL, _T("myver.exe"), NULL,
NULL, SW_SHOW);
_tprintf(_T("hInst: %p\n"), hInst);
#endif
}

Compiled this source first into "AppCompat.exe" with TESTAPP2 defined!
Then compiled this source into "myver.exe" *without* TESTAPP2 defined!

Then changed the settings of "AppCompat.exe" to "Compatibility-Mode
(XP-SP2)".

Then started "AppCompat.exe". The output was the following:
dwMajorVersion: 5
dwMinorVersion: 1
bVistaOrGreater: 1
Press any key to continue...hInst: 0000002A

A second console-window appeared and the output there (from myver.exe) was:
dwMajorVersion: 5
dwMinorVersion: 1
bVistaOrGreater: 1
Press any key to continue...


So it seems that the app-compat-layer will be "inherited"!!!!


This test was done on "Vista-RTM-x64".
All processes were running as x86 apps (you cannot set app-compat on x64
apps ;) ).
I have currently no x86-Vista, to verify this on the "main" platform...



I also think it is somewhere documented... but I could not remember where...

Post by Jordan Russell
This same issue affects my app: It sees the OS version as "5.1" if it's
running in XP compatibility mode (which can be because it was launched
by another app running in XP compatibility mode).

Yes. This happens if the "parent-process" was running in app-compat-mode!

Post by Jordan Russell
I want it to see "6.0"
all the time when running on Vista. Thus, I'm looking for a way to
obtain the true OS version, or a way to prevent Windows from running my
app in compatibility mode.

Good question... one solution was provided by Skywing.

Post by Jordan Russell

Post by Jeffrey Tan[MSFT]
You should switch to using an API like VerifyVersionInfo and
"Determine Windows Version and Edition"
http://codeguru.earthweb.com/cpp/w-p/system/systeminformation/print.php/c897
3__2/

I suppose in specific cases those might work (assuming they don't lie
about the OS version as well).

It seems that "VerifyVersionInfo" is not affected by app-compat.

Post by Jordan Russell
However, I would still like to be able to obtain the true version number for use in log files, etc.

Yes... the best solution would be to disable the "inheritence" of
"app-compat"... still searching...

[Jochen Kalmbach [MVP]]

Post by Jochen Kalmbach [MVP]
This test was done on "Vista-RTM-x64".
All processes were running as x86 apps (you cannot set app-compat on x64
apps ;) ).
I have currently no x86-Vista, to verify this on the "main" platform...

The same behaviour can also be seen in XP (-SP2-x86). So I assume that
it will be the same in Vista-x86.

[Stefan Kuhr]

Hi Jochen,

Post by Jochen Kalmbach [MVP]

Post by Jochen Kalmbach [MVP]
This test was done on "Vista-RTM-x64".
All processes were running as x86 apps (you cannot set app-compat on
x64 apps ;) ).
I have currently no x86-Vista, to verify this on the "main" platform...

The same behaviour can also be seen in XP (-SP2-x86). So I assume that
it will be the same in Vista-x86.

It *is* the same on x86 Vista.

[Jordan Russell]

Post by Jochen Kalmbach [MVP]

Post by Jordan Russell
2. Right-click c:\testcmd.exe, click Properties, and on the
Compatibility tab, check "Run in compatibility mode". Click OK.
3. Double-click testcmd.exe.

But this is a "permanent" setting and then it should run *always* in
this mode.

It should be noted, though, that compatibility mode can become enabled
on an EXE without the user explicitly going in and checking that box.
For example, clicking "Reinstall using recommended settings" at a
Program Compatibility Assistant dialog enables XP compatibility mode for
all future invocations of the EXE:

http://blogs.msdn.com/astebner/archive/2007/05/08/2491743.aspx

Undoing this breakage requires manual effort on the part of end users.
Replacing the EXE with an updated version is not enough:

http://blogs.msdn.com/astebner/archive/2007/08/02/4195204.aspx

Post by Jochen Kalmbach [MVP]
It seems that "VerifyVersionInfo" is not affected by app-compat.

Yes, that does appear to be the case. Though I wonder: Is it by design,
or an inadvertent oversight? How do I know that a future appcompat
update for Vista won't "fix" VerifyVersionInfo to use a false version
number as well?