A sidebar to the article “Microsoft Windows,” published in Byte, issue 12/1983, pp. 49.

What makes it possible for Microsoft Windows to output graphics to different devices – printer/plotter devices as well as bit-mapped screens – without changing the graphics code?

Microsoft Windows works with a device-independent graphics system called Graphics Device Interface, or GDI. GDI consists of graphics routines that provide the interface between programs that want to draw images and different output devices. The graphics calls from these programs are not specific to any device. GDI mediates between the graphics calls and the actual devices. The calling program may be an operating-system extension like Microsoft Windows or an application program written in a high-level language.

The design of a device-independent graphics system like GDI begins with the definition of an abstract device. The abstract device is the collection of all the functions that ultimately will be performed by the actual graphics devices. (For example, “draw a circle” or “change hatch style” would be functions for devices to perform.)

When a function is called, GDI takes the function parameters, in abstract-device terms, and passes them to a logical-device driver. A logical-device driver is the software that translates abstract-device functions into a sequence of device-specific actions. These actions (communicated through a physical-device driver) result in the appearance of graphics on the device.

The GDI Abstract Device

The design of the abstract device ultimately determines the types of devices the system can talk to and to what degree the system will be device independent. To define the abstract device for GDI, Microsoft included graphics commands from the current ANSI-VDI (American National Standards Institute-Video Display Interface) standard for drawing on plotting devices. The raster frame-buffer class of device was included by adding the graphics functionality from IBM Personal Computer BASIC. A screen-dump facility and additional raster support provide hard copy and animation capability. GDI’s abstract device can support any of the usual graphics subroutine libraries (for example, SIGGRAPH/ACM CORE, ISO GKS, Plot-10) as applications.

The Graphics Primitives

The language of the abstract device is made up of “primitives.” The primitives are the calls to the graphics functions available at the lowest level of GDI – the level of the logical-device driver. They are described functionally as follows:

	Control Primitives. These primitives initialize, terminate, and clear the device.
	Output Primitives. These primitives result in the appearance of an actual image on a graphics device. Included are move, mark, polymark, line, polyline, polygon, rectangle, circle, arc, text, and put/get/move bit maps.
	Attribute Primitives. These primitives describe something about the appearance of the output primitives. Each output primitive has a set of appearance commands, including size, color, and style. The filled-output primitives (those defining closed areas, such as polygon and circle) take on additional attributes for the color and style of the interior. Attribute primitives are also provided for using color translation tables and doing high-quality text.
	Viewing Primitives. These primitives control clipping, relative or absolute coordinates, and absolute sizing of images (to inches or meters). They define the border to which output primitives will be clipped. The viewing primitives also map coordinates from the logical device driver to the physical device driver and from one coordinate space to another, and they set up the resolution of the logical coordinate space.
	Inquiry Primitives. These primitives return information to the application program about the current attributes, viewing pipeline, and control flags from the logical-device driver.

GDI provides a language that application programs can use to create images. An application program can create images without knowing about the characteristics of the output device.

by John Butler