Application Compatibility: Graphical Device Interface (GDI)
Graphical Device Interface (GDI)
Painting (WM_PAINT) Behavior Differences
Feature Impact
Low
Brief Description
As part of the Desktop Window Manager work, Microsoft has made subtle but important changes to the way applications paint to the screen. Prior to Windows Vista® and Windows Server® 2008, a window handle (HWND) was painted directly to the screen, which had certain benefits, but limited how Windows could display and manage top-level windows. In Windows Vista and Windows Server 2008, all top-level windows are rendered to an off-screen bitmap (similar to WS_EX_LAYERED), and the Desktop Window Manager combines the images together to draw the desktop.
Manifestation
Black areas around tool tips, pop-up menus, balloons, splash screens, and so on
This issue can happen when the application has not painted the entire HWND, usually because that application assumed that the pixels in the background windows are good enough.
Flashes of black
A related issue can occur where the background contains uninitialized pixels that appear to the user as flashes of black on the screen. This issue occurs when applications do painting that is not part of a WM_PAINT message. The system detects that the application is drawing and redraws the desktop, but the application might not have finished drawing the HWND, which causes the flashes of black.
Glass disabled for application
This issue can happen when an application draws to the non-client area of the window (for example, the title bar).
Rubber bands, custom shadows, and other special effects
These effects are often done using GetDC(NULL); however, reading and writing to GetDC(NULL) tends to be problematic when applications are backed by a bitmap rather than drawing straight to the screen. Reading and writing to the screen is significantly slower than Windows XP. Also, not all GDI raster operations (rasterops) are supported (but XOR is).
Improved non-Latin fonts
Windows Vista and Windows Server 2008 include numerous changes to the Chinese, Japanese and Korean fonts to make them more readable; one of the side effects is that text can layout slightly differently in these new fonts as characters may have different widths. Consider testing how your text lays out on the screen and on the printer. Also consider testing places where non-Latin characters can be mixed with Latin character sets (for example, English).
Rendering Performance
Feature Impact
Low
Brief Description
Most applications will run as fast or faster on Windows Vista and Windows Server 2008 , but there are some changes that might require monitoring.
Manifestation
Overall GDI drawing performance is slower?
GDI primitives such as LineTo and Rectangle are now rendered in software rather than video hardware, which greatly simplify the display drivers.
Slower text rendering?
Calls such as DrawText better support international and East Asian languages.
Reduced application address space?
The bitmap for a top-level window is stored in the application's address space (see section on painting), potentially reducing available address space by a few megabytes.
Reading from and writing to GetDC(NULL)
This operation is slower than previous versions of Windows because applications now render to an off-screen bitmap rather than directly to the screen. Where possible, consider drawing to an HDC backed by your HWND, or creating overlay windows. GetDC(NULL) is still the preferred way to get a screen snapshot.
User Interface Privilege Isolation (GUI Portion of User Account Control)
Feature Impact
Low
Brief Description
As an added layer of defense against malicious software, Windows Vista and Windows Server 2008 allow different UI applications to run with three different levels of UI privilege. Applications can freely interact with other applications of the same and lower permission, but cannot modify or talk to applications of higher permission. Most applications will run with the middle permission, while applications that require administrator privileges run in a higher mode. Restricted processes such as low-rights Internet Explorer use the lowest-privilege mode.
More specifically, applications in lower-privilege modes cannot generally send messages to higher-privileged applications unless the higher-privileged application explicitly allows that message by calling ChangeWindowMessageFilter. Similarly, lower-privileged applications can read, but cannot modify an HWND owned by a higher-privileged application. For compatibility reasons, SendMessage and other APIs will return success even if the API was blocked because of privilege issues. Similarly, where compatibility impact is high and security risk is low, sometimes low-privileged applications are allowed to send unsolicited messages to high-privileged applications.
Manifestation
Applications that interact with other applications stop doing so.
These applications include utilities that reposition windows, type keystrokes for you, add extra buttons to windows, and so on.
Cut and paste between different applications fails.
Does it work at all, and does it support all the different clipboard formats you expect (rich text, HTML, and so on)?
Remedies
Journaling hooks
WH_JOURNALPLAYBACK and WH_JOURNALRECORD are inherently cross-process, so require the highest privilege level. The SendInput API, which does not require full UI privilege for many cases, can often be used instead of journaling hooks.
For programs where the source code is available, consider reviewing any code that uses the following APIs, as they often indicate cross-process communications and associated issues:
SendInput
Search for source files with findstr /s /g:temp.txt *.c *.cpp *.h *.hpp where temp.txt is the above list of APIs copied to a text file. While not an exhaustive search, it will help to identify issues versus minimizing false positives.
High DPI scaling
Feature Impact
Low
Brief Description
On systems using the high-DPI setting, applications that do not natively understand high DPI will be automatically scaled up.
Manifestation
Pixel sizes have been roughly constant for a long time, but LCD manufacturers are increasingly coming out with monitors with smaller and smaller pixels, also known as high dots per inch (DPI). If an application uses the same number of pixels on a high DPI screen as it does on a standard 96-DPI screen, the application will look very small. Windows Vista and Windows Server 2008 introduce the ability to scale applications that were written for 96-DPI screens, which they do by rendering the application's bitmap at a larger size. Like all bitmap scaling, this rendering can result in some blurriness, but otherwise gives a correctly sized and properly rendered image. Applications can also decide to support high DPI natively, which will give the crispest possible look. Currently an application can turn off scaling and declare itself DPI-aware by calling SetProcessDPIAware. A manifest-based way to make this declaration is under investigation. For more information about writing applications that natively support high DPI, see How to Write High-DPI Applications.
The rest of this section talks about potential problems with non-DPI aware applications. Applications ask Windows questions such as "how many pixels wide is a scrollbar", so when a 96-DPI application asks, Windows Vista and Windows Server 2008 give the application the 96 DPI answer. There are, however cases where Windows does not provide an answer based on the application, usually because Windows Vista and Windows Server 2008 do not yet have enough information (please give us this feedback), and sometimes because the "right" answer depends on what the application is trying to do with the answer. (Screen coordinates often raise this problem.)
Most compatibility problems come from these imperfect conditions. Things to look for when testing:
Text is clipped (partially hidden).
Text is too big.
Something is drawn at the wrong size or in the wrong place.
Remedies
For more information about writing applications that natively support high DPI, see How to Write High-DPI Applications.
PNG Icons
Feature Impact
Low
Brief Description
The icon file format (*.ico) now supports PNG images in addition to the older BMP-style icons; many Windows Vista and Windows Server 2008 icons use the PNG variant.
Manifestation
Applications that view or edit icon files might not understand the new format.
Links to Other Resources
USER & GDI Compatibility in Windows Vista