Application Compatibility
Getting Apps to work...
Monday 5 October 2009, 10:34 AM
API Calls that break under Windows 7
As mentioned in the Microsoft Compatibility tool-kit, the Developer cookbook and Microsoft Developer Network (MSDN - see references below) there is a section called "Safe Exception handling" under Windows 7 that refers to the deprecation (end of support and removal from the operating system) for two Application Programming Interfaces (API's) under Windows 7 and Windows Server2008.
These two API calls (IsBadReadPtr and IsBadWritePtr) relate to the handling of pointer to the global memory stack used by Windows. These API calls are used ensure that a particular pointer (or memory handle) is properly committed to the Windows Heap stack. Meaning that the code in question has not cased a corruption in the Windows swap file or memory stack. These calls were intended for debugging purposes and known affectionately as "CrashMyApplication" and "CrashMyApplicationAndMyMemory" respectively as they had a very common habit of crashing an application under debug and trace conditions.
Microsoft has removed support for the two API's for security reasons and Windows 7 and Windows 2008 Server will no longer support these API's. It is possible to determine if these calls are included in shipped software but unless the application is tested thoroughly and all functionality is tested, it is impossible to determine if these calls are actually employed and potentially could cause a compatibility issue. However, there is a rough an ready way to determine if these calls are actively employed in an application. If the application works under the following operating systems, then these calls are not being used;
· Windows 2K (all service packs)
· Windows XP SP1 and SP2
· Windows 2000 Advanced Server
· Windows 2003 Server
The IsBadReadPtr and isBadWritePtr API calls really translate to very old applications that related to Windows 9x and NT4 systems. If your applications are currently running normally (i.e. without frequent and continuous crashes) then your application is very unlikely to actively employ these (now deprecated) API calls.
Simply scanning an application for references to these API's would produce serious over-reporting without actually demonstrating that these calls are likely to be used in a production environment (i.e. not a developer testing or debugging mode). To generate an accurate assessment of these API related issues, you will need to ensure that you are scanning the IAT table for files (EXE's and DLL's) that are actually going to be installed on the target platform.
Once done, you should see relatively few instances of this particular application compatibility issue across your application portfolio.
For further reading, please have a loo at the following links;
IsBadReadPtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366713.aspx
IsBadWritePtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366716.aspx
These two API calls (IsBadReadPtr and IsBadWritePtr) relate to the handling of pointer to the global memory stack used by Windows. These API calls are used ensure that a particular pointer (or memory handle) is properly committed to the Windows Heap stack. Meaning that the code in question has not cased a corruption in the Windows swap file or memory stack. These calls were intended for debugging purposes and known affectionately as "CrashMyApplication" and "CrashMyApplicationAndMyMemory" respectively as they had a very common habit of crashing an application under debug and trace conditions.
Microsoft has removed support for the two API's for security reasons and Windows 7 and Windows 2008 Server will no longer support these API's. It is possible to determine if these calls are included in shipped software but unless the application is tested thoroughly and all functionality is tested, it is impossible to determine if these calls are actually employed and potentially could cause a compatibility issue. However, there is a rough an ready way to determine if these calls are actively employed in an application. If the application works under the following operating systems, then these calls are not being used;
· Windows 2K (all service packs)
· Windows XP SP1 and SP2
· Windows 2000 Advanced Server
· Windows 2003 Server
The IsBadReadPtr and isBadWritePtr API calls really translate to very old applications that related to Windows 9x and NT4 systems. If your applications are currently running normally (i.e. without frequent and continuous crashes) then your application is very unlikely to actively employ these (now deprecated) API calls.
Simply scanning an application for references to these API's would produce serious over-reporting without actually demonstrating that these calls are likely to be used in a production environment (i.e. not a developer testing or debugging mode). To generate an accurate assessment of these API related issues, you will need to ensure that you are scanning the IAT table for files (EXE's and DLL's) that are actually going to be installed on the target platform.
Once done, you should see relatively few instances of this particular application compatibility issue across your application portfolio.
For further reading, please have a loo at the following links;
IsBadReadPtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366713.aspx
IsBadWritePtr references can be found at;
http://msdn2.microsoft.com/En-US/library/aa366716.aspx
PreviousComments on this post
Good stuff.
You've demonstrated another reason to trash old software. API compatibility is likely to get even worse if Microsoft actually manages to pull off the new OS project I've seen small mentions about. Win32 API calls will disappear and probably have to be emulated in some fashion.
To add a comment, fill out the form below
