Windows 7 Application Compatibility Manifest Will Impact Windows 8 at CodenameWindows

And all Windows releases for that matter.

Here is a sample offered by Chris Jackson, an Architect and the Technical Lead for the Windows Application Experience SWAT Team:

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestVersion=”1.0″>
<compatibility xmlns=”urn:schemas-microsoft-com:compatibility.v1″>
<application>
<!–Windows 7–>
<supportedOS Id=”{35138b9a-5d96-4fbd-8e2d-a2440225f93a}”/>
<!–Windows Vista–>
<supportedOS Id=”{e2011457-1546-43c5-a5fe-008deee3d3f0}”/>
</application>
</compatibility>
</assembly>

Jackson’s explanation:

“The argument for GUIDs (Globally Unique Identifier): Nobody knows what the GUID for Windows 8 is going to be yet. Not even us. So, by using GUIDs, we prevent somebody from claiming compatibility with an operating system they can’t possibly have tested with. (Odd that we’d be so against such a thing in one group, while the IE team gives you the X-UA-Compatible option of edge to do exactly that.)The argument against GUIDs: You’re punishing the good guys in order to prevent the bad guys from shooting themselves in the foot. If I test something on Windows 8, and add its GUID to my manifest, I’m going to get both the Windows 8 and Windows 7 fixes (since the OS will simply look at the highest version and apply all previous fixes). But, if I *only* put in the Windows 8 GUID, on Windows 7, I won’t recognize the Windows 8 GUID (since it doesn’t exist yet), and not only will I not give it the Windows 8 fixes, I won’t give it the Windows 7 fixes either. And, if the only fixes I actually needed were the Windows 7 ones, I just broke the app.”

Application Manifest (source MSDN)

[This documentation is preliminary and is subject to change.]

Affected Platforms

Clients – Windows 7

Servers – Windows Server 2008 R2

Feature Impact

Severity – Low

Frequency – Low

Description

Windows 7 introduces a new section in the application manifest called “Compatibility.” This section helps Windows determine the versions of Windows that an application was designed to target, and enables Windows to provide the behavior that the application expects based on the version of Windows that the application targeted.

The Compatibility section allows Windows to provide new behavior to new developer-created software while maintaining the compatibility for existing software. This section also helps 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.

Manifestation of Change

Applications without a Compatibility section in their manifest will receive Windows Vista behavior by default on Windows 7 and future Windows versions. Note that Windows XP and Windows Vista ignore this manifest section and it has no impact on them.

The following Windows components provide divergent behavior based on the Compatibility section in Windows 7:

RPC Default Thread Pool

Windows 7: To improve scalability and reduce thread counts, RPC switched to the NT thread pool (default pool). For Windows Vista, RPC used a private thread pool.
- For binaries compiled for Win7 the default pool is used
- If I_RpcMgmtEnableDedicatedThreadPool is called before any RPC API is called, the private thread pool is used (Vista behavior)
- If I_RpcMgmtEnableDedicatedThreadPool is called after an RPC call, the default pool is used, I_RpcMgmtEnableDedicatedThreadPool returns the error 1764, and the requested operation is not supported
Windows Vista (default): For binaries compiled for Windows Vista and below, the private pool is used.

DirectDraw Lock

Windows 7: Applications manifested for Windows 7 cannot call Lock API in DDRAW to lock the primary Desktop video buffer. Doing so will result in error, and NULL pointer for the primary will be returned. This behavior is enforced even if Desktop Window Manager Composition is not turned on. Windows 7 compatible applications must not lock the primary video buffer to render.
Windows Vista (default): Applications will be able to acquire a lock on the primary video buffer as legacy applications depend on this behavior. Running the application turns off Desktop Window Manager.

DirectDraw Bit Block Transfer (Blt) to Primary without Clipping Window

Windows 7: Applications manifested for Windows 7 are prevented from performing Blt?s to the primary Desktop video buffer without a clipping window. Doing so will result in error and the Blt area will not be rendered. Windows enforces this behavior even if you do not turn on Desktop Window Manager Composition. Windows 7 compatible applications must Blt to a clipping window.
Windows Vista (default): Applications must be able to Blt to the primary without a clipping window as legacy applications depend on this behavior. Running this application turns off the Desktop Window Manager.

GetOverlappedResult API

Windows 7: Resolves a race condition where a multi-threaded app using GetOverlappedResult can return without resetting the event in the overlapped structure, causing the next call to this function to return prematurely.
Windows Vista (default): Provides the behavior with the race condition that applications may have a dependency on. Applications wishing to avoid this race prior to the Windows 7 behavior should wait on the overlapped event and when signaled, call GetOverlappedResult with bWait == FALSE.

CreateFileEx API

Windows 7: Mitigates a potential denial of service by modifying the behavior of the API so that any requests to open the file for exclusive read by a user who does not have write permission to a file will fail such that they cannot block the file from being opened by those with proper access.
Windows Vista (default): Allows users requesting an exclusive read open to successfully open the file (though the open is still downgraded to a shared read open).

Program Compatibility Assistant (PCA)

Windows 7: Applications with Compatibility section will not get the PCA mitigation.
Windows Vista (default): Applications that fail to install properly or crash during runtime under some specific circumstances will get the PCA mitigation. For more details, see the reference section.

Leveraging Feature Capabilities

Update the application manifest with the latest Compatibility information for operating system support. The section describes the additions to the manifest:

Name Space: Compatibility.v1 (xmlns=”urn:schemas-microsoft-com:compatibility.v1″>)

Section Name: Compatibility (new section)

SupportedOS: GUID of supported operating system. The GUIDs that map to the supported operating systems are:

{e2011457-1546-43c5-a5fe-008deee3d3f0} for Windows Vista: This is the default value for the switchback context.
{35138b9a-5d96-4fbd-8e2d-a2440225f93a} for Windows 7: Applications that set this value in the application manifest get the Windows 7 behavior.

Microsoft will generate and post GUIDs for future Windows versions as needed.

An XML example of an updated manifest:

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>

<supportedOS Id=”{35138b9a-5d96-4fbd-8e2d-a2440225f93a}”/

</application>

</compatibility>

Compatibility, Performance, Reliability, and Usability Testing

Test the application with the new Compatibility section and SupportedOS={7?} to ensure that the application works properly using the latest Windows 7 components
Test the application with the new Compatibility section and SupportedOS={6?} to ensure that the application works properly using the legacy behavior for certain Windows 7 components
Test the application without the new Compatibility section to ensure that the application works properly using the legacy behavior for certain Windows 7 components

CodenameWindows