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
|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
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.