A typical personal computer system includes (FIG. 1) a computer monitor 6 having a computer screen 8 displaying information to an end-user of the system. Often, the information is displayed using a presentation "shell" program 10 having a graphical user interface ("GUI"). The shell program is provided by operating system software (e.g., Microsoft.RTM. Windows.RTM.95) running on the system. On the monitor's screen, the GUI provides one or more display windows, each defining a specific sub-area within the screen's entire display area, or encompassing the entire display area. The GUI allows the end-user or an application program 12 (e.g., a word-processing program) to create one or more display windows corresponding to one or more tasks. Once created, the display windows can be positioned at different parts of the computer screen by the application program or by the end-user manipulating an input device such as a computer mouse or a keyboard.
To display information in one or more of the display windows, an application program running on the system uses a graphical device interface subsystem 14 ("GDI") provided by the operating system. GDI serves as a link between the application program and a graphics device, such as a video display adapter 15 (e.g., a plug-in card) included with the computer to provide graphics output signals to the computer monitor. More particularly, GDI lies logically between the application program and a graphics device driver 16, which is a computer program designed to control a particular graphics hardware device such as the video display adapter. The device driver is not technically part of the operating system. Rather, the device driver is a software module (often provided by the vendor of the video display adapter) supplementing the operating system for updating the status of the video display adapter and the monitor in response to calls made to functions of the operating system in general and to functions of GDI in particular.
Communication between GDI and the device driver is facilitated by a device driver interface 18 ("DDI"). DDI is a set of functions provided by the device driver for access by GDI. Information is passed between GDI and the device driver through input and output parameters of these functions. Some of the functions are necessary for communication between GDI and DDI, while others are optional. GDI calls to an "Enable" function initialize the device driver and cause GDI to receive information about device-driver-supported DDI functions. GDI itself handles any operations not supported by the device driver. Most of the functions are exposed to GDI through an array of pointers residing in a pointer table.
GDI maintains important internal data structures and provides the device driver with access to public fields (i.e., externally-relevant fields) of these structures by passing the public fields as GDI/DDI software objects to the device driver. Thus, GDI/DDI software objects are intermediate data structures providing an interface between GDI data structures and a device driver needing access to information within the GDI data structures. A typical GDI/DDI software object provides information such as colors of a palette associated with the screen or definitions of brush objects for graphic functions that output lines, text, or fills. The device driver can pass a pointer to a GDI/DDI software object back to GDI to query for information or to request execution of various operations.
In response to application program originated function calls routed through GDI, the device driver ensures that the video display adapter produces the required output. I.e., in response to a request from an application, if GDI determines that a function relating to the request is supported by the device driver, GDI calls the function. It is the responsibility of the device driver to execute the function properly and return control to GDI upon completion of processing instructions associated with the function.
Typically, in response to calls to its DDI, the device driver updates the status of the video display adapter by changing the contents of memory and registers used by the adapter. The memory used by the adapter is referred to as "screen memory" or "frame buffer". What appears on the monitor's screen is controlled directly by the adapter and corresponds to the contents of the screen memory and the registers. The device driver also typically performs additional functions such as monochrome-to-color conversion of bitmaps, drawing of repetitive patterns in screen memory, and moving of an image from one portion of screen memory to another (referred to as a "bit block transfer" or "BitBlt"). Often, the operating system cannot perform these additional functions as quickly because, unlike the device driver, the operating system is not configured to take advantage of the video display adapter's particular characteristics and capabilities.
When an application or an operating system function needs to use a graphics hardware device such as the video display adapter, the application or function calls GDI's "CreateDC()" function, via GDI's application programming interface ("API"), with a data string specifying the name of the device (e.g., "Display"). In response, a data structure known as a "device context" is created for the device. The device context reflects the current state of many attributes determining how GDI functions work on the device. Among the attributes specified in the device context are a text font (i.e., typeface), a text color, a background color behind text, and intercharacter spacing.
When CreateDC is called, GDI returns a handle ("hDC"), which is a pointer to the device context and which is used later by the application to interact with the device context by passing the handle to other GDI APIs. GDI also identifies a graphics device driver for the device specified by the data string (e.g., "Display") noted above. GDI then calls operating system functions to load the specified device driver. Once the device driver is loaded, GDI is able to communicate with the device through DDI functions. Via the device driver, GDI is able to perform actions such as initializing the device and drawing graphics on the screen of the monitor driven by the device. Multiple hDC's may exist for a single device, so that multiple application programs can cause graphics to be drawn on a single device. GDI handles the synchronization between the hDC's.
GDI has several hundred functions making up several broad groups. One group includes CreateDC() and other functions providing the operating system and application programs with the ability to control the existence of device contexts. Another group includes functions providing device context information such as the dimensions of a currently-selected font. Functions relating to displaying text or drawing graphics such as lines, filled areas, and bit-mapped images are included in another group. Still another group provides functions for setting and determining the status of device context attributes relating to details such as the color and justification of text. Functions of yet another group provide access to GDI objects, which are constructs such as logical pens and brushes, and which allow the setting of widths and styles of lines and other graphics drawn in the display windows on the screen.
The display windows appearing on the screen occupy a logical space known as the GUI "desktop." The desktop is an essentially two-dimensional working template area supporting various graphical objects, including the display windows. The screen of the monitor corresponds to at least a subset of the desktop. The operating system allows applications running on the computer to specify desktop object characteristics such as colors, font sizes, and output resolutions and the like without regard for the specific limitations of a particular video display adapter or monitor. GDI converts the application's specified characteristics to conform to the adapter's and monitor's limitations. For example, the application may specify a yellow color, but the adapter and monitor combination may be capable of displaying gray scales only. If so, GDI converts the yellow color to a gray scale.
When the operating system is started, the device context of the video display adapter is initialized by another operating system subsystem "USER". USER provides functions relating to the GUI, including functions to create, move, size, and remove screen objects such as display windows, selection menus appearing in the display windows, graphical icons, and the like. For example, an application program can call a USER function to remove a display window associated with the application program. USER also controls other resources such as a sound driver, a timer, and communications ports. In addition, end-user input from a mouse, a keyboard, or other input device is directed by USER to an application program.
Like GDI, USER is able to interact directly with the adapter's device driver. For example, in Windows.RTM.97, USER requires the device driver to provide cursor support directly, i.e., requires the device driver to make directly available some functions relating to displaying a mouse pointer (cursor). These functions include "CheckCursor" for drawing the cursor if drawing is not disabled, "InquireCursor" for retrieving information about the cursor, "MoveCursor" for moving the cursor to a specified position on the screen, and "SetCursor" for setting the cursor's shape. When the operating system first starts, USER calls the InquireCursor function to retrieve information about the cursor. USER then sets a system timer to call the CheckCursor function on each timer interrupt (i.e., at predetermined intervals) and starts a mouse-related device driver. As a result, whenever moved by the end-user, the mouse generates a hardware-based asynchronous interrupt causing the operating system to call MoveCursor. USER and application programs subsequently set the shape of the cursor using SetCursor. In this example, because USER calls MoveCursor at each mouse interrupt occurrence, MoveCursor sets a flag with a non-interruptable instruction (e.g., "bts") to prevent the MoveCursor function from being called again before completing processing of a current call. Once the flag is set, MoveCursor determines a new position (i.e., the x and y coordinates) and draws the cursor in the new position. When finished, MoveCursor clears the flag with another non-interruptable instruction. Meanwhile, the CheckCursor function is called at each timer interrupt to determine whether the cursor should be redrawn and whether drawing is enabled. If so, the function redraws the cursor.
After the device context is initialized, USER queries the device for several of its characteristics and capabilities so as to properly maintain the desktop. Initializing the device context provides USER with information about icons, key and mouse cursors, and bitmap resources for defining the appearance of other screen objects such as graphical buttons controlling the presence of a display window. Once initialized by USER, the device context typically remains fairly stable for the duration of the Windows.RTM. session, i.e., until the operating system is restarted for some reason.
In Windows.RTM.97, USER also supports reconfiguring the logical width and height of the screen during the Windows.RTM. session. The logical width and height are measured in pixels organized in a raster grid. A pixel refers to the smallest unit of the screen addressable via the screen memory and is usually represented in the screen memory by multiple bits representing the state of one or more characteristics (e.g., color) of the pixel. For example, the color of the pixel may be represented by 24 bits, i.e., a pixel's color may have a "bit-depth" of 24. In the case of a computer monitor employing cathode-ray tube ("CRT") technology, a pixel corresponds to a phosphor dot or a set of phosphor dots configured to illuminate when struck by one or more beams emanating from an electron gun.
Changing the logical height and width of the screen during a Windows.RTM. session is accomplished by instructing the device driver to direct the video display adapter to re-initialize itself with the new height and width. Assuming the adapter is capable of such a re-initialization, USER subsequently queries the adapter for its capabilities to update the adapter's device context. In Windows.RTM.97, USER also updates the positions on the screen of any of the desktop's display windows that are affected by the change. Typically, like the size of the screen, the size of a display window is measured in pixels. Thus, for example, if a screen originally having a size (i.e., resolution) of 1024 (width) by 768 (height) pixels is then changed to having a resolution of 640 by 480 pixels, one or more display windows that were originally completely visible may lie partially or completely offscreen after the change. Also, as a result of the change in resolution, a window originally sized to cover a considerable portion of the desktop may no longer fit on the screen. USER repositions any such windows, first by attempting to move those windows horizontally or vertically or both, and then, if unsuccessful, by resizing the windows to fit within the available desktop space.
GDI allows specially-designed application programs to make use of multiple screens corresponding to multiple monitors. As mentioned above, when an application program or an operating system subsystem is directed to change the appearance of graphics on the screen (i.e., to draw on the screen), the application or operating system obtains an hDC from GDI (unless the application has done so already) and issues drawing commands to that hDC. GDI then translates the drawing commands into a form understandable by a device driver associated with that particular hDC. Accordingly, GDI is able to handle multiple screens by providing different hDC's for each screen. More particularly, an application is thus able to draw on two screens by referring to two different hDC's. For example, a portable computer may be equipped with two video display adapters (i.e., the equivalent of two plug-in video cards), with one adapter driving a built-in liquid crystal display ("LCD") screen and the other adapter driving a CRT screen connected to the computer by a cable. So equipped, the portable computer can run a specially-designed application such as Microsoft.RTM. PowerPoint.RTM. for displaying on the CRT screen a presentation controlled according to configurable settings appearing in a display window on the LCD screen. Because in this case the CRT screen does not represent part of the desktop, an enduser can position neither a display window nor the operating system's mouse pointer on the CRT screen.
USPTO Backgrounds
USPTO Backgrounds