Vista Program Compatibility Tips
How-To Guide for Win32 Programmers to Ensure Vista Compatibility
Jun 3, 2008
Programming for a new operating system release is always a little daunting; especially when the result is something as vitally different as Vista is proving to be for professional and casual developers alike. Microsoft sums up the changes in a list of five Vista Program Compatibility Tips (presented as a PowerPoint presentation). Paraphrasing from the original, there are a few things that a well developed program can do that will make sure that it is compatible with Vista, even if it has not been specifically developed for Vista.
These are as follows:
- GUI API Calls such as FindWindow and SendMessage do not work across sessions;
- 16 bit components do not work under Vista;
- "Document and Settings" has been renamed, and programs do not have access to their Program Files sub-folder;
- Only use documented Registry entries;
- Make allowances for Vista.
The last point is where this article will concentrate most of the information : being able to detect Vista, and take appropriate steps to make sure that any non-Vista portable code is not executed. This represents a minimum responsibility of the programmer; they can not assume that because the Win32 program will work 'most of the time', it is sufficiently robust to be deployed.
If this approach is taken, then:
- The User will become dissatisfied with the application;
- Time will be wasted trying to solve 'ghost' bugs.
So, the correct approach is to identify Vista-incompatible features and rewrite them to be portable. This might mean creating a new solution that works for both Win32 XP/2000 as well as for Vista, or adapting the application to include Vista-specific code. This last solution offers the advantage of not having to change working code. The first step, of course, is to identify the operating system using a portable API call.
Using OSVERSIONINFO and GetVersionEx
The portable way to identify the operating system version is to use the GetVersionEx API function. It is important to choose a method that works for both Win32 and Vista, otherwise functionality will be affected on one or the other platforms. The following is adapted from the aforementioned Microsoft presentation:
OSVERSIONINFO osVersion;
osVersion.dwOSVersionInfoSize = sizeof(osVersion);
if (GetVersionEx((LPOSVERSIONINFO)&osVersion)) {
if (osVersion.dwMajorVersion == VISTA_VERSION) {
// Perform Vista Specific Processing
} else {
// Do XP/2000 Processing
}
}
Of course, the above can also be bundled into a function BOOL CheckForVista() that should return TRUE if the operating system is Vista or higher. One example of using the above could be to avoid writing in the application folder (C:\Program Files\>app_name< or SHGetFolderPath location) by prompting the user for a folder, or storing application data in the Registry, or in the CSIDL_APPDATA folder.
If this last option is chosen then the application data will usually be stored under the 'Documents and Settings' folder specific to the user and application. This location has been renamed to 'Users', but can still be reached through the CSIDL_APPDATA location:
SHGetFolderPath ( NULL, CSIDL_APPDATA, NULL, 0, (LPSTR) szPath );
Of course, those developing for Vista only will use the FOLDERID_RoamingAppData location, rather than CSIDL_APPDATA.
