Passing these requirements will help ensure that your application runs in a stable, reliable manner on Windows operating systems.
Customers can be confident that a compliant product will not adversely affect the reliability of the operating system.
Supporting Long File Names:
http://msdn.microsoft.com/library/psdk/winbase/filesio_7qwj.htm
Using Driver Verifier tool:
www.microsoft.com/hwdev/driver/driververify.htm
General Functionality and Stability Test Procedure for the Certified for Microsoft® Windows® Logo:
http://msdn.microsoft.com/certification/download.asp
VeriTest-Rational Install Analyzer for Windows 2000
http://www.veritest.com/mslogos/windows2000/
Link Utility-Microsoft Platform SDK
Your application must perform its primary functionality without compromising the stability of the operating system or your application.
Primary functions are: functions so important that, in the estimation of a normal user, their inoperability or impairment would render the product unfit for its purpose. For example:
While users perform the primary functions of your application, it must not hang, crash, or lose users' data. Primary functions should not become inoperable or obstructed, and the application must not disrupt Windows or other applications running on the computer.
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 Link utility on the Microsoft Platform Software Developer's Kit (SDK) or the VeriTest-Rational Install Analyzer tool available for free download from http://www.veritest.com/mslogos/windows2000/.
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.
Important When you submit your product for compliance testing, you must list the file name 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.
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.
Whenever possible, you should avoid using 16-bit code, even for backward compatibility, because 64-bit versions of Windows will not support 16-bit code.
If your application exposes file names 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 name 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 valid Win32 long file names, see the Platform SDK and http://msdn.microsoft.com/library/psdk/winbase/filesio_7qwj.htm.
Windows allows long file names for Printers. If your application supports printing, it must accept names up to 220 characters long for printers, and print to devices with names such as these:
\\PrintServer44.domain.com\Duplex printer: number 0047 (accounting group)
Color laser-Research and Design Dept IP 123.456.78.9 see Fred or Wilma
Note Commas and exclamation points are illegal printer name characters.
Your application must not read from or write to Win.ini, System.ini, Autoexec.bat, or Config.sys. These file are not used by Windows 2000 systems, and some users remove them.
Every non-hidden file that your application creates outside its directory in "Program Files" (see Requirement 3) 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 is 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. Note that 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 are not 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:
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 2000 with Service Pack 1 (SP1), your version-checking should allow installation on Major Version 5, Minor Version 0, SP1, and it must also install on all operating system version numbers that are greater than this number (such as Windows 2000 Service Pack 2 (SP2) and so on).
Exception In certain cases, it is acceptable to block install on later versions of Windows. If you choose to do this, you must:
Examples where this is appropriate would be for low-level disk utilities. In this case, running such an application on a Windows version for which the product was not tested could potentially result in lost user data. For example, the application might not be aware that there could be changes in the file system.
For applications that will run only on Windows 2000 and later versions, we recommend that you use the VerifyVersionInfo API to determine the version of the operating system. Note, however, that this API is not available on down-level platforms. For applications that also run on Windows NT® 4.0, you should use the GetVersionEx() API to determine the OS version. See the code samples below for examples of each implementation.
Using VerifyVersionInfo helps applications more reliably determine if the application can be installed on a particular OS. In the past, the application would request the version info from the OS and then write code to decide it the current version met its needs. In contrast, with VerifyVersionInfo, the application tells the OS what version it needs, and then asks the OS if the current version meets this. Fewer lines of code are needed.
#ifdef Windows2000
//
//This sample is for Windows2000 and later versions
//
BOOL bIsWindowsVersionOK(DWORD dwMajor, DWORD dwMinor, DWORD wSPMajor )
{
OSVERSIONINFOEX osvi;
DWORDLONG dwlConditionMask;
ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);
osvi.dwMajorVersion = dwMajor;
osvi.dwMinorVersion = dwMinor;
osvi.wServicePackMajor = wSPMajor;
// Set up the condition mask.
VER_SET_CONDITION( dwlConditionMask, VER_MAJORVERSION, VER_GREATER_EQUAL );
VER_SET_CONDITION( dwlConditionMask, VER_MINORVERSION, VER_GREATER_EQUAL );
VER_SET_CONDITION( dwlConditionMask, VER_SERVICEPACKMAJOR, VER_GREATER_EQUAL );
// Perform the test.
return VerifyVersionInfo(&osvi,
VER_MAJORVERSION | VER_MINORVERSION | VER_SERVICEPACKMAJOR,
dwlConditionMask);
}
#endif
This code runs on all 32-bit Windows platforms. Note that, 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, as in this sample.
HKLM\system\CurrentControlSet\control\windows\CSDVersion
The values of CSDVersion will be 0x100 for Service Pack 1, 0x200 for Service Pack 2, and so forth. See below for code sample to determine the Service Pack level.
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;
}
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 folder on Windows 2000 systems. See www.microsoft.com/hwdev/driver/driververify.htm for more information on using the Driver Verifier Manager and diagnosing driver problems.
If your product includes drivers for hardware devices, these drivers must be tested by Windows Hardware Quality Labs (WHQL). Note that turnaround times at WHQL can be up to 30 days. For more information, see www.microsoft.com/hwdev/winlogo/default.htm.
Client components that run on Windows 2000 Professional and that ship with your application must comply with the desktop application specification for Windows 2000 (see http://msdn.microsoft.com/library/specs/w2kcli.htm) in order for the whole application to be Certified for Windows. Distributed applications that have client components are eligible to carry both Windows 2000 Server and Windows 2000 Professional designations on their Certified for Windows logo.
The following clients may be exempted from complying with the Desktop Application Specification:
In addition, special considerations apply for browser-hosted client applications. Please see Appendix B for details.
Note Testing for client components will be performed on Windows 2000 Professional, but not on down-level operating systems.
Use the VeriTest-Rational Install Analyzer for Windows 2000, available from http://www.veritest.com/mslogos/windows2000/-or 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:
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 name that contains spaces from a command line, you will need to enclose the name in quotes.