This blog post discusses Application Manifest elements for use in Win32 desktop applications. This is not about the App package manifest (aka AppX) used for Windows Store apps for Windows 8.x.

User Account Control

Back when Windows Vista launched and the User Account Control feature was first introduced, there was one key recommendation for game developer writing PC games: your game should not require administrator rights to run, and you should add the proper embedded manifest to the game EXE so Windows Vista could tell the game was updated for the new OS. With Visual Studio 2005, this was done by turning on some settings for the Linker (Generate Manifest File: Yes) and Manifest Tool (Embed Manifest: Yes) and then setting the “Additional Manifest Files” field to point to a text file that contained:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="asInvoker" uiAccess="false" />
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>

With Visual Studio 2008 and later, the project settings dialog offered direct support for this under Linker \ Manifest File – “Enable User Account Control (UAC)” and “UAC Execution Level”. This guidance still fully applies to Windows 7, Windows 8 and Windows 8.1. See User Account Control for Game Developers for more details on UAC and related implications. 

High-DPI

Windows Vista also introduced another feature, “High-DPI” which scaled the UI by a factor of 125% or 150% but was off by default. With Windows 7 this was enabled by default depending on the EDID native DPI information so the recommendation is for all Direct3D full-screen applications to declare themselves “High-DPI Aware”. Again, this is done via another manifest element. With Visual Studio 2005 and VS 2008, you add an “Additional Manifest Files” file reference to a text file containing:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

With Visual Studio 2010 and 2012, the project settings dialog offers the choice of “Enable DPI Awareness” set to “No” or “Yes”. See Writing High-DPI Win32 applications for more information.

Note the value in the <dpiAware> element is not case-sensitive, so you'll see it as both “true” and “True” in articles and samples.

Program Compatibility Assistant (PCA)

With Windows Vista, just having the UAC elements was enough to know that the application had been updated for Windows Vista. If no UAC manifest element was found, Windows Vista enabled the Program Compatibly Assistant (PCA) which could check for common failures and resolve them.

Windows 7 needed a new way to detect if the EXE really understood Windows 7 to avoid any use of the PCA, and UAC manifest elements alone wasn't sufficient. The solution was... (drum roll, please): more manifest elements! You again add an “Additional Manifest Files” file reference to a text file containing:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!-- Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
</application>
</compatibility>
</assembly>

Windows 8 also used the same mechanism with a new GUID to indicate Windows 8 support.

<!-- Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>

For most programs, the PCA behavior impact wasn't really noticeable, so the <compatibility> section was mostly ignored by developers. This, by the way, is what determines the column “Operating System Context” in the Windows 7 or Windows 8 Resource Monitor (resmon) which defaults to “Windows Vista” if there's no <compatibly> manifest elements. On Windows 8.x, you can also see “Operating System Context” as a column in the Task Manager (taskmgr).

Windows 8.1

Windows 8.1 has two important changes to this guidance. First, without the Windows 8.1 GUID in the <compatibility> section, GetVersion(Ex) APIs will always return “6.2” and not “6.3”. The default behavior improves appcompat for the vast majority of applications, but it could cause problems for custom OS-version telemetry, support tools, and potentially 3rd party DRM solutions. Adding the latest GUID to the manifest causes the process to get “6.3” when running on Windows 8.1:

<!-- Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>

See Windows 8.1 Preview and Windows Server 2012 R2 Preview AppCompat Cookbook for more details, as well as Certification requirements for Windows desktop apps. As I've recommended in the past, you really shouldn't be using GetVersion(Ex) APIs at all except perhaps in very specialized cases, and there are better ways to handle 'minimum supported OS' checks (See What's in a version number?)--the Windows 8.1 SDK also offers a set of helpers in VersionHelpers.h that are useful for such checks.

Windows 8.1 also includes enhancements to High-DPI support including per-monitor scaling, 200% scaling, and improved UI behavior. This has necessitated two additional settings for the <dpiaware> manifest value: “Per Monitor” means the application is Per-Monitor DPI-Aware on Windows 8.1. There is also a “True/PM” setting which is both “Per Monitor DPI-Aware” on Windows 8.1, and “System DPI-Aware” on Windows Vista / Windows 7 / Windows 8-- Per Monitor” by itself is interpreted the same as setting “false” down-level. The recommended High-DPI manifest elements for Direct3D full-screen applications is now:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>True/PM</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

Visual Studio 2010 and 2012 do not offer the new “Per Monitor” or “True/PM” settings, so you will need to go back to using “Additional Manifest Files” and set the “Enable DPI Awareness” project setting to “No”.

See Writing DPI-Aware Desktop Applications in Windows 8.1 Preview.

Some examples of what can go wrong for a game that fails to use the proper High-DPI manifest setting are covered by KB 2908279 and KB 2907016.

Related: Desktop Games on Windows 8.x

Certification requirements for Windows desktop apps: The WACK 3.0 test will generate warnings if your application is missing any of these manifest elements.

Manifest Tool Note: Older versions of MT.EXE (including the one that comes with VS 2010 and the Windows 7.0 SDK) will generate a harmless warning for the <compatibility> section. This can be resolved by updating to a newer version of the Manifest Tool by copying MT.EXE out of the Windows 7.1 SDK, Windows 8.0 SDK, or Windows 8.1 SDK into a directory on your project's $(ExecutablePath). This issue does not affect VS 2012 or VS 2013.