Graphics Device Interface
From Wikipedia, the free encyclopedia
The Graphics Device Interface (GDI) is a Microsoft Windows application programming interface and core operating system component that is responsible for representing graphical objects and transmitting them to output devices such as monitors and printers.
GDI is responsible for tasks such as drawing lines and curves, rendering fonts and handling palettes. It is not directly responsible for drawing windows, menus, etc.; that task is reserved for the user subsystem, which resides in user32.dll and is built atop GDI. GDI is similar to Macintosh's classic QuickDraw.
Perhaps the most significant capability of GDI over more direct methods of accessing the hardware is its scaling capabilities, and abstraction of target devices. Using GDI, it is very easy to draw on multiple devices, such as a screen and a printer, and expect proper reproduction in each case. This capability is at the centre of all What You See Is What You Get applications for Microsoft Windows.
Simple games which do not require fast graphics rendering use GDI. However, GDI cannot animate properly (no notion of synchronizing with the framebuffer) and lacks rasterization for 3D. Modern games tend to use DirectX or OpenGL, which give programmers the capabilities to use features of modern hardware.
[edit] Technical details
A Device Context (DC) is used to define the attributes of text and images that are output to the screen or printer. The actual context is maintained by GDI. An HDC, which is a handle to the structure, is obtained before output is written and released after the elements have been written.
A DC, like most GDI objects, is opaque - its data cannot be accessed directly, but its handle can be passed to various GDI functions that will operate on it, either to draw an object, to retrieve information about it, or to change the object in some way.
[edit] GDI+
With the introduction of Windows XP, GDI was deprecated in favor of its successor, the C++ based GDI+ subsystem. Unlike its predecessor GDI which did not access the graphics hardware directly, GDI+ provided hardware acceleration by interacting directly with the graphics device on behalf of the application.[1] GDI+ adds anti-aliased 2D graphics, floating point coordinates, gradient shading, more complex path management, intrinsic support for modern graphics-file formats like JPEG and PNG, and support for composition of affine transformations in the 2D view pipeline. GDI+ uses ARGB values to represent color. Use of these features is apparent in Windows XP's user interface and several of its applications such as Microsoft Paint, Windows Picture and Fax Viewer, Photo Printing Wizard, My Pictures Slideshow screensaver, and their presence in the basic graphics layer greatly simplifies implementations of vector-graphics systems such as Flash or SVG. The GDI+ dynamic library can be shipped with an application and used under older versions of Windows.
Because of the additional text processing and resolution independence capabilities in GDI+, text rendering is nearly an order of magnitude slower than in GDI.[2] Chris Jackson, an application compatibility expert working for Microsoft published some tests indicating that a piece of text rendering code he had written could render 99,000 glyphs per second in GDI, but the same code using GDI+ rendered 16,600 glyphs per second.
The Microsoft .NET class library provides a managed interface for GDI+ via the System.Drawing
namespace.
GDI+ is similar (in purpose and structure) to Apple's Quartz 2D subsystem, and the open-source libart and Cairo libraries.
[edit] GDI and GDI+ applications in Windows Vista
Starting with Windows Vista, all Windows applications including GDI and GDI+ applications run in the new compositing engine, Desktop Window Manager which is built atop the Windows Display Driver Model. The GDI render path is redirected through DWM and GDI is no longer hardware-accelerated by video card driver. [3][4] However, due to the nature of desktop composition (internal management of moving bitmaps and transparency and anti-aliasing of GDI+ being handled at the DWM core), operations like window moves can be faster or more responsive because underlying content does not need to be re-rendered by the application.[3]
[edit] Relation between GDI and GDI printers
[edit] GDI printers
A GDI printer or a Winprinter (similar to a Winmodem) is a print processor that uses software to do all the print processing instead of requiring the printer hardware to do it. It works by rendering an image to a bitmap on the host computer and then sending the bitmap to the printer.
This allows low-cost printers to be built by printer manufacturers, because all the page composition is done in software. Usually, such printers do not natively support a page description language such as PostScript or XPS. A Winprinter uses GDI to prepare the output, which is then passed to the printer driver (usually supplied by the manufacturer) for further processing and only afterwards to the printer itself.[5]
In general, usually, the lowest-cost printers are GDI devices. Most manufacturers also produce more flexible models that add PCL compatibility, or PostScript, or both. In most cases it is only the very lowest-cost models in any given manufacturer's range that are GDI-only.
[edit] Limitations
Each time a window is opened, it consumes GDI objects. As the complexity of the window increases, with additional features such as buttons and images, its GDI object usage also increases. When too many objects are in use, Windows is unable to draw any more GDI objects, leading to misbehaving software and frozen and unresponsive program operation. [6][7] The total available GDI varies from one version of Windows to the next. Windows 95, 98 and Millenium had a limit of 1,200 total handles, while Windows XP and Vista have a limit of 10,000 objects, and Windows 2000 has a limit of 16,384 objects. [8][9]
Earlier versions of Windows such as Windows 3.1 and Windows 98 included a Resource Meter program to allow the user to monitor how much of the total system GDI resources were in use. Later versions such as Windows 2000 and Windows XP can report GDI object usage for each program in the Task Manager, but they cannot tell the user the total GDI capacity available.
Overflowing GDI capacity can affect Windows itself, preventing new windows from opening, menus from displaying, and alert boxes from appearing. The situation can be difficult to clear and can potentially require a forced hard-reset of the system, since it prevents core system programs from functioning.
For example, forcing a frozen process to end using the Task Manager normally makes an "Are you sure" alert window appear. With no free GDI, Windows just beeps an error and the alert choice does not appear, so the GDI-overflowing processes cannot be terminated.
Sometimes a single application can consume the entire free desktop heap memory. There is a tool from Microsoft called Desktop Heap Monitor which can show which application consumes what percent of the desktop heap [10]
[edit] Vulnerabilities
Microsoft GDI and GDI+ have been a rich and ongoing source of vulnerabilities. The list below is not exhaustive:
[edit] MS04-028 Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution (833987)
On September 14, 2004, a vulnerability in GDI+ and other graphics APIs was discovered related to a defect in the standard JPEG library. It allowed arbitrary code execution on any system that displayed a malicious JPEG file using a tool that used the decoder in GDI+.[11][12] A patch was released to fix the issue on October 12, 2004.
[edit] MS07-017 Vulnerabilities in GDI Could Allow Remote Code Execution (925902)
3 April 2007. Local elevation of privilege. An attacker who successfully exploited the most severe of these vulnerabilities could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.[13].
[edit] MS07-046 - Critical - Vulnerability in GDI Could Allow Remote Code Execution (938829)
14 August 2007. A remote code execution vulnerability exists in the Graphics Rendering Engine in the way that it handles specially crafted images. An attacker could exploit the vulnerability by constructing a specially crafted image that could potentially allow remote code execution if a user opened a specially crafted attachment in e-mail. An attacker who successfully exploited this vulnerability could take complete control of an affected system. [14]
[edit] MS08-021 – Critical - Vulnerabilities in GDI Could Allow Remote Code Execution (948590)
8 April 2008. Two vulnerabilities, either of which could allow remote code execution if a user opens a specially crafted EMF or WMF image file. An attacker who successfully exploited these vulnerabilities could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. [15]
[edit] MS08-071 – Critical - Vulnerabilities in GDI Could Allow Remote Code Execution (956802)
9 December 2008. Two vulnerabilities, either of which could allow remote code execution if a user opens a specially crafted WMF image file. An attacker who successfully exploited these vulnerabilities could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights. [16]
[edit] See also
[edit] Notes and references
- ^ MSDN: GDI+ under title Purpose: "Applications based on the Microsoft Win32 API do not access graphics hardware directly. Instead, GDI+ interacts with device drivers on behalf of applications."
- ^ Jackson, Chris. "GDI vs. GDI+ Text Rendering Performance". Chris Jackson's Semantic Consonance. Microsoft. http://blogs.msdn.com/cjacks/archive/2006/05/19/gdi-vs-gdi-text-rendering-performance.aspx.
- ^ a b GDI is not hardware accelerated in Windows Vista
- ^ Layered windows...SW is sometimes faster than HW. Avalite on MSDN Blogs.
- ^ "linuxprinting.org about GDI printer". The Linux Foundation. http://www.linuxprinting.org/show_printer.cgi?recnum=Generic-GDI_Printer. Retrieved on 2007-09-22.
- ^ Microsoft Knowledgebase article 838283 - Desktop application menus are improperly displayed if a process exceeds its GDI object quota in Windows XP or in Windows 2000 http://support.microsoft.com/kb/838283
- ^ Microsoft Developer Network Blog - GDI leak in Outlook 2007 causes problems when GDI usage reaches 10,000 objects http://blogs.msdn.com/rgregg/archive/2007/09/03/outlook-2007-gdi-leak-hotfix.aspx
- ^ Microsoft Developer Network - GDI Object limits http://msdn.microsoft.com/en-us/library/ms724291(VS.85).aspx
- ^ Microsoft Knowledge base Article 894500 - .NET programs designed on newer NT operating systems may malfunction on older Win 95 / Win 98 / Win ME due to lower GDI usage limits http://support.microsoft.com/kb/894500
- ^ http://www.microsoft.com/DownLoads/details.aspx?familyid=5CFC9B74-97AA-4510-B4B9-B2DC98C8ED8B&displaylang=en
- ^ Microsoft Security Bulletin MS04-028 Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution (833987). Microsoft TechNet.
- ^ Critical vulnerability in MS Windows may escalate the virus threat. F-Secure.
- ^ MS07-017 Vulnerabilities in GDI Could Allow Remote Code Execution (925902)
- ^ MS07-046 - Critical - Vulnerability in GDI Could Allow Remote Code Execution (938829)
- ^ MS08-021 – Critical - Vulnerabilities in GDI Could Allow Remote Code Execution (948590)
- ^ MS08-071 – Critical - Vulnerabilities in GDI Could Allow Remote Code Execution (956802)
[edit] External links
- Microsoft's GDI+ page
- Bob Powell's GDI+ FAQ list
- MSDN article on GDI overview
- Microsoft Security Bulletin MS04-028
- F-Secure: Critical vulnerability in MS Windows may escalate the virus threat
|