Meeting Enterprise Needs

[This is preliminary documentation and subject to change.]

Application software is increasingly being used in large enterprises, where customer requirements are different from those of individuals who do not depend on a network.

To radically reduce the total cost of ownership (TCO) for desktops running Microsoft® Windows NT® Workstation 5.0 in large organizations, it is essential to create applications that can be easily deployed and maintained by an administrator, rather than asking the user to deal with such complexities. In the "no touch" management paradigm, administrators should be able to deploy applications to any number of users in a few simple steps. Administrators should be able to customize these applications, so that users receive precisely the components they need. Administrators should be able to update applications easily — it should only require a few simple steps to upgrade a group of users to a new version of an application.

For users, application installation should become virtually transparent. Key applications should always be available, even when a user roams from computer to computer, or works offline on a laptop. If a user encounters a file with an associated application that is not within his or her user profile, that application should be automatically loaded, without the user being asked to figure out what application is needed. Application updates occur automatically, without the need for users to intervene. Finally, if a user's computer fails, it should be possible simply to plug in a replacement and have all the user's settings and data automatically restored.

Windows NT Workstation 5.0 addresses these kinds of software management problems that large enterprises face, and gives you the tools to solve them.

Using those tools and incorporating those solutions in your product may require a significant investment of development time on your part, but the payoff more than justifies the effort. In today's highly competitive market, support for Windows NT 5.0 infrastructure technologies offers an extraordinary opportunity to distinguish your product from the competition, with features that a wide spectrum of corporate buyers have identified as crucial to their buying decisions.

The formula is straightforward:

What's more, following the guidelines for writing "clean" applications will help your application qualify for the Designed for Microsoft® Windows® Logo, another strong selling point in the enterprise marketplace.

The following sections discuss what your development team needs to do to make your product a "clean application" suited for deployment in a large enterprise.

For more information about all the new Windows NT 5.0 technologies that can help you meet enterprise needs, see http://www.microsoft.com/windows/zaw.


What is a Clean Application?

A clean application is one that follows the Designed for Microsoft® Windows® Logo guidelines so as to support the Zero Administration for Windows initiative from Microsoft. A clean application has the following characteristics:

  • Segmentation. A clean application of any size should be partitioned into components, each of which implements a subset of the application's functionality and feature set. This is usually the most difficult change you may have to make, because it affects your entire application architecture. The core program, and possibly several other components, will need to be designed to run independently of the others.

    Feature segmentation should be approached with two goals in mind:

    1. Just-in-Time Installation. Good segmentation lets you take advantage of the new Microsoft installation and component management technology to keep your application's footprint small. Using this technology, you can install components supporting specialized, seldom-used features only when they are actually needed, saving space on most users' hard drives.
    2. Feature-Set Configuration. Good segmentation also helps your application present itself at different levels of complexity suited to different user audiences, as controlled by registry entries.

      For example, a group of advanced features only needed by specialized users might be isolated in a single component and might appear in your application's user interface only if a registry key is set to indicate that it should be exposed.

      Not only can this keep your memory and storage footprint small, it also allows administrators to lock down features of your application that their users may not need in a given enterprise environment. The ability to configure your application can help administrators significantly lower training and support costs in their organizations while increasing productivity .

  • Abstraction of Data Locations. Microsoft® Windows NT® 5.0 makes possible a new level of flexibility and mobility on enterprise networks. In particular, it supports:
    • Roaming users. A person should be able to log on to any unused computer in an organization and have the same settings and data available.
    • Mobile users. Even when working on your laptop offline, you should have access to the resources you need to do your job.
    • Side-by-side computer replacement. When hardware fails, it should no longer be necessary to spend hours reconfiguring a new computer. From now on, you should be able to plug a new computer in and within a few minutes recover the same configuration and data as existed on the computer that failed.

    In order to make such flexibility possible, applications must not save settings and data to hard-coded locations on the local hard drive. Instead, they should look up the location of the appropriate paths using a shell function supplied for that purpose (SHGetSpecialFolderLocation). By doing so, they allow administrators to specify where various kinds of data reside, and to relocate data to network servers rather than local computers. A related issue is that applications using the registry must read and write carefully, in a way that will work as well on a busy remote server as on a dedicated local hard drive.

  • Policy Support. The most challenging aspect of policy support is the implementation of private policy options, mentioned above under the subject of segmentation. These are configuration options controlled through the registry that are provided by an application to make itself easier to administer and use in an enterprise environment. In addition to whatever private policy options an application may implement, it should also support the few public policy options published by Microsoft. This last requirement is important, but generally not difficult
  • Management Support Tools. Client applications should provide or support any tools needed that administrators will need to manage deployment or use of the application in a large enterprise environment. The new Microsoft Management Console (MMC) provides an easy and consistent way for applications to expose management features.


Partitioning Applications

It can be a daunting task to divide an application into independent components, each of which supports a coherent feature set. Nonetheless, it is a challenge that an increasing number of large applications are meeting. The component architectures from Microsoft provide the technological underpinnings needed to make such segmentation possible.

