Installation

User Experience

Required:
The product must have an installation program with a graphical Setup program that executes in a 32-bit Microsoft Windows operating system.

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

Required:
The installer must automatically detect the version of Microsoft Windows NT and/or Windows 95 running and install the correct version of your product automatically. This must be a seamless experience for the user.

Required:
All shortcuts created by the installation must be viable, that is, not result in "file not found" or other error conditions when activated.

Required:
Products distributed on CD-ROM must utilize the AutoPlay feature to begin setup or launch the program itself 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 utilize the AutoPlay feature or behave during install like a subsequent floppy disk (continue install without prompting user for action.) It is not acceptable to require the end user to Start, Run the CD-ROM during installation.

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

Required:
The 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 their machine, or if the application is being installed onto a non-English language, localized version of Windows.

Required:
The application's installer must not install application DLLs or executables under the system root.

Required:
The installer must check before starting any operation to ensure that it can complete that operation. The following are the 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. Installers that need to overwrite system files, for example, should check up-front if the current user is a member of the administrators 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 admin privileges, and the installer must allow them to discontinue the installation. This may be accomplished by using the Sample Code below or the KB article PSS ID# Q118626.

Sample Code:

//--------------------------------------------------------//
//									 
// 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;
}

Recommended:
Applications should not assume that directory names will be in the English language, or unchanged by the user (for example, "Program Files".) Applications should query the registry directly to obtain the proper, language specific directory names. Vendors should be aware that English versions of their application might be installed onto a non-English language version of Windows. In this instance a search for the English language directory string "Program Files" would not be successful & would result in a failed install. For other folders the proper paths can be queried via the SHGetSpecialFolderLocation() function with the following CSIDL flags:

#define CSIDL_PROGRAMS                  0x0002
#define CSIDL_PERSONAL                  0x0005
#define CSIDL_FAVORITES                 0x0006
#define CSIDL_STARTUP                   0x0007
#define CSIDL_RECENT                    0x0008
#define CSIDL_SENDTO                    0x0009
#define CSIDL_STARTMENU                 0x000b
#define CSIDL_DESKTOPDIRECTORY          0x0010
#define CSIDL_NETHOOD                   0x0013
#define CSIDL_TEMPLATES                 0x0015
#define CSIDL_COMMON_STARTMENU          0x0016
#define CSIDL_COMMON_PROGRAMS           0X0017
#define CSIDL_COMMON_STARTUP            0x0018
#define CSIDL_COMMON_DESKTOPDIRECTORY   0x0019
#define CSIDL_APPDATA                   0x001a
#define CSIDL_PRINTHOOD                 0x001b

Recommendations to enable roaming users & unattended install:

Recommended:
User settings should be maintained across application version changes. It’s also recommended that user settings be able to be moved from machine to machine. Examples of user settings include customized toolbars, any dynamic, user-generated lists or other user specific options. For information about supporting a Networked or Managed environment refer to section 6.2.4.

Recommended:
If the application can be sure it is installing on a single user machine, it should collect user name or Personal ID (PID) information the first time the application is run, not during install.

Using the Registry

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

[HKEY_CLASSES_ROOT]

.(file type extension)
(Default) = REG_SZ:FileTypeID

See the “Windows Interface Guidelines for Software Design," chapter 10 (available from MS Press), for further details on registering file types and application data.

Required:
The application installer must register all shared components designed to be uninstalled under the following Registry key:

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

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

Required:
Core components must not be refcounted in the registry by application installers. Please see http://www.microsoft.com/windows/thirdparty/winlogo/ for the most up-to-date and complete list of Windows 95 and Windows NT core components.

Required:
The application must not add information to Win.ini or System.ini.

Exception:
Certain multimedia applications may require video codecs not supplied with Windows NT or 95. Products that must support links to existing 16-bit products may write to these files. Certain other products, such as screen savers, may not be supported in the Registry and must write to the .ini files. 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.

Any writes to Win.ini or System.ini must be explained in the Vendor Questionnaire.

Recommended:
In addition to the above requirements, the following behaviors are strongly recommended with regard to registry usage:

• Applications should provide the following set of information in the registry. This information will be used by the Add/Remove Programs Control Panel to provide a central place for information about the application.
  
  
• The registry values in the table below 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’s uninstall program.
ModifyPath	REG_SZ*	Full path to the Application’s setup/modify program.
InstallLocation	REG_SZ*	Full path where the Application is located (folder or *.exe).
InstallSource	REG_SZ*	Location where the Application was installed from.
DisplayVersion	REG_SZ	Displayed version number of Application.
VersionMajor	DWORD	Major Version Number of Application.
VersionMinor	DWORD	Minor Version of Application.
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 Helpfile or Help URL for Application.
URLUpdateInfo	REG_SZ*	URL of Update Informaton for Application.
URLInfoAbout	REG_SZ*	URL that provides a link to the publisher’s home page or the application’s home page.




* For Windows NT 4.0, Windows95, and future versions of Windows 95, 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 with asterisks.

InstallSource: This is the path from which the application was installed. It could also be an HTTP site or a network UNC path, such as \\applications\sample. If the application were installed from floppy, then 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 are up to the application. Note that newer versions of the application must have a larger VersionMinor and/or a larger VersionMajor field to indicate an update.