Application Compatibility: Windows Driver Display Model
Windows Driver Display Model
Windows Vista® and Windows Server® 2008 Display Driver Model (VDDM) is a completely new display driver model that improves display driver stability in Windows. There are a number of key features in VDDM, including:
Efficient management of video memory for DirectX (DX) applications and the new Desktop Window Manager (DWM). Multiple 3-D applications will be using the graphics processor unit (GPU) in Windows Vista and Windows Server 2008.
Driver upgrades without reboot.
Dynamic detection of GPU hangs and recovery without reboot.
Hot Plug detection support of monitors.
Using the hardware features mandated by DX9L.
Glitch-free video playback.
An opportunity for a very secure design.
While most of the applications from earlier versions of Windows should not be impacted by VDDM, some risks include:
DX games compatibility, resulting in DX run-time, IHV driver, or core graphics stack issues.
Mobile functionality such as hotkey, cloneview, brightness, and zoom due to stricter ACPI requirements.
Accessibility, specifically that screen magnification applications designed by Windows XP will not work on Windows Vista or Windows Server 2008.
Safe Exception Handling
Under earlier Windows versions, the IsBadReadPtr and IsBadWritePtr functions were used to validate parameters. These functions are now banned on Windows Vista and Windows Server 2008. Also, applications that rely on Windows components using these functions to validate parameters will find that Windows no longer uses them. Applications should not rely on Windows to do any parameter validation (a check for null is done, and the application fails if it is a bad pointer).
Safe exception handling (SEH) also goes hand-in-hand with the no-execute flag. Exception handlers are checked that they are marked page_execute before the exception is dispatched, and also that the handler is valid code and that it is in the SEH table.
DllMain Operations
The load order of DLLs during process creation is not guaranteed and should never be depended upon to perform operations. Complex processing in the DllMain function may cause applications to hang or crash because of new OS component dependencies. For details, see the following pages:
"Calls to an OLE Object Should Not Be Done from DllMain" (Knowledge Base)
"PRB: Cannot Create an MFC Thread During DLL Startup" (Knowledge Base)
"COM Application Hangs When You Call CoCreateInstance from DllMain" (Knowledge Base)
Outlook Express Renamed
Outlook Express has been changed and moved and is now called Windows Mail. MAPI applications need to be aware of this change. Most applications that dynamically use the default program for MAPI should not see any compatibility problems.
Shell: Themes and My Documents
Windows Explorer Shell has introduced new visual themes for Windows Vista and Windows Server 2008. An application capable of handling themes in earlier versions of Windows should have no compatibility impact with the new themes.
Also, the My Documents location and structure has changed in Windows Vista and Windows Server 2008 to provide a better user experience. The user data is now stored in the \users\%username%\ folder structure. Pictures, Music, Documents, Desktop, and Favorites are all new folders directly under this structure. If an application uses the ShGetFolderPath function and uses the folder path dynamically, it will be redirected automatically to the new path and file locations. In general, applications will not see a compatibility impact due to these changes.
Fast User Switching (FUS)
Fast User Switching (FUS) is now available on Windows Vista and Windows Server 2008 for all versions, including domain-joined computers. Applications and installers need to be aware of FUS and be able to handle multiple logged in user sessions and terminal server scenarios. For more information, see Microsoft Windows XP Fast User Switching: Design Guide for Building Business Applications.
CriticalSection Code Changes
CriticalSection code was changed to increase security and robustness. Applications using critical section locks:
Should always initialize critical sections.
Should not read into undocumented objects. Applications that read into the undocumented structures to assess the status of a critical section will most likely break if they are looking for uninitialized and freed critical sections.
Should prevent starvation. Applications that call Sleep while holding the critical section lock now can cause starvation for other threads that need the lock. Sleep calls should be placed after the LeaveCriticalSection call.
For more information, see Critical Section Objects.