Passing these requirements will help your application run in a stable and reliable manner on Windows operating systems.
Customers can be confident that a compliant product will not adversely affect the reliability of the operating system.
1.1 Perform primary functionality and maintain stability
1.2 Provide 32-bit components and document any 16-bit code
1.3 Support Long File Names and UNC paths
1.4 Support printers with long names and UNC paths
1.5 Do not read from or write to Win.ini, System.ini, Autoexec.bat or Config.sys on any Windows operating system based on NT technology
1.6 Ensure non-hidden files outside of your application directory have associated file-types with icons, descriptions, and actions
1.7 Perform Windows version checking correctly
1.8 Support AutoPlay of compact discs
1.9 Any kernel mode drivers your application installs must pass verification testing on Windows 2000
1.10 Any hardware drivers included with your application must pass WHQL testing
Your application must perform its primary functions without compromising the stability of the operating system or your application. If your application is available on other Windows operating systems, your application must perform its primary functionality at least as well on Windows 2000 as it does on down-level versions of Windows.
For example:
Users must be able to use system features supported by Windows 2000 with your application. For example:
For more information on primary functions and stability, see the "General Functionality and Stability Test Procedure for the Certified for Microsoft Windows Logo" located at: http://msdn.microsoft.com/certification/download.asp.
An application must be a 32-bit executable file of the Portable Executable (PE) format. This means that all executable files, including dynamic-link libraries (DLLs) and executable (EXE) program files, must be 32-bit files. You can test for the correct executable format by using the VeriTest-Rational Install Analyzer tool available for free download from: www.veritest.com/mslogos/windows2000/Installation_analyzer.htm
If your application is not represented in PE format, for example, interpreted code, then the "run-time engine" must be a Win32-based executable file in PE format. For example, if you develop an application in Microsoft Access, your application is an .mdb file, not an .exe file. However, msaccess.exe is a Win32-based executable file in the PE format.
If you require 16-bit executable files or DLLs for backward compatibility and links to 16-bit products, you must provide a mechanism to ensure that the application continues to function properly if the user upgrades the operating system to Windows 2000. For more information, see: "Chapter 7: Application Migration".
Note Whenever possible, you should avoid using any 16-bit code even for backward compatibility, because 64-bit versions of Windows will not support 16-bit code.
Note Each 16-bit file must be tested as part of the Certification process to ensure that system stability is not compromised. This may require additional testing time and consequent additional charges by the testing agency. The time and charges will be determined on a case-by-case basis by the testing agency.
Important When you submit your product for compliance testing, you must list the filename and fully explain the use of any 16-bit file your application could install. This must be done in the electronic Vendor Questionnaire you submit with your application.
If your application exposes filenames to users and/or allows users to enter file names, then your application must support all valid Win32 file names, including Long File Names (LFNs) and Universal Naming Convention (UNC) names. LFNs and UNC names may be longer than the names allowed by 16-bit Windows and legacy DOS applications, and they may contain characters that were not allowed in 16-bit Windows or DOS.
For example, your application must properly recognize and display the following paths:
C:\documents and settings\joe user\my documents\my letter.txt
C:\documents and settings\Joe [joeuser]\my documents\Ca$h;flow\
my letter to André.txt
D:\Our folder\project 10\project 11\project 12\project 13\
project 14\project 15\ project 16\project 17\project 18\project 19\
project 20\project 21\ project 22\project 23\project 24\project 25\
project 26\project 27\ project 28\project 29\project 30\filename.ext
\\server\sharename\joe user\my letter.txt
All Win32 functions that create, open, locate and save files and folders use the constant MAX_PATH as the maximum buffer size for path information. Your application must allow users to create files with a total path length up to MAX_PATH, and your application must open any supported files the user creates, with your application and any other application, on paths up to MAX_PATH long. The MAX_PATH constant is defined in the platform SDK support file windef.h. In the current platform SDK, the value of MAX_PATH is "260." You should use the MAX_PATH constant name instead of coding the value in your application. Using the constant instead of the value will help you quickly adapt your application to future versions of Windows, which may support longer paths, but use the same constant name.
For more details on supporting valid Win32 long file names, see the Platform SDK and http://msdn.microsoft.com/library/psdk/winbase/filesio_7qwj.htm.
Note Double Byte Character Set (DBCS) applications: DBCS-enabled ANSI applications are required to properly support LFNs with DBCS characters in the language they support (e.g., a Japanese application must handle all Japanese LFNs correctly). Applications that are submitted for any double byte language will be tested for compliance with this requirement using LFNs based on those character sets.
Exception Applications may be exempted from supporting file names and paths that contain certain characters, provided: 1) the application reserves those characters for special use. For example, some applications allow users to open multiple files at once and use a semi-colon to separate file names; 2) the application can support those characters if the filename or path is enclosed in quotes; 3)This is documented in the vendor questionnaire.
Windows allows names for Printers up to 220 characters long. Your application must start and function without errors, even if the Windows default printer has a long name. If your application supports printing, your application must accept and display printer names up to 220 characters long (if any printers are displayed by name in the print dialogs), and print to devices with long names. Examples of long printer names are:
\\PrintServer44.domain.com\Duplex printer: number 0047 (accounting group)
Color laser - Research & Design Dept IP 123.456.78.9 see Fred or Wilma
Note Commas and exclamation points are illegal printer name characters.
Note Double Byte Character Set (DBCS) applications: DBCS-enabled ANSI applications are required to properly support printer names with DBCS characters in the language they support (e.g., a Japanese application must handle all Japanese long printer names correctly). Applications that are submitted for any double byte language will be tested for compliance with this requirement using long printer names based on those character sets.
Your application must not read from or write to Win.ini, System.ini, Autoexec.bat, or Config.sys on any Windows operating system based on NT technology. These files are not used by NT-based Windows operating systems and some users remove them.
Exception You may write to these four files during installation only if your application needs to support legacy 16-bit code. The 16-bit code may read those files when the application runs. Windows 2000 security prevents Users from writing to any files in the %systemroot% folder and the 16-bit code will not be able to make changes to win.ini or system.ini when members of the Users group run your application. Running the application as a User is required for Certification for Windows 2000. All writes to and reads from win.ini, system.ini, autoexec.bat and config.sys must be documented in the Vendor Questionnaire
Every file that does not have the hidden bit set that your application creates outside its directory in "Program Files" (see: Requirement 2.4) must have an associated registered file-type. This includes:
If the file-type is already registered, no action is required, though you may take over the file-type if you wish.
If the file-type is not already registered, you must do the following for each new file type:
The NoOpen designation may be used for files that you don't want users to open. When the user double-clicks a file marked as NoOpen, the operating system will automatically provide a message informing the user that the file should not be opened. If an action is later associated with a NoOpen file type, the NoOpen designation will be ignored.
Exception If your application allows the user to save or export file types that aren't native to your application, the user may choose to save a file as a type that has no association on the user's computer. Your application may save the file as requested by the user, even though the file will have a default Windows icon.
To check if a file extension is already registered:
To register new file-types:
The file-type is the unique identifier for all files with a given file extension. For example, "txtfile" is the file-type for files with the .txt extension. Note that multiple extensions can point to the same file-type. For example, ".txt" and ".log" both point to the same file-type, "txtfile." The default value for the file-type key is the "friendly name" that is displayed in Windows Explorer. For example, extensions that point to the "txtfile" key have the friendly name, "Text Document."
We recommend 4 or 5 characters since this will help avoid file-type collisions and will make the file-type easier to identify. Then set the default value for the file extension to point to the file-type you've just created. For example the default value for ".txt" is the file-type "txtfile".
To register an icon for a file type:
To identify a file as "No Open":
Example: Registry structure to associate ".txt" file extension with "Txtfile" file type:
HKEY_CLASSES_ROOT\.txt
(default) = "txtfile"
HKEY_CLASSES_ROOT\txtfile
\DefaultIcon
(default) = %SystemRoot%\system32\shell32.dll,-152
\shell\open\command
(default) = %SystemRoot%\system32\NOTEPAD.EXE %1
Your application must verify that the operating system meets the minimum version requirements for your application. The application must also install and run on all later versions of that operating system.
For example, if the application requires Windows NT 4.0 with Service Pack 3 (SP3), your version checking should allow installation on Windows NT, Major Version 4, Minor Version 0, SP3, and it must also install on all operating system version numbers that are greater than this number (such as Windows NT 4.0 Service Pack 4 [SP4], Windows 2000, Windows 2000 with any subsequent Service Packs, and so on).
Exception In certain cases it is acceptable to block install on later versions of the OS. If you choose to do this, you must: 1) Document this in the Vendor Questionnaire and explain the rationale, AND 2) Display a message to the user when blocking installation or execution that your application is not designed for the later OS version. Examples where this is appropriate would be for low-level disk utilities. In this case, running such an application on an OS for which the product was not tested for could potentially result in lost user data, if for example there were changes in the file system that the application was not aware of.
In general, you should use the GetVersionEx() API to determine the OS version. If you need to verify the version of an NT4 Service Pack prior to Service Pack 4, you should also query the following registry key to determine the SP level.
HKLM\system\CurrentControlSet\control\windows\CSDVersion
The values of CSDVersion will be 0x100 for Service Pack 1, 0x200 for Service Pack 2, etc. See below for code sample to determine the Service Pack level.
This code runs on all 32-bit Windows platforms:
BOOL bIsWindowsVersionOK(DWORD dwMajor, DWORD dwMinor, DWORD dwSPMajor )
{
OSVERSIONINFO osvi;
// Initialize the OSVERSIONINFO structure.
//
ZeroMemory(&osvi, sizeof(OSVERSIONINFO));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
GetVersionEx((OSVERSIONINFO*)&osvi);
// First the major version
if ( osvi.dwMajorVersion > dwMajor )
return TRUE;
else if ( osvi.dwMajorVersion == dwMajor )
{
// Then the minor
if (osvi.dwMinorVersion > dwMinor )
return TRUE;
else if (osvi.dwMinorVersion == dwMinor )
{
// OK, better check the Service Pack
if ( dwSPMajor &&
osvi.dwPlatformId == VER_PLATFORM_WIN32_NT )
{
HKEY hKey;
DWORD dwCSDVersion;
DWORD dwSize;
BOOL fMeetsSPRequirement = FALSE;
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
System\\CurrentControlSet\\Control\\Windows",
0, KEY_QUERY_VALUE, &hKey) == ERROR_SUCCESS)
{
dwSize = sizeof(dwCSDVersion);
if (RegQueryValueEx(hKey, "CSDVersion",
NULL, NULL,
(unsigned char*)&dwCSDVersion,
&dwSize) == ERROR_SUCCESS)
{
fMeetsSPRequirement =
(LOWORD(dwCSDVersion) >= dwSPMajor);
}
RegCloseKey(hKey);
}
return fMeetsSPRequirement;
}
return TRUE;
}
}
return FALSE;
}
For products distributed on CD-ROM or DVD-ROM, the first time the disc is inserted, your application must use AutoPlay to either prompt the user to install or to run the application. It is up to you whether AutoPlay is enabled on subsequent insertions of the CD-ROM/ DVD-ROM. In the case of products distributed on multiple discs, subsequent discs must either use the AutoPlay feature or behave during installation like a subsequent floppy disk; they must continue installation without prompting the user for action.
It is not acceptable to require the user to use Start/Run to launch the installation from the CD-ROM or DVD-ROM.
For more information on using AutoPlay, please see: http://msdn.microsoft.com/library/techart/msdn_autoplay.htm
Poorly written kernel mode drivers have the potential to crash the system. Therefore, it is critical that any application that includes kernel mode drivers, such as anti-virus products, be thoroughly tested to minimize this risk.
If your application includes any kernel mode drivers, each of these drivers must pass validation triggered by the Windows 2000 Driver Verifier Manager tool (Verifier.exe). Driver Verifier is located in the \system32 directory on Windows 2000 systems. For more information on using the Driver Verifier Tool and diagnosing driver problems see: www.microsoft.com/hwdev/driver/driververify.htm.
If your product includes drivers for hardware devices, these drivers must pass testing by Windows Hardware Quality Labs (WHQL). Please note that turn-around times at WHQL can be up to 30 days. For more information, see: www.microsoft.com/hwdev/winlogo.
Use the VeriTest-Rational Install Analyzer for Windows 2000, available from: www.veritest.com/mslogos/windows2000/ OR you can use the Link utility in the Microsoft Platform SDK.
If you use the Link utility, at the command line, type: "link -dump -headers exename.exe | more". If your application is in the proper PE format, the output of this command will be:
Microsoft (R) COFF Binary File Dumper Version 5.12.8181
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file exename.exe
PE signature found
File Type: EXECUTABLE IMAGE
.
.
.
You should not get the following output, which would be produced if the application were 16-bit:
Microsoft (R) COFF Binary File Dumper Version 5.12.8181
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file exename.exe
LINK : warning LNK4095: " exename.exe" is an NE format executable; use EXEHDR to dump it
.
.
.
LFNs must do the following:
You can test for this by typing " test " or similar text in the "Save As" dialog box. The program should strip the spaces and add an extension, returning the file name "test.ext".
Note The ANSI 0160 character, used as a non-breaking space character in many fonts, should always be retained, even if used as the leading or trailing character in folder and file names.
| If you type… | It should be saved as |
| "test" | "test.ext" |
| " test" | "test.ext" |
| "test " | "test.ext" |
| "test#;#+#,#=#[#]" | "test#;#+#,#=#[#].ext" |
| " test " (non-breaking space characters ANSI 0160) | " test .ext" |
| "…..test….." | "…..test……ext" |
| "\\server\share one\folder three\file" | "\\server\share one\folder three\file.ext" |
NOTE If you are typing a UNC or LFN name that contains spaces from a command line, you may need to enclose the name in quotes.