Classic Computer Magazine Archive CREATIVE COMPUTING VOL. 11, NO. 9 / SEPTEMBER 1985 / PAGE 112

The view from the top; IBM images. (evaluation) Will Fastie.

I have now had a chance to play with two new environments for the PC: IBM's own TopView and Digital Research's GEM. Let's get the cards on the table right away: I'm not crazy about either of them. In fact, I can't figure out why I would want either of them.

One step at a time. Let's first define the term "environment." Used in this context, the environment is the way in which the operating system presents itself and its functions to the user. Using DOS as an example, a user types the command COPY to make a duplicate of one file somewhere else. In the DOS environment, one generally types a command from the keyboard along with further information the system needs to perform the function. Sometimes the system will ask questions, which also must be answered by typing at the keyboard.

The environment also includes a programmer's interface, a method by which system functions can be invoked under program control. Because I try to write this column from the user's point of view, I will mention this only in passing.

TopView and GEM are programs (not operating systems) that run in the DOS environment and extend it so signficantly that the environment is radically different. (I thus refer to TopView and GEM as environments unto themselves.) Generally, commands are not typed. Instead, both environments require the user to point, and both manage the screen display in a manner that has come to be known as windowing. Beyond that, the two programs are dramatically different.


To begin with, GEM requires both a graphics display (the IBM Color/Graphics adapter or equivalent is okay, as are the Hercules card and the IBM Enhanced Graphics Adapter) and a mouse (the Microsoft interface is supported). When started, its screen display very much resembles a Macintosh and much of its method of operation is the same as Mac.

Once running, GEM displays its main screen, which initially includes only icons for the disk drives and some selections from the menu bar at the top. Menus are pulled down by clicking on the menu bar, and operations are selected from those menus. Just about everything can be done by pointing, clicking, and, in some cases, dragging. The first operation most users will probably select is OPENing one of the disk icons, which causes the contents of the disk to be displayed in a new window in icon form. The predefined GEM icons allow regular files and directories to be distinguished; executable programs can be distinguished only after the user has "taught" GEM what they are.

Many operations are simple in GEM. To run a program, one need only click on its icon and it will begin operation. Other operations are simple in concept but tedious in execution. For example, copying a file involves selecting the file to be copied by pointing at it and then dragging a copy of it to a disk or directory icon. That's simple to say, but it gets old after a while. One very nice feature of the GEM copy operation is that multiple files can be marked and then copied to the same place in a single drag. It is something I often wish I could do in DOS (the copy function in a package called Direc-Tree works this way).

COPY is a good example, because it is simple. It is equally simple in DOS, however, and that is where I have the biggest problem with GEM. If is not simpler than DOS, why on earth would I want to use it? Other GEM functions are harder and more tedious than COPY, so I found it quite annoying to work in the environment.

One reason we are all so interested in new environments is the expectation that concurrency, that is, the ability to run more than one program at a time, will be included. GEM does allow multiple windows to be open with programs operating, but only the program in the currently active window actually runs. Whenever you open a new window, the program in the previous window is suspended. So GEM is not concurrent.

I do not want to talk about other programs included with GEM, such as the calculator, because it is more important to consider first how the environment will support the programs you already have rather than how neat the environment's own programs are. I did not have any problems running any programs under GEM, except for GEM Draw, and this leads me to a severe criticism of the product. The documentation is atrocious.

Here's the rub. GEM Draw is a separate program, individually packaged and documented. Nowhere in that document is described the process by which the program is installed in the GEM environment. And yes, installation is required. I had read the main GEM book completely through, and it still took me about 20 minutes to figure it out. I finally got Draw installed so I could get it started, but then it complained about the absence of its font files. Back to the books. No mention of font files, no mention of error messages. Back to the disk. Nothing looked like or was named as a font file. Finally, I just guessed and managed to get the required files in the right spot. Totally unacceptable, especially for a product supposedly designed for the end-user.

GEM does have some virtues. It is very pretty, and it runs quite well--even on a PC. It is even prettier and quicker on my AT with the EGA. And, as with the Mac, operation of the system is mostly intutive, with some exceptions.


IBM's program is, at once, both more and less than GEM. It is more because it is concurrent; it is less because it has extremely limited support for graphics. That is also one of its virtues, because it will run on a system with a monochrome display and can be used (albeit slowly) from the keyboard, without a mouse.

I can't think of much else to say that's nice. As with GEM, I had a pretty terrible time with TopView, but this time it was the fault of the program itself, not the documentation. Three things turned me off to TopView.

First, its support for standard DOS functions is abysmal. Only five (5, as in 1-2-3-4-5) DOS functions are on the DOS services menu. All other DOS commands must be typed in a specially provided window. But wait! Not all DOS functions are supported! About 20 are listed, and TopView prohibits others that it does not know about. I had no such trouble with GEM; Microsoft Windows (pre-release version) does not appear to be so handicapped. Worse, TopView will run in any version of DOS but only knows about things up to DOS 2.1. Egad. One would hope for transparency.

Second, TopView steadfastly refused to run Turbo Pascal Version 3.0, no matter what set of facts I gave it. When TopView is told about a new executable program, it asks only three simple questions and assumes worst-case things for about a dozen others. A facility that allows more specific answers to be given is provided. As I say, nothing worked. TopView and the computer still worked, but Turbo seemed to become completely stunned before it even got its first word out. Maybe Turbo is way out of line, but I could find no information in the TopView manual to help me out. I am now in the process of working through IBM for an answer, but my hopes are not high.

Finally, TopView ran one of my own programs incorrectly. I have written a version of David Mannering's famous program Air Traffic Controller. It is written in C, and it absolutely, positively, obeys all DOS and BIOS rules! When the program runs, it displays a radar map; just after the first keystroke, the map is scrolled up by one line. That is, it is scrolled by some unknown force: my program don't have no such code, and she work fine in DOS! Egad again.

So my opinion of TopView is not very high. Neither, apparently, is IBM's: the program is being offered free with certain PC system configurations. If it were good, we would all be beating a path to IBM's door. As it is, IBM may have to beat us to make us take it.

Two other points about TopView deserve mention. There is a programmer's toolkit for TopView, and I have talked to a few software developers who are using the environment for its concurrency. Each has said that it has what they need and in particular is saving them development time because of the windowing support. I cannot comment personally, but I pass on the information. The review of TopView to appear in PC Tech Journal will include the toolkit, and I'll ask that reviewer to write a few words about it for this space in the near future. The other things is that TopView does impose some overhead, and programs run a little slower. This is the case with most concurrent environments, so it's not a fatal flaw. Better machines, such as the AT, tend to mask such overhead.

The Bottom Line

I used GEM and Topview on my system at home for about ten hours each. I want you to know this: it was a sacrifice. I did it for you. I gritted my teeth the whole time. Don't ask me to do it again.

Products: IBM TopView (computer program)
Digital Research GEM (computer program)