Welcome

Welcome to the Windows 2000/XP Application Compatibility Demonstration Application. This application was specifically designed to illustrate how several common compatibility issues can be addressed in Windows 2000/XP. Microsoft has developed an Application Compatibility Toolkit that can be used to overcome these issues. You can download the Toolkit at http://msdn.microsoft.com/compatibility.

Background

Windows 2000/XP include changes that move the platform forward towards the goal of making it a more useful and reliable platform. These changes affect the way in which some applications run, and should be considered when designing new applications for use on Windows 2000/XP. The Demonstration Application contains several examples of these changes.

Examples of Common Issues

Some of the most common compatibility issues are listed below. Each one of these is demonstrated in the sample application.

 Disk Space Issues

 Erroneous Debug Messages

 File Path Issues

 Printing Issues

 Reboot Issues

 Registry Issues

 Version Checking


Version Checking

The number one application compatibility issue on Windows 2000 is problematic versioning code.  Many of the applications we have tested call GetVersionEx and only install and run if it returns a specific version. Windows 2000 returns a new Major Version number (5) that is not handled by such programs. The Windows 2000 API includes the function VerifyVersionInfo. This function compares a set of operating system version requirements to the corresponding values for the currently running version of the system.  When a new version of the operating system is released, your application will still install and run on it. There are many options and ways to use VerifyVersionInfo. Examples include checking for a certain "flavor" of the operating system such as Professional, Server, Advanced Server, or Datacenter Server. In addition, you could check for the presence of Terminal Services or a particular service pack. Because this function is only available on Windows 2000, applications should fallback to the GetVersion or GetVersionEx APIs if necessary. Please consult the Platform SDK at http://msdn.microsoft.com/library/default.asp for information on these APIs.


Erroneous Debug Messages

While this problem is not so common, erroneous debug messages have been witnessed in several applications not specifically designed or Windows 2000. In most cases, the application performs a version check to determine the platform on which it is running. During installation or normal use of the program, it may encounter some type of error that does not cause the program to end, but causes the application to display a "debug" message only on the Windows NT/2000 platform, not on the Windows 9x/ME platform. Examples may be differences in registry structures, file or directory layouts, or several other things. These can usually be safely ignored.


Printing Issues

Applications that call the EnumPrinters API or any other print API that allowed the PRINTER_ENUM_LOCAL flag to be passed may experience problems on Windows 2000. On Windows 95, this flag would also enumerate network printers. This was a design feature for Windows 9x/ME, not Windows 2000. This behavior causes network printers not to be available when applications attempt the enumeration.


Registry Issues

First introduced in Windows NT 3.51, the REG_EXPAND_SZ registry value type is an expandable data string that contains a variable to be replaced when an application retrieves the value. In the example below, the string "%SystemRoot%" will replaced by the actual location of the directory containing the Windows NT system files:

File: REG_EXPAND_SZ: %SystemRoot%\explorer.exe

In many cases, older applications don't handle this registry value type properly.  When an application reads this value type, it must call ExpandEnvironmentStrings before using the value.

In addition to the new data type, other issues exist with registry access on Windows 2000. Examples of these include applications that leave a trailing slash on most registry API calls. In addition, applications that attempt to save data to HKEY_LOCAL_MACHINE under the normal user context will most likely fail. This is because there are restrictions on the Windows NT/2000 registry, unlike the Windows 9x/ME, which is wide-open. Finally, a small difference exists with the RegDeleteKey API. On Windows 9x/ME, the API would work successfully if the specified key had subkeys, as these would be deleted by the operating system. On Windows NT/2000, this is not the case as the application is required to delete subkeys prior to making the call.


Reboot Issues

Windows 2000 does not require rebooting as often as other versions of the platform when installing software. Applications should handle each platform separately and only reboot when it is really required.

If a reboot is absolutely necessary under Windows 2000, you must acquire the appropriate security privileges before calling ExitWindowsEx or InitiateSystemShutdown (which is only available on NT/2000). This is demonstrated in the sample application and requires a call to the AdjustTokenPrivileges API.


Disk Space Issues

Hard drive size has increased dramatically over the years to the point that applications may not handle large amounts of free space correctly. For example, calling GetDiskFreeSpace, which returns 32 bit values, gives incorrect results when there is more that 2GB of free space.

New applications should use the GetDiskFreeSpaceEx API, which uses a ULARGE_INTEGER instead of an INT, to return available free space. Note that this API is available on Windows 95 OSR2 or later and Windows NT 4.0 or later.


File Path Issues

The location of many folders and directories changes with each release of Windows.  These location changes are the cause of a number of application incompatibilities on Windows 2000.

The Windows functions SHGetFolderPath, GetWindowsDirectory, GetSystemDirectory and GetTempPath should be used to find directories used by Windows.  Applications that use hard-coded paths to specific locations may not work on other versions of Windows.

For example, the My Documents folder was simply a folder off the root on Windows 9x, somewhere on C drive, or on D drive.

Windows NT 4.0 created personal folders on a per-user basis, and put each user’s folder deep in the Windows system directory:

%windir%\profiles\user\personal

Windows 2000 has moved it again. Instead of the system directory, or even at the root, a default installation of Windows 2000 Professional puts the folder on the system drive at:

\Documents and Settings\user\My Documents

In many enterprise situations, the user’s My Documents folder may even be moved off the local machine to a network share. That makes it available to the user from anywhere in the enterprise using roaming profiles. However, an application that searches for the folder on the local system, instead of hard-coding the path, will not be able to find the relocated My Documents unless it uses the Windows API functions.

SHGetFolderPath

To find shell folders such as My Documents, use SHGetFolderPath to get the path. You can use it on Windows 95, Windows 98, or any Windows platform, and it will find the correct location for the specified folder. For complete information on the use of SHGetFolderPath, please consult the Platform SDK at http://msdn.microsoft.com/library/default.asp.