From a user's perspective, payoffs for segmentation are provided by two technologies:

  • Just-in-Time Installation. The ability to install applications and application components on an as-needed basis. Not only does this save precious local hard drive space, it reduces the bandwidth needed to run an application from a network. (For more information on new installation and component management technology from Microsoft, see Introduction to New Microsoft Installer Technology.
  • Feature-Set Configuration. The idea is that each application makes a number of its features optional, based on the settings of one or more registry keys. In some cases, these registry keys might be public, shared among numerous applications, but more often they would be private, specific to a single application.

    Administrators using Group Policy can take advantage of Feature-Set Configuration to tailor applications to the needs of different groups of users. This gives them a powerful tool to reduce training and support costs while increasing productivity among their users.


Supporting Just-in-Time Installation

Just-in-time installation relies on new Microsoft installation and component management technology. This technology allows each component of an application (including the core component) to be installed only when it is actually needed. Some components can be installed locally while others run from a CD-ROM drive or network server when needed.

Using this system installation technology, your application can effectively offer as deep and broad a feature set as your market demands while keeping the small local footprint that both users and administrators appreciate. Local hard drive space is often at a premium, and the less your application requires, the happier your customers will be.

Keeping the core component of your application small also makes running it over a network, with no local copy, much more practical. The application starts more quickly, consuming less network bandwidth.

The key to taking advantage of the benefits made possible by the new installer technology is to segment your application intelligently, so that core functionality is delivered in one compact component, and a wealth of supplementary features are delivered in additional components. Wherever possible, features that will be used together should be grouped in the same component.

An additional consideration in grouping features into components is to minimize installation of features that may be removed from your application through feature-set configuration. If, for example, your application offers a group of optional "Advanced Formatting" features that feature-set configuration could remove from the user interface, then it would generally make sense to isolate these features in a component or components that would never have to be installed if the features were not enabled.

For detailed documentation about how to take advantage of this new installer technology, see Introduction to New Microsoft Installer Technology.


Supporting Feature-Set Configuration

Because many users are more comfortable and productive when using programs whose feature-sets have been tailored to their specific needs, you should consider what configurations of your application's feature-set would be useful under different circumstances.

This is an issue that enterprise administrators generally take very seriously, because they have found that a disproportionate amount of their training and support costs are devoted to application features that few personnel actually need or use.

On the other hand, of course, for some users, these same features may be vitally important in getting their jobs done.

The solution is to make such features optional, and to give administrators a way to lock them down when they aren't needed.


Abstracting Data Locations

There are three areas in particular where applications need to help in achieving a manageable environment:

  • Use default data locations.
  • Use the registry properly.
  • Do not assume a single-user installation.

By following these guidelines, applications allow the enterprise network to be used much more flexibly. In particular, they enable three kinds of usage that have not been possible before:

  • Roaming use. You can log on to any unused computer in your organization and have all your settings and data available to you.
  • Mobile use. When you take your laptop home or on a trip, you automatically have access to cached copies of the network data you need.
  • Side-by-side computer replacement. If your computer fails, you can replace it with a new one within minutes, recovering your configuration and data automatically.


Data Categories

Data on the desktop can be divided into three categories:

  • Reconstructable Data. This is information that can be regenerated. For example, an application's binaries can be reinstalled.
  • Recoverable Data. This is information that has been saved in a location from which it can be recovered at need. Data that has been backed up to tape or floppy disk is one example. Another is data that has automatically been saved or mirrored on an enterprise server (by Microsoft® IntelliMirror™, for example).
  • Unprotected Data. This is information that could be lost in the event of an unforeseen failure — it should be considered as information that will be lost.

Microsoft® Windows NT® 5.0 provides new opportunities to reduce Unprotected Data on the desktop to an absolute minimum.

Applications must play a role in achieving this goal, by clearly distinguishing between reconstructable elements such as application binaries and default settings, and user data such as settings, other profile data, documents, and other content files created explicitly by the user.

The operating system provides new, transparent ways of achieving some of these goals. IntelliMirror, for example, is a Windows technology that mirrors users' data, applications, and customized operating-system settings to a server using intelligent caching and centralized synchronization. This means that users have access to information and applications on their local hard drives even when they are not connected to the network, but also that their data is safely maintained on the server when they are connected.

To take the fullest advantage of this kind of new technology, user data of all sorts should be saved to standard locations that are determined by consulting the registry through the SHGetSpecialFolderLocation function.

Categories of Application Data

Data associated with an application generally includes some or all of the following categories and subcategories:

Application files
Application executables
Private DLLs
Shared DLLs
Help Files
Tutorials
Setup files and utilities
Support Files
Profile Information
Per-user settings
Workstation-specific settings

Hardware configuration information

User Content Files
Documents or other content files created by users

It is very important and useful to keep user data completely separate from application binaries on the one hand, and computer-specific data on the other.


Default Data Locations

For your application to work properly in a 32-bit enterprise environment, you must take care to store data in standard places. See the Designed for Microsoft® Windows® Logo requirements and recommendations at:

  • Be Easy to Install and Remove
  • Use the Registry Correctly
  • Save Data to the Best Locations

The main things to keep in mind are:

  • Use new Microsoft installation and component management technology to install application files as needed to the correct folders, and to let some components be accessed over a network or from a CD-ROM. Satisfying this Designed for Microsoft® Windows® Logo requirement considerably eases the complexity of creating a good setup. Furthermore, applications installed using the new installer technology are generally much more reconstructable than applications that are not.
  • Avoid DLL version conflicts. Except for operating system components, do not globally share DLLs. The small additional hard drive usage that this requires is more than compensated for by not running the risk of destabilizing your users' environments. The Designed for Microsoft® Windows® Logo guidelines strongly recommend the following:
    • Do not write to Windows system directories. (Recommended)
    • Use Microsoft update packs to upgrade system components. (Recommended)
    • Do not install globally shared DLLs. (Recommended)
  • Store user settings in the registry, in the HKEY_CURRENT_USER hive, or, in the case of large blocks of user profile information, in the Application Data folder under the user's Profile folder. If you do need to use the Application Data folder, be sure to establish the same hierarchical structure that HKEY_CURRENT_USER has, namely:

    Application Data\
    Software\
    [company name]\
    [product name]\
    [version]\
    [your top level]\

  • Do not assume that you know the names or locations of any of the standard folders, such as My Documents or Application Data, that you are going to use (for example, starting with Windows NT 5.0, the default name of the Personal folder has changed to My Documents). For all you know, your application might be running on a foreign-language version of Windows, or the user's profile folder might reside on a server instead of on a local hard drive.

    Rather than make any assumptions, call SHGetSpecialFolderLocation to obtain a path to standard folders, as explained in Locating the Standard Folders Where Data Belongs.

  • Use the improved My Documents folder (previously the Personal folder) to save all files created by users. "My Documents" is a collection of operating-system changes designed to help centralize local user data storage so as to ensure recoverability and improve discoverability.

    A My Documents folder now appears on every desktop (this is not to be confused with the My Documents folder created by Office 95). The Home directory defaults to this folder, and it appears by default in standard FileOpen/SaveAs dialog boxes if you initialize lpstrInitialDir to NULL or to the path to "My Documents". You can always locate it by calling SHGetSpecialFolderLocation with CSIDL_PERSONAL.

  • Support security by assuming that the file system is NTFS, locked down with Access Control Lists (ACLs), and that %UserProfile% and %Temp% are the only writeable locations.
  • Hide extra program files and directories to present a simplified file system (use the hidden attribute).


Locating the Standard Folders Where Data Belongs

For many standard folders, a qualified path can be obtained by calling SHGetSpecialFolderLocation with an appropriate CSIDL constant (CSIDL constants are defined in ShlObj.h, a Windows header file). The following standard folders are accessible in this way.

Standard Folder CSIDL Constant Name Hex
Alternate Startup (All Users; DBCS)
CSIDL_COMMON_ALTSTARTUP

0x1e
Alternate Startup (user's; DBCS)
CSIDL_ALTSTARTUP

0x1d
Application Data (user's profile)
CSIDL_APPDATA

0x1a
Control Panel virtual folder
CSIDL_CONTROLS

0x03
Cookies folder
CSIDL_COOKIES

0x21
Desktop (namespace root)
CSIDL_DESKTOP

0x00
Desktop folder ("All Users" profile)
CSIDL_COMMON_DESKTOPDIRECTORY

0x19
Desktop folder (user's profile)
CSIDL_DESKTOPDIRECTORY

0x10
Favorites folder (All Users profile)
CSIDL_COMMON_FAVORITES

0x1f
Favorites folder (user's profile)
CSIDL_FAVORITES

0x06
Fonts virtual folder
CSIDL_FONTS

0x14
History folder
CSIDL_HISTORY

0x22
Internet Cache folder
CSIDL_INTERNET_CACHE

0x20
Internet virtual folder
CSIDL_INTERNET

0x01
My Computer virtual folder
CSIDL_DRIVES

0x11
My Documents folder (user's)
CSIDL_PERSONAL

0x05
Network Neighborhood root
CSIDL_NETWORK

0x12
Network Neighborhood directory
CSIDL_NETHOOD

0x13
Personal folder (user's profile)
CSIDL_PERSONAL

0x05
Printers virtual folder
CSIDL_PRINTERS

0x04
PrintHood folder (user's profile)
CSIDL_PRINTHOOD

0x1b
Programs folder (under Start Menu in "All Users" profile)
CSIDL_COMMON_PROGRAMS

0X17
Programs folder (under Start Menu in user's profile)
CSIDL_PROGRAMS

0x02
Recent folder (user's profile)
CSIDL_RECENT

0x08
Recycle Bin folder
CSIDL_BITBUCKET

0x0a
SendTo folder (user's profile)
CSIDL_SENDTO

0x09
Start Menu ("All Users" profile)
CSIDL_COMMON_STARTMENU

0x16
Start Menu (user's profile)
CSIDL_STARTMENU

0x0b
Startup folder ("All Users" profile)
CSIDL_COMMON_STARTUP

0x18
Startup folder (user's profile)
CSIDL_STARTUP

0x07
Templates folder (user's profile)
CSIDL_TEMPLATES

0x15

Other standard folders can also be located using the following environment variables.

Standard Folder or Location | Environment Variable
System drive | %SystemDrive%
System root directory | %SystemRoot%
Windows folder | %windir%
Program Files folder | %ProgramFiles%
User's profile folder | %UserProfile%
Temporary folder (per user) | %Temp%

Access to specific user profile folders such as My Documents or Application Data should be obtained through SHGetSpecialFolderLocation rather than by relying on a combination of an environment variable and the standard English folder name (such as %UserProfile%\Application Data\).


Using the Registry Properly

  • Do not store hard-coded path names in the registry. Use system environment variables wherever possible. This allows administrators to redirect components and remap drive letters. Important environment variables are:
    %UserProfile%\
    %Temp%\
    %ProgramFiles%\
    %SystemDrive%\
    %SystemRoot%\

    This is also a Designed for Windows Logo recommendation.

  • Register classes on a per-user basis. On Microsoft® Windows NT® 5.0, be sure to register class information in HKEY_CURRENT_USER (in HKCU\Software\Classes).
  • Use the correct access mask when opening a registry key. Use KEY_READ and KEY_WRITE rather than KEY_ALL_ACCESS.
  • Store user settings separately from computer settings. User settings and computer settings are different. Computer settings do not vary from user to user. As a general rule, user settings should be recoverable, and computer settings reconstructable.

    Do not store a mixture of user information and computer information together, and definitely do not store them with the application binaries, where they will be lost if the computer fails.

    This is also a Designed for Microsoft Windows Logo requirement.

  • Store small user setting data in HKEY_CURRENT_USER (HKCU).
  • Store large user-profile data in the Application Data folder. Store any user-profile information that is too large to be suitable for the registry in the Application Data folder of the user's Profile. Get the path to this folder by calling SHGetSpecialFolderLocation with CSIDL_APPDATA.

    For more information, see the applicable Designed for Windows Logo recommendation.

  • Store hardware-independent computer settings in HKLM. Installed hardware can change, whether by docking and undocking, computer replacement, presence or absence of portable peripherals, and so forth. HKEY_LOCAL_MACHINE should contain static information that has to do with the logical computer in the context of the enterprise, as opposed to an actual physical configuration of that computer.
  • Store hardware-dependent computer settings in HKCC. HKEY_CURRENT_CONFIG is the place to store all hardware-related data about the computer's configuration.
  • Do not assume that HKEY_CURRENT_USER is initialized. In a multi-user environment an application can be installed on a computer without setup having had an opportunity to initialize HKEY_CURRENT_USER (HKCU) for the user who starts the application. Supply a reasonable default value for each user setting, and use it if the corresponding registry key is not present in HKCU. This is also a logo recommendation.


Registry Keys That Are Important for Policy

Developers should make sure that their applications check various registry keys if the applications expose any functionality controlled by settings of certain registry keys.

If a registry key is applicable to functionality that an application exposes, the application should take the following steps:

  • Check the registry at startup for the settings of the relevant key.
  • At startup, remove from the user interface access to functionality that the registry key indicates should be disabled.
  • Immediately before exposing the functionality, check the registry again, and fail gracefully if the functionality has been disabled since startup.

When spawning another process, an application does not have to check that the new process is permitted as long as it uses ShellExecute to spawn the application in question rather than CreateProcess. If ShellExecute is used, the shell checks that the executable being spawned is allowed.

The following keys are particularly important for implementation of system policies in enterprise environments:

HKEY_CURRENT_USER\
Software\
Microsoft\
Windows\
CurrentVersion\
Policies\
System\

DisableRegistryTools
 Disable registry editing tools.
DisableTaskMgr
 Disable Task Manager.
NoDispAppearancePage
 Hide Control Panel Appearance tab.
NoDispBackgroundPage
 Hide Control Panel Background tab.
NoDispCPL
 Do not display Control Panel.
NoDispScrSavPage
 Hide Control Panel Screen Saver tab.
NoDispSettingsPage
 Hide Control Panel Settings tab.

HKEY_CURRENT_USER\
Software\
Microsoft\
Windows\
CurrentVersion\
Policies\
Explorer\

EnforceShellExtensionSecurity
 Run only certain shell extensions.
LinkResolveIgnoreLinkInfo
 Disable link file tracking.
NoClose
 Disable the Shut Down option on the Start menu.
NoCommonGroups
 Do not display common groups in Start menu, Programs.
NoDesktop
 Hide all items on the desktop.
NoDrives
 Remove the drive icons in My Computer.
NoEntireNetwork
 Do not display the entire network in Network Neighborhood.
NoFileMenu
 Remove the File menu from the Windows® Explorer toolbar.
NoFind
 Remove the Find command from the Start menu.
NoNetConnectDisconnect
 Remove the Map Network Drive and Disconnect Network Drive buttons and menu options.
NoNetHood
 Remove the Network Neighborhood icon from the desktop.
NoRun
 Remove the Run command from the Start menu.
NoSaveSettings
 Do not save settings on exit.
NoSetFolders
 Remove Control Panel and Printer folders from the Start, Settings menu.
NoSetTaskbar
 Remove the Taskbar from the Start, Settings menu.
NoStartMenuSubFolders
 Hide all Start menu subfolders.
NoTrayContextMenu
 Disable context menus on the taskbar.
NoViewContextMenu
 Disable the Explorer default context menu.
NoWorkgroupContents
 Do not display workgroup contents in Network Neighborhood.
RestrictRun
  \[Index Numbers]
 Run only those Windows applications listed in the numbered keys under RestrictRun.

HKEY_LOCAL_MACHINE\
Software\
Microsoft\
Windows\
CurrentVersion\
Run\

[Application Name]
 List of applications user may run when logging on interactively.


Registry Keys for Standard Folder Locations

The following registry keys contain the locations of various standard folders. These locations can be set by administrators as a part of policy.

HKEY_CURRENT_USER\
Software\
Microsoft\
Windows\
CurrentVersion\
Explorer\
User Shell Folders\

Desktop
 Specify the folder displayed on the Desktop.
NetHood
 Specify the folder displayed when navigating Network Neighborhood.
Programs
 Specify the folder displayed by Start menu, Programs.
Start Menu
 Specify the folder displayed as the Start menu.
Startup
 Specify the Startup folder (displayed in Start menu, Programs, Startup).

HKEY_LOCAL_MACHINE\
Software\
Microsoft\
Windows\
CurrentVersion\
Explorer\
User Shell Folders\

Common Programs
 Specify the common groups folder displayed in Start menu, Programs.
Common Desktop
 Specify a folder of shared items displayed on the desktop.
Common Start Menu
 Specify a folder of shared items displayed in the Start menu.
Common Startup
 Specify a folder of shared startup items.


Other Registry Keys Used in Policy

HKEY_CURRENT_USER Keys

HKEY_CURRENT_USER\
Control Panel\
Appearance

Current
 Specify the Desktop Color Scheme.

HKEY_CURRENT_USER\
Control Panel\
Desktop

TileWallpaper
 Specify the tiling of Desktop wallpaper.
Wallpaper
 Specify the path of Desktop wallpaper.

HKEY_CURRENT_USER\
Software\
Microsoft\
Windows NT\
CurrentVersion\
Winlogon\

ParseAutoexec
 Include environment variables contained in Autoexec.bat in user's environment.
RunLogonScriptSync
 Run logon scripts synchronously (wait for completion).

HKEY_CURRENT_USER\
Software\
Microsoft\
Windows\
CurrentVersion\
Explorer\
Tips\

Show
 Show welcome screen and tips at logon.

HKEY_LOCAL_MACHINE Keys

HKEY_LOCAL_MACHINE\
Software\
Microsoft\
Windows NT\
CurrentVersion\
Winlogon\

LegalNoticeCaption
 The caption of a pre-logon dialog box/banner.
LegalNoticeText
 The text of a pre-logon dialog box/banner.
ShutdownWithoutLogon
 Disable the Shutdown button in the logon dialog.
DontDisplayLastUserName
 Disable display of last logged-on user name.
RunLogonScriptSync
 Force the logon script to run synchronously (wait for it to finish).
DeleteRoamingCache
 Delete cached copies of roaming profiles.
SlowLinkDetectEnabled
 Automatically detect slow network connections.
SlowLinkTimeOut
 Set timeout for slow network connections.
ProfileDlgTimeOut
 Set timeout for user profile dialog boxes.

HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Control\
FileSystem\

NtfsDisable8dot3NameCreation
 Disable creation of 8.3 file names for long names.
NtfsAllowExtendedCharacterIn8dot3Name
 Allow extended characters in 8.3 file names.
NtfsDisableLastAccessUpdate
 Do not update the last access time for files that are only read (increases system performance).

HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Control\
Print\

DisableServerThread
 Disable browse thread on this computer.
SchedulerThreadPriority
 Set scheduler priority.
BeepEnabled
 Enable beep on remote print server job error.

HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Control\
Update\

UpdateMode
 Controls remote update of remote policies.
NetworkPath
 Path for policy file used in manual update mode.
Verbose
 Controls display of error messages in update.
LoadBalance
 Controls load balancing.

HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Services\
LanManServer\
Parameters\

AutoShareWks
 Creates administrative workstation drive shares.
AutoShareServer
 Creates administrative server drive shares.

HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Services\
RemoteAccess\
Parameters\

AuthenticateRetries
 Set maximum number of unsuccessful authentication retries.
AuthenticateTime
 Set maximum time limit for authentication.
CallbackTime
 Set wait interval for callback.
AutoDisconnect
 Set idle time before RAS auto-disconnect.

HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Services\
SNMP\
Parameters\

ValidCommunities
  \[Index Numbers]
 List of valid SNMP Communities.
PermittedManagers
  \[Index Numbers]
 List of SNMP Permitted Managers.
TrapConfiguration
  \Public
    \[Index Numbers]
 List of SNMP Traps for Public community.


Introduction

The documentation for the Designed for Microsoft® Windows® Logo program describes the scope and purpose of the program, tells you how to obtain the logo for your product, and specifies exactly what the programming guidelines are with which your application has to comply. The documentation is divided into four parts:

  • Introduction. The section you are now reading provides an overview of the rest of the documentation and describes what the logo program is all about. It is divided into the following sections:
    • Welcome
    • What getting the logo means
    • What the logo does NOT mean
    • The right Microsoft logo program for you
  • Getting the Logo for Your Application. This section lists the steps you have to take to obtain the Designed for Microsoft® Windows® Logo, including a bird's eye view of the programming guidelines and requirements.
  • Logo Requirements, Recommendations, and Best Practices. This reference section contains the formal specification for each programming guideline. It includes the following types of guidelines:
    • Requirements. Your application must comply with all of these before it can receive the Designed for Microsoft® Windows® Logo.
    • Recommendations. These guidelines are likely to become requirements in the future, so it is worth complying with them now.
    • Best Practices. These guidelines are designed to help make your application work consistently and well in a Microsoft Windows environment, particularly in large enterprises.
  • Quick-Reference Lists of Programming Guidelines. This section provides lists of programming guidelines, including recently added guidelines, logo requirements, recommendations and best practices, and recently deleted guidelines.


Welcome

The Designed for Microsoft® Windows® Logo handbook has three primary goals:

  • To introduce a draft of the requirements for the Microsoft® Windows NT® 5.0 and Microsoft® Windows® 98 Logo.
  • To provide developers with guidelines about how to write clean applications for Windows environments.
  • To provide an easy-to-use reference for all technical information related to the Designed for Microsoft Windows Logo program.

The handbook documents the following different types of programming guidelines:

  • Requirements for the Designed for Microsoft Windows Logo.
  • Proposed requirements for the next version of the logo program, to become effective in the timeframe of Windows 98 and Windows NT 5.0.
  • Additional guidelines and suggestions for building applications that take full advantage of the upcoming releases of Windows 98 and Windows NT.

This document will be updated with subsequent drafts until it is finalized at the release of Windows NT 5.0 beta 2. For the latest version, see the Windows Logo web site at http://www.microsoft.com/windows/thirdparty/winlogo/.

Current Logo Partners should note that this document includes the complete and unchanged Designed for Microsoft Windows Logo requirements that are currently in effect. The guidelines for the current program remain available in the Logo Handbook version 3.0, which you can download from http://www.microsoft.com/windows/thirdparty/winlogo/.

Requirement Timeline

  • Today - Application must pass testing against Designed for Microsoft Windows requirements contained in the Logo Handbook version 3.0.
  • Windows NT 5.0 Release (1998) - Applications must pass testing against current requirements and new requirements for the Designed for Windows Logo.

More about this document

So, your first impression probably is that this is a big document. Don't be intimidated! This document is a terrific development resource and includes guidelines that can help you develop the most competitive, highest quality Windows applications available.

So why does the logo program have so much documentation? There are two reasons:

  1. We've explained and detailed exactly what each requirement means, how to implement it, and why we believe it's important to define a Designed for Windows application. Based on feedback from our Logo Partners, we've found that developers appreciate getting the most specific, detailed information possible about all the guidelines.
  2. We've researched what customers think of as an ideal application. We've worked with our Logo Partners, with end users, and with major corporations to develop the recommendations you will find in this Handbook. This document is a way for us to share this information with you, our current and future Logo Partners; to enable you to leverage not only the Windows brand, but also the valuable feedback that Microsoft hears every day from our customers.

Additionally, to help make the documentation a little easier to use, we've transformed this document from a print format to an online format, and we've added multiple ways of looking at the guidelines and requirements, depending on whether you're trying to get a bird's eye view, or are deep in writing code.

Finally, we look forward to welcoming you to the Microsoft® Windows® Logo Partnership.

Sincerely,

The Windows Logo Team
Microsoft Corporation

October 30, 1997


What Getting the Logo Means

The Designed for Microsoft® Windows® Logo program was developed by Microsoft to help end-users easily identify desktop hardware and software products that are adapted specifically to run properly on Microsoft® Windows® 95, Microsoft® Windows® 98, and Microsoft® Windows NT® Workstation (hereafter referred to as Windows NT).

Users can mix and match hardware and software products with the Designed for Microsoft® Windows® Logo and be assured that the products will take advantage of the new technologies integrated into both of these operating systems. As a software vendor, licensing the Logo enables you to use the Logo on your product packaging, advertising, collateral, and other marketing materials. This signals customers that your product has the following characteristics:

A Tested Product
Your product has been tested and is fully functional on both Windows NT and Windows 95.
Provides Best User Experience
Your product is designed to provide optimum usability and to ensure a consistent, accessible user experience.
Works Well with Other Applications
Your product has been designed to take advantage of the latest software and hardware technologies available on Windows NT and Windows 95.
Runs on the Latest Versions of Windows NT and Windows 95
Your application runs equally well on Windows 95 and Windows NT. For more information, see guideline..


What the Logo Does NOT Mean

The Logo does NOT mean that Microsoft or the testing laboratory endorses or certifies your product.

Please note that the license agreement states:

YOU MAY ONLY USE THE LOGO AS A SYMBOL THAT YOUR PRODUCT IS COMPATIBLE WITH MICROSOFT WINDOWS NT AND WINDOWS 95. YOU MAY NOT EXPLICITLY STATE OR IMPLY THAT MICROSOFT OR THE TESTING ORGANIZATION IN ANY WAY ENDORSES YOUR PRODUCT. ALSO, THE WINDOWS NT AND WINDOWS 95 LOGO PROGRAM IS NOT INTENDED TO BE A "CERTIFICATION" PROGRAM, THAT IS, THE LOGO DOES NOT REPRESENT THAT MICROSOFT OR THE TESTING ORGANIZATION CERTIFIES YOUR PRODUCT(S) IN ANY WAY.

Software applications are tested by an independent laboratory, VeriTest, Inc. (http://www.veritest.com/microsoft.htm or send e-mail to logolab@veritest.com).

The Designed for Microsoft® Windows® Logo indicates that a software product provides all the features outlined in this documentation, but it is not a quality assurance seal. Neither Microsoft nor the testing organization will be testing the quality of your product or ensuring that it is bug-free. The testing organization's job is to ensure that your product has full functionality, that the Logo features are present, and that your product is not generating frequent faults or system crashes.

See Also

Important Restrictions on International and Localized Versions


The Right Microsoft Logo Program For You

The Designed for Microsoft® Windows® Logo is for commercially marketed desktop applications that run primarily on Windows NT Workstation and Windows 95. It is not for client/server applications or Windows NT Server-based applications.

If your application is a client/server application or runs primarily on Windows NT Server, you should consider applying for the Designed for BackOffice® Logo. This logo does not require that you also qualify for the Designed for Microsoft® Windows® Logo. For additional information on the Designed for BackOffice® Logo, see http://www.microsoft.com/backoffice/designed, or send an e-mail message to bckoffc@microsoft.com.

Microsoft also offers the Microsoft® Office Compatible Logo Program. This logo program requires that your application also receive the Designed for Microsoft® Windows® Logo. For additional information on the Microsoft® Office Compatible Logo program, see http://www.microsoft.com/office/compatible, or send an e-mail message to offcomp@microsoft.com.

See Also

Important Restrictions on International and Localized Versions


Other Resources

Accessibility
http://microsoft.com/enable/
ACPI/OnNow
http://www.microsoft.com/hwdev/onnow.htm
Differences between Windows NT 4.0 and Windows 95
http://www.microsoft.com/win32dev/guidelns/apidiffs.htm
Image Color Matching (ICM 2.0)
http://www.microsoft.com/msdn/sdk/icm20.htm
Zero Administration for Windows Initiative from Microsoft
http://www.microsoft.com./windows/zaw/
MSDN
http://www.microsoft.com/msdn/default.htm
Software Development Kits available through MSDN
http://www.microsoft.com/msdn/sdk/default.htm
Windows Driver Model
http://www.microsoft.com/hwdev/pcfuture/wdm.htm


Getting the Logo for Your Application

Getting the Logo
for Your Application

[This is preliminary documentation and subject to change.]

Getting the Designed for Microsoft® Windows® Logo may be surprisingly easy for your application, since many of the requirements are standard practice among Windows programmers, and of those requirements that are new, many are quite easy to comply with.

The process of application testing and licensing consists of seven straightforward steps:

  1. Make sure your application meets the requirements . Review your product to ensure that it complies with Logo requirements, as described in this documentation.
  2. PreTest . Pretest your product's installation using the Installation Analyzer tool from VeriTest, Inc.
  3. Sign Agreements . Obtain and sign necessary legal documents.
  4. Send to VeriTest . Submit your product, together with pretest results and legal documents, to VeriTest for testing. All fees are to be paid to VeriTest, not Microsoft.
  5. Get Test Results . VeriTest will notify you of test results within eight (8) business days from when your complete application package is received. VeriTest will also send Microsoft a copy of the test results, and if your product passed, Veritest will also send the license agreement to Microsoft.
  6. If you pass, Microsoft signs your license. Microsoft will then sign the license agreement and send it to your marketing contact. The license allows you to use the Logo on packaging, advertising, your web site, and other promotional materials.
  7. Use the Logo . At this point, you can download an electronic copy of the Logo artwork kit from a secure web server using a password provided to you by VeriTest. This contains electronic copies of the Logo and Logo usage guidelines.

See Also

Important Restrictions on International and Localized Versions


Meeting the Requirements

Meeting Designed for Microsoft® Windows® Logo requirements may not be as difficult as you imagine. This section summarizes logo requirements to help you in your planning, and discusses some of the areas in which new guidelines are being introduced:

  • Roadmap to Logo Requirements.
  • New Areas of Focus of the Logo Program.


Roadmap to Logo Requirements

This section provides a brief overview of the Designed for Microsoft® Windows® Logo requirements to help you plan for Logo compliance.

Please 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. Designed for Windows Logo guidelines that relate to this goal are presented in the following categories:

  • General. Your application must be a multi-tasking 32-bit program that is stable and fully functional running on all current versions of Windows 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 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, it must explicitly link to a TAPI32 library, and must gracefully degrade to work with TAPI version 1.4 as well. 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.

Be Easy to Install and Remove

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 installer technology, 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, 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 uninstallation, 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 directory 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 spawning other applications. If your application is a shell extension, it must support the NoViewContextMenu key.

Special Requirements

Several types of application 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 95 and on 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 Rules

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 must be pretested before the application is submitted for testing.


New Areas of Focus of the Logo Program

There are several areas where the Designed for Microsoft® Windows® logo program has introduced new requirements, recommendations, and suggested practices for Windows applications:

  • Supporting networked and managed environments. As more and more personal computers are operating in large, complex networked environments, applications must take a share of the responsibility to help administrators manage these environments for everyone's benefit.
  • Managed software installation. Microsoft is adding new managed software installation technology to Windows 95, Windows 98, and Windows NT. This technology makes it much easier to install and uninstall your application correctly. For more information, see Introduction to New Microsoft Installer Technology .
  • Avoiding DLL Version Conflicts. Take up a little more disk space in order to save your users from potential problems.
  • Upcoming COM+ Technology. COM+ will make your COM objects easier than ever to use and re-use.
  • Upcoming Directory Services Technology. Take advantage of the new directory services provided with Windows NT 5.0.


Supporting Networked and Managed Environments

As the world moves to an increasingly networked environment, applications need to become more manageable. Support for roaming users, remote administration, automatic updates of software, and other similar features are increasingly important and saleable in the enterprise.

For the Designed for Microsoft® Windows® Logo guidelines relating to this area, see the section titled Cooperate with Administrators.

Vendors can contribute a great deal to making their applications manageable in an enterprise environment. Writing all user-specific information to user-profile folders, for example, gives an end-user or administrator the option to store and manage the information on a remote, shared server, which makes possible the support of roaming users, remote installation, and policy-based management.

Note that both Windows 95 and Windows NT 4.0 support the use of remote user profiles today. For more information, see the Microsoft Windows 95 Resource Kit or the Microsoft Zero Administration Kit.

Windows NT 4.0 provides administrators the ability, through a single interface, to customize aspects of the user's environment and restrict the actions a given user can perform. This enables an administrator to reduce inadvertent actions by end-users and thereby greatly reduce application support costs.

The configuration that an administrator develops for users and computers is referred to as a system policy. The policy actually takes the form of a file that is parsed at logon. The registry settings contained in that file are applied to the registry on the client computer to create a specifically defined environment for the user. When a system policy is applied, the existing user-specific or computer-specific registry settings can be overwritten with the settings the administrator has established in the policy file. This gives the administrator the ability to set restrictions on the client computer and on the end-user.

These policy settings can be applied to a specific user account or computer. These policy settings can also be applied to the group membership of a set of users. With a properly implemented policy, regardless of where a user logs on, that user's environment can be customized to the administrator's specification.

For more information about how your applications can support a networked or managed environment, see http://www.microsoft.com/windows/zaw.


Managed Software Installation

With Windows NT® 5.0, Microsoft is delivering new installation and component management technology that will greatly simplify the installation and uninstallation of applications. This technology will function as a gateway to the registry, handling reference counting, component tracking, and other aspects of installation and uninstallation. Microsoft is working with major vendors of installation tools to ensure that toolkits will be available to take advantage of this new technology.

  • Use of the new managed installation technology for installation and uninstallation is a requirement for the Windows NT® 5.0 release.

Today's installation requirements and the recommended changes in registry usage reflect incremental steps toward a model in which registry entries will be managed by a central operating system service.

Applications that are developed using the new installation technology will be compliant by default with the majority of the installation and uninstallation Logo requirements.

See the section entitled Be Easy to Install and Remove for the specific Designed for Microsoft® Windows® Logo guidelines relating to installation and uninstallation.

Resources

For more information, see Introduction to New Microsoft Installer Technology .


Avoiding DLL Version Conflicts

A significant number of users have experienced problems because applications install new versions of shared DLLs that then fail to work with other applications that depend on them.

To avoid causing such DLL versioning problems with your application, it is very important to follow these three recommendations:

  • Do not write to Windows system directories.
  • Use Microsoft update packs to upgrade system components.
  • Do not install globally shared DLLs.

The only cost in following these recommendations is that your application will occupy slightly more disk space than it would if it relied on shared DLLs. The benefit is that you will not risk disrupting your users' environments.


Upcoming COM+ Technology

The future of COM is coming up soon. See http://www.microsoft.com/com for more information.

For Designed for Microsoft® Windows® Logo guidelines concerning new COM+ programming, see the section titled OLE / COM and COM+. These guidelines recommend that you support Microsoft Transaction Server, and expose all new object servers as COM+ objects.

Support the COM+ versioning and configuration model, COM+ declarative attributes, and COM+ events rather than custom event programming. Expose standard COM+ interfaces and take advantage of COM+ run-time interfaces and DLL functions. Do not write InprocServer32 entries for components directly to HKCR. Use COM+ calling conventions, COM+ automatic transaction support, persistence, data binding, and persistent event binding system. Implement system monitoring or call monitoring and management using interception. Use the COM+ importer, emitter, portable executable format, and run-time system where appropriate.


Upcoming Directory Services Technology

You may well want to take advantage of the new directory services being introduced with Windows NT® 5.0.

Designed for Microsoft® Windows® Logo guidelines in the Directory Services section recommend that you use a product-specific Directory Services object in the configuration/services container, use RpcNsBindingLookupBegin in RPC clients to find RPC server objects, and use WSALookupServiceBegin in clients to find Windows Sockets server objects. Locate COM objects in the Class Store transparently in COM and DCOM, and publish only computer-specific parameters in the registry.


Paperwork

You must complete the following paperwork to obtain the Designed for Microsoft® Windows® Logo:

Complete the Logo License.
You must sign the Microsoft Windows NT and Windows 95 Logo License Agreement, available by phone/fax service at (425) 635-2222, document #830, and submit it on paper with your product for testing.

Important Your signature on this contract does not mean that you can start using the Designed for Microsoft® Windows® Logo. It means only that you've agreed to the license terms and are awaiting your product's passage of the tests and the signing of the license by Microsoft.

Complete VeriTest's Testing Agreement.
You must sign the testing agreement from VeriTest, available by phone/fax service at (425) 635-2222, document #831, and submit it on paper with your product for testing.

Confidentiality Option. On the VeriTest Testing Agreement, you are given the option to keep your testing and test results confidential from Microsoft. If you choose this option, upon passing you must sign a release allowing VeriTest to send the results to Microsoft. Only after you sign this release can Microsoft grant you license to use the Logo.

Complete VeriTest's Online Vendor Questionnaire.
You must fill out the online VeriTest Vendor Questionnaire completely. This questionnaire is available on the VeriTest Web site, at http://www.veritest.com/microsoft.htm.

The more information you put in the Vendor Questionnaire, the better. This is where exceptions and requests for exemptions must be noted. Filling out the Vendor Questionnaire accurately and completely will ensure that your product is tested in the shortest amount of time possible.

After filling out the Questionnaire, click the Submit button, and you will receive a tracking number from VeriTest.

We recommend that you write this tracking number on your product disk or CD-ROM when you send it in for testing.


Pretesting

To receive the Designed for Microsoft® Windows® Logo, you are required to pretest your product's installation process, as described in Pretest the Install Process.

To ensure the best results and avoid retests, consider pretesting your product for compliance with other logo requirements as well. The pretesting techniques suggested in the following sections are designed to help your product pass on its first submission, to save you time and money.

It may also be helpful to check the Top Ten Reasons Why Applications Fail Logo Testing on the First Try at http://www.veritest.com/nt95top10.htm.

  • Pretesting for stability on Windows 95
  • Pretesting for stability on Windows NT
  • Pretesting high-contrast support
  • Pretesting exposure of keyboard focus
  • Pretesting UNC and LFN support
  • Pretesting ACPI/OnNow support


Pretest the Install Process (Required)

Before submitting your product to VeriTest for testing, you are required to pretest its installation procedure.

To pretest your product's installation, use the Installation Analyzer found at: http://www.veritest.com/installation_analyzer.htm.

To save yourself from having to retest, it is also a good idea to perform all relevant pretests listed in Pretesting.


Pretesting for Stability on Windows 95

The following is one of the tests we will run to test the stability of your product. You can use it to pretest your product prior to submitting for the Designed for Microsoft® Windows® Logo testing.

  1. Find the Stress application in the Platform SDK (\mstools\bin\win95\stress.exe).
  2. Select the following options:

    User Heap
    GDI Heap
    Wind32 Heap
    Menu32 Heap
    GDI32 Heap

    Set the Level to 2.

  3. Start the Stress program.
  4. With Stress running, start your product from its icon.
  5. Exercise all of your product's functions, and make sure they are stable even when the system is under stress.
  6. Switch video modes "on the fly," and make sure your product is still operational.
  7. Test that printing and all other input/output functions supported.
  8. Close Stress, and then start one popular 16-bit application and one popular 32-bit application to see whether your product will still run without problems while these are active.


Pretesting for Stability on Windows NT

The following is one of the tests we will run to test the stability of your product. You can use this test to pretest your product prior to submitting it for Designed for Microsoft® Windows® Logo testing.

  1. Start the Performance Monitor (Perfmon.exe).
  2. Choose to view counters from "Memory", "Objects", and any other object-types that are relevant to your application.
  3. Run your application for extended periods of time, exercising all of your product's functions, and ensure that all systematic changes in system resources are accounted for.
  4. Switch video modes "on the fly," and make sure your product is still operational (not supported on Windows NT prior to version 4.0).


Pretesting High-Contrast Support

  1. Open Control Panel, double-click Accessibility Options, and then click the Display tab.
  2. Click Settings and verify that White on Black is selected. Apply these settings.
  3. Go back into your product and test the major screens, dialog boxes, and controls to ensure that these changes have been properly reflected.

The application should still be usable.

Screen elements should be displayed correctly and be compatible with the appearance scheme. For example, make sure that text contrasts with its background, that graphics on toolbar buttons are distinguishable, and that menus and scroll bars have the appropriate sizes.

You can also experiment with appearance schemes by opening Control Panel, double-clicking Display, and then clicking the Appearance tab.


Pretesting Exposure of Keyboard Focus

Use the screen magnification accessory that is included with the Active Accessibility™ SDK (this will also be included in future versions of Windows).

The magnifier must accurately track the location of the keyboard focus when the focus is moved.

Check to ensure that the magnifier tracks the focus in documents and toolbars.


Pretesting UNC and LFN Support

The following sections describe the pretesting for Uniform Naming Convention (UNC) paths and Long File Names (LFNs).

Test direct network browsing with UNC paths

Open a file and then use the Save As command to save the file to a standard server with a Long File Name (LFN) and with various Uniform Naming Convention (UNC) paths (for example, \\ServerName\MySubdirectory\MyLongFileName).

  • It should be possible to save and retrieve files without specifically referring to a network drive letter.

Proper handling of LFNs

Basically, LFN handling must do the following:

  • Allow plus signs ( + ), commas ( , ), semicolons ( ; ), equal signs ( = ), and square brackets ( [ ] ) anywhere in the file name.
  • Not save leading or trailing spaces. You can test for this by removing the name inserted into the Save As dialog box, pressing the spacebar several times, typing "test", and then pressing the spacebar several more times. Your program should strip the spaces and add an extension, returning the file name "test.ext" (not " test .ext").
  • Not save question marks.
  • Support 255 characters (including the path and extension).
  • Save to a UNC path, such as \\Server\Directory\Filename.
  • Add an extension before saving a file. For example, "test." should be saved as "test.ext".

Testing proper LFN handling

Test each of the allowed file names in the following list. Note that the pound sign ( # ) in the names below is intended to represent a spacebar space:

test
test#test#test#test
test#1234567890[up to a total of 260 characters]

You should also test the following list of file names, which should be saved to the hard disk as indicated. Again, the pound sign ( # ) in the names below is intended to represent a spacebar space, and ext is intended to stand for the file extension that is appropriate to your application:

test                (should be saved as "test.ext")
###test             (should be saved as "test.ext")
test###             (should be saved as "test.ext")
test#;#+#,#=#[#]    (saved as "test#;#+#,#=#[#].ext")

\\folder#one\folder#two\folder#three\folder#four\file

Testing LFN Handling for Utilities:

  • Run the utility (your product), and manipulate several LFN files.
  • Open these files both with their LFNs and with their 8.3 aliases, and make sure both relate to the same file.
  • Check overall LFN file structure to ensure its integrity has not been damaged.


Pretesting ACPI/OnNow Support

The following sections describe the pretesting for ACPI/OnNow support.

Productivity Applications

Productivity applications can verify compliance with ACPI/OnNow recommendations using the following tests:

  • Open a file on a local hard disk, edit it (don't save), put the computer to sleep, wake the computer, and verify that the application continues to run, the file can be saved, and so forth.
  • Open a file on a hard disk in a docking station, edit it (don't save), put the computer to sleep, undock the computer, wake the computer, and verify that the application correctly informs the user of the problem and leads them through steps to correct the problem.
  • Open a file on the network, edit it (don't save), put the computer to sleep, wait a few minutes for the network connection to time out, wake the computer, and verify that the application continues to run, the file can be saved, and so forth.

Games

Games can verify compliance with ACPI/OnNow recommendations using the following test:

  1. While in game play, put the computer to sleep using the Sleep button or Start menu.
  2. Verify that the computer goes to sleep and sound stops playing.
  3. Wake the computer.
  4. Verify that the game play remains paused. After resuming game play, verify that the game continues to function normally (graphics, sound, and input devices continue to function as before).

Event-Handling Applications

Event-handling applications can verify compliance with ACPI/OnNow recommendations using the following test:

  1. In the Power control panel, set the system idle time as low as possible.
  2. Start the application and its event handling feature.
  3. Put the computer to sleep using the computer's Sleep button or using the Start Menu.
  4. Start an event that will take longer to process than the system idle time.
  5. Verify that the computer does not go to sleep while the event is being processed, and after the event has been processed, the computer goes to sleep immediately.

Presentation Applications

Presentation applications can verify compliance with ACPI/OnNow recommendations with the following test:

  1. In the Power control panel, set the system idle time as low as possible.
  2. Start the application and play a presentation.
  3. Wait for a time longer than the system idle time and verify that the computer does not go to sleep and that the display does not blank during that time.

Tips

  • Applications that need the computer to wake up quickly to respond to an event can call RequestWakeupLatency to notify the operating system to configure the computer to wake as quickly as the computer allows.
  • Applications that need to wake the computer at a certain time can do so using CreateWaitableTimer and associated functions.
  • Messaging applications can display the number of new messages on the computer's message waiting indicator panel by calling SetMessageWaitingIndicator.


Testing

Software applications are tested by an independent laboratory, VeriTest, Inc. For a current fee schedule and more information, see the VeriTest Web site at: http://www.veritest.com/microsoft.htm. You can also send e-mail, to logolab@veritest.com.

Note that all testing fees are to be paid to VeriTest, not to Microsoft.

When you submit your product to VeriTest, you must include all of the following:

  • Your software product (on floppy disk or CD-ROM).
  • The results of a pretest you have run on your product (see Pretesting).
  • A signed paper copy of the VeriTest Testing Agreement (see Paperwork).
  • A signed paper copy of the Windows NT® and Windows® 95 Logo License Agreement (see Paperwork).

We recommend that you write the tracking number that you received from VeriTest, after submitting the online Vendor Questionnaire, on the items you submit (see the section called Paperwork).


Notification

Notification of testing results is a multistep process:

  • You will receive test results from VeriTest within eight (8) business days from when your complete application package is received.
  • If you chose the Confidentiality Option in VeriTest's Testing Agreement (see Paperwork), you must provide VeriTest a signed release form before VeriTest will forward the test results to Microsoft. If you have not chosen the Confidentiality Option, VeriTest will send Microsoft a copy of the test results at the same time it sends them to you.
  • If your product passed testing, VeriTest will also send to Microsoft the license agreement that you previously signed and submitted with your product testing to VeriTest. Again, if you chose the Confidentiality Option, VeriTest will not send anything to Microsoft until you have provided a signed release form.
  • Microsoft will then sign the license agreement and send it to the person designated as the marketing contact in the Vendor Questionnaire you submitted.

    If your company already has product(s) licensed to use the Designed for Microsoft® Windows® Logo, Microsoft will send you an update to the license after we receive your positive test results. This update will reflect the addition of the new product(s) to the license. Your signature on this update is required to complete the process.

  • Now you can use the Logo!


Using the Logo

Before using the Logo, please read the Microsoft® Windows® and Microsoft® Windows NT® trademark guidelines available at:

http://www.microsoft.com/windows/thirdparty/winlogo/

Once your product has passed testing and you have received a copy of the Microsoft® Windows NT® and Windows® 95 Logo License Agreement signed by Microsoft, you can download an electronic copy of the Logo artwork kit from a secure web server using a password provided to you by VeriTest. This kit also contains electronic copies of the Logo and Logo usage guidelines.

Once signed by Microsoft, the Microsoft® Windows NT® and Windows® 95 Logo license allows you to use the Logo on packaging, advertising, your Web site, and other promotional materials.

If your product box will be printed before you obtain the license...

If your product box will be printed before you obtain the license to use the Designed for Microsoft® Windows NT® and Windows® 95 Logo, you can order Logo stickers from Special Effects, Seattle, WA (an outside vendor) at specialeffex@msn.com. The stickers will be delivered when you receive the license to use the Logo.


Important Restrictions on International and Localized Versions

Because of the differences in core components of Windows NT® and Windows® 95 when localized to a language other than English, the Logo can only be used for localized versions of a product that are in the same language group as the product that was tested. The following list shows the language groups:

Double Byte Language Group - Far East:
Japanese, Korean, Traditional Chinese (Taiwan Region), Simplified Chinese (PRC).
Single Byte Language Group - Western European:
English, German, French, Spanish, Swedish, Italian, Dutch, Portuguese/Brazilian, Portuguese/Iberian, Catalan.
Single Byte Language Group - Eastern European:
Finnish, Russian, Czech, Slovenian, Greek, Hungarian, Polish, Turkish, and Slovak.
Single Byte Language Group - Other:
Arabic, Hebrew, Thai, and Vietnamese.

An application must be submitted in the primary language version in which it is to be marketed (where the most units are expected to be sold). VeriTest will test the application using the matching localized versions of Windows NT and Windows 95. If the application passes testing, the Logo will be licensed only for use with that language version of the application and other languages within the same language group. For example, if an application is submitted in English and passes in English, the Logo may be used on the packaging and advertising for the English version and also any Western European language listed above, but, in a case like this, the Logo may not be used on the Japanese version (unless the application is also submitted and passes in Japanese or another Double Byte language.)

If the Logo is desired for a version of the application that is in another language group, a version of the application localized to a language in the intended group must be submitted and a retest fee will be applied to this testing. If the application passes testing in this new version, the Logo is licensed for use with that language version as well as other languages within the same language group.

You do not need to notify Microsoft if distributing the product internationally, unless distribution includes the PRC, Taiwan Region, or Korea. If you are distributing to these countries/regions, please send the Windows Logo Department (winlogo@microsoft.com) a note with your company name, title(s) being distributed, and countries/regions where they are being distributed. Please note the following language from the License Agreement:

The license right set forth in Section 2(a) shall not extend to the Taiwan Region, South Korea ("Korea"), or the People's Republic of China ("PRC"), unless and until COMPANY provides MS with written notice of COMPANY's intent to distribute Product in these countries/regions. COMPANY agrees not to use the Logo in such countries/regions and shall not be licensed pursuant to this Logo Agreement to do so until COMPANY has provided MS with such written notice.


Logo Requirements, Recommendations, and Best Practices

This reference section contains the formal specification for each programming guideline associated with the Designed for Microsoft® Windows® Logo. It includes three types of guidelines:

  • Requirements. Your application must comply with all of these before it can receive the Designed for Microsoft® Windows® Logo.
  • Recommendations. These guidelines are likely to become requirements in the future, so it is worth complying with them now.
  • Best Practices. These guidelines are designed to help make your application work consistently and well in a Microsoft Windows environment, particularly in large enterprises.

The Designed for Microsoft Windows Logo guidelines are divided into the following categories:

  • Provide consistent, up-to-date Windows support.
  • Be easy to Install and Remove.
  • Use the Registry correctly.
  • Save data to the best locations.
  • Cooperate with administrators.
  • Special requirements.
  • Testing rules.


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. Designed for Microsoft® Windows® Logo guidelines that relate to this goal are presented in the following categories:

  • General
  • File System
  • Operating-System Migration
  • Accessibility and User Interface
  • Internet
  • OLE / COM and COM+
  • Telephony
  • OnNow / ACPI
  • Directory Services


General

These are guidelines that relate to providing consistent, up-to-date support for Microsoft® Windows® in general:

  • Meet all requirements on the latest releases of Windows NT and Windows 95. (Required)
  • Support multiple platforms. (Required)
  • Make your application stable and fully functional. (Required)
  • Make your application 32-bit. (Required)
    • Identify 16-bit legacy versions clearly. (Required)
  • Support multiTasking. (Required)
  • Support standard system settings. (Required)
    • Support additional standard system settings. (Recommended)
    • Use standard system settings for multi-monitor support. (Best Practice)
  • Support Windows Sockets 2.0. (Recommended)
  • Detect and handle slow or dead network links. (Best Practice)


Meet All Requirements on the Latest Releases of Windows NT and Windows 95

Requirement (Designed for Microsoft® Windows® Logo)

Your application will be fully tested on the latest releases of both Windows NT Workstation (version 4.0 at the time of publication) and Windows 95. To receive the Designed for Microsoft® Windows® Logo, your application must pass this testing for all requirements on both systems.

If your application runs only on Windows 3.x or only on Windows 95, do not submit your application for this Logo (see Exception below). Similarly, if your application runs only on Windows NT or only on Windows NT 3.51 but not on Windows NT 4.0, do not submit your application for this Logo. There is no Microsoft Logo program for software that runs only on Windows NT.

Exception

If your application does not run on Windows NT because it uses Direct3D® or DirectSound®, you can submit your application for the Designed for Microsoft Windows® 95 Logo. To license this Logo, your application must pass all the same requirements as those required for the Designed for Microsoft® Windows® Logo, but your application is not required to run on Windows NT.

Only applications that fail on Windows NT because of their use of Direct3D or DirectSound are eligible for the Designed for Microsoft Windows® 95 Logo. The Designed for Microsoft Windows® 95 Logo is no longer available for any other applications. For more information, see Games and Multimedia Applications.


Support Multiple Platforms

Requirement (Designed for Microsoft® Windows® Logo)

Windows NT runs on multiple hardware platforms. Windows 95 is a single-platform operating system. You must provide a version of your application that runs on both Windows NT 4.0 and Windows 95. You can ship multiple platform versions (for example, different binaries that work on platforms such as Intel x86 or Alpha AXP) of your application in the same package. All multiple platform versions can be submitted simultaneously for testing.

  • If your product can be installed on multiple platforms from a single distribution media (for example, a CD-ROM), the installer must automatically detect the platform. It is not acceptable to ask the user which platform to install.
  • If you ship your application in a multiple-platform package that displays the Logo, you must include in that package a version of your application that runs on Windows 95. Similarly, any advertising or marketing materials you use that display the Logo must refer to a package that includes a version of the product that runs on Windows 95.


Make Your Application Stable and Fully Functional

Requirement (Designed for Microsoft® Windows® Logo)

Your application must be fully functional and stable on the most recent versions of both the Windows NT and Windows 95 operating systems. Vigorous stability testing must confirm that your product does not adversely affect the overall stability of Windows NT or Windows 95.

See Also

See the following topics for a description of pretesting you can do to help ensure that your application is stable on Windows 95 and Windows NT:

  • Pretesting for stability on Windows 95
  • Pretesting for stability on Windows NT


Make Your Application 32-bit

Requirement (Designed for Microsoft® Windows® Logo)

Your application must be a Win32® application programming interface executable file compiled with a 32-bit compiler that generates an executable file of the PE (Portable Executable) format ("[PE_Win32]" as reported by the Exedump program in the Platform SDK). This means that all the major program files (DLLs and EXEs) must be 32-bit (see Exceptions below).

Exceptions

Fully 32-bit code allows applications to ship a single binary that works on Windows 95, Windows 98, and Windows NT. Otherwise, it may be necessary to ship different binaries for different operating systems. On Windows NT, for example, thunks allow applications to call from 16-bit to 32-bit code, but calling from 32-bit to 16-bit code is not supported. On Windows 95, thunks allow applications to call in both directions. As a result, for Windows NT you may need to ship 32-bit code to replace 16-bit code that works on Windows 95.

Applications executed by a run-time engine
If your application is executed by a run-time engine (interpreted code, for example), then it need not be represented in PE format. However, the run-time engine that executes it must be a Win32-based executable file in the PE format. For example, if you develop an application in Microsoft® Access, your application is an .mdb file, not an .exe, but Access.exe must be a Win32-based executable file in the PE format.
Conditions for inclusion of small amounts of 16-bit code
Under the following circumstances, certain 16-bit code elements can be included in your product:
  • Some minor, subsidiary 16-bit executable files and dynamic-link libraries (DLLs) can be used to provide backward compatibility and links to 16-bit products. However, your main program files (including DLLs) must be 32-bit.
  • Other minor, subsidiary 16-bit executable files and DLLs can be used for convenience in a very limited fashion but only if there is no existing 32-bit version of the DLL you need for your application. These files cannot constitute a significant portion of the product.
  • You must fully explain all instances of 16-bit code when you submit your product for testing. This must be done in the electronic Vendor Questionnaire you submit with your application.
Special Case: Utilities
Certain components of utilities can be 16-bit, such as those that must use the Exclusive Volume Locking function, soft interrupts, or components that must communicate directly to 16-bit drivers. The user interface and other components of these applications must be 32-bit and use the Windows 95 thunking mechanism to access these 16-bit components.


Identify 16-Bit Legacy Versions Clearly

Requirement (Designed for Microsoft® Windows® Logo)

The Logo program is for 32-bit Windows-based applications. However, vendors can distribute 16-bit versions of their product on the same distribution media as the 32-bit Logo tested product. Vendors can only do this if the installer clearly distinguishes the difference between the 16-bit product and the 32-bit product that has qualified for the Designed for Microsoft Windows Logo. A message such as the following must be included:

Do you also wish to install Product Y? This is a 16-bit product that is not designed for Microsoft Windows NT and Microsoft Windows 95 but must operate in this environment.


Support MultiTasking

Requirement (Designed for Microsoft® Windows® Logo)

Your application must support multitasking. It must support either alt+tab or ctrl+esc to switch focus from full screen to the desktop.


Support Standard System Settings

Requirement (Designed for Microsoft® Windows® Logo)

Your application must be compatible with the following system color, size, font, sound, and input settings (color settings are required only when the High Contrast option is turned on):

Required Size Settings
SM_CXFIXEDFRAME,        SM_CYFIXEDFRAME
SM_CXDLGFRAME,          SM_CYDLGFRAME
SM_CXMENUSIZE,          SM_CYMENUSIZE
SM_CXSIZEFRAME,         SM_CYSIZEFRAME
SM_CXFRAME,             SM_CYFRAME
SM_CXVSCROLL,           SM_CYVSCROLL
SM_CXSCREEN,            SM_CYSCREEN
SM_CXFULLSCREEN,        SM_CYFULLSCREEN
SM_CXMAXIMIZED,         SM_CYMAXIMIZED
SM_CXTRACK,             SM_CYTRACK
SM_CYMENU
SM_CYCAPTION
SM_CYSMCAPTION
SPI_GETICONTITLELOGFONT
SPI_GETNONCLIENTMETRICS
SPI_GETBORDER
SPI_GETWORKAREA
Required Color Settings
SPI_GETHIGHCONTRAST    (All GetSysColor settings are required
                        when SPI_GETHIGHCONTRAST is TRUE)
Required Input Settings
SM_CXDOUBLECLK,         SM_CYDOUBLECLK
SM_CXDRAG,              SM_CYDRAG
SPI_GETKEYBOARDPREF
Required Sound Settings
SM_SHOWSOUNDS
SPI_GETSHOWSOUNDS

Remarks

Support for these system settings is required to provide users with a consistent user interface and allow them to customize the system to meet their needs and preferences.

These settings are queried using the GetSystemMetrics, SystemParametersInfo, or GetSysColors functions.

Standard window classes and controls automatically support all of the settings required here. Applications only need to be aware of these settings when creating custom window classes or controls.

See Also

For more information, see the accessibility guidelines for application developers at http://microsoft.com/enable/.


Support Additional Standard System Settings

Recommendation (Designed for Microsoft® Windows® Logo)

In addition to the required system settings listed in Support standard system settings, applications should be compatible with the following recommended system settings.

Recommended Size Settings
SM_CXMENUCHECK,      SM_CYMENUCHECK
SM_CXSIZE,           SM_CYSIZE
SM_CXSMSIZE,         SM_CYSMSIZE
SM_CXICON,           SM_CYICON
SM_CXICONSPACING,    SM_CYICONSPACING
SPI_ICONHORIZONTALSPACING
SPI_ICONVERTICALSPACING
SPI_GETICONTITLEWRAP
SPI_GETICONMETRICS
Recommended Sound Settings
SPI_GETBEEP
Recommended Input Settings
SPI_GETMOUSEHOVERHEIGHT
SPI_GETMOUSEHOVERWIDTH
SPI_GETMOUSEHOVERTIME
SM_SWAPBUTTON
Other Recommended Settings
SPI_GETSCREENREADER
SPI_GETMENUDROPALIGNMENT

Remarks

Support for these system settings helps provide users with a consistent user interface and allows them to customize the system to meet their needs and preferences.

These settings are queried using the GetSystemMetrics, SystemParametersInfo, or GetSysColors functions.


Use Standard System Settings for Multi-Monitor Support

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should make use of the following system settings to be compatible with multi-monitor support.

Recommended Multi-Monitor System Settings
SM_XVIRTUALSCREEN,           SM_YVIRTUALSCREEN
SM_CXVIRTUALSCREEN,          SM_CYVIRTUALSCREEN
SM_SAMEDISPLAYFORMAT
SM_CMONITORS

Remarks

These settings are queried using the GetSystemMetrics function.


Support Windows Sockets 2.0

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should support Windows Sockets (WinSock) 2.0.

Support for the Broadcast PC capabilities of future versions of Windows will require WinSock 2 support.


Detect and Handle Slow or Dead Network Links

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should use the MultinetGetConnectionPerformance function and/or other means to detect slow and dead network links and should handle them gracefully.

In the case of a dead link, this means not timing out after a reasonable period, and if appropriate, alerting the user that the network connection could not be established.

In the case of a slow link, this means providing the user an opportunity to cancel potentially lengthy operations, degrading gracefully where possible, and asking before initiating operations unsuitable over a slow link.


File System

These are guidelines that relate to providing consistent, up-to-date file system support for Microsoft® Windows®:

  • Do not assume a hard-drive size limit of 2 GB. (Required)
  • Support the Universal Naming Convention (UNC). (Required)
  • Support long file names for files exposed to users. (Required)
  • Support long file names for files exposed in Windows Explorer. (Required)
  • Use long file names in user-interface elements. (Required)
  • Test LFN functionality on Windows NT FAT, NTFS, and compressed NTFS partitions. (Required)
  • Be file-system independent. (Best Practice)
  • Hide program files and directories that users do not need to see. (Best Practice)


Do Not Assume a Hard-Drive Size Limit of 2 GB

Requirement (Designed for Microsoft® Windows® Logo)

Your application should not assume a 2 GB hard-drive size limit. On drives larger than 2 GB, FAT32 is the only file system on Windows that allows the user to format the disk as a single partition.

On Windows 95, the existing Win32 function, GetDiskFreeSpace, may obtain incorrect values for volumes that are larger than 2 GB; whereas GetDiskFreeSpaceEx obtains correct values on all platforms for all volumes, including those that are larger than 2 GB. New applications should use GetDiskFreeSpaceEx instead of GetDiskFreeSpace.


Support the Universal Naming Convention (UNC)

Requirement (Designed for Microsoft® Windows® Logo)

Your application must support the Uniform Naming Convention (UNC). UNC paths allow logical connections to network devices without the need to specifically reference a network drive letter.

Your application must work seamlessly in a network environment but is not necessarily required to be network aware. Your application must be able to locate the network server and path with the UNC name even over a modem connection.

Supporting UNC does not mean that the application is disallowed from presenting network drive letters to users. It merely means that the user must have the option of using only the UNC path name.

Remarks

A long file name (LFN) is 260 characters long, which generally includes:

  • 3 bytes for "<driveletter>:\"
  • 255 bytes for the file name and extension
  • 2 bytes for the null terminator

A UNC path has 2 bytes for "\\" instead of 3 bytes for "<driveletter>:\", and the path may not include an extension (file type).

Exception

Non-File-Based Applications are not required to provide UNC support.

See Also

See Pretesting UNC and LFN support for a description of pretesting you can do to ensure that your application provides proper UNC and LFN support.


Support Long File Names for Files Exposed to Users

Requirement (Designed for Microsoft® Windows® Logo)

If the application saves files that are exposed to the user, the application must support long file names (LFNs) with all of the following required features:

  • Users must be able to enter names of 255 characters including all uppercase and lowercase standard characters, embedded spaces, embedded periods, and so forth.
  • Leading and trailing spaces must be stripped by the Save As command. To test this, enter a name with leading and trailing spaces, such as "####This is a test###", retrieve the file, and then make sure the spaces are deleted (the pound sign, #, indicates a spacebar space).
  • Question marks anywhere in the file name must prevent the file from being saved. No error message needs to be displayed.
  • The following characters must be supported anywhere in the name, including leading and trailing positions, without causing any error conditions:
    +    (plus sign)
,    (comma)
;    (semicolon)
=    (equal sign)
[    (opening square brace)
]    (closing square brace)

Remarks

Support for leading and trailing periods ( . ) has been dropped from the Logo requirements.

An LFN is 260 characters long, which generally includes:

  • 3 bytes for "<driveletter>:\"
  • 255 bytes for the file name and extension
  • 2 bytes for the null terminator

A Uniform Naming Convention (UNC) path has 2 bytes for "\\" instead of 3 bytes for "<driveletter>:\", and the path may not include an extension (file type).

See Also

See Pretesting UNC and LFN support for a description of pretesting you can do to ensure that your application provides proper UNC and LFN support.


Support Long File Names for Files Exposed in Windows Explorer

Requirement (Designed for Microsoft® Windows® Logo)

If a file name is fully exposed in Microsoft® Windows® Explorer, it must be a fully supported long file name (LFN). Applications are allowed to use "labeling schemes" in which a user is saving, for example, a report type or a game state without actually creating a file that is exposed to the user in Windows Explorer.

See Also

See Pretesting UNC and LFN support for a description of pretesting you can do to ensure that your application provides proper UNC and LFN support.


Use Long File Names in User-Interface Elements

Requirement (Designed for Microsoft® Windows® Logo)

Your application must use long file names (LFNs) to display all documents and data files in the shell, title bars, dialog boxes, controls, and icons.


Test LFN Functionality on Windows NT FAT, NTFS, and Compressed NTFS Partitions

Requirement (Designed for Microsoft® Windows® Logo)

You must test your LFN functionality on Windows NT FAT, NTFS, and compressed NTFS partitions.

See Also

See Pretesting UNC and LFN support for a description of pretesting you can do to ensure that your application provides proper UNC and LFN support. By running these tests on different kinds of partitions, you can ensure that this requirement is met.


Be File-System Independent

Best Practice (Designed for Microsoft® Windows® Logo)

An application written for the Windows operating system must exhibit its full functionality regardless of the file system of the partition upon which it is installed.

For most applications, this guideline is not a problem (most applications are file-system independent).

However, some applications and device drivers such as disk utilities and anti-virus utilities specifically rely on a partition type. For example, a disk defragmenter written for a FAT16 partition will not work for a FAT32 partition. The disk defragmenter should include support to defragment both FAT16 and FAT32 partitions.


Hide Program Files and Directories That Users Do Not Need To See

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should use the Hidden attribute to hide program files and folders that a user does not need to access directly.

Remarks

This guideline simplifies the user's view of the file system and helps prevent inadvertent deletion of files needed by the application.


Operating-System Migration

These are guidelines that relate to providing consistent, up-to-date support for upgrading a computer from one version of Microsoft® Windows® to another:

  • Provide a Migration DLL where necessary. (Required)
  • Migration DLLs work silently. (Recommended)
  • Avoid operating system differences. (Best Practice)


Provide a Migration DLL Where Necessary

Requirement (Designed for Microsoft® Windows® Logo)

Your application must migrate seamlessly from Windows 95 to Windows NT 5.0. So if an application is installed on Windows 95 and the operating system is upgraded to Windows NT 5.0, the application must remain fully functional after the operating system upgrade.

If this is not the case automatically, the application vendor must develop and make available to users a Migration DLL as described in the Windows 95 to Windows NT 5.0 Migration Kit and the Migration Extension Interface Reference.

The Migration DLL should perform all tasks necessary to make the Windows 95 version of the application functional on Windows NT 5.0 after an operating system upgrade. This includes modifying or adding new registry entries and copying new files to their proper locations on Windows NT 5.0.

See Also

This upgrade DLL should be tested by installing the application on Windows 95 and then upgrading it to Windows NT version 5.0 or later using the rules described in the Windows 95 to Windows NT Migration Kit (to be available with Windows NT 5.0 Beta 1) and the Migration Extension Interface Reference. Watch for more information on Windows 95 to Windows NT 5.0 migration at http://www.microsoft.com/


Migration DLLs Work Silently

Recommendation (Designed for Microsoft® Windows® Logo)

During an upgrade, a Migration DLL should not require user interaction or display a user interface to the end user.


Avoid Operating System Differences

Best Practice (Designed for Microsoft® Windows® Logo)

You should ensure that the differences between the Windows 95 and the Windows NT versions of your application are minimal.

Therefore, it is recommended that you review your application to ensure that it:

  • Does not write to different registry locations on Windows 95 and Windows NT (registry values may also be different).
  • Does not install different files (.dll, .exe, and so forth) on the two operating systems (or additional files on Windows 95).
  • Does not install different versions of files that are common to both Windows 95 and Windows NT.
  • Does not make operating-system-specific calls on Windows 95 that are not available on Windows NT.


Accessibility and User Interface

These are guidelines that relate to providing consistent, up-to-date support for accessibility under Microsoft® Windows®, and for other user-interface standards:

  • Be compatible with the High Contrast option. (Required)
  • Provide keyboard access to all features. (Required)
  • Document the keyboard user interface. (Required)
  • Provide notifications of the keyboard focus location. (Required)
  • Do not rely on sound alone. (Recommended)
  • Do not rely on color alone. (Recommended)
  • Let other software identify and manipulate screen elements. (Recommended)
  • Support Active Accessibility. (Best Practice)
  • Do not hard-code font sizes smaller than 10 points. (Best Practice)
  • Allow users to customize UI timings. (Best Practice)
  • Support system font and resolution changes. (Best Practice)
  • Allow users to set font names and sizes. (Best Practice)
  • Handle changes in pointer or keyboard focus. (Best Practice)
  • Test using multiple displays. (Best Practice)


Be Compatible With the High Contrast Option

Requirement (Designed for Microsoft® Windows® Logo)

Your application must be compatible with the High Contrast option, which indicates that the user wants a high degree of legibility. When this option is set, the application must use only system colors selected through Control Panel or other colors that the user can customize. Because documents are typically shared, a user must not be required to alter a document to adjust the colors drawn on the screen. System colors must be used in their proper foreground/background combinations.

Remarks

To determine how much space the tray takes up on the screen and how much is left over, use either the GetSystemMetrics function to query SM_CXFULLSCREEN and SM_CYFULLSCREEN or use the SystemParametersInfo function to query SPI_GETWORKAREA.

Exceptions

Palettes where the user selects a color may continue to display their full range of fixed colors. Games and certain multimedia applications may have aesthetic and design considerations, such as custom dialog boxes and user interface elements where system settings are inappropriate. Games, certain multimedia applications, and inherently graphical applications such as image editing tools may also be exceptions to color requirements. These are judged on a case-by-case basis. You must detail these exceptions in your Vendor Questionnaire.

Java applications are temporarily exempt from supporting High Contrast. Vendors should expect this temporary exemption to be removed from future versions of the Logo program when popular class libraries such as AFC 4.0 provide support for this feature.

See Also

See Pretesting High-Contrast support for a description of pretesting you can do to ensure that your application properly supports High Contrast.

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Provide Keyboard Access to All Features

Requirement (Designed for Microsoft® Windows® Logo)

Your application must provide keyboard access to all features.

Exceptions

Exceptions may be made in the following cases:

  • Games that are dependent upon the use of a mouse or joystick. It is recommended, but not required, that games provide keyboard support where feasible. They should not require a pointing device except where it is unavoidable due to the nature of the game.
  • CAD and similar applications that are dependent upon graphing tablets and other input devices.
  • Applications that are entirely graphical, such as image editors, may rely on the MouseKeys feature built into the 32-bit Windows operating systems to allow users to move the mouse pointer. However, this is not acceptable for drawing applications that allow the user to independently manipulate separate text and graphic objects.

Exceptions may be made for minor features that are not required for operation of the program, when the major features in the application have keyboard access. All major features or functional areas without keyboard access should be explained in the Vendor Questionnaire.

Java applications are temporarily exempt from supporting full functionality through the keyboard. Vendors should expect this temporary exemption to be removed from future versions of the Logo program when popular class libraries such as AFC 4.0 provide support for this feature.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Document the Keyboard User Interface

Requirement (Designed for Microsoft® Windows® Logo)

The keyboard user interface must be documented.

Remarks

Implementation information may be provided in your standard documentation that is included with the application, or it may be orderable separately. In the latter case, it is strongly recommended that the standard documentation inform the user that this additional documentation is available.

Exception

It is not necessary to document elements that simply follow the Windows conventions for elements such as standard menus and controls.


Provide Notifications of the Keyboard Focus Location

Requirement (Designed for Microsoft® Windows® Logo)

Your application must notify other software of the locations of the keyboard focus, either by moving the system caret or by using Microsoft® Active Accessibility™.

Remarks

This requirement enables the use of accessibility aids such as the screen magnification accessory included with the Active Accessibility SDK. This accessory will be included in future versions of the Windows operating systems.

Exceptions

Development tools are temporarily exempt from the requirement to expose the keyboard focus. Vendors should be aware that this exemption will be removed in the next update of the Logo guidelines.

Java applications are also temporarily exempt from exposing the keyboard focus. Vendors should expect this temporary exemption to be removed from future versions of the Logo program when popular class libraries such as AFC 4.0 provide support for this feature.

See Also

See Pretesting exposure of keyboard focus for a description of pretesting you can do to ensure that your application properly supports notification of keyboard focus location.

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Do Not Rely on Sound Alone

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should not convey any important information by sound alone. If sound alone is the default method for conveying the information, the application should provide an option to convey this information by other means.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Do Not Rely on Color Alone

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should not convey important information by color alone. If color alone is the default method for conveying the information, the application should provide an option to convey this information by other means.


Let Other Software Identify and Manipulate Screen Elements

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should allow other software to identify and manipulate all screen elements that the user interacts with. This should be accomplished by supporting Microsoft® Active Accessibility™.

This recommendation will become a requirement in the future and may require significant work to accomplish. It is strongly recommended that vendors begin planning for this as soon as possible.

Remarks

Standard window classes and controls automatically support this mechanism. Applications only need to add additional support when creating custom window classes or controls or when drawing content in their window client area.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Support Active Accessibility

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should support Microsoft® Active Accessibility™.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/


Do Not Hard-Code Font Sizes Smaller Than 10 Points

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should avoid hard-coding any font sizes smaller than 10 points. Small fonts can cause eyestrain and are difficult for many people to read.


Allow Users to Customize UI Timings

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should allow the user to customize all user interface timings that are not based on standard system settings.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Support System Font and Resolution Changes

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should be compatible with changes to the system font size and with changes to the number of pixels per logical inch.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Allow Users to Set Font Names and Sizes

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should allow the user to choose font names and font sizes to make the document or window content more legible.


Handle Changes in Pointer or Keyboard Focus

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should not trigger unexpected side effects based on changes in pointer or keyboard focus locations.

See Also

For more information on accessibility guidelines for application developers, see http://microsoft.com/enable/.


Test Using Multiple Displays

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should be tested for multiple display support to verify correct behavior when two or more displays are attached to the desktop.

You should test your application for dialog boxes or windows positioned on a monitor other than the one expected and for windows that are prevented from moving to a secondary display.


Internet

These are guidelines that relate to providing consistent, up-to-date support for the Internet on Microsoft® Windows®:

  • Digitally sign ActiveX controls. (Required)
  • Support Authenticode signing of downloadable code. (Required)
  • Support automatic download of ActiveX controls. (Best Practice)
  • Register an Internet update site when installing. (Best Practice)
  • Register a product information site when installing. (Best Practice)
  • Support ModuleUsage registration of DLLs. (Best Practice)
  • Expose Help documentation as HTML. (Recommended)
  • Support saving to an FTP site. (Best Practice)
  • Generate browsable output. (Best Practice)


Digitally Sign ActiveX Controls

Requirement (Designed for Microsoft® Windows® Logo)

Authors of ActiveX™ controls must digitally sign their controls as specified in the ActiveX SDK. Controls should also be marked "safe for persistence" as appropriate.

See Also

For more information, see the Microsoft ActiveX SDK at http://www.microsoft.com/IntDev/sdk.


Support Authenticode Signing of Downloadable Code

Requirement (Designed for Microsoft® Windows® Logo)

Any code intended to be downloaded from the Internet must support Authenticode signing. Commercial publishers can obtain a digital signature at http://www.microsoft.com/workshop/prog/security/authcode/certs-f.htm.

Executables must be signed to allow users to identify provenance using procedures and technology found at http://www.microsoft.com/workshop/prog/security/authcode/codesign-f.htm.


Support Automatic Download of ActiveX Controls

Best Practice (Designed for Microsoft® Windows® Logo)

Authors of ActiveX™ controls should provide support for automatic code download. If the control is a single file, no additional work is required. If multiple files are required, a .cab, .inf, or a self-extracting executable should be provided.

See Also

For more information, see the Internet Component Download specification in the Microsoft ActiveX SDK, at http://www.microsoft.com/IntDev/sdk.


Register an Internet Update Site When Installing

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should register an Internet update site for the application when installing. This site will provide information about upgrades available for the application. Upgrades should be made available for user-initiated download.

See Also

For information about how to include this URL in the registry, see Support informational keys in the registry.


Register a Product Information Site When Installing

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should register a general product information site when installing.

See Also

For information about how to include this URL in the registry, see Support informational keys in the registry.


Support ModuleUsage Registration of DLLs

Best Practice (Designed for Microsoft® Windows® Logo)

Applications, tools, controls, or any other software that installs or sets up DLLs should honor the ModuleUsage registry section described in the Microsoft ActiveX SDK.

See Also

For more information, see the ActiveX SDK at http://www.microsoft.com/IntDev/sdk.


Expose Help Documentation as HTML

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should expose Help files as HTML. Over time, Microsoft will phase out support for the Windows Help engine and replace it with World Wide Web-based help.


Support Saving to an FTP Site

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should have an FTP Save option enabling users to save to an FTP site the same way they save to the local drive or to a network drive.


Generate Browsable Output

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should produce documents that can be viewed from a browser. You can do this either by implementing a Save As HTML feature or by adding ActiveX document (docobj) support to the application.

See Also

For more information about adding ActiveX documents, see the ActiveX SDK at http://www.microsoft.com/IntDev/sdk.


OLE / COM and COM+

These are guidelines that relate to providing consistent, up-to-date support for OLE, COM, DCOM, and the new COM+ technology on Microsoft® Windows®:

OLE / COM

  • Provide an OLE container or object server. (Required)
  • Allow users to drag objects to any container. (Required)
  • Implement IDropTarget and/or IDropSource interfaces in containers . (Required)
  • Test object servers for basic OLE functionality. (Required)
  • Test containers for basic OLE container functionality. (Required)
  • Place an Object command on a container's Insert menu. (Required)
  • Make object servers ActiveX document servers. (Recommended)
  • Make containers ActiveX document containers. (Recommended)
  • Close object servers automatically after object delivery. (Recommended)
  • Support ActiveX Accessibility in containers. (Recommended)
  • Support modifier keys in containers. (Recommended)
  • Provide linking and in-place activation in containers. (Recommended)
  • Support the structured storage compound file format in containers. (Recommended)
  • Use component categories. (Best Practice)
  • Use the system property set implementation. (Best Practice)
  • Provide a type library for public automation interfaces. (Best Practice)

COM+

  • Support Microsoft Transaction Server. (Best Practice)
  • Expose all new object servers as COM+ objects. (Best Practice)
  • Support the COM+ versioning and configuration model. (Best Practice)
  • Use COM+ calling conventions. (Best Practice)
  • Support COM+ events rather than custom event programming. (Best Practice)
  • Expose standard COM+ interfaces. (Best Practice)
  • Take advantage of COM+ run-time interfaces. (Best Practice)
  • Take advantage of COM+ run-time DLL functions. (Best Practice)
  • Do not write InprocServer32 entries for components directly to HKCR. (Best Practice)
  • Support COM+ declarative attributes. (Best Practice)
  • Use COM+ automatic transaction support, persistence, and data binding as necessary. (Best Practice)
  • Implement system monitoring or call monitoring and management using interception. (Best Practice)
  • Use the COM+ persistent event binding system. (Best Practice)
  • Use the COM+ importer, emitter, portable executable format, and run-time system. (Best Practice)


Provide an OLE Container or Object Server

Requirement (Designed for Microsoft® Windows® Logo)

Your application must be an OLE container or object server. Although an application can be both a server and a container, it is not required to be both.

Remarks

If you want to host Java or ActiveX controls in your application, you should make your application an OLE container.

See Also

For more information, developers should read Inside COM by Dale Rogerson, published by Microsoft Press (1997).


Allow Users to Drag Objects to Any Container

Requirement (Designed for Microsoft® Windows® Logo)

The user must be able to drag the object to any container, including other internal documents, the desktop, or documents in another OLE-supporting application.

Exception

Development Tools are not required to provide drag-and-drop support within the tool's design environment.


Implement IDropTarget and/or IDropSource Interfaces in Containers

Requirement (Designed for Microsoft® Windows® Logo)

Containers must implement the IDropTarget and/or IDropSource interfaces for drag-and-drop functionality. This means that the application can accept drops from any IDropSource or can drag into any IDropTarget, or both.

Remarks

If you use the Windows 95 and Windows NT common controls, or the RichEdit control for your edit controls, your application already has support for drag-and-drop.

Exception

Development Tools are not required to provide drag-and-drop support within the tool's design environment.


Test Object Servers for Basic OLE Functionality

Requirement (Designed for Microsoft® Windows® Logo)

Object servers must pass basic OLE server functionality testing. You can test this by dragging an object created by your product into an application such as Microsoft® Word.


Test Containers for Basic OLE Container Functionality

Requirement (Designed for Microsoft® Windows® Logo)

Your application must pass basic OLE container functionality testing. You can test this by creating an object in any standard OLE server, such as Microsoft Word, and dragging it into your application.


Place an Object Command on a Container's Insert Menu

Requirement (Designed for Microsoft® Windows® Logo)

Containers must provide an Object command on the Insert menu.


Make Object Servers ActiveX Document Servers

Recommendation (Designed for Microsoft® Windows® Logo)

All object servers should be ActiveX™ document servers.


Make Containers ActiveX Document Containers

Recommendation (Designed for Microsoft® Windows® Logo)

All containers should be ActiveX™ document containers.


Close Object Servers Automatically After Object Delivery

Recommendation (Designed for Microsoft® Windows® Logo)

An object server should close automatically after delivering an object.


Support ActiveX Accessibility in Containers

Recommendation (Designed for Microsoft® Windows® Logo)

Containers should support ActiveX™ Accessibility.


Support Modifier Keys in Containers

Recommendation (Designed for Microsoft® Windows® Logo)

Containers should provide support for modifier keys.


Provide Linking and In-place Activation in Containers

Recommendation (Designed for Microsoft® Windows® Logo)

Containers should provide linking and in-place activation.


Support the Structured Storage Compound File Format in Containers

Recommendation (Designed for Microsoft® Windows® Logo)

Containers should support the structured storage compound file format. Summary information should be usable and complete as presented by the 32-bit Microsoft Windows operating system user interface.


Use Component Categories

Best Practice (Designed for Microsoft® Windows® Logo)

Applications should use component categories. In particular, containers should indicate which standard component categories they support. Also, component categories should be used in preference to adding a key, such as Control, under a component CLSID registry key.

Remarks

This best practice allows an object to publish its capabilities to other objects.

See Also

For more information, see Control and Container Guidelines in the Platform SDK.


Use the System Property Set Implementation

Best Practice (Designed for Microsoft® Windows® Logo)

The system-provided property set implementation should be used to read and write all property sets supported by an application.


Provide a Type Library for Public Automation Interfaces

Best Practice (Designed for Microsoft® Windows® Logo)

Applications that expose a public Automation interface should provide a type library.


Support Microsoft Transaction Server

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should provide support for Microsoft Transaction Server. Among the requirements for Microsoft Transaction Server support are:

  • Deploy the application as a Microsoft Transaction Server package.
  • Use Microsoft Transaction Server for context management.
  • Use a Microsoft Transaction Server resource dispenser.
  • Use role-based security.

See Also

For information about Microsoft Transaction Server, see the appropriate topics in the Platform SDK and at http://www.microsoft.com/com.


Expose All New Object Servers as COM+ Objects

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should expose all new object servers (whether application servers, document servers, or other types of object server) as COM+ objects.

Remarks

Most applications should accomplish this best practice by using a compiler that can generate COM+ executables.

Tools vendors may need to use the COM+ Meta data, calling conventions, and executable formats directly.

See Also

For information about COM+, see http://www.microsoft.com/com.


Support the COM+ Versioning and Configuration Model

Best Practice (Designed for Microsoft® Windows® Logo)

The client application should support the COM+ versioning and configuration model.

Remarks

Most applications should implement this best practice by using a compiler that can generate COM+ executables.

Tools vendors may need to support the COM+ executable format directly. by compiling client applications in a COM+ compatible tool or by supporting the COM+ executable format [only for tools vendors]

See Also

For information about COM+, see http://www.microsoft.com/com.


Use COM+ Calling Conventions

Best Practice (Designed for Microsoft® Windows® Logo)

Applications should avoid using direct (native) code for calling within or between objects to enable interception; instead, they should always use the COM+ calling conventions.

See Also

For information about COM+, see http://www.microsoft.com/com.


Support COM+ Events Rather Than Custom Event Programming

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should support COM+ events instead of custom event programming with callback functions.

See Also

For information about COM+, see http://www.microsoft.com/com.


Expose Standard COM+ Interfaces

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should expose COM+ interfaces that are callable by all COM+ compatible languages. To achieve this, the application should only use established COM+ data types and calling conventions.

See Also

For information about COM+, see http://www.microsoft.com/com.


Take Advantage of COM+ Run-Time Interfaces

Best Practice (Designed for Microsoft® Windows® Logo)

Your application supporting COM+ objects does not have to implement any of the following interfaces supplied by the COM+ run time:

  • IUnkown
  • IDispatch
  • IProvideClassInfo
  • IProvideErrorInfo
  • IClassFactory
  • IConnectionPointContainer
  • IConnectionPoint

See Also

For information about COM+, see http://www.microsoft.com/com.


Take Advantage of COM+ Run-Time DLL Functions

Best Practice (Designed for Microsoft® Windows® Logo)

Your application supporting COM+ objects does not have to expose any of the following COM+ DLL API functions that are exposed by the COM+ run time:

  • DllRegisterServer
  • DllUnregisterServer
  • DllGetClassObject

See Also

For information about COM+, see http://www.microsoft.com/com.


Do Not Write InprocServer32 Entries for Components Directly to HKCR

Best Practice (Designed for Microsoft® Windows® Logo)

Components should not write entries directly to the registry for HKEY_CLASSES_ROOT under their class ID (CLSID) for the InprocServer32 entry.

See Also

For information about COM+, see http://www.microsoft.com/com.


Support COM+ Declarative Attributes

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should support COM+ declarative attributes.

See Also

For information about COM+, see http://www.microsoft.com/com.


Use COM+ Automatic Transaction Support, Persistence, and Data Binding as Necessary

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should use COM+ automatic transaction support, persistence, and data binding, as necessary.

See Also

For information about COM+, see http://www.microsoft.com/com.


Implement System Monitoring Or Call Monitoring And Management Using Interception

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should implement system monitoring or call monitoring and management code by using interception.

See Also

For information about COM+, see http://www.microsoft.com/com.


Use the COM+ Persistent Event Binding System

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should use the COM+ persistent event binding system for triggering events that require administrative control.

An example of such an event is sending an e-mail message when certain conditions occur.

See Also

For information about COM+, see http://www.microsoft.com/com.


Use the COM+ Importer, Emitter, Portable Executable Format, and Run-Time System

Best Practice (Designed for Microsoft® Windows® Logo)

Tool vendors should target the generation and consumption of COM+ objects by using the COM+ importer, emitter, portable executable format, and run-time system.

See Also

For information about COM+, see http://www.microsoft.com/com.


Telephony

These are guidelines that relate to providing consistent, up-to-date support for telephony on Microsoft® Windows®:

  • Use TAPI for telephony. (Required)
  • Use the Assisted Telephony interface in telephony-enabled applications. (Required)
  • Implement the full TAPI interface in telephony-centric applications. (Required)
  • Apply dialing properties to numbers in telephony-centric applications. (Required)
  • Allow a user to select the calling device in telephony-centric applications. (Required)
  • Share serial devices properly in telephony-centric applications. (Required)
  • Explicitly link to a TAPI32 Library if using TAPI 2.x. (Required)
  • Gracefully degrade to work with TAPI 1.4 from TAPI 2.x. (Required)
  • Use TAPI 2.1 remote service provider for client-server telephony. (Recommended)
  • Use TAPI 2.1 client-management functions for client-server telephony. (Recommended)
  • Use TAPI 2.1 for telephony as soon as it becomes available. (Best Practice)
  • Use the dialing properties current location settings in telephony-enabled applications. (Best Practice)
  • Use the canonical/international form for the number dialed in telephony-enabled applications. (Best Practice)
  • Provide separate fields with defaults for phone number entry. (Best Practice)
  • Handle the LINE_CREATE message properly in telephony-centric applications. (Best Practice)
  • Handle _REINIT messages properly in telephony-centric applications. (Best Practice)


Use TAPI for Telephony

Requirement (Designed for Microsoft® Windows® Logo)

Communications applications that dial, answer, and otherwise control telephone calls on equipment such as modems, ISDN adapters, and telephones must control those calls using the Windows Telephony Application Programming Interface (TAPI).

This includes online registration of an application. All telephony-enabled applications must either use the full TAPI interface or must pass requests to a telephony-centric application that does.

See Also

For more information about writing TAPI service providers, see the TAPI Service Provider documentation.


Use the Assisted Telephony Interface in Telephony-Enabled Applications

Requirement (Designed for Microsoft® Windows® Logo)

Telephony-enabled applications must, at a minimum, use the Assisted Telephony interface and pass requests for dialing of calls to a telephony-centric application such as Phone Dialer that uses the full TAPI interface for call control.


Implement the Full TAPI Interface in Telephony-centric Applications

Requirement (Designed for Microsoft® Windows® Logo)

Telephony-centric applications must use the full Windows Telephony API (TAPI) for telephony-related functions. They must not control telephony-related equipment through proprietary interfaces, drivers, or APIs other than TAPI.

In particular, the application must not access a modem by directly opening the serial port using the CreateFile function ("COMx"), although a "Direct to COMx" mode may be available for accessing non-modem devices.


Apply Dialing Properties to Numbers in Telephony-centric Applications

Requirement (Designed for Microsoft® Windows® Logo)

Telephony-centric applications must apply the user's Dialing Properties settings to numbers to be dialed. This can be accomplished by passing the number to the lineTranslateAddress function before the call is placed.

This number must be in canonical/international form unless the number to be dialed is an internal extension or the user has otherwise explicitly instructed the application to dial the digits "as is" without applying Dialing Properties. Even so, they should pass to lineTranslateAddress so that tone/pulse dialing settings can be applied.


Allow a User to Select the Calling Device in Telephony-centric Applications

Requirement (Designed for Microsoft® Windows® Logo)

Telephony-centric applications must allow the user to select the device to use for calls. The device name can be obtained from the LINEDEVCAPS structure returned by the TAPI lineGetDevCaps function.


Share Serial Devices Properly in Telephony-centric Applications

Requirement (Designed for Microsoft® Windows® Logo)

If a telephony-centric application is performing extended control functions on a serial device that is also accessible through TAPI (such as a fax application issuing Class 1 or 2 fax AT commands to a fax modem), the application must use LINEBEARERMODE_PASSTHROUGH as defined in TAPI rather than opening the serial device directly. This enables the device to be properly shared with other TAPI applications when not in use.

Your application must not open the serial device directly with the CreateFile function.


Explicitly Link to a TAPI32 Library If Using TAPI 2.x

Requirement (Designed for Microsoft® Windows® Logo)

If the application uses TAPI 2.x functions, it must either explicitly link to TAPI32.dll (by calling GetProcAddress) or be linked to theTAPI32.lib static-link library so that it will load on both Windows 95 (TAPI 1.4) and Windows NT 4.0 (TAPI 2.0).


Gracefully Degrade to Work With TAPI 1.4 from TAPI 2.x

Requirement (Designed for Microsoft® Windows® Logo)

Your application must gracefully degrade its features so that it works as well as possible within the limitations of TAPI 1.4 when running on Windows 95.


Use TAPI 2.1 Remote Service Provider for Client-Server Telephony

Recommendation (Designed for Microsoft® Windows® Logo)

Client-server telephony-centric applications should use the TAPI 2.1 Remote Service Provider.


Use TAPI 2.1 Client Management Functions for Client-Server Telephony

Recommendation (Designed for Microsoft® Windows® Logo)

Client-server telephony-centric applications should use the TAPI 2.1 client management API to enable value-added client management and control from the server.


Use TAPI 2.1 for Telephony As Soon As It Becomes Available

Best Practice (Designed for Microsoft® Windows® Logo)

As soon as TAPI 2.1 is available, telephony applications should use TAPI 2.1 for Windows 95, Windows NT 4.0 Workstation, and Windows NT 4.0 Server. TAPI 2.1 is the only version that runs on all three platforms.


Use the Dialing Properties Current Location Settings in Telephony-Enabled Applications

Best Practice (Designed for Microsoft® Windows® Logo)

In telephony-enabled applications, phone number entry fields for country code and area code should use the Dialing Properties current location settings as defaults. These defaults can be obtained by calling tapiGetLocationInfo.


Use the Canonical/International Form for the Number Dialed in Telephony-Enabled Applications

Best Practice (Designed for Microsoft® Windows® Logo)

A telephony enabled application should pass the number dialed to tapiRequestMakeCall in canonical/international form.

Remarks

This best practice is done so that the call-manager application placing the call can properly apply the user's Dialing Properties settings.


Provide Separate Fields with Defaults for Phone Number Entry

Best Practice (Designed for Microsoft® Windows® Logo)

User entry of phone numbers should be in separate fields for country code, area/city code, and local number. The country code and area code fields should default to the user's current location country code and area code obtained from the lineGetTranslateCaps function. The country code selected can consist of a drop-down list of countries obtained from the lineGetCountry function.


Handle the LINE_CREATE Message Properly in Telephony-centric Applications

Best Practice (Designed for Microsoft® Windows® Logo)

A telephony-centric application should properly handle the LINE_CREATE message so that telephony devices added by a user while the application is active become immediately available for use.


Handle _REINIT Messages Properly in Telephony-centric Applications

Best Practice (Designed for Microsoft® Windows® Logo)

A telephony-centric application should properly respond to LINEDEVSTATE_REINIT and PHONESTATE_REINIT messages by shutting down the application's use of TAPI at the earliest opportunity so that TAPI can be restarted.


OnNow / ACPI

These are guidelines that relate to providing consistent, up-to-date support for automatic hardware configuration and power-management on Microsoft® Windows®:

  • Handle system Sleep-Wake transitions properly. (Required)
  • Eliminate even minor memory leaks. (Recommended)
  • Process Sleep or Query messages silently. (Recommended)
  • Pause play and sound on receiving a Sleep message in a game. (Recommended)
  • Call SetThreadExecutionState in event-handling applications. (Best Practice)
  • Call SetThreadExecutionState in presentation applications. (Best Practice)
  • Curtail background activities when running on batteries. (Best Practice)
  • Take no action on receiving a …RESUMEAUTOMATIC message. (Best Practice)


Handle System Sleep-Wake Transitions Properly

Requirement (Designed for Microsoft® Windows® Logo)

Applications should handle system sleep/wake transitions by monitoring WM_POWERBROADCAST messages. When applications receive sleep messages (WM_POWERBROADCAST PBT_APMSUSPEND), they must:

  • Flush any unsaved user data to nonvolatile media. Applications must save this data to a temporary file or backup file since the user has not given the command to save the original file.
  • Close all open files.

When applications receive wake messages (WM_POWERBROADCAST PBT_APMRESUMESUSPEND), they must:

  • Reopen any files that had been open.
  • Verify the user's files and inform the user if there are any problems (for example: files can no longer be found, files have been modified by someone else, and so forth).

Applications must avoid destabilizing or crashing the system as a result of sleep/wake transitions.

See Also

For a description of pretesting you can do to ensure that your application provides proper ACPI/OnNow support, see Pretesting ACPI/OnNow support.

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Eliminate Even Minor Memory Leaks

Recommendation (Designed for Microsoft® Windows® Logo)

With the introduction of OnNow, applications will be run continuously, without restarting, for a much longer period than is typical today. For this reason, applications should ensure that they do not have any memory leaks.

Remarks

A memory leak is defined as a memory allocation that grows without bounds. Memory leaks occur when an application opens a system handle and does not close it. A shortage of system resources resulting from memory leaks causes a decline in system performance and eventual failure.

See Also

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Process Sleep or Query Messages Silently

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should not request any user input while it is processing a WM_POWERBROADCAST sleep or query message.

Exception

Your application can display a confirmation dialog box only if both of the following conditions are met:

  • The UI Allowed bit is set in the WM_POWERBROADCAST message.
  • Putting the computer to sleep will cause user data loss or corruption.

See Also

For a description of pretesting you can do to ensure that your application provides proper ACPI/OnNow support, see Pretesting ACPI/OnNow support.

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Pause Play and Sound on Receiving a Sleep Message in a Game

Recommendation (Designed for Microsoft® Windows® Logo)

Games should pause game play and stop playing sound when they receive WM_POWERBROADCAST sleep messages.

See Also

For a description of pretesting you can do to ensure that your application provides proper ACPI/OnNow support, see Pretesting ACPI/OnNow support.

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Call SetThreadExecutionState in Event-Handling Applications

Best Practice (Designed for Microsoft® Windows® Logo)

Event handling applications such as phone answering machine applications, fax servers, and periodic maintenance or desktop management applications should call SetThreadExecutionState before and after handling each event.

Remarks

This best practice allows the operating system to keep the computer awake while the event is being handled and then put the computer to sleep immediately thereafter.

See Also

For a description of pretesting you can do to ensure that your application provides proper ACPI/OnNow support, see Pretesting ACPI/OnNow support.

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Call SetThreadExecutionState in Presentation Applications

Best Practice (Designed for Microsoft® Windows® Logo)

Presentation applications should call SetThreadExecutionState when switching into and out of slide-show mode.

Remarks

This best practice allows the operating system to keep the computer awake and the display turned on while the event is being handled. The operating system can then put the computer to sleep immediately thereafter.

See Also

For a description of pretesting you can do to ensure that your application provides proper ACPI/OnNow support, see Pretesting ACPI/OnNow support.

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Curtail Background Activities When Running On Batteries

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should reduce background activities such as background pagination, background recalculation, autosaves and autoformatting when the computer is running on batteries because the hard disk and CPU are the highest power consumers an application affects.

While running on batteries, the following should be done to reduce hard disk and CPU usage:

  • Performing non-essential disk activity at regular intervals can cause the hard disk to spin up and down frequently, and, thus, use significantly more power than leaving the disk fully running. Therefore, applications should delay all nonessential disk activity until essential disk activity is required (for example, in response to an explicit user command). This allows the hard disk to remain off as much as possible. An application can detect whether the hard disk is already running by calling GetDevicePowerState before accessing the disk.
  • Applications should not perform operations at idle time unless the operations are in response to an explicit user command. This allows the operating system to stop the processor temporarily between time slices.

Applications can determine when the computer is running on batteries by calling GetSystemPowerStatus and by checking for the PBT_APMPOWERSTATUSCHANGE value returned by the WM_POWERBROADCAST message.

See Also

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Take No Action on Receiving a …RESUMEAUTOMATIC Message

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should take no action when it receives a PBT_APMRESUMEAUTOMATIC value returned by the WM_POWERBROADCAST message.

OnNow computers can be configured to automatically wake when no user is present. Since no user is present, most programs should not need to take action. If the operating system detects a user, it returns a PBT_APMRESUMESUSPEND value from the WM_POWERBROADCAST message.

See Also

For more information about the OnNow initiative and for OnNow technical specifications, see http://www.microsoft.com/hwdev/onnow.htm.


Directory Services

These are guidelines that relate to providing consistent, up-to-date support for Directory Services on Microsoft® Windows®:

  • Use a product-specific DS object in the configuration/services container. (Best Practice)
  • Use RpcNsBindingLookupBegin in RPC clients to find RPC server objects. (Recommended)
  • Use WSALookupServiceBegin in clients to find Windows Sockets server objects. (Recommended)
  • Locate COM objects in the Class Store transparently in COM and DCOM clients. (Recommended)
  • Publish only machine-specific parameters in the registry. (Recommended)


Use a Product-Specific DS Object in the Configuration/Services Container

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should both publish global configuration information to a product-specific DS object created in the Configuration/Services container and obtain global configuration information from the Configuration/Services container.

Remarks

This container is replicated to every Domain Controller in the enterprise. It is the preferred way to establish enterprise-wide configuration defaults for applications.

See Also

For more information about Windows NT 5.0 Directory Services, see http://www.microsoft.com/ntserver/info/directoryservices.htm.


Use RpcNsBindingLookupBegin in RPC Clients to Find RPC Server Objects

Recommendation (Designed for Microsoft® Windows® Logo)

To find the RPC server objects in the Directory Service, RPC clients should look up server endpoints using the RpcNsBindingLookupBegin function and related functions.

See Also

For more information about Windows NT 5.0 Directory Services, see http://www.microsoft.com/ntserver/info/directoryservices.htm.


Use WSALookupServiceBegin in Clients to Find Windows Sockets Server Objects

Recommendation (Designed for Microsoft® Windows® Logo)

To find the Windows Sockets objects in the Directory Service, Windows Sockets clients should look up server endpoints using the WSALookupServiceBegin function and related functions.

See Also

For more information about Windows NT 5.0 Directory Services, see http://www.microsoft.com/ntserver/info/directoryservices.htm.


Locate COM Objects in the Class Store Transparently in COM and DCOM Clients

Recommendation (Designed for Microsoft® Windows® Logo)

COM and DCOM clients should look up COM objects in the class store. This process requires no special action on the part of the client.

See Also

For more information, see Class Store.

For more information about Windows NT 5.0 Directory Services, see http://www.microsoft.com/ntserver/info/directoryservices.htm.


Publish Only Machine-Specific Parameters in the Registry

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should publish only machine-specific parameters in the registry. User-specific parameters should be published on the User object for the user in question. Global application parameters should be published in the Configuration/Services container.

See Also

For more information about Windows NT 5.0 Directory Services in general, see http://www.microsoft.com/ntserver/info/directoryservices.htm. See also Use a product-specific DS object in the configuration/services container.


Be Easy to Install and Remove

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 needing to remove an application expects to be provided an easy, automated way to do so.

The guidelines in this section apply to two areas:

  • Installing and removing entire applications.
  • Installing and removing individual components.


Installing and Removing Applications

The guidelines in this section relate to making applications easy to install and uninstall. They particularly apply to installing and removing entire applications, as opposed to individual components:

  • Use Microsoft installer technology. (Required)
  • Provide graphical 32-bit setup. (Required)
  • Provide a fully automated uninstaller. (Required)
  • Provide attended and/or silent installation. (Required)
  • Detect versions when installing. (Required)
    • Maintain user settings across version changes. (Best Practice)
  • Create working shortcuts during installation. (Required)
  • Support autoplay of CD-ROMs. (Required)
  • Support Add/Remove Programs if not on CD-ROM. (Required)
  • Check operations in advance when installing. (Required)
  • Avoid rebooting the system. (Best Practice)
  • Register uninstaller and make it appear in Add/Remove Programs. (Required)
  • Uninstall from Add/Remove Programs. (Required)
  • Remove all application files during uninstall. (Required)
  • Remove all references from the Start Menu during uninstall. (Required)
  • Remove registry entries during uninstall. (Required)
  • Remove uninstaller during uninstall. (Required)


Use Microsoft Installer Technology

Requirement (Designed for Microsoft® Windows® Logo)

Starting with the releases of Windows NT 5.0 and Windows 98, applications must use the new Microsoft installation technology for installing and uninstalling. This technology will greatly facilitate meeting all of the other install and uninstall requirements for the Designed for Microsoft Windows Logo program. This technology will also make your application far easier to manage in a complex environment.

See Also

For more information, see Introduction to New Microsoft Installer Technology .


Provide Graphical 32-bit Setup

Requirement (Designed for Microsoft® Windows® Logo)

The applicatioin must have an installation program with a graphical Setup program that runs in a 32-bit Microsoft Windows operating system.


Provide a Fully Automated Uninstaller

Requirement (Designed for Microsoft® Windows® Logo)

Your application must provide a fully automated uninstaller that removes the program files, folders, and registry entries for Windows 95, Windows 98, and Windows NT.


Provide Attended and/or Silent Installation

Requirement (Designed for Microsoft® Windows® Logo)

The installer must either lead the user through the installation process in a user-attended mode (not just instruct the user to copy or decompress files) or provide a facility for an unattended (silent) installation requiring no user input. Preferably (though not required), the application will provide both options.


Detect Versions When Installing

Requirement (Designed for Microsoft® Windows® Logo)

The installer must automatically detect the version of Windows NT, Windows 95, or Windows 98 running and install the correct version of your application automatically. This must be a seamless transition for the user.


Maintain User Settings Across Version Changes

Best Practice (Designed for Microsoft® Windows® Logo)

User settings should be maintained across application version changes.


Create Working Shortcuts During Installation

Requirement (Designed for Microsoft® Windows® Logo)

All shortcuts created by the installation must not result in file not found or other error conditions when activated.


Support AutoPlay of CD-ROMs

Requirement (Designed for Microsoft® Windows® Logo)

Products distributed on CD-ROM must use the AutoPlay feature to begin setup or to launch the program the first time the application is run. It is up to the vendor whether AutoPlay is enabled on subsequent insertions of the CD-ROM. In the case of products distributed on multiple CD-ROMs, subsequent CD-ROMs must either use the AutoPlay feature or behave during installation like a subsequent floppy disk (that is, continue installation without prompting the user for action). It is not acceptable to require the user to go to the Run command on the Windows Start menu to start the subsequent CD-ROM during installation.


Support Add/Remove Programs If Not on CD-ROM

Requirement (Designed for Microsoft® Windows® Logo)

The installer for media other than CD-ROM must provide the ability to launch the installer through Add/Remove Programs in the Control Panel.


Check Operations in Advance When Installing

Requirement (Designed for Microsoft® Windows® Logo)

The installer must check before starting any operation to ensure that it can complete that operation. The following are requirements based on this principle:

  • Installers must fail gracefully in the case where a system component cannot be replaced because file system security prevents an existing file from being overwritten. For example, installers that must overwrite system files should check up-front if the current user is a member of the administrator's local group. This will avoid confusion later by preventing the user from getting file copy errors from which there is no recovery.
  • Applications must be tested on Windows NT under non-administrator accounts. An application must run under a user account, but that user must not be able to change the application setup configuration.
  • When installing the application, the installer must check for the user privilege level. If the user is not an administrator and the application will work but with limited functionality, the installer must warn the user that only limited functionality will be available since they do not have administrator privileges; the installer must allow them to discontinue the installation.

Remarks

The following sample code checks for user privilege level.

//----------------------------------------------------------
// IsAdmin - tests to see if the current user is an admin
//----------------------------------------------------------

BOOL IsAdmin( )
{
    SC_HANDLE hSC;

// Try an Admin Privileged API - if it works, return TRUE, else FALSE
    hSC = OpenSCManager(
        NULL,
        NULL,
        GENERIC_READ | GENERIC_WRITE | GENERIC_EXECUTE  );

    if ( hSC == NULL )
        return FALSE;
    CloseServiceHandle( hSC );
    return TRUE;
}

See Also

For more information about how to check the user privilege level, see KB article PSS ID# Q118626.


Avoid Rebooting the System

Best Practice (Designed for Microsoft® Windows® Logo)

System reboots should be avoided during installation or at any other time if at all possible. However, if the system must be rebooted (for example, after installing a service pack for the operating system), setup should gracefully resume where it left off.


Register Uninstaller and Make It Appear in Add/Remove Programs

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must be properly registered and must appear under Add/Remove Programs in the Control Panel. The method for this registration is:

[HKEY_LOCAL_MACHINE]
  \SOFTWARE
    \Microsoft
      \Windows
        \Current Version
          \Uninstall
            \YourProductName

DisplayName=REG_SZ:<your product name and version number>
UninstallString=REG_SZ: c:\apps\myapp\uninstll.log /h


Uninstall from Add/Remove Programs

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must be accessible through Add/Remove Programs in the Control Panel and must operate properly from the Control Panel.


Remove All Application Files During Uninstall

Requirement (Designed for Microsoft® Windows® Logo)

All files and folders copied onto the hard disk must be removed (see Exceptions below).

Remarks

Remember to remove .gid files created by Help. Create a zero-length (0) file with the same name at installation.

Exceptions

User data files should remain on the hard disk.

Resources that other programs might use, such as sharable DLLs, sharable fonts, and sharable registry entries should remain on the hard disk.

It is better to err on the side of safety regarding other applications. If you are not sure whether removing a DLL might harm other applications, it is better to leave it behind. However, you must explain everything you leave behind when you submit your application for testing. The proper place to do this is in the Vendor Questionnaire.


Remove All References from the Start Menu During Uninstall

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must remove all advertisements and shortcuts placed anywhere in the Start menus (by its installer) that are associated with the component that is being removed.


Remove Registry Entries During Uninstall

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must remove all registry entries created by the application with the exception of keys that might be shared by other programs.


Remove Uninstaller During Uninstall

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must remove itself.

Remarks

The new installation technology is a system component, and, as such, must not be removed. However, using this technology will ensure that all required parts of the installation package are removed.


Installing and Removing Components

The guidelines in this section relate to making applications easy to install and uninstall. They particularly apply to installing and removing individual components, as opposed to entire applications.

The following three recommendations are placed first because of their importance in preventing DLL versioning problems:

  • Do not write to Windows system directories. (Recommended)
  • Use Microsoft update packs to upgrade system components. (Recommended)
  • Do not install globally shared DLLs. (Recommended)

  • Do not overwrite core components. (Required)
  • Do not decrement or remove core components during uninstall. (Required)
  • Register all shared components during installation. (Required)
  • Do not register self-registering components during installation. (Required)
  • Do not ref-count core components during installation. (Required)
  • Decrement the count on shared components while uninstalling. (Required)
  • Leave a zero count if not removing a component during uninstall. (Required)
  • Set count correctly for pre-existing unregistered shared components during installation. (Best Practice)


Do Not Write to Windows System Directories

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should not write anything to the Windows \system or \system32 directory. In particular, they should not place shared DLLs or executables to the Windows system directories.

On Windows NT 5.0, the operating system will support a mode in which the \system32 directory is read-only and unavailable to applications and installers. This will be part of the Zero Administration for Windows effort to reduce DLL conflicts and other shared component problems.

Exceptions

Fonts and Control Panel applications can continue to be installed in the appropriate Windows system directory.

Applications may update system components in the Windows system directories if they use a Microsoft update package to do so.


Use Microsoft Update Packs to Upgrade System Components

Recommendation (Designed for Microsoft® Windows® Logo)

If the application requires updated system DLLs or other core components, ship a self-extracting executable provided by Microsoft that handles installation of these components.

Applications are strongly discouraged from installing system components by any other means than Microsoft-provided update packs.

Microsoft will distribute all new DLLs by means of component update packs only. Vendors should distribute these self-extracting executables from Microsoft rather than the latest DLLs themselves.


Do Not Install Globally Shared DLLs

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should avoid installing globally shared DLLs. Instead, an application should install all the DLLs it uses in the same directory as its executable (.exe) files.

Remarks

Versioning problems relating to globally shared DLLs have plagued users. The price for avoiding such problems with your installation is modestly increased disk space usage for your application. DLL versioning problems can be avoided by not relying on globally shared DLLs unless they are part of the operating system. Given the low cost of hard disk space, this is a small price to pay to avoid potentially disrupting your users' environments.


Do Not Overwrite Core Components

Requirement (Designed for Microsoft® Windows® Logo)

Your application must not overwrite core components with older versions of the components. The vendor must check http://www.microsoft.com/windows/thirdparty/winlogo.htm for the most up-to-date and complete list of Windows 95 and Windows NT core components.


Do Not Decrement or Remove Core Components During Uninstall

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must not decrement or remove any core component, in particular MicrosoftFoundation Class Library (MFC) DLLs, Open Database Connectivity (ODBC), and DAO DLLs.

See Also

For the most up-to-date and complete listing of all Windows NT and Windows 95 core components, see http://www.microsoft.com/windows/thirdparty/winlogo/.


Register All Shared Components During Installation

Requirement (Designed for Microsoft® Windows® Logo)

Your application installer must register all shared components that are designed to be uninstalled under the following registry key:

[HKEY_LOCAL_MACHINE]
  \SOFTWARE
    \Microsoft
      \Windows
        \Current Version
          \SharedDLLs


Do Not Register Self-Registering Components During Installation

Requirement (Designed for Microsoft® Windows® Logo)

The installer must not register components that are self-registering, such as Microsoft® DirectX® and Microsoft® Direct3D®. The installers for these components will register their components as needed.


Do Not Ref-Count Core Components During Installation

Requirement (Designed for Microsoft® Windows® Logo)

Core components must not be ref-counted in the registry by application installers.

See Also

For the most up-to-date and complete list of Windows 95 and Windows NT core components, see http://www.microsoft.com/windows/thirdparty/winlogo.htm.


Decrement the Count on Shared Components While Uninstalling

Requirement (Designed for Microsoft® Windows® Logo)

The uninstaller must accurately decrement the count on all components the application uses that are installed as shared components.


Leave a Zero Count If Not Removing a Component During Uninstall

Requirement (Designed for Microsoft® Windows® Logo)

If the reference count is at zero (0) and you will not be removing the component, you must leave the reference count at 0. This requirement prevents installers from inaccurately incrementing the shared count if the component was on the system but was not registered.


Set Count Correctly for Pre-existing Unregistered Shared Components During Installation

Best Practice (Designed for Microsoft® Windows® Logo)

If your installer finds a shared component already on the system and not registered, the SharedDLL reference count should be incremented by one plus the number of clients being installed.

Remarks

For example, if you install your application with three clients using a shared component, your installer will raise the SharedDLL count by three. But if the shared component is already on the system and no SharedDLL exists for it (that is, the previous installer did not create the ref-count), set the SharedDLL count to four. This way, when your application is uninstalled, it leaves the shared component on the system with a ref-count of one.


Use the Registry Correctly

These guidelines relate to making appropriate use of the Microsoft® Windows® registry:

  • Register native data file types. (Required)
  • Ask before reassigning file-extension associations. (Best Practice)
  • Do not add to Win.ini or System.ini. (Required)
  • Support informational keys in the registry. (Required)
  • Use the correct access mask when opening a registry key. (Recommended)
  • Register classes on a per-user basis in HKCU. (Recommended)
  • Do not write default profile settings to the registry. (Recommended)
  • Do not register hard-coded paths. (Best Practice)
  • Use REG_EXPAND_SZ strings on Windows NT 5.0. (Best Practice)
  • Do not register strings As REG_BINARY. (Best Practice)
  • Register policy keys in a standard location. (Best Practice)
  • Store hardware-independent machine settings in HKEY_LOCAL_MACHINE. (Best Practice)
  • Store hardware-dependent settings in HKEY_CURRENT_CONFIG. (Best Practice)


Register Native Data File Types

Requirement (Designed for Microsoft® Windows® Logo)

Native data file types (if applicable) must be registered as follows:

[HKEY_CLASSES_ROOT]
.(file type extension)
    (Default) = REG_SZ:FileTypeID

See Also

For further details on registering file types and application data, see the Windows Interface Guidelines for Software Design, Chapter 10 (available from Microsoft Press).


Ask Before Reassigning File-Extension Associations

Best Practice (Designed for Microsoft® Windows® Logo)

If your program uses a file extension that is also used by other applications (for example, .htm files), the installer program should check the registry and ask the user whether to change the default program associated with that particular file extension.


Do Not Add to Win.ini or System.ini

Requirement (Designed for Microsoft® Windows® Logo)

Your application must not add information to Win.ini or System.ini.

Exception

Applications that must support links to existing 16-bit products can write to these files. For example, certain multimedia applications may require video codecs not supplied with Windows NT or Windows 95. Certain other products, such as screen savers, may not be supported in the registry and must write to Win.ini or System.ini. Writes to the embedded section of Win.ini may be unavoidable. It is okay to write to the font section of Win.ini and to leave behind fonts and font information after uninstallation. However, any writes to Win.ini or System.ini must be explained in the Vendor Questionnaire.


Support Informational Keys in the Registry

Requirement (Designed for Microsoft® Windows® Logo)

Your application must write all the information in the table below to the registry so that Add/Remove Programs in the Control Panel can obtain information about the application as needed.

The registry values should be written under the following key:

HKEY_LOCAL_MACHINE
  \Software
    \Microsoft
      \Windows
        \CurrentVersion
          \Uninstall
            \NameofApplication

Name of Value | Type | Contains
DisplayName | REG_SZ | Display name of application.
UninstallPath | REG_SZ* | Full path to the application uninstall program.
ModifyPath | REG_SZ* | Full path to the application setup/modify program.
InstallLocation | REG_SZ* | Full path to the application (folder or *.exe).
InstallSource | REG_SZ* | Location where the application was installed from. See Implementation below.
DisplayVersion | REG_SZ | Displayed version number of application.
VersionMajor | DWORD | Major version number of application. See Implementation below.
VersionMinor | DWORD | Minor version of application. See Implementation below.
Publisher | REG_SZ | Publisher/developer of application.
ProductID | REG_SZ | Product ID of installed application.
RegOwner | REG_SZ | Registered owner of application.
RegCompany | REG_SZ | Registered company of application.
HelpTelephone | REG_SZ | Telephone number for support/help.
HelpLink | REG_SZ* | Full path of Help file or Help URL for application.
URLUpdateInfo | REG_SZ | URL of update information for application. See Implementation below.
URLInfoAbout | REG_SZ | URL that provides a link to the publisher's home page or the application home page. See Implementation below.

Implementation

InstallSource
This is the path from which the application was installed. It can also be an HTTP site or a network UNC path, such as \\applications\sample. If the application is installed from a floppy, this value would be a:\ for the floppy drive letter. This value also supports multiple paths. To add additional paths, just separate each path with a semicolon. For example:
InstallSource = \\applications\sample; \\\\corpnet\\sample
VersionMajor/VersionMinor
Future versions of Add/Remove Programs will use these two values to compute whether an upgrade is necessary. These values will not be displayed to the user. The numbering and ordering scheme of these numbers is up to the application. Newer versions of the application must have a larger VersionMinor and/or a larger VersionMajor field to indicate an update.
Sample Registry Data for a Windows NT 5.0 Application
Below is an example of registration information for a Windows NT 5.0 application.
Name of Value | Type | Contains
DisplayName | REG_SZ | Sample application
UninstallPath | REG_EXPAND_SZ | %SYSTEMDRIVE%\Program Files\Sample\uninstall.exe
ModifyPath | REG_EXPAND_SZ | %SYSTEMDRIVE%\Program Files\Sample\modify.exe
InstallLocation | REG_EXPAND_SZ | %SYSTEMDRIVE%\Program Files\Sample
InstallSource | REG_EXPAND_SZ | A:\
DisplayVersion | REG_SZ | 1.0a
VersionMajor | DWORD | 1
VersionMinor | DWORD | 1
Publisher | REG_SZ | Sample Corporation
ProductID | REG_SZ | 111-111-111
RegOwner | REG_SZ | Test user
RegCompany | REG_SZ | Test company
HelpTelephone | REG_SZ | 1-800-555-5555
HelpLink | REG_EXPAND_SZ | %SYSTEMDRIVE%\Program Files\Sample\sample.hlp
URLUpdateInfo | REG_SZ | http://sample.com/sampleapp/ update.html
URLInfoAbout | REG_SZ | http://sample.com/sampleapp/ default.html


Use the Correct Access Mask When Opening a Registry Key

Recommendation (Designed for Microsoft® Windows® Logo)

Instead of opening a registry key with KEY_ALL_ACCESS, use KEY_READ if all you need to do is read the key, or use KEY_WRITE if you need to change its value.

Remarks

By applying this recommendation, you cooperate better with other processes that may need access to the key. In a complex managed enterprise environment, this can be important.


Register Classes on a Per-User Basis in HKCU

Recommendation (Designed for Microsoft® Windows® Logo)

Applications should register class information in the HKEY_CURRENT_USER (HKCU) registry hive, not in HKEY_LOCAL_MACHINE or any other location.

Register class information in:

HKEY_CURRENT_USER\
  Software\
    Classes\


Do Not Write Default Profile Settings to the Registry

Recommendation (Designed for Microsoft® Windows® Logo)

HKCU settings that are application defaults or part of an administered profile should not be written to the registry until the user modifies them (through setting/option changes, and so forth).

Until such a time, the settings should reside within the application. Therefore, any HKCU keys that are written to the registry should contain different values than those that reside in the application as defaults.


Do Not Register Hard-Coded Paths

Best Practice (Designed for Microsoft® Windows® Logo)

Installers and applications should make use of the registry REG_EXPAND_SZ string type; the %SystemDrive%, %SystemRoot%, %windir%, %ProgramFiles%, %Temp%, and %UserProfile% environment variables; and the ExpandEnvironmentStrings function.

Do not hard-code paths to the Windows system root or to the drive containing Windows in the registry because users can remap their drives under Windows NT.

For example, under Windows NT, do not use a key such as the following:

MyPath : REG_SZ : "C:\Program Files\MyApp"    // BAD PRACTICE!

Instead, use a key such as:

MyPath : REG_EXPAND_SZ : "%SystemDrive%\Program Files\MyApp"

When the string is retrieved, the ExpandEnvironmentStrings function can be used to get the up-to-date path.


Use REG_EXPAND_SZ Strings on Windows NT 5.0

Best Practice (Designed for Microsoft® Windows® Logo)

For Windows NT 4.0, Windows 95, and Windows 98, the REG_SZ notation should be used for all registry entries requiring string values. However, for Windows NT 5.0, the REG_EXPAND_SZ notation should be used whenever possible for all string entries containing asterisks.


Do Not Register Strings As REG_BINARY

Best Practice (Designed for Microsoft® Windows® Logo)

Installers and applications should store string data as separate REG_SZ, REG_MULTI_SZ, or REG_EXPAND_SZ values instead of embedding such strings as REG_BINARY data in the registry. This helps resolve ANSI to Unicode conversion issues when upgrading a computer running Windows 95 to future versions of Windows NT.


Register Policy Keys in a Standard Location

Best Practice (Designed for Microsoft® Windows® Logo)

Policy keys added to the registry should be created under either HKLM\Policy or HKCU\Policy and should follow the "software" key style. For example:

HKLM\
  Policy\
    companyname\
      NameofApplication\
        <values>


Store Hardware-Independent Machine Settings in HKEY_LOCAL_MACHINE

Best Practice (Designed for Microsoft® Windows® Logo)

Information concerning a computer's logical (as opposed to physical) configuration should be stored in the HKEY_LOCAL_MACHINE (HKLM) hive of the registry.

Such information is distinct from information that pertains to a specific user (which should be stored in HKEY_CURRENT_USER) and from information that pertains to the physical computer hardware (which should be stored in HKEY_CURRENT_CONFIG).


Store Hardware-Dependent Settings in HKEY_CURRENT_CONFIG

Best Practice (Designed for Microsoft® Windows® Logo)

Applications should store all information relating to a computer's physical hardware in the HKEY_CURRENT_CONFIG (HKCC) hive of the registry.

Such information is distinct from information that pertains to a specific user (which should be stored in HKEY_CURRENT_USER) and from information that pertains to the logical workstation (which should be stored in HKEY_LOCAL_MACHINE).


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. These guidelines relate to installing programs and saving data in locations that minimize such confusion and frustration:

General

  • Install applications to the \Program Files directory. (Required)
  • Do not install executables or DLLs in the root directory. (Required)
  • Separate user data from application bits. (Required)
  • Query the registry for directory names. (Required)
  • Store user data under the user's Profile folder. (Recommended)
  • Do not assume that profile settings have been initialized. (Recommended)

Avoid DLL Versioning Problems

  • Do not write to Windows system directories. (Recommended)
  • Use Microsoft update packs to upgrade system components. (Recommended)
  • Do not install globally shared DLLs. (Recommended)


Install Applications to the \Program Files Directory

Requirement (Designed for Microsoft® Windows® Logo)

Your application must default installation to a directory (or directories) under "drive:\Program Files". The installer must query the registry for this directory path to ensure appropriate install if, for example, a user has renamed this directory on his or her computer or if the application is being installed onto a non-English localized version of Windows.


Do Not Install Executables or DLLs in the Root Directory

Requirement (Designed for Microsoft® Windows® Logo)

Your application installer must not install application DLLs or executables at the root of the system drive (%SystemDrive%), which is usually C:\.


Separate User Data from Application Bits

Requirement (Designed for Microsoft® Windows® Logo)

Applications must maintain strict separation of user data from application bits whenever possible.


Query the Registry for Directory Names

Requirement (Designed for Microsoft® Windows® Logo)

Your application should not assume that directory names such as "My Computer" will be in English or will be unchanged by the user. Your application should query the registry directly to obtain the proper language-specific directory names.

Vendors should be aware that English versions of their applications might be installed onto non-English versions of Windows. In this instance, a search for the English language directory string "Program Files" would not be successful and would result in a failed installation.

For many standard folders, a qualified path can be obtained by calling the SHGetSpecialFolderLocation function with the appropriate CSIDL constant. The following standard folders are accessible in this way.

Standard Folder CSIDL Constant Name Hex
Alternate Startup folder (All Users profile, DBCS)
CSIDL_COMMON_ALTSTARTUP

0x1e
Alternate Startup ([user], DBCS)
CSIDL_ALTSTARTUP

0x1d
Application Data ([user] profile)
CSIDL_APPDATA

0x1a
Control Panel virtual folder
CSIDL_CONTROLS

0x03
Cookies folder
CSIDL_COOKIES

0x21
Desktop (namespace root)
CSIDL_DESKTOP

0x00
Desktop folder (All Users profile)
CSIDL_COMMON_DESKTOPDIRECTORY

0x19
Desktop folder ([user] profile)
CSIDL_DESKTOPDIRECTORY

0x10
Favorites folder (All Users profile)
CSIDL_COMMON_FAVORITES

0x1f
Favorites folder ([user] profile)
CSIDL_FAVORITES

0x06
Fonts virtual folder
CSIDL_FONTS

0x14
History folder
CSIDL_HISTORY

0x22
Internet Cache folder
CSIDL_INTERNET_CACHE

0x20
Internet virtual folder
CSIDL_INTERNET

0x01
My Computer virtual folder
CSIDL_DRIVES

0x11
Network Neighborhood root
CSIDL_NETWORK

0x12
Network Neighborhood directory
CSIDL_NETHOOD

0x13
Personal folder ([user] profile)
CSIDL_PERSONAL

0x05
Printers virtual folder
CSIDL_PRINTERS

0x04
PrintHood folder ([user] profile)
CSIDL_PRINTHOOD

0x1b
Programs folder (under Start menu in All Users profile)
CSIDL_COMMON_PROGRAMS

0X17
Programs folder (under Start menu in [user] profile)
CSIDL_PROGRAMS

0x02
Recent folder ([user] profile)
CSIDL_RECENT

0x08
Recycle Bin folder
CSIDL_BITBUCKET

0x0a
SendTo folder ([user] profile)
CSIDL_SENDTO

0x09
Start menu (All Users profile)
CSIDL_COMMON_STARTMENU

0x16
Start menu ([user] profile)
CSIDL_STARTMENU

0x0b
Startup folder (All Users profile)
CSIDL_COMMON_STARTUP

0x18
Startup folder ([user] profile)
CSIDL_STARTUP

0x07
Templates folder ([user] profile)
CSIDL_TEMPLATES

0x15

Folders can also be located using the following Windows NT environment variables.

Standard Folder or Location | Environment Variable
System drive | %SystemDrive%
System root directory | %SystemRoot%
Windows folder | %windir%
Program Files folder | %ProgramFiles%
User's profile folder | %UserProfile%
User's temporary folder | %Temp%

Access to specific user profile folders, such as Application Data, should be obtained through SHGetSpecialFolderLocation rather than by relying on the standard English folder name (as in %UserProfile%\Application Data\).


Store User Data Under the User's Profile Folder

Recommendation (Designed for Microsoft® Windows® Logo)

By default, user data should be stored in the user profile. On Windows NT, this means that applications should use the following folders to store user document files and large user profile data, respectively:

%SystemRoot%\Profiles\username\Personal
%SystemRoot%\Profiles\username\Application Data

Paths to these folders should be obtained by calling SHGetSpecialFolderLocation with the CSIDL_PERSONAL and CSIDL_APPDATA constants, respectively.

On Windows 95 and Windows 98, applications should explicitly create equivalent folders to use for this purpose:

...\windows\Profiles\username\Personal
...\windows\Profiles\username\Application Data

Remarks

  • In Windows NT 5.0 and later, the Personal folder has been renamed to My Documents. You should still access it by calling SHGetSpecialFolderLocation with the CSIDL_PERSONAL constant.
  • If you do have user profile data that is more appropriate for the Application Data folder than for the registry, you should use the same hierarchical structure under the Application Data folder as that which exists in HKEY_CURRENT_USER:

    Application Data\
    Software\
    [company name]\
    [product name]\
    [version]\
    [your top level]\


Do Not Assume That Profile Settings Have Been Initialized

Recommendation (Designed for Microsoft® Windows® Logo)

If an application finds that user settings or data are not present in the user's profile, the application should recover gracefully and regenerate the necessary settings based on the application defaults.

Remarks

In a multiuser environment, an application can be installed on a computer without the opportunity for setup to initialize HKEY_CURRENT_USER (HKCU) for the specific user starting the application.


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. These guidelines relate to making your application manageable:

  • Enable policy settings to uninstall and unadvertise your application. (Required)
  • Provide an .ADM system policy file for your application. (Required)
  • Provide for disabling Run and Find dialogs. (Required)
  • Support NoViewContextMenu in shell extensions. (Required)
  • Call ShellExecute instead of CreateProcess. (Required)
  • Support roaming users. (Best Practice)
  • Do not collect single-user data during installation. (Best Practice)
  • Support administrative additions during network install. (Recommended)
  • Generate a disk image for multiple installs during network installation. (Recommended)
  • Install shared files in shared locations during network installation. (Recommended)
  • Support silent installs and push strategies during network installation. (Recommended)
  • Do not require a local footprint during network install. (Recommended)
  • Provide a diagnostic logging option. (Recommended)
  • Do not assume write access to a user's machine. (Recommended)
  • Support dynamic policy changes by handling WM_SETTINGCHANGE messages. (Recommended)
  • Expose private policy keys where appropriate. (Best Practice)


Enable Policy Settings to Uninstall and Unadvertise Your Application

Requirement (Designed for Microsoft® Windows® Logo)

Administrators must be able to uninstall and remove shortcuts for the application by means of a centrally managed Group Policy Template or through changes to user profiles.

See Also

For more information about the importance of policy and policy templates, see Supporting Networked and Managed Environments.


Provide an .ADM System Policy File for Your Application

Requirement (Designed for Microsoft® Windows® Logo)

As a vendor, you must either include an .adm file with your application or make such a file available for download from your World Wide Web site.

Remarks

Applications must include a system policy template so that administrators can remotely manage the roll-out and use of the application. By using a system policy template, global changes to registry parameters can be applied to all users or a subset of users at the next interactive log on. This allows the administrator to choose registry settings from a template so as to customize the application roll-out or behavior on users' computers.

Such a template is referred to as an .adm file. The administrator (or software developer) can mandate a value, remove a value, or disregard the current state of a particular value at each interactive user log on. For example, a vendor can provide a template to administrators that can set the default server locations in each user's personal preferences.

See Also

For details on Windows NT 4.0 system policies, a whitepaper titled "Windows NT 4.0 Profiles and Policies" is on the Microsoft Web site at file://\\\\pilotnt\\whitepaper\\ProfilesPolicies.doc). Additionally, more information on generating ADM files for use with System Policy Editor can be found in the Platform SDK.


Provide for Disabling Run and Find Dialogs

Requirement (Designed for Microsoft® Windows® Logo)

If the application uses the Run or Find dialog box, support should be added to disable these dialog boxes and make them inaccessible when a system policy is in effect that limits the user's access to them.


Support NoViewContextMenu in Shell Extensions

Requirement (Designed for Microsoft® Windows® Logo)

If the application is a shell extension, it must support the system policy, NoViewContextMenu, which disables the context menu on the desktop or within the Windows Explorer interface.


Call ShellExecute Instead of CreateProcess

Requirement (Designed for Microsoft® Windows® Logo)

Your application must use the Win32 ShellExecute function instead of the CreateProcess function when starting another application.

Remarks

Using system policy, administrators can define which applications cannot be started from the Windows Explorer interface. If applications call ShellExecute, the shell has an opportunity to check such system policy settings before the new application is started.


Support Roaming Users

Best Practice (Designed for Microsoft® Windows® Logo)

User settings should be able to move automatically from computer to computer on a network, following a user wherever that user logs on. Examples of user settings include customized toolbars, any dynamic user-generated lists, or other user-specific options.

Remarks

Recommendations for handling user registry keys:

  • Store all per-user registry keys in HKEY_CURRENT_USER (HKCU). Since the user profile includes the Ntuser.dat file (which contains the HKCU hive), the user registry keys will roam with the user.
  • Store all per-computer keys in HKEY_LOCAL_MACHINE (HKLM).
  • Do not assume that any HKCU keys have been set.
  • Do not assume that any keys initialized in HKCU during installation will be set correctly at a later time. New users can roam to a computer and will not have any HKCU keys for your application.
  • Applications should detect the lack of required keys and automatically create them using smart defaults.

Recommendations for handling user application data:

  • Store all user-specific application information not stored in the registry in the user's profile Application Data folder. Use the same hierarchical structure in the Application Data folder as is used in HKEY_CURRENT_USER:

    Application Data\
    Software\
    [company name]\
    [product name]\
    [version]\
    [your top level]\

  • Do not assume that the content of the user's profile Application Data folder you initialized during installation will be set correctly at a later time.
  • Place user data into the user's My Documents (previously named Personal) folder.


Do Not Collect Single-User Data During Installation

Best Practice (Designed for Microsoft® Windows® Logo)

Your application should collect the user name or Personal ID (PID) information the first time the application is run, not during installation.

Exception

If you are sure that your application will be installed only on single-user computers, this is not necessary.


Support Administrative Additions During Network Install

Recommendation (Designed for Microsoft® Windows® Logo)

Setup should support network installations that enable network administrators to add additional components to network installations (such as third-party tools, add-ons, and so forth).


Generate a Disk Image for Multiple Installs During Network Installation

Recommendation (Designed for Microsoft® Windows® Logo)

Setup should support creating a disk image that can be installed onto multiple computers. In this situation, computer and user-specific settings should be collected the first time the application is run.


Install Shared Files in Shared Locations During Network Installation

Recommendation (Designed for Microsoft® Windows® Logo)

Setup should not install shared files in non-shared volumes. Files shared by multiple users or applications should reside in a location that is common and accessible.


Support Silent Installs and Push Strategies During Network Installation

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should support silent installations and push strategies in managed environments.


Do Not Require a Local Footprint During Network Install

Recommendation (Designed for Microsoft® Windows® Logo)

Your application should be capable of running directly from source in the case of CD or network installations. This should be accomplished with no local computer footprint. Local use of the registry is considered zero-footprint when it is unavoidable.


Provide a Diagnostic Logging Option

Recommendation (Designed for Microsoft® Windows® Logo)

Users should be able to track two types of events on every client computer:

  • Configuration Changes
    For example, installing applications or changing registry keys.
  • Application Notification Events
    For example, starting and stopping services or reporting hardware performance.

Remarks

Currently, neither applications nor the operating system provide options on how much or what kind of information to write to system log files. No options exist to log configuration changes. Users should be able to record both of these types of events. Users should also have the option to control the level of logging through a registry key set by way of a policy or through a user interface.

When something breaks, it is very difficult to find out what happened. For example, the user could have installed a game, some DLLs could have been overwritten, the network settings could have been changed, or the installed applications could have some unplanned behaviors. Both the operating system and the applications need to track this kind of information.

When your application or service starts, it should check the DiagnosticLogging registry key for the appropriate level and detail of logging:

HKLM:
  \System
    \CurrentControlSet
      \Control
        \DiagnosticLogging
          \Global = 0 | 1 | 2

This registry key's values correspond to the following modes.

Logging Mode | Description | Example
Quiet Mode | Only system-critical events logged, like we do today | A service starting/stopping
Normal Mode | Critical events and configuration changes are logged | Changing the systems static IP Address
Verbose Mode | Information overload is logged | Monitor files copied to %WINDIR%

See Also

For more information about writing clear messages for logging, see Guidelines for Error Messages and Other Event Messages.


Do Not Assume Write Access to a User's Machine

Recommendation (Designed for Microsoft® Windows® Logo)

Do not assume that your application has write access to any part of a user's computer except for the folders referenced by the %temp% and %userprofile% environment variables.

Remarks

Do not assume or require the ability to create or edit files throughout the user's computer. In a locked down environment, the user running your application may not have write access to the file system.


Support Dynamic Policy Changes by Handling WM_SETTINGCHANGE Messages

Recommendation (Designed for Microsoft® Windows® Logo)

By handling WM_SETTINGCHANGE messages where LParam points to the user's policy, applications can respond to policy changes as they happen.


Expose Private Policy Keys Where Appropriate

Best Practice (Designed for Microsoft® Windows® Logo)

If there are features of an application that enterprise administrators might want to lock down for some users, the application should provide registry keys that can be set to enable or disable these features.


Special Requirements

Several types of application have special requirements and exemptions when applying to use the Designed for Microsoft® Windows® Logo. These are:

  • Development Tools.
  • Non-File-Based Applications.
  • Utilities.
  • Games and Multimedia Applications.
  • Java Applications.
  • Separate Add-On Products.


Development Tools

Development tools are products such as languages and compilers that create executable files or interpreted code modules that mimic the action of executable files when used with a run-time engine of the developing application.

These products must meet all the general requirements, with the following exceptions, and with the following additional requirements and recommendations:

Special Requirements for Development Tools

  • Make a development tool capable of generating logo-compliant applications. (Required)
  • Submit a sample application for testing of your development tool. (Required)
  • Make it easy to create OLE containers and/or object servers with your development tool. (Required)
  • Advise customers of potential logo-requirement problems in your development tool. (Required)

Special Exceptions for Development Tools

  • OLE drag-and-drop support is not required within the tool's design environment.
  • Development tools that create Java applications do not need to be capable of generating applications that can meet all of the Designed for Microsoft® Windows® Logo requirements (see Java Applications).
  • Development tools are temporarily exempt from the requirement to expose the keyboard focus. Vendors should be aware that this exemption will be removed in the next update of the Logo Handbook.
  • Java applications must use and re-distribute the 32-bit virtual machine for Java.
  • Add-on products must be hosted by a 32-bit product that is logo-compliant.


Make a Development Tool Capable of Generating Logo-Compliant Applications

Requirement (Designed for Microsoft® Windows® Logo)

If Windows is one of the compiler or development tool target platforms, the application must be capable of generating applications that can meet all of the Designed for Microsoft Windows Logo requirements.

Exception

Development tools that create Java applications do not need to be capable of generating applications that can meet all of the Designed for Microsoft Windows Logo requirements (see Java Applications).


Submit a Sample Application for Testing of Your Development Tool

Requirement (Designed for Microsoft® Windows® Logo)

Development tools are required to submit a sample application in uncompiled form for testing. When compiled, this sample application must demonstrate the following:

  • Win32® PE format
  • Large and small icons for its executable file
  • The ability to save/retrieve files with long file names
  • The ability to save/retrieve files with UNC file names
  • OLE container and/or server drag and drop functionality

Remarks

Sample applications are not required to meet any of the other Designed for Microsoft Windows Logo requirements, such as install/uninstall, and so forth.


Make It Easy to Create OLE Containers and/or Object Servers with Your Development Tool

Requirement (Designed for Microsoft® Windows® Logo)

The development tool must provide an easy point-and-shoot way (commonly known as wizards or experts) to create applications with OLE container or object server, or must provide OLE container or object-server functionality by default.


Advise Customers of Potential Logo-Requirement Problems in Your Development Tool

Requirement (Designed for Microsoft® Windows® Logo)

Certain interactive entertainment authoring tools that are intended only for authoring non-file-based multimedia applications are not required to create applications that support OLE and UNC paths (see Non-File-Based Applications).

However, the developer of this kind of tool must advise customers that if they create a file-based application using this tool (whether or not they use other tools), the application must meet the file-based requirements, including OLE support, to be eligible for the Designed for Microsoft Windows Logo.

As with other development tools, a sample application must be submitted in uncompiled form for testing.


Non-File-Based Applications

Non-file-based applications are treated differently than file-based applications for Logo purposes. Examples of non-file-based applications might be utilities, multimedia reference titles, games, or applications like Terminal and Clock. These applications, for the most part, do not save files in any way, or if they do, they only do so to store user profile data.

Exemption for Non-File-Based Applications:

  • If your product is a non-file-based application, the requirements to support OLE and to support UNC pathnames do not apply.

Distinguishing Between File-Based and Non-File-Based Applications

The following points distinguish between file-based and non-file-based applications:

  • 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).
  • The primary purpose of file-based applications is the creation and editing of documents. These applications include Open, Save, and Close commands, typically on the File menu of the application.

    For example, the primary purpose of applications such as Microsoft® Word and Microsoft® Excel is creating, editing, and manipulating files. Therefore, applications like these must support the requirements for file-based applications in order to be eligible to license the Designed for Microsoft® Windows® Logo.

  • Many accounting packages and Personal Information Manager (PIM) products are considered non-file-based applications. If you are uncertain about whether your product is considered non-file-based, please explain your case in the Vendor Questionnaire.
  • Generally, applications that run exclusively in full-screen mode are not, for Logo purposes, considered file-based. An application that runs exclusively in full-screen mode is one that cannot, for example, be windowed or resized.
  • Utilities are considered non-file-based applications.


Utilities

Utilities are products such as shell extensions, disk optimizers, antivirus software, certain query engines, and accessibility aids for people with disabilities.

Because utilities are considered Non-File-Based Applications, they are not required to provide OLE or UNC support.

They must meet all other general requirements contained in this document with the following special requirements, and with the following exceptions:

Special Requirements for Utilities

  • Provide meaningful functionality on both Windows 95 and Windows NT. (Required)
  • Extensively test any utility that uses the Exclusive Volume Locking function. (Required)

Special Exceptions for Utilities

  • Certain components of utilities may be 16-bit, such as those that must use the Exclusive Volume Locking function, soft interrupts, or components that must communicate directly to 16-bit drivers. The user interface and other components of these applications must be 32-bit and use the Windows® 95 thunking mechanism to access these 16-bit components.


Provide Meaningful Functionality on Both Windows 95 and Windows NT

Requirement (Designed for Microsoft® Windows® Logo)

For a utility product to receive the Logo, it must include meaningful functionality for both Windows 95 and Windows NT® environments in the same package (box).

Some products, such as disk utilities, implement operating-system-specific functionality that cannot be implemented on the other platform. For example, a set of utilities might include a disk defragmenter that operates on Windows NT but not on Windows 95. Nonetheless, such products must still include meaningful functionality for the other operating system.


Extensively Test Any Utility That Uses the Exclusive Volume Locking Function

Requirement (Designed for Microsoft® Windows® Logo)

Utility products that use the Exclusive Volume Locking API to access the 8.3 aliases directly and manipulate them (such as disk optimizers, file utilities, and antivirus software), must be tested extensively to ensure that these products function properly and do not damage the file allocation table or the long file name structure.

See Also

For more information about verification, see the "Pre-testing and Verification of Compliance" section.


Games and Multimedia Applications

Games and multimedia applications are a special case primarily because of their use of DirectX technologies, which are supported differently on different versions of Microsoft® Windows®.

Special Eligibility for the Designed for Windows 95 Logo

Products that use Direct3D or DirectSound are eligible for the Designed for Windows® 95 Logo. No other products are eligible.

Products that use the Direct3D and DirectSound APIs without updating Windows NT using SP3 may be granted the Designed for Windows® 95 Logo provided that the product does not load on Windows NT and displays a meaningful user message.

Special Requirements for Games and Multimedia Applications

  • Use DirectX compatibly with Windows NT Versions. (Required)
  • Use Direct3D and DirectSound compatibly with Windows NT 4.0 and Windows 95. (Required)
  • Use DirectX 5.0 for multimedia capabilities. (Required)

Resources

For more information on DirectX 5.0 please refer to the following web site: http://www.microsoft.com/directx.


Use DirectX Compatibly with Windows NT Versions

Requirement (Designed for Microsoft® Windows® Logo)

All applications that use Microsoft DirectX® must fail gracefully on Windows NT® 3.51 but must function properly on Windows NT 4.0 and later.

See Also

For more information about DirectX 5.0, see http://www.microsoft.com/directx.


Use Direct3D and DirectSound Compatibly with Windows NT 4.0 and Windows 95

Requirement (Designed for Microsoft® Windows® Logo)

All applications that use the Microsoft Direct3D® or Microsoft DirectSound® API must provide a comparable user experience on both Windows NT® 4.0 and Windows 95.

See Also

For more information about Microsoft DirectX 5.0, see http://www.microsoft.com/directx.


Use DirectX 5.0 for Multimedia Capabilities

Requirement (Designed for Microsoft® Windows® Logo)

Games and multimedia applications must support Microsoft DirectX® 5.0 (or later) as described below or use the Microsoft Win32® multimedia subsystem API.

  • Applications with 2-D graphics output should be produced using Microsoft DirectDraw® in either window or full-screen mode.
  • Applications providing sound playback should use Microsoft DirectSound®.
  • Applications with game support for keyboard, mouse, and gaming devices (such as joysticks and game pads) should use Microsoft DirectInput®.
  • Applications with hardware accelerated 3-D graphics should be accessed through Microsoft® Direct3D®.
  • Applications with advanced services for media integration, animation, or streaming of 2-D, 3-D, video, and audio should support Microsoft® DirectX® media (Microsoft ActiveMovie™ 2.0).

See Also

For more information about DirectX 5.0, see http://www.microsoft.com/directx.


Java Applications

A Java application, for the purposes of the Designed for Microsoft® Windows® Logo program, is defined as any application written in the Java programming language that requires a Java virtual machine to run. This section details the requirements and exemptions applicable to Java applications.

Special Requirement for Java Applications

  • Use and redistribute the 32-bit Virtual Machine for Java Applications. (Required)

Special Exceptions for Java Applications

  • Java applications are not required to be OLE servers or containers.
  • Java applications are temporarily exempt from providing support for high contrast, from supporting full functionality through the keyboard, and from exposing the keyboard focus.

    Popular class libraries such as AFC 4.0 will provide support for these accessibility features in the future. Thus vendors should expect this temporary exemption to be removed from future versions of the logo program.


Use and Redistribute the 32-bit Virtual Machine for Java Applications

Requirement (Designed for Microsoft® Windows® Logo)

To qualify for the Designed for Microsoft Windows Logo, a Java application must use and redistribute the Microsoft Win32® virtual machine for Java when running on a Windows-based computer.

See Also

For information about using and redistributing the Microsoft Win32 virtual machine for Java, see http://www.microsoft.com/java or the Microsoft SDK for Java.


Separate Add-On Products

Add-on products are accessory products, such as wizards, templates, and macros, that are not executable files.

A separate add-on product is packaged and marketed separately from the product it supports. If a wizard, template, or macro is always packaged only with the 32-bit product it supports, it is considered part of that product for purposes of the Designed for Microsoft® Windows® Logo testing.

Special Requirement for Add-On Products

  • Host an add-on product on 32-bit products that are logo-compliant. (Required)

General Requirements

An add-on product, by definition, does not have to provide an executable file (.exe). With that exception, add-on products must follow all Designed for Microsoft® Windows® Logo requirements that apply to any functionality they provide. For example:

  • Any executable code included in add-on products must be 32-bit code.
  • Add-on products must provide automated installers and uninstallers that follow user-interface guidelines.
  • Add-on products that use native data file types must register them and their icons.
  • Add-on products that use the mouse or keyboard, or that draw on the screen must support the Accessibility requirements.


Host an Add-On Product on 32-Bit Products That Are Logo-Compliant

Requirement (Designed for Microsoft® Windows® Logo)

To qualify for the Designed for Microsoft Windows Logo, add-ons must be used by a 32-bit application that is compliant with the Logo.

Remarks

This requirement does not require the host application to license the Logo.


Testing Rules

These guidelines relate to how an application is tested for logo compliance:

  • Bundled applications are tested individually.
  • Add-on products included in a suite are tested both individually and with the suite.
  • Pretest application installation.


Bundled Applications Are Tested Individually

Requirement (Designed for Microsoft® Windows® Logo)

For a bundled package of applications (commonly known as a suite) to use the Logo, each individual product in that suite must be tested and pass the Logo requirements. If you want the Logo to go on a product (from the suite) that is available separately, that product must be retested for compliance with Logo installation and uninstallation requirements only.


Add-On Products Included in a Suite Are Tested Both Individually and With the Suite

Requirement (Designed for Microsoft® Windows® Logo)

If separately marketed add-on products are also included in a suite of applications, they must be tested both separately and with the suite for the add-on product to qualify for the Designed for Microsoft Windows Logo.

See Also

For more information, see Separate Add-On Products.


Pretest Application Installation

Requirement (Designed for Microsoft® Windows® Logo)

The vendor must pretest the application using the Install Analyzer from VeriTest, Inc. and submit the report results in the Vendor Questionnaire. Improper handling of core and shared components is the main reason applications fail Logo testing on the first try and must retest. The Install Analyzer provides automated testing of compliance in this area. The Install Analyzer can be found at http://www.veritest.com/installation_analyzer.htm


Quick-Reference Lists of Programming Guidelines

This section helps you identify and find several useful subsets of the Designed for Microsoft® Windows® Logo guidelines:

  • New Requirements.
  • All Requirements.
  • Recommendations and Best Practices
  • Old Guidelines that have been removed


New Requirements

The following list of new requirements is provided to help plan logo compliance work for applications that have obtained earlier versions of the Designed for Microsoft® Windows® Logo.

This list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which this list refers.

Provide Consistent, Up-to-date Windows Support

  • Do not assume a hard-drive size limit of 2 GB.
  • Provide a Migration DLL where necessary.
  • Support Authenticode signing of downloadable code.
  • Handle system Sleep-Wake transitions properly.

Be Easy to Install and Remove

  • Use Microsoft installer technology. (Required)

Use the Registry Properly

  • Support informational keys in the registry.

Save Data to the Best Locations

  • Separate user data from application bits.
  • Query the registry for directory names.

Cooperate with Administrators

  • Enable policy settings to uninstall and unadvertise your application.
  • Provide an .ADM system policy file for your application.
  • Provide for disabling Run and Find dialogs.
  • Support NoViewContextMenu in shell extensions.
  • Call ShellExecute instead of CreateProcess.


All Requirements

This section lists all requirements for the Designed for Microsoft® Windows® Logo, but does not include any recommendations or best practices.

The list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which this list refers.

  • Provide consistent, up-to-date Windows support
  • Be easy to Install and Remove
  • Use the Registry correctly
  • Save data to the best locations
  • Cooperate with administrators.
  • Special requirements
  • Testing rules


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.

Designed for Microsoft® Windows® Logo requirements that relate to this goal are listed below. The list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the list refers.

General

  • Meet all requirements on the latest releases of Windows NT and Windows 95. (Required)
  • Support multiple platforms. (Required)
  • Make your application stable and fully functional. (Required)
  • Make your application 32-bit. (Required)
    • Identify 16-bit legacy versions clearly. (Required)
  • Support multiTasking. (Required)
  • Support standard system settings. (Required)

File System

  • Do not assume a hard-drive size limit of 2 GB.
  • Support the Universal Naming Convention (UNC).

    Exception: Non-File-Based Applications are not required to provide UNC support

  • Support long file names for files exposed to users.
  • Support long file names for files exposed in Windows Explorer.
  • Use long file names in user-interface elements.
  • Test LFN functionality on Windows NT FAT, NTFS, and compressed NTFS partitions.

Operating System Migration

  • Provide a Migration DLL where necessary.

Accessibility

  • Be compatible with the High Contrast option.
  • Provide keyboard access to all features.
  • Document the keyboard user interface.
  • Provide notifications of the keyboard focus location.

    Exception: Development tools and Java Applications are temporarily exempt from the requirement to expose the keyboard focus.

Internet Security

  • Digitally sign ActiveX controls.
  • Support Authenticode signing of downloadable code.

OLE / COM

  • Provide an OLE container or object server.

    Exception: Non-File-Based Applications and Java Applications are not required to provide OLE support.

  • Allow users to drag objects to any container.

    Exception: Development Tools are not required to provide drag-and-drop support within the tool's design environment.

  • Implement IDropTarget and/or IDropSource interfaces in containers .

    Exception: Development Tools are not required to provide drag-and-drop support within the tool's design environment.

  • Test object servers for basic OLE functionality.
  • Test containers for basic OLE container functionality.
  • Place an Object command on a container's Insert menu.

Telephony

  • Use TAPI for telephony.
  • Use the Assisted Telephony interface in telephony-enabled applications.
  • Implement the full TAPI interface in telephony-centric applications.
  • Apply dialing properties to numbers in telephony-centric applications.
  • Allow a user to select the calling device in telephony-centric applications.
  • Share serial devices properly in telephony-centric applications.
  • Explicitly link to a TAPI32 Library if using TAPI 2.x.
  • Gracefully degrade to work with TAPI 1.4 from TAPI 2.x.

OnNow / ACPI

  • Handle system Sleep-Wake transitions properly.


Be Easy to Install and Remove

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 needing to remove an application expects to be provided an easy, automated way to do so.

Designed for Microsoft® Windows® Logo requirements that relate to this goal are listed below. The list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the list refers.

Installing and Removing Applications

  • Use Microsoft installer technology.
  • Provide graphical 32-bit setup.
    • Provide attended and/or silent installation.
    • Detect versions when installing.
    • Create working shortcuts during installation.
    • Support autoplay of CD-ROMs.
    • Support Add/Remove Programs if not on CD-ROM.
    • Check operations in advance when installing.
  • Provide a fully automated uninstaller.
    • Register uninstaller and make it appear in Add/Remove Programs.
    • Uninstall from Add/Remove Programs.
    • Remove all application files during uninstall.
    • Remove all references from the Start Menu during uninstall.
    • Remove registry entries during uninstall.
    • Remove uninstaller during uninstall.

Installing and Removing Individual Components

  • Do not overwrite core components.
  • Do not decrement or remove core components during uninstall.
  • Register all shared components during installation.
  • Do not register self-registering components during installation.
  • Do not ref-count core components during installation.
  • Decrement the count on shared components while uninstalling.
  • Leave a zero count if not removing a component during uninstall.


Use the Registry Correctly

Designed for Microsoft® Windows® Logo requirements that relate to making appropriate use of the Microsoft® Windows® registry are listed below. The list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the list refers.

  • Register native data file types.
  • Do not add to Win.ini or System.ini.
  • Support informational keys in the registry.


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. Designed for Microsoft® Windows® Logo requirements that relate to installing programs and saving data in locations that minimize such confusion and frustration are listed below.

This list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the list refers.

  • Install applications to the \Program Files directory.
  • Do not install executables or DLLs in the root directory.
  • Separate user data from application bits.
  • Query the registry for directory names.


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. Designed for Microsoft® Windows® Logo requirements that relate to making your application manageable are listed below.

This list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the list refers.

  • Enable policy settings to uninstall and unadvertise your application.
  • Provide an .ADM system policy file for your application.
  • Provide for disabling Run and Find dialogs.
  • Support NoViewContextMenu in shell extensions.
  • Call ShellExecute instead of CreateProcess.


Special Requirements

Several types of application have special requirements and exemptions when applying to use the Designed for Microsoft® Windows® Logo. Designed for Microsoft® Windows® Logo requirements relating to particular types of applications are listed below.

These lists are just summaries. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the lists refer.

Development Tools

  • Make a development tool capable of generating logo-compliant applications.
  • Submit a sample application for testing of your development tool.
  • Make it easy to create OLE containers and/or object servers with your development tool.
  • Advise customers of potential logo-requirement problems in your development tool.

Utilities

  • Provide meaningful functionality on both Windows 95 and Windows NT.
  • Extensively test any utility that uses the Exclusive Volume Locking function.

Games and Multimedia Applications

  • Use DirectX compatibly with Windows NT Versions.
  • Use Direct3D and DirectSound compatibly with Windows NT 4.0 and Windows 95.
  • Use DirectX 5.0 for multimedia capabilities.

Java Applications

  • Use and redistribute the 32-bit Virtual Machine for Java Applications.

Separate Add-On Products

  • Host an add-on product on 32-bit products that are logo-compliant.


Testing Rules

The requirements listed below relate to how an application is tested for Designed for Microsoft® Windows® Logo compliance.

This list is just a summary. To qualify for the Designed for Windows Logo, you must comply with all stipulations of the requirement reference text to which the list refers.

  • Bundled applications are tested individually.
  • Add-on products included in a suite are tested both individually and with the suite.
  • Pretest application installation.


Recommendations and Best Practices

This section lists all recommendations and best practices associated with the Designed for Microsoft® Windows® Logo program, but does not include any requirements.

These lists are just summaries. To comply with the recommendations and best practices, you must follow all stipulations of the reference text to which the lists refer.

  • Provide consistent, Up-to-date Windows Support
  • Be easy to Install and Remove
  • Use the Registry correctly
  • Save data to the best locations
  • Cooperate with administrators.


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.

Designed for Microsoft® Windows® Logo recommendations and best practices that relate to this goal are listed below. The lists are just summaries. To comply with the recommendations and best practices, you must follow all stipulations of the reference text to which the lists refer.

General

  • Support additional standard system settings. (Recommended)
  • Use standard system settings for multi-monitor support. (Best Practice)
  • Support Windows Sockets 2.0. (Recommended)
  • Detect and handle slow or dead network links. (Best Practice)

File System

  • Be file-system independent. (Best Practice)
  • Hide program files and directories that users do not need to see. (Best Practice)

Operating System Migration

  • Migration DLLs work silently. (Recommended)
  • Avoid operating system differences. (Best Practice)

Accessibility and User Interface

  • Do not rely on sound alone. (Recommended)
  • Do not rely on color alone. (Recommended)
  • Let other software identify and manipulate screen elements. (Recommended)
  • Support Active Accessibility. (Best Practice)
  • Do not hard-code font sizes smaller than 10 points. (Best Practice)
  • Allow users to customize UI timings. (Best Practice)
  • Support system font and resolution changes. (Best Practice)
  • Allow users to set font names and sizes. (Best Practice)
  • Handle changes in pointer or keyboard focus. (Best Practice)
  • Test using multiple displays. (Best Practice)

Internet

  • Support automatic download of ActiveX controls. (Best Practice)
  • Register an Internet update site when installing. (Best Practice)
  • Register a product information site when installing. (Best Practice)
  • Support ModuleUsage registration of DLLs. (Best Practice)
  • Expose Help documentation as HTML. (Recommended)
  • Support saving to an FTP site. (Best Practice)
  • Generate browsable output. (Best Practice)

OLE / COM

  • Make object servers ActiveX document servers. (Recommended)
  • Make containers ActiveX document containers. (Recommended)
  • Close object servers automatically after object delivery. (Recommended)
  • Support ActiveX Accessibility in containers. (Recommended)
  • Support modifier keys in containers. (Recommended)
  • Provide linking and in-place activation in containers. (Recommended)
  • Support the structured storage compound file format in containers. (Recommended)
  • Use component categories. (Best Practice)
  • Use the system property set implementation. (Best Practice)
  • Provide a type library for public automation interfaces. (Best Practice)

COM+

  • Support Microsoft Transaction Server. (Best Practice)
  • Expose all new object servers as COM+ objects. (Best Practice)
  • Support the COM+ versioning and configuration model. (Best Practice)
  • Use COM+ calling conventions. (Best Practice)
  • Support COM+ events rather than custom event programming. (Best Practice)
  • Expose standard COM+ interfaces. (Best Practice)
  • Take advantage of COM+ run-time interfaces. (Best Practice)
  • Take advantage of COM+ run-time DLL functions. (Best Practice)
  • Do not write InprocServer32 entries for components directly to HKCR. (Best Practice)
  • Support COM+ declarative attributes. (Best Practice)
  • Use COM+ automatic transaction support, persistence, and data binding as necessary. (Best Practice)
  • Implement system monitoring or call monitoring and management using interception. (Best Practice)
  • Use the COM+ persistent event binding system. (Best Practice)
  • Use the COM+ importer, emitter, portable executable format, and run-time system. (Best Practice)

Telephony

  • Use TAPI 2.1 remote service provider for client-server telephony. (Recommended)
  • Use TAPI 2.1 client-management functions for client-server telephony. (Recommended)
  • Use TAPI 2.1 for telephony as soon as it becomes available. (Best Practice)
  • Use the dialing properties current location settings in telephony-enabled applications. (Best Practice)
  • Use the canonical/international form for the number dialed in telephony-enabled applications. (Best Practice)
  • Provide separate fields with defaults for phone number entry. (Best Practice)
  • Handle the LINE_CREATE message properly in telephony-centric applications. (Best Practice)
  • Handle _REINIT messages properly in telephony-centric applications. (Best Practice)

OnNow / ACPI Support

  • Eliminate even minor memory leaks. (Recommended)
  • Process Sleep or Query messages silently. (Recommended)
  • Pause play and sound on receiving a Sleep message in a game. (Recommended)
  • Call SetThreadExecutionState in event-handling applications. (Best Practice)
  • Call SetThreadExecutionState in presentation applications. (Best Practice)
  • Curtail background activities when running on batteries. (Best Practice)
  • Take no action on receiving a …RESUMEAUTOMATIC message. (Best Practice)

Directory Services

  • Use a product-specific DS object in the configuration/services container. (Best Practice)
  • Use RpcNsBindingLookupBegin in RPC clients to find RPC server objects. (Recommended)
  • Use WSALookupServiceBegin in clients to find Windows Sockets server objects. (Recommended)
  • Locate COM objects in the Class Store transparently in COM and DCOM clients. (Recommended)
  • Publish only machine-specific parameters in the registry. (Recommended)


Be Easy to Install and Remove

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 needing to remove an application expects to be provided an easy, automated way to do so.

Designed for Microsoft® Windows® Logo recommendations and best practices that relate to this goal are listed below. The list is just a summary. To comply with the recommendations and best practices, you must follow all stipulations of the reference text to which the lists refer.

Installing and Removing Applications

  • Maintain user settings across version changes. (Best Practice)
  • Avoid rebooting the system. (Best Practice)

Installing and Removing Individual Components

  • Do not write to Windows system directories. (Recommended)
  • Use Microsoft update packs to upgrade system components. (Recommended)
  • Do not install globally shared DLLs. (Recommended)
  • Set count correctly for pre-existing unregistered shared components during installation. (Best Practice)


Use the Registry Correctly

Designed for Microsoft® Windows® Logo recommendations and best practices that relate to making appropriate use of the Microsoft® Windows® registry are listed below. The list is just a summary. To comply with the recommendations and best practices, you must follow all stipulations of the reference text to which the lists refer.

  • Ask before reassigning file-extension associations. (Best Practice)
  • Use the correct access mask when opening a registry key. (Recommended)
  • Register classes on a per-user basis in HKCU. (Recommended)
  • Do not write default profile settings to the registry. (Recommended)
  • Do not register hard-coded paths. (Best Practice)
  • Use REG_EXPAND_SZ strings on Windows NT 5.0. (Best Practice)
  • Do not register strings As REG_BINARY. (Best Practice)
  • Register policy keys in a standard location. (Best Practice)
  • Store hardware-independent machine settings in HKEY_LOCAL_MACHINE. (Best Practice)
  • Store hardware-dependent settings in HKEY_CURRENT_CONFIG. (Best Practice)


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. Designed for Microsoft® Windows® Logo recommendations and best practices that relate to installing programs and saving data in locations that minimize such confusion and frustration are listed below. The list is just a summary. To comply with the recommendations and best practices, you must follow all stipulations of the reference text to which the lists refer.

  • Do not write to Windows system directories. (Recommended)
  • Use Microsoft update packs to upgrade system components. (Recommended)
  • Do not install globally shared DLLs. (Recommended)
  • Store user data under the user's Profile folder. (Recommended)
  • Do not assume that profile settings have been initialized. (Recommended)


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. Designed for Microsoft® Windows® Logo recommendations and best practices that relate to making your application manageable are listed below. The list is just a summary. To comply with the recommendations and best practices, you must follow all stipulations of the reference text to which the lists refer.

  • Support roaming users. (Best Practice)
  • Do not collect single-user data during installation. (Best Practice)
  • Support administrative additions during network install. (Recommended)
  • Generate a disk image for multiple installs during network installation. (Recommended)
  • Install shared files in shared locations during network installation. (Recommended)
  • Support silent installs and push strategies during network installation. (Recommended)
  • Do not require a local footprint during network install. (Recommended)
  • Provide a diagnostic logging option. (Recommended)
  • Do not assume write access to a user's machine. (Recommended)
  • Support dynamic policy changes by handling WM_SETTINGCHANGE messages. (Recommended)
  • Expose private policy keys where appropriate. (Best Practice)


Old Guidelines That Have Been Removed

The following guidelines present in previous versions of the Designed for Microsoft® Windows® Logo Handbook have been removed:

  • Uninstallers should require adequate security permissions (Logo Handbook version 3.0, page 28).
  • Development tools should be able to create applications that use multiple threads (Logo Handbook version 3.0, page 45).


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

Remedy: Rerun the MSDN Library Setup.

  • The file (.chm) that contains the current topic or destination topic is out-of-date and the link is no longer valid.

Remedy: Install the latest version of the MSDN Library.

  • The MSDN Library CD is not in the CD-ROM drive.

Remedy: Insert the MSDN Library CD into the CD-ROM drive.