ST Outlook
Philip I Nelson, Assistant Editor
Journey From The Center Of The ST: Part 2
Our tour of the ST's system software began last month with a look at the three elements of its operating system: BIOS (Basic Input/Output System), XBIOS (Extended BIOS), and GEMDOS (GEM Disk Operating System). This month we'll conclude by examining GEM, the user interface that lets you control the operating system.
Who Needs An Interface?
An operating system, as we noted earlier, gives the computer the basic equipment needed to perform useful work. But without a user interface of some kind, you still can't make the system do your bidding. In older systems such as CP/M or MS-DOS, the user interface is the notoriously unfriendly command line, which waits for you to type in some magic words and responds with an electronic raspberry if you use the wrong lingo or make a typing error. GEM replaces the command line interface with a graphics interface. As on the Macintosh or Amiga, the screen depicts a work surface populated with graphic objects whose form suggests their purpose: The trash can is where you discard unwanted material, for instance. And this interface is mouse-driven instead of keyboard-driven: Rather than type arcane commands on a keyboard, you use a mouse pointer to manipulate graphic shapes.
In terms of ultimate results, the GEM desktop doesn't differ notably from, say, the MS-DOS command line: Both interfaces allow you to run programs, shuffle files around, and find out what's on a disk, for example. But the way you do those jobs is very different. By substituting a set of related visual metaphors for a list of gobbledygook commands, GEM, the Graphics Environment Manager, creates a coherent little world in the computer which is certainly easier to learn, if not inherently more efficient, than the old command line environment.
GEM is composed of three major parts, known as VDI (Virtual Device Interface), GDOS (Graphics Device Operating System), and AES (Applications Environment Services).
VDI
VDI, which includes well over 100 functions, is concerned mainly with drawing and text operations. There are VDI routines to draw points, lines, and polygons, fill enclosed areas, display and manipulate text, control screen colors, and so forth. The name Virtual Device Interface underscores an important characteristic of GEM, which is that it's designed for device-independent graphics output. Unlike the Macintosh and Amiga graphic interfaces, GEM was not written with a specific host computer in mind. In theory, at least, it can work on a variety of machines, which may have different screen sizes, numbers of colors, and so on. Accordingly, VDI allows you to write programs that aren't tied to specific hardware. Thus, rather than program specifically for a particular device like the ST color monitor (although that's always an option), you can program for a virtual, or ideal, display device, unconcerned about such details as the number of dots or colors on the physical screen. In effect, a device-independent program says to the system, "I don't care how you get it done, just do it."
GDOS
It's the task of GDOS, the Graphics Device Operating System, to help translate ideal, device-independent graphics requests into output on an actual device. Just as a disk operating system mediates between a program and file-storage hardware, GDOS mediates between a program and graphics hardware. As anexample of what GDOS does, consider a desktop publishing program, which needs to support a variety of printing devices and a number of different text fonts. GDOS allows such a program to load fonts and device drivers as needed, and to access them once they're in memory.
AES
At the top of the GEM/TOS software hierarchy is AES, which stands for Applications Environment Services. This group of routines gives life to the surface characteristics of GEM: the mouse pointer, menus, windows, icons, and interactive dialogs.
A single AES routine can do a lot, and it may call on several other levels of system software. Consider, for instance, the familiar file-selector dialog used to choose a filename in GEM applications. To create this dialog, GEM must first save the contents of the screen underlying the dialog box and draw the box with all of its gadgets in place. Then it must respond to your manipulation of the box, displaying the contents of whatever disk and subdirectory you choose. When you choose OK, GEM remembers the DOS path and filename that you have chosen and erases the box, restoring the image that previously occupied that area. All this is done with just one call to the AES routine known as fsel__input. In addition to such large-scale routines, AES has routines to handle GEM's smaller details, like the shape of the mouse pointer.
We've covered a lot of ground. There still are a few minor items floating around at the operating system level (line A exceptions, for instance, or intelligent keyboard processing). But if you understand what makes up TOS and GEM, you know basically what's inside the ST.