Location: GUIs >
Windows in 1983|
<< Previous Page
| 3 | Next Page >>
Photo 13 shows the graph displayed in accordance with the instructions
entered - with a 4 by 4 pixel-pen size and a gray shading. The graphics
capabilities of Microsoft Windows owe much to the device-independent graphics
system described by John Butler in the text box. "Device-Independent Graphics
Output for Microsoft Windows" on Page 49.
Microsoft Windows seems to offer remarkable openness, reconfigurability,
and transportability as well as modest requirements and pricing. As a result,
the desktop metaphor and mouse, intended to bring computing power to nontechincal
people, are finally going to reach the hands of many such people. Barring
a surprise product introduction from another company, Microsoft Windows
will be the first large-scale test of the desktop metaphor in the hands
of its intended users.
It is natural to wonder whether Microsoft Windows ability to run in
limited memory and off floppy disks will result in noticeable delays during
execution. Even Lisa with its megabyte of memory and 68000 microprocessor
frequently asks the user to wait. Is the ease of use worth the waiting?
Will Microsoft Windows somehow ingeniously avoid the problems of these
delays? The answers to these questions will shape the future of mass-market
The open approach and the presentation of Microsoft Windows as an extension
of MS-DOS 2.0 will help attract the horde of programmers necessary to assure
acceptable execution speeds on the IBM PC. Just as enough programmers working
long enough on different approaches have made the Apple II perform feats
that once seemed incredible, enough programmers working long enough on
enough different approaches will make applications run fast under Microsoft
Windows on ordinary hardware. Even if this judgment proves mistaken, Microsoft's
policy of openness and low pricing will have made possible a major experiment
in mass-market software. For many software authors as well as users, this
will be the first chance to test an approach to the user interface that
has hovered just beyond reach for several years.
|Device-Independent Graphics Output for Microsoft Windows
by John Butler
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 function 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 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:
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.
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
(these 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
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 on 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.
The Byte magazine also displayed throughout various images of IBM PC
compatible computers, including an Apple II with a PC emulator card, running
Microsoft Windows. Obviously this was meant to imply and demonstrate that
Windows, when released, would run on a variety of different hardware.
<< Previous Page
| 3 | Next Page >>