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.

Conclusions

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

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

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.