Note This document contains all of the technical requirements necessary to obtain the Designed for Windows NT® and Windows® 95 Logo. There are additional forms (Vendor Questionnaire, License Agreement, and Testing Agreement) you will need to complete in order to submit your application for testing. These are available at http://www.microsoft.com/windows/thirdparty/winlogo/
This handbook is divided into the following sections:
Welcome
A welcome letter from the Microsoft Designed for Windows Logo Team.
What Does The “Designed For Windows NT and Windows 95” Logo Mean?
This section provides an overview of the purpose of the Logo, why this Logo has value to your customers and how it differs from the Designed for Windows 95 Logo.
How to Obtain the Logo
This section describes the procedure you must follow in order to apply for and obtain the Logo.
The Logo Requirements: Overview
This section provides a high level summary of the Logo requirements.
The Logo Requirements: Detailed Specifications
This section details the complete requirements that your application must meet in order to obtain the Logo.
Legend for Detailed Specifications
| Type | Definition |
| Required | The feature must be supported as described in order for the application to pass testing and receive the Logo. |
| Exception | These are situations where a requirement may not apply. |
| Recommendation | These features are recommended but not required at this time in order for the application to pass testing and receive the Logo. A recommendation will become a requirement in the future. |
| Verification | These are suggested ways that you can test whether your application meets a specific requirement or recommendation. |
| Tip | These are helpful suggestions. They are not recommendations or requirements. |
| Note | These are clarifications to the requirements/recommendations. |
Exceptions, Exemptions, And Additional Requirements
This section describes exceptions, exemptions, and additional requirements for certain application categories, such as non-file-based applications, development tools, utilities, games and multimedia applications, and add-on products.
Pretesting & Verification of Compliance
This section provides tips on how to pretest your product to verify compliance with requirements before submitting for testing. We include this section to help reduce the need for product retests, and therefor speed up the testing process for you.
Other Resources
This section provides links to additional information to help you with your Windows-based application development.
Key Definitions
| Term | Definition |
| AutoPlay | Denotes the behavior of automatically launching a program immediately after inserting a CD-ROM into the drive. |
| Autorun.inf | Text-based information file called during AutoPlay. Contains operating system instructions describing what executable to launch, etc. |
| Core Components | Core components are defined as DLLs that application developers have come to depend on for the proper functionality of their applications. Reverting to an older version or to an incorrectly implemented version may break many third party applications. In general terms, the core components are USER, GDI, and KERNEL. Core components are files which are installed by the operating system during a full installation, or which are considered operating system upgrades (for example, DirectX®, Direct3D®). This includes such things as DLLs which are installed by applets. This list is dynamic. For the most up to date list of core components for Windows NT and Windows 95, see http://www.microsoft.com/windows/thirdparty/winlogo/. |
| Degrade Gracefully |
|
| File-Based Application | File-based applications have as their primary purpose the creation and editing of documents and include Open, Save, and Close commands, typically on the File menu of the application. |
| Labeling Scheme | Common to games, accounting, and database programs. Users save “profiles” of reports, game states, etc. which have limited naming schemes. Labels may create actual file names, but the file naming behavior only vaguely represents the input of the user. Example: User may enter, “File Name Test”, but the application would save “SAV001.EXT”, or “FILAAAA.EXT” to the hard disk. These files are not intended to be accessed directly from Windows Explorer. A labeling scheme is not required to save long file names to the hard disk and is exempt from the long file name requirements. |
| Non-File-Based Application | A non-file-based application is one that is not primarily used to create, edit, and save files (although file operations may be common ancillary tasks). |
| Product Category | These categories are used to determine what behavior is required from the application to pass the Logo test. Includes: File-Based, Non-File-Based, Utility, Development Tool, Add-On. The final determination of what category applies to a product will be made by Microsoft. |
| Refcount | The act of incrementing and decrementing shareable components in the system registry under the ...\SharedDLLs key. |
| Shared Components | Any files which are installed by an application, but might be shared by multiple applications. Shared components are usually DLLs, but may be EXEs or any other file type. These must be “refcounted” unless they are “core components” or installed to the application’s own directory. |
| Suite vs. Product | A suite is a collection of programs typically denoted by more than one shortcut on the Start Menu. A product can be a suite or a single executable. The final determination of whether or not a product is a suite will be made by Microsoft and VeriTest. |
| Telephony Centric | One of two categories of communications applications. An application that performs any telephony function beyond simple dialing of voice calls is considered a telephony centric application (including, for example, all applications that use a modem for data or fax calls). Examples of telephony centric include: dialers, answering machines, voicemail, interactive voice response, modem or fax communications, etc. |
| Telephony Enabled | One of two categories of communications applications. Telephone communications are not the primary purpose of the application. Examples of telephony enabled applications are: Personal Information Managers, address books, and databases |
| Win32 | Any 32-bit executable file described as “[PE_Win32]” by the Exedump program available on the Win32® SDK (Software Development Kit). |