Roadmap to Logo Requirements
[This is preliminary documentation and subject to change.]
This section provides an overview of the Designed for Microsoft® Windows® Logo requirements to help you plan for Logo compliance.
Keep in mind that the overview is not all-inclusive and that all Logo testing is performed against the requirements specified in Logo Requirements, Recommendations, and Best Practices.
Review of this section is not a substitute for a careful reading of the requirements themselves!
Provide Consistent, Up-to-date Windows Support
Providing consistent, up-to-date support for Windows standards and technologies makes your application easier to use and administer, and helps to avoid incompatibility problems. The Designed for Microsoft Windows Logo guidelines supporting this goal are presented in the following categories:
-
General. Your application must be a multitasking, 32-bit program that is stable and fully functional running on the current versions of Microsoft Windows® 98 and Windows NT®. Your application must also support standard system user-interface settings.
-
File System. Your application must support the Universal Naming Convention, long file names, and hard drives larger than 2 GB in size.
-
Operating-System Migration. Your application must support users who upgrade their computers from one version of Windows to another by providing a migration DLL when necessary.
-
Accessibility and User Interface. Your application must be compatible with the High Contrast option, provide keyboard access to all features, document the keyboard user interface, and provide notifications of the keyboard focus location.
-
Internet Security. Your application must digitally sign Microsoft® ActiveX® controls that it provides and support Authenticode signing of all its downloadable code.
-
OLE / COM. Your application must provide an OLE container or object server and allow users to drag objects to any container; it must implement IDropTarget and/or IDropSource. Object servers and OLE containers must pass tests of basic functionality, and an object command must be placed on a container's Insert menu.
-
Telephony. Your application must use TAPI for telephony. If using TAPI version 2.x, the application must explicitly link to a TAPI32 library and must gracefully degrade to work with TAPI version 1.4. Telephony-enabled applications must use the Assisted Telephony interface. Telephony-centric applications must implement the full TAPI interface, apply dialing properties to numbers, allow the user to select the calling device, and share serial devices properly.
-
OnNow / ACPI. Your application must handle system sleep-wake transitions properly.
Install and Uninstall Easily
Installation is one of the most important and sensitive areas for a user or administrator. First impressions are lasting, and a trouble-free installation is the best kind of first impression to make. Also, a user or administrator who must remove an application expects to be provided an easy, automated way to do so.
-
Installing and removing entire applications. Your application must use new Microsoft® Windows® installer, which makes it easy to meet the other install/uninstall requirements. Your installation must provide a graphical, 32-bit setup that works in an attended and/or silent scenario, detects software versions, creates working shortcuts, supports CD-ROM AutoPlay, supports Add/Remove Programs, and checks operations in advance. Your application must provide and register a fully automated uninstaller that appears in Add/Remove Programs and that, when run, removes all application files, references in the Start menu, and registry entries, and removes itself as well.
-
Installing and removing individual components. Your application must not overwrite core components when installing or decrement or remove core components when uninstalling. It must register all shared components during installation, but must not register self-registering components. It must not ref-count core components during installation. When uninstalling, it must decrement the ref-count of shared components; and, if not removing a component during an uninstall, it must leave a zero ref-count if appropriate.
Use the Registry Correctly
Your application must register native data types and support informational keys in the registry. It must not add any entries to the Win.ini or System.ini files.
Save Data to the Best Locations
One of the things that often confuses and frustrates users is the difficulty of locating files and programs on their computers. To minimize such confusion and frustration, your application must not install executables or DLLs in the root directory, but must use the \Program Files folder instead. It must separate user data from application bits and must query the registry for the names of suitable directories in which to save user data.
Cooperate with Administrators
As more and more software is used in large networked enterprise settings, it is increasingly important to make your application easy to manage. Your application must enable policy settings to uninstall and unadvertise it and provide an .adm system policy file for administrators. Your application must also provide for disabling Run and Find dialogs and must use ShellExecute rather than CreateProcess when launching other applications. If your application is a shell extension, it must support the NoViewContextMenu key.
Special Requirements
Several types of applications have special requirements and exemptions when applying to use the Designed for Microsoft Windows Logo.
-
Development Tools must be capable of generating logo-compliant applications and must submit such a sample application for testing purposes. They must make it easy to create OLE containers and/or object servers and advise customers of any potential logo-requirement problems with applications that they build.
-
Utilities must provide meaningful functionality on both Windows 98 and Windows NT®. Any utility that uses the Exclusive Volume Locking function must undergo extensive testing to ensure that it does not cause problems as a result.
-
Games and Multimedia Applications must use Microsoft® DirectX® 5.0 for multimedia capabilities, including Microsoft® Direct3D® and Microsoft® DirectSound®, in such a way that they are compatible with Windows NT.
-
Java Applications must use and redistribute the 32-bit Virtual Machine for Java.
-
Separate Add-On Products must be hosted by 32-bit products that are logo-compliant.
Testing Configuration
Bundled applications must be tested individually. Add-on products included in a suite must be tested both individually and with the suite. An application's installation program must be pretested before the application is submitted for testing.