Compatibility and Interoperability Requirements

Compatibility and Interoperability Requirements
This module presents various gotchas associated with interop assemblies and other areas that would prevent operations on a 64-bit operating system. It outlines possible implications in the build process stemming from the need to sign files and drivers. It describes options for version checking and how to avoid the potential problem of checking only for version equality. It outlines the need to support concurrent user sessions and describes the circumstances that would cause drivers to load in safe mode. It describes anti-malicious software (“malware”) policies used to prevent certification of malicious software and spyware. After completing this module, students will be able to: Describe how to build software that passes the compatibility and interoperability test cases. Understand potential problems associated with 64-bit operation. Be aware of required changes to the build process. List options for version checking. Be aware of the problems associated with checking only for equality. Understand the problems associated with blocking multiple instances of the application. Be aware of the registry settings that would cause drivers and services to run in safe mode. Understand strategies for preventing certification of malicious software and spyware.

Agenda Compatibility and interoperability requirements
Support for x64 versions Signing files and drivers Version checking Support for concurrent user sessions Safe mode Support for anti-malware policies Compatibility and interoperability test cases This module includes the following topics and demonstrations: Compatibility and Interoperability Requirements. This topic summarizes logo requirements associated with compatibility and interoperability. Support for x64 Versions. Because many Microsoft Windows Vista users will be running x64 versions, it is very important that applications support this operating system. This topic describes how to ensure applications support x64 versions of Windows Vista. Signing Files and Drivers. Signing enables users to decide whether they want to trust an application and ensures files have not been tampered with. On 64-bit versions of the Windows Vista operating system, unsigned drivers will not be able to load. This topic describes the process of signing files and drivers and the potential impact on the build process. Version Checking. This topic covers the problems associated with checking only for equality when version checking. It outlines the options for checking the operating system version. Support for Concurrent User Sessions. Windows users should be able to run concurrent sessions, including user sessions created using Remote Desktop Connection, without conflict or disruption. This topic covers how to avoid blocking the application’s use in concurrent user sessions and Fast User Switching (FUS). Safe Mode. Drivers and services should not run in safe mode unless they are needed for basic operations of the system. This topic covers the registry settings associated with safe mode. Demonstration: Safe Mode Registry Settings. This demonstration shows the registry settings associated with loading drivers and services in safe mode. Support for Anti-Malware Policies. Applications that are considered malware or spyware will not gain logo certification. If the application is not malware or spyware, it should automatically pass this test case. Compatibility and Interoperability Test Cases. This topic summarizes the module by listing the test cases associated with compatibility and interoperability.

Compatibility and Interoperability Requirements
Support x64 Versions Sign files and drivers Perform version checking properly Support concurrent user sessions Avoid loading services and drivers in safe mode Follow anti-malware policies Support x64 Versions of Windows Vista. Many Windows Vista users will be running x64 versions of the operating system, so it is crucial for applications to be compatible with this version of the operating system. Sign files. Signing helps users decide whether they want to trust an application and assures users that files have not been tampered with. Sign drivers. On 64-bit versions of the Windows Vista operating system, unsigned drivers will not be able to load. Perform version checking properly. When Windows users upgrade their operating system, they should be able to continue using their current applications. Support concurrent user sessions. Windows users should be able to run concurrent sessions without conflict or disruption. Avoid loading services and drivers in safe mode. Drivers and services should not run in safe mode unless they are needed for basic operations of the system (for example, file system drivers) or for diagnostic and recovery purposes (for example, antivirus scanners). Follow anti-malware policies. Malicious software is a major concern for customers. When they buy software that carries the Windows Vista logo, they should have some assurance that it is free of malicious software.

Support for x64 versions Signing files and drivers Version checking Support for concurrent user sessions Safe mode Support for anti-malware policies Compatibility and interoperability test cases This module includes the following topics and demonstrations: Compatibility and interoperability requirements. This topic summarizes logo requirements associated with compatibility and interoperability. Support for x64 versions. Because many Microsoft Windows Vista users will be running x64 versions, it is very important that applications support this operating system. This topic describes how to ensure applications support x64 versions of Windows Vista. Signing files and drivers. Signing enables users to decide whether they want to trust an application and ensures files have not been tampered with. On 64-bit versions of the Windows Vista operating system, unsigned drivers will not be able to load. This topic describes the process of signing files and drivers and the potential impact on the build process. Version checking. This topic covers the problems associated with checking only for equality when version checking. It outlines the options for checking the operating system version. Support for concurrent user sessions. Windows users should be able to run concurrent sessions, including user sessions created using Remote Desktop Connection, without conflict or disruption. This topic covers how to avoid blocking the application’s use in concurrent user sessions and Fast User Switching (FUS). Safe mode. Drivers and services should not run in safe mode unless they are needed for basic operations of the system. This topic covers the registry settings associated with safe mode. Demonstration: Safe Mode Registry Settings. This demonstration shows the registry settings associated with loading drivers and services in safe mode. Support for anti-malware policies. Applications that are considered malware or spyware will not gain logo certification. If the application is not malware or spyware, it should automatically pass this test case. Compatibility and Interoperability Test Cases. This topic summarizes the module by listing the test cases associated with compatibility and interoperability.

Support for x64 Versions No 16-bit code or components
x64 versions of drivers Application setup detects and installs proper drivers and components WOW64—Not necessary to run application natively Acceptable to remove nonessential features 32- and 64-bit COM servers communicate with 64- and 32-bit clients Many Windows Vista users will be running x64 versions of the operating system, so it is crucial for applications to be compatible with this version of the operating system. To maintain compatibility with x64 versions of the Windows operating system, the following are necessary: Applications and their installers must not contain any 16-bit code or rely on any 16-bit component because 16-bit code will not run on 64-bit versions of the Windows Vista operating system. If an application is dependent on kernel-mode drivers for operation, x64 versions of these drivers must be available. The application setup must detect and install the proper drivers and components for the 64-bit Windows operating system. It is not necessary that the application run natively on x64 versions of the Windows operating system because Windows-on-Windows 64-bit (WOW64) allows 32-bit code to run on 64-bit versions of the Windows operating system. When an application installs on an x64 version of the Windows operating system, some features of the application can be removed as long as these features are not part of the application’s essential functionality. On 64-bit versions of the Windows operating system, an out-of-process 32-bit Component Object Model (COM) server can communicate with a 64-bit client, and an out-of-process 64-bit COM server can communicate with a 32-bit client.

WOW64 Windows-on-Windows 64-bit
Handles differences between 32-bit and 64-bit versions of the Windows operating system Capable of running 32-bit applications Included on all 64-bit versions of the Windows operating system WOW64 (Windows-on-Windows 64-bit) Basically, WOW64 is a layer of code that allows for 32-bit processes to run just as if they were running on a 32-bit system under a 32-bit operating system even though in reality they are running on a 64-bit operating system. WOW64 is a Microsoft operating system subsystem capable of running 32-bit applications and is included on all 64-bit versions of the Windows operating system—including Windows XP 64-bit Editions, Windows Server 2003 x64 Edition, and Windows Vista 64-bit Editions. WOW64 takes care of all the differences between 32-bit versions and 64-bit versions of the Windows operating system, particularly those involving structural changes to the operating system itself. The WOW64 emulator runs in user mode, provides an interface between the 32-bit version of Ntdll.dll and the kernel of the processor, and intercepts kernel calls.

Support for x64 versions Signing files and drivers Version checking Support for concurrent user sessions Safe mode Support for anti-malware policies Compatibility and interoperability test cases This module includes the following topics and demonstrations: Compatibility and interoperability Requirements. This topic summarizes logo requirements associated with compatibility and interoperability. Support for x64 versions. Because many Microsoft Windows Vista users will be running x64 versions, it is very important that applications support this operating system. This topic describes how to ensure applications support x64 versions of Windows Vista. Signing Files and Drivers. Signing enables users to decide whether they want to trust an application and ensures files have not been tampered with. On 64-bit versions of the Windows Vista operating system, unsigned drivers will not be able to load. This topic describes the process of signing files and drivers and the potential impact on the build process. Version Checking. This topic covers the problems associated with checking only for equality when version checking. It outlines the options for checking the operating system version. Support for Concurrent User Sessions. Windows users should be able to run concurrent sessions, including user sessions created using Remote Desktop Connection, without conflict or disruption. This topic covers how to avoid blocking the application’s use in concurrent user sessions and Fast User Switching (FUS). Safe Mode. Drivers and services should not run in safe mode unless they are needed for basic operations of the system. This topic covers the registry settings associated with safe mode. Demonstration: Safe Mode Registry Settings. This demonstration shows the registry settings associated with loading drivers and services in safe mode. Support for Anti-Malware Policies. Applications that are considered malware or spyware will not gain logo certification. If the application is not malware or spyware, it should automatically pass this test case. Compatibility and Interoperability Test Cases. This topic summarizes the module by listing the test cases associated with compatibility and interoperability.

Signing Files Ensures files have not been tampered with
All executable files must be signed with an Authenticode certificate Code-signing certificates are available from several vendors Use the SignTool in the Windows SDK to sign files Digital signatures enable administrators and users who install Windows-based software to know whether a legitimate publisher has provided the software package. Earlier versions of the Windows operating system use digital signatures to discourage users from installing download packages, executable files, and drivers from untrusted sources. In Windows Vista, new features take advantage of code-signing technologies, and new requirements for security in the operating system enforce the use of digital signatures for some kinds of code. Signing helps users decide whether they want to trust an application and assures users that files have not been tampered with. It also enables applications to run properly in locked-down environments. All executable files must be signed with a Microsoft Authenticode certificate. This includes files with the following extensions: .exe, .dll, .ocx, .sys, .cpl, .drv, and .scr. Code-signing certificates are available from several vendors. Microsoft maintains a list of trusted third-party commercial Certificate Authorities. These Certificate Authorities validate the identity and entitlement of an applicant and, as an output of this process, issue the applicant a digital certificate. Once the certificate is obtained, the certificate holder should sign files that require signing by using the SignTool that comes with the Windows software development kit (SDK).

Signing Drivers Malicious software drivers affect stability and security Driver binaries loaded at boot time contain embedded signatures Microsoft signature for kernel-mode drivers through WHQL or DRS program 64-bit versions of Windows Vista will not load unsigned drivers Administrator privilege is required to install unsigned kernel-mode components Poorly written drivers or malicious software drivers can negatively affect the stability and security of a system. Driver binaries that load at boot time must contain an embedded signature. Any kernel-mode drivers that are installed by the application must have a Microsoft signature obtained through the Windows Hardware Quality Labs (WHQL) or DRS (Driver Reliability Signature) program. On 64-bit versions of the Windows Vista operating system, unsigned drivers will not be able to load. Administrator privilege is required to install unsigned kernel-mode components, including device drivers, filter drivers, services, and so on. This rule applies to all development phases, including for prerelease product code and nonproduct code such as tests.

Creating Test Certificates
Need only one MakeCert test certificate per computer Certificate store added to Windows managed list Install in test computer’s Trusted Root Certification Authorities and Trusted Publishers certificate stores MakeCert –r –pe –ss TestCertStoreName –n “CN=CertName” CertFileName.cer A development and test team can create and install MakeCert test certificates on the computers that they use to develop, sign, and test the drivers. A developer needs to create only one MakeCert test certificate to sign driver packages on a development computer. To create a test certificate on a development computer, use the MakeCert command-line tool as follows: MakeCert -r -pe -ss TestCertStoreName -n "CN=CertName" CertFileName.cer The -r option specifies that the certificate is self-signed, that is, the certificate is a root certificate. The -pe option specifies that the private key that is associated with the certificate can be exported. The -ss TestCertStoreName option specifies the name of the certificate store that contains the test certificate. The -n "CN=CertName" option specifies a name for the certificate that can be used with the Sign tool command-line tool to identify the certificate. It is recommended that you use a certificate name that clearly identifies the certificate as a test certificate, for example, "WDK Driver Testing Cert—for in-house use only." The CertFilename.cer option supplies the file name that contains a copy of the test certificate. The certificate file is used to add the certificate to the Trusted Root Certificates Authorities and the Trusted Publishers certificate stores. The certificate store is added to the list of certificate stores that the Windows operating system manages for the user account on the development computer on which the certificate store was created. On a test computer that is used to install a test-signed driver package, the corresponding MakeCert test certificate should be installed in the computer’s Trusted Root Certification Authorities certificate store and the Trusted Publishers certificate store. This is necessary for Setup to treat the driver package as signed and to avoid Setup displaying a driver signing dialog box that informs the tester that the publisher is not trusted.

Delay Signing Developers require public key
Defer signing until shipping Use delayed signing at build time Reserves space in PE for strong name signature An organization can have a closely guarded key pair to which developers do not have access on a daily basis. The public key is often available, but access to the private key is restricted to only a few individuals. When developing assemblies with strong names, each assembly that references the strong-named target assembly contains the token of the public key used to give the target assembly a strong name. This requires that the public key be available during the development process. Just before shipping, you submit the assembly to your organization’s signing authority for the actual strong name signing using the –R option with the Strong Name tool. The following example signs an assembly called myAssembly.dll with a strong name using the sgKey.snk key pair. sn -R myAssembly.dll sgKey.snk You can use delayed or partial signing at build time to reserve space in the portable executable (PE) file for the strong name signature, but defer the actual signing until some later stage (typically just before shipping the assembly).

Delay Signing Process Obtain .snk file
Created using sn.exe Annotate with custom attributes: AssemblyKeyFileAttribute AssemblyDelaySignAttribute Turn off signature verification [assembly:AssemblyKeyFileAttribute("myKey.snk")] [assembly:AssemblyDelaySignAttribute(true)] The following steps outline the process to delay signing an assembly: Obtain the public key portion of the key pair from the organization that will eventually do the signing. Typically, this key is in the form of an .snk file, which can be created using the Strong Name tool (sn.exe) provided by the Microsoft .NET Framework SDK. Annotate the source code for the assembly with two custom attributes from System.Reflection: AssemblyKeyFileAttribute, which passes the name of the file containing the public key as a parameter to its constructor. AssemblyDelaySignAttribute, which indicates that delay signing is being used by passing true as a parameter to its constructor. For example: [Visual Basic] <Assembly:AssemblyKeyFileAttribute("myKey.snk")> <Assembly:AssemblyDelaySignAttribute(true)> [C#] [assembly:AssemblyKeyFileAttribute("myKey.snk")] [assembly:AssemblyDelaySignAttribute(true)] The compiler inserts the public key into the assembly manifest and reserves space in the PE file for the full strong name signature. The real public key must be stored while the assembly is built so that other assemblies that reference this assembly can obtain the key to store in their own assembly reference. Because the assembly does not have a valid strong name signature, the verification of that signature must be turned off. You can do this by using the –Vr option with the Strong Name tool. The following example turns off verification for an assembly called myAssembly.dll. sn –Vr myAssembly.dll CAUTION Use the –Vr option only during development. Adding an assembly to the skip verification list creates a security vulnerability. A malicious assembly could use the fully specified assembly name (assembly name, version, culture, and public key token) of the assembly added to the skip verification list to fake its identity. This would allow the malicious assembly to also skip verification.

Version Checking Allows application to be used in future versions
Check for ≥ desired version number Do not check CurrentVersion in registry If EULA prohibits use on future operating systems, fail gracefully GetVersionEx Version-checking API Check for capabilities rather than version Windows build team recommendation VerifyVersionInfo Environment.Version property When Windows users upgrade their operating system, they should not be prevented from using their current applications simply because the operating system version has been upgraded. They must not read the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion registry key for the operating system version. If the End User License Agreement (EULA) prohibits use on future operating systems and the application is supposed to fail, it must do so gracefully by sending a message to the user and writing a message to the Windows NT event log. Applications must use the version-checking application programming interfaces (APIs) (GetVersionEx) to check the operating system version. When using the GetVersionEx function to determine whether an application is running on a particular version of the operating system, check for version numbers that are greater than or equal to the desired version numbers. This ensures that the test succeeds for later versions of the operating system. The Windows build team recommends checking for capabilities (by calling GetProcAddress) rather than checking for version. This option only works for Win32 functions - It won’t work for window messages, for example. Another approach is to call VerifyVersionInfo, which lets you specify flags that define your requirements – and then the function will test for them. This is not very easy to call from managed code. From managed code you can use the Environment.Version property.

Fast User Switching Multiple users can log on
Switches quickly between open accounts Does not change application state Uses Terminal Services technology In previous versions of the Windows operating system (prior to Windows XP), one user is required to log off of his or her account before another could log on. Windows Vista allows more than one person to be logged on to a computer at the same time and allows users to switch quickly between accounts. Windows users should be able to run concurrent sessions without conflict or disruption. Switching to another account does not change the state of applications currently running. When a user switches back to his or her account, the applications will still be running and the network connections will have been preserved. Fast User Switching uses Terminal Services technology and is therefore compatible with most earlier Microsoft Win32 applications.

FUS Application Best Practices (1)
Test application under FUS Implement true profile separation Register for notification of a user switch Be aware of other running instances It is important to test your application under Fast User Switching to ensure that it behaves as users would expect. Implement true profile separation. The system provides an underlying infrastructure that supports separation of user data, user settings, and computer settings. The best way to implement this is by using Windows Installer to manage the installation and setup of your application. For example, the installer sets the AppDataFolder property to the full path to the Application Data folder for the current user and sets the LocalAppDataFolder property to the full path to the directory for data that should not be available to the user on other computers, such as temporary files. You can also use the SHGetSpecialFolderLocation or SHGetSpecialFolderPath function with CSIDL_APPDATA or CSIDL_LOCAL_APPDATA to locate these folders. Register for notification of a user switch. Typically, an application does not need to be notified when the switch occurs. However, if your application must be notified of a session change, register the application to receive a WM_WTSSESSION_CHANGE message. This message is sent only to applications that have registered to receive this message by calling WTSRegisterSessionNotification. Be aware of other instances of your application that might be running. If your application attempts to download an update of itself from the Internet, the update might conflict with another user who is running your application in a different session. The update can fail or disrupt other running instances of the application. Your application should be designed to signal all running instances of the application to save data and exit before starting a dynamic update.

FUS Application Best Practices (2)
Applications must allow multiple sessions unless prevented by architecture Includes Remote Desktop Connection sessions If not supported, alert user and write to Windows NT event log 3D graphics applications Not required to work over RDC User alerted on failure Sound in another user session inaudible in current session Applications must allow multiple sessions unless they are prevented by architecture issues. If an application does not support running in multiple user logon sessions, it must alert the user of this fact before failing and write a message to the Windows NT event log. This includes user sessions created using Remote Desktop Connection. Additionally, applications that rely on 3D graphics are not required to work over a Remote Desktop Connection, but the user must be alerted upon failure. Sound from an application in one user session must not be heard when another user is active in the current session.

Safe Mode Enables users to diagnose and repair Windows configuration
Drivers and services should not run unless needed for: Basic operations Diagnostic purposes Recovery purposes Safe mode is designed to enable users to diagnose and repair their Windows configurations. Drivers and services should not run in safe mode unless they are needed for basic operations of the system (for example, file system drivers) or for diagnostic and recovery purposes (for example, antivirus scanners).

Safe Mode Registry Keys
If set, drivers and services run in safe mode without any errors Minimal and network registry keys Any use of these keys must be listed in the logo documentation HKLM\System\CurrentControlSet\ Control\SafeBoot\Minimal Control\SafeBoot\Network If any of the following subkeys are set, the drivers and services must run in safe mode without any errors: HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal HKLM/System/CurrentControlSet/Control/SafeBoot/Network If any of these keys are set, they must be listed in the logo documentation.

Safe Mode Registry Settings
This demonstration shows starting Windows Vista in safe mode and the associated registry keys.

Anti-Malware Applications MUST meet privacy guidelines
You risk losing logo certification if your application is identified as malware or spyware Anti-Spyware Coalition 40-plus member organizations Includes Microsoft Malicious software is a major concern for customers. When they buy software that carries the Windows Vista logo, they should have some assurance that the software is free of malicious software. All applications must meet the privacy guidelines put forth by the Anti-Spyware Coalition (ASC). The ASC is a group dedicated to building a consensus about definitions and best practices in the debate surrounding spyware and other potentially unwanted technologies. Composed of anti-spyware software companies, academics, and consumer groups, the ASC seeks to bring together a diverse array of perspectives on the problem of controlling spyware and other potentially unwanted technologies. Applications that are considered malicious software or spyware are subject to losing their logo certification. Current ASC members include the following: Aluria Software an Earthlink company, AhnLab, AOL, Berkman Center for Internet and Society, Harvard Law School, Bit9, Blue Coat Systems, Canadian Coalition Against Unsolicited Commercial , US Coalition Against Unsolicited Commercial , Canadian Internet Policy and Public Interest Clinic, Center for Democracy and Technology, CNET Download.com, Computer Associates, Cyber Security Industry Alliance, Dell, Inc., Eset, F-Secure Corporation, Grisoft, HP, ICSA Labs, Internet Education Foundation, ISS, Lavasoft, McAfee Inc., Mi5 Networks, Microsoft, National Center for Victims of Crime, National Cyber Security Alliance, National Network to End Domestic Violence, Panda Software, PC Tools, Radialpoint, Safer-Networking Ltd., Samuelson Law, Technology and Public Policy Clinic at Boalt Hall, UC Berkeley School of Law, Sana Security, Sophos, SurfControl, Symantec, Tenebril, Trend Micro, Webroot Software, Websense, and Yahoo! Inc.

Compatibility and Interoperability Test Cases (1)
Verify application installer: Does not have a 16-bit installer Does not use or rely on 16-bit code or components Does not attempt to install any non-64-bit drivers on x64 versions of the Windows operating system regardless of whether application is a Win32 application or is native to 64-bit Verify the application installer does not have a 16-bit installer, does not use or rely on 16-bit code or components, and does not attempt to install any non-64-bit drivers on x64 versions of the Windows operating system regardless of whether the application is a Win32 application or is native to 64-bit. The application must be supported on the x64 version of the Windows operating system regardless of whether the application is native to 64-bit or is a Win32 application to pass this test case. Applications that install using 16-bit code will not be able to complete the install on 64-bit versions of the Windows operating system and will indicate this by displaying an error message. Applications that install drivers dependent on 64-bit versions of Windows Vista must be 64-bit to pass this test case. WOW64 allows Win32 applications to run on 64-bit versions of the Windows operating system and must be able to run properly without data loss to pass this test case.

Verify executable files and other files installed by the application are signed Verify all kernel-mode drivers installed by the application are signed Verify application properly checks for operating system version Verify application launches and runs properly using Fast User Switching Verify executable files and other files installed by the application are signed. Each application executable file with an extension of .exe, .dll, .ocx, .sys, .cpl, .drv, or .scr must contain a valid signature to pass this test case. Each application executable file must not return any errors as a result of the signature to pass this test case. Verify all kernel-mode drivers installed by the application are signed. (Req:1.4) All kernel-mode drivers installed by the application must contain a valid Microsoft signature and should not cause the Windows operating system to alert the user about installing an unsigned driver through a pop-up message. In a WHQL signature, the command window output under the Signing Certificate Chain must have Microsoft Windows Hardware Compatibility Publisher in the Issued to: line and Microsoft Windows Hardware Compatibility PCA in the Issued by: line. That means that the kernel-mode driver has passed the WHQL certification and has obtained a valid Microsoft signature from the WHQL program. The Certification Path will also have these names under the signature Root Authority. In a DRS signature, the command window output under Signing Certificate Chain must have Microsoft Windows Driver Reliability Publisher in the Issued to: line and Microsoft Windows Driver Reliability PCA in the Issued by: line. That means that the kernel-mode driver has passed the Driver Reliability Certification and has obtained a valid Microsoft signature from the Driver Reliability program. The Certification Path will also have these names under the signature Root Authority. Verify application properly checks for operating system version. The application installer and all executable files installed by the application must use the GetVersion or GetVersionEx API when checking for the version of the Windows operating system to pass this test case. If the application is supposed to fail because it is incompatible with Windows Vista, it must do so gracefully by displaying a pop-up message informing the user of the failure and writing a message to the Windows NT event log. As a result, the application cannot be certified for Windows Vista. If the application is supposed to fail because the version is later than the Windows Vista version, it must do so gracefully by displaying a pop-up message informing the user of the failure and writing a message to the Windows NT event log. The AppVerifier logs might show HighVersionLie, but contain no data. This indicates that the application did not attempt to check the operating system version and therefore will also pass this test case. Verify application launches and runs properly using Fast User Switching. The application must support Fast User Switching to pass this test case. The application must be able to launch and perform a normal operation beyond using the Fast User Switching method to pass this test case. If application does not support concurrent user sessions, it must display a message indicating this to the user and write a message to the Windows NT event log to pass this test case. If the application uses sounds, the sound in one user’s session must not be heard in another user’s session to pass this test case.

Verify application launches and run properly using Remote Desktop Verify drivers and services start in safe mode Verify the application launches and runs properly using Remote Desktop. (Req.1.8) The application must not crash or lose its state when accessed through a Remote Desktop connection to pass this test case. If the application does not support Remote Desktop, it must display a message indicating this to the user and write a message to the Windows NT event log to pass this test case. Verify drivers and services start in safe mode. All drivers and services that were written to the safe boot registry keys by the application are started when the machine is running in safe mode, and this can be verified in Windows Task Manager. If the application wrote any drivers or services to either safe boot registry key, those drivers and services must run without error and the application must be able to perform normal operations beyond when the machine is running in safe mode to pass this test case. The safe boot registry keys are the following: HKLM/System/CurrentControlSet/Control/SafeBoot/Minimal HKLM/System/CurrentControlSet/Control/SafeBoot/Network If the application writes to either safe boot registry key, documentation must be provided to Microsoft detailing why the application must run in safe mode and the application must apply for a waiver from Microsoft to pass this test case.

Summary Compatibility and interoperability requirements
Support for x64 versions Signing files and drivers Version checking Support for concurrent user sessions Safe mode Support for anti-malware policies Compatibility and interoperability test cases Compatibility and Interoperability Requirements. This topic summarized logo requirements associated with compatibility and interoperability. Support for x64 Versions. Because many Windows Vista users will be running x64 versions, it is very important that applications support this operating system. This topic described how to ensure applications support x64 versions of the Windows Vista operating system. Signing Files and Drivers. Signing enables users to decide whether they want to trust an application and ensures files have not been tampered with. On 64-bit versions of the Windows Vista operating system, unsigned drivers will not be able to load. This topic described the process of signing files and drivers and the potential impact this has on the build process. Version Checking. This topic covered the problems associated with checking only for equality when checking versions. It outlined the options for checking the operating system version. Support for Concurrent User Sessions. Windows users should be able to run concurrent sessions, including user sessions created using Remote Desktop Connection, without conflict or disruption. This topic covered how to avoid blocking the application’s use in concurrent user sessions and use of Fast User Switching (FUS). Safe Mode. Drivers and services should not run in safe mode unless they are needed for basic operations of the system. This topic covered the registry settings associated with safe mode. Support for Anti-Malware Policies. Applications that are considered malicious software or spyware will not gain logo certification. If the application is not malicious software or spyware, it should automatically pass this test case. Compatibility and Interoperability Test Cases. This topic summarized the module by listing the test cases associated with compatibility and interoperability.

Additional Resources WOW64 implementation details /default.asp?url=/library /en-us/win64/win64 /wow64_implementation_details.asp Delay signing /2004/03/17/91575.aspx Fast User Switching /en-us Anti-malware

Compatibility and Interoperability Requirements

Similar presentations

Presentation on theme: "Compatibility and Interoperability Requirements"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Compatibility and Interoperability Requirements

Similar presentations

Presentation on theme: "Compatibility and Interoperability Requirements"— Presentation transcript:

Similar presentations

About project

Feedback