This is still the same Application Manifest that you store in your Win32 Resource or put next to your executable (i.e. "MyExecutable.exe.manifest" ).
Under Windows XP, this manifest allowed you to create Isolated Applications and Side-by-side Assemblies.
Under Windows Vista, we added the DPI Awareness and execution level for your application.
Under Windows 7, we introduced a new section called compatibility.
If it’s not present, your application will get the Windows Vista behavior by default on Windows 7 and future Windows versions. This new section allows us:
1. To provide new behavior to new developer-created software while maintaining the compatibility for existing software.
2. To help Windows deliver greater compatibility in future versions of Windows as well.For example, an application declaring support only for Windows 7 in the Compatibility section will continue to receive Windows 7 behavior in future version of Windows.
So the question is what’s the Windows Vista behavior? In my personal order of preference:
1. Program Compatibility Assistant (PCA)
2. GetOverlappedResult API
3. RPC Default Thread Pool
4. DirectDraw Lock
5. DirectDraw Bit Block Transfer (Blt) to Primary without Clipping Window
Here is an example using the corresponding pre-defines GUIDs:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<!--The ID below indicates application support for Windows Vista -->
<!--The ID below indicates application support for Windows 7 -->
Chris Jackson goes into a bit more details here and voici a bit more resources:
- Application Manifest in the Windows 7 and Windows Server 2008 R2 Application Quality Cookbook
- The still obscure (to me) activation context stuff: the QueryActCtxW Function and COMPATIBILITY_CONTEXT_ELEMENT Structure
Y colorín colorado, este cuento se ha acabado...