The Certified for Microsoft Windows Logo identifies products that have been verified through independent testing to comply with the Application Specification for Windows. This specification was developed by Microsoft in cooperation with customers and other developers to provide a road map for building reliable and manageable applications. Software vendors who comply with the specification qualify for the Certified for Microsoft Windows logo and then license the logo for use on their product packaging, advertising, collateral, and other marketing materials.
For more information about Windows Vista, Windows XP, and Windows Server 2008 certification for your applications, see the Microsoft Partner Program.
For more information about the Windows Server 2003 and Windows 2000 certification for your applications, see http://msdn.microsoft.com/certification.
If you are authoring an installation package for your application, you may take advantage of the capabilities of the Microsoft Windows Installer to help satisfy several of the requirements for certification. The following table provides links to information in Windows Installer documentation pertinent for some of the certification requirements. Note that the not every requirement for certification discussed in the Application Specification is dependent upon Windows Installer.
| Requirement for Certification | See the following sections |
|---|---|
| 1.1
Application should perform primary functionality and maintain stability. |
If you provide an installation package, your application can use the installer service available on all 32-bit Windows platforms. Using the Installer can improve the functionality and stability of your application. See Resiliency |
| 1.3
Application should support Long File Names and UNC paths |
The installer supports installing to and from both UNC and drive network and always uses the long file names provided in your package except if the SHORTFILENAMES Property is set or if the target volume does not support long file names. See Filename, File Table, Directory Table, SHORTFILENAMES Property. |
| 1.5
The application should not read from or write to Win.ini, System.ini, Autoexec.bat or Config.sys. |
Your installation program should add entries to the registry not to the Win.ini, System.ini, Autoexec.bat or Config.sys. Windows Installer supports informational keys in the registry. When your application uses the installer, these registry keys become available as installer properties. You can author the package for your application such that it is easy to check and set the values of these keys.
If your application uses information that you do not want to put in the registry, create a private initialization file and place it in the directory with the application's executable files. You can easily manage the installation of a private .ini file, as well as add or remove information from existing .ini files, by using Windows Installer to install your application. See Modifying the Registry, Registry Tables Group, Registry Table, RemoveRegistry Table, WriteRegistryValues Action, RemoveRegistryValues Action, Uninstall Registry Key, Properties, File Table, Directory Table, Using the Directory Table, IniFile Table, RemoveIniFile Table, IniLocator Table, WriteIniValues Action , RemoveIniValues Action, RemoveIniFile Table. |
| 1.7
The application should perform Windows version checking correctly. |
When you prepare an installation package for your application, you must include information about the product's operating system version requirements. On initialization, the installer automatically sets certain properties to the version of the current operating system. Your setup program can use these installer properties to provide easy version checking. See Properties, Version9X Property, VersionDatabase Property, VersionNT Property, WindowsBuild Property, ProductCode Property, ProductName Property, ProductVersion Property, Summary Information Stream, Revision Number Summary Property. |
| 2.1
The application should install using a Windows Installer package that passes validation testing. |
You can check that your installation package passes validation testing by using a specific set of validation rules known as
Internal Consistency Evaluators - ICEs. These ICEs are contained in the file Logo.cub. To qualify for certification, an installation package must not produce any errors when validated using these rules. Warnings are acceptable, but generally should be corrected.
The Windows Installer SDK includes the Logo.cub, Darice.cub, and Mergemod.cub files. The ICEs in the Logo.cub file are included in the Darice.cub file. If your package passes validation using Darice.cub, it will pass with Logo.cub. For more information, see Package Validation. |
| 2.2
The installation package used to install the application should follow the rules for creating components. |
An installer component is a part of an application that is always installed or removed as one piece. There is a set of rules to help you decide how best to divide your application into components. If the components in your installation package are correctly defined, the installer can install and remove them safely. See Organizing Applications into Components, Components and Features, Changing the Component Code, What happens if the component rules are broken?, Working with Features and Components, Component Table. |
| 2.3
The application's installation package should identify shared components. |
If you provide an installation package that correctly organizes your application into components, and set msidbComponentAttributesSharedDllRefCount in the Component table, Windows Installer can track shared components using the reference count in the shared DLL registry of the component's key file. If you do not use the installer, then your application must keep track of its use of shared DLLs by incrementing a usage counter for the DLL in the SharedDLLs registry key.
For more information, see Directory Table, Using the Directory Table, Component Table. For the discussion of the SharedDllRefCount bit, see Component Table, Organizing Applications into Components. |
| 2.4
The application should install to the Program Files folder by default. |
On initialization, the installer sets a property to the full path of the Program Files folder. When you prepare the installation package you can specify that the installer install your application to this folder by default. If you also include a UI in your package, the installer can provide users with an option to select another installation location. For more information, see Directory Table, Using the Directory Table, TARGETDIR Property, MsiSetTargetPath, Properties, ProgramFilesFolder Property. |
| 2.5
The application should support Add/Remove Program Files properly. |
You can supply all the information that is needed by Add/Remove Programs in the Control Panel by setting the values of certain installer properties in your application's Windows Installer package. Setting these properties automatically writes the corresponding values into the registry. See Properties, Required Properties, ProductName Property, ARPINSTALLLOCATION Property, Manufacturer Property, ProductVersion Property. |
| 2.6
The application should ensure that Windows Installer package supports advertising. |
Support advertising by organizing your application for advertising and by including all the information needed for advertisement in the application's Windows Installer package. For more information, see Advertisement, Installation-On-Demand, Publishing Products, Features, and Components, Platform Support of Advertisement, Components and Features, Suggested AdvtExecuteSequence, Suggested AdvtUISequence, Advertise Property, Advertise Action, PublishProduct Action, Feature Table, Shortcut Table, Class Table, Extension Table, Icon Table, MIME Table, ProgId Table, TypeLib Table, Verb Table, MsiConfigureFeature, MsiConfigureProduct. |
| 2.7
The application's installation package should ensure correct uninstall support. |
If you use the installer to install your application, you do not need to create a separate uninstaller. You can author an installation package that enables the installer to install, uninstall, and repair your application. See Overview of Windows Installer, Organizing Applications into Components, Standard Actions, About Standard Actions, Using Standard Actions, Standard Actions Reference, Installing an Application, MsiInstallProduct, INSTALL Action. |
| 3.1
On Windows 2000 do not attempt to replace files that are protected by Windows File Protection. |
Windows Installer adheres to Windows File Protection (WFP) when installing essential system files on Windows 2000. Windows Installer never attempts to install or replace a protected file. If a protected system file is modified by an unattended installation of an application, WFP restores the file to the verified file version. For more information, see Using Windows Installer and Windows Resource Protection. |
| 3.2
Authors writing new redistributable components must use side-by-side sharing techniques so their components can be installed into the application directory. |
Authors of Windows Installer packages can specify that the installer copy the shared files (commonly shared DLLs) of an application into the application's folder rather than to a shared location. This private set of files (DLLs) are then used only by the application. See Isolated Components. |
| 3.3
For Windows 2000 and Windows 98 Second Edition, any side-by-side DLLs that your application depends on must be installed into your application directory: |
Authors of Windows Installer packages can specify that the installer copy the shared files (commonly shared DLLs) of an application into the application's folder rather than to a shared location. This private set of files (DLLs) are then used only by the application. See Isolated Components or Installation of Isolated Components. |
| 4.3
The application should degrade gracefully if access is denied. |
The objective of this requirement is to ensure that if the user is denied access to resources, the application fails in a manner that maintains a secure environment.
Windows Installer handles privileges only during installation. The application must handle privileges at run time. The installer can set certain properties on initialization to the user's privilege level or to a level specified by System Policy. You can then author your Windows Installer package such that the installer checks the user's access privileges before installation begins. You can author the installation package so that the installer determines whether there is sufficient disk space. If you author a user interface (UI) for the application's package, it can display options to users that run out of disk space. If the installation is unsuccessful, the installer can switch into its rollback mode and automatically restore the original state of the computer. For more information, see Overview of Windows Installer, Resiliency, Source Resiliency, Privileged Property, AdminUser Property, System Policy, InstallValidate Action, File Costing, DiskCost Dialog, OutOfDiskSpace Property, OutOfNoRbDiskSpace Property, AllocateRegistrySpace Action, VolumeCostList Control, Rollback, Installation Mechanism, PROMPTROLLBACKCOST Property, DISABLEROLLBACK Property, EnableRollback ControlEvent. |
| 4.5
The application should adhere to system-level Group Policy settings. |
Windows Installer can follow policies pertaining to installation. For more information, see System Policy. |
| 7.1
Applications should continue to function after upgrade to Microsoft Windows 2000 Professional without reinstall |
The installer has a component attribute that can facilitate preparation of your application for migration to Windows 2000. For more information, see Using Transitive Components. |
Send comments about this topic to Microsoft
Build date: 8/13/2009
© 2009 Microsoft Corporation. All rights reserved.