A GEM Seminar

John Markoff and Phillip Robinson
BYTE Magazine

June 1985

In the March BYTE West Coast (page 355) we mentioned GEM (Graphics Environment Manager), a new program from Digital Research (DR) that gives a computer a Macintosh-like face of icons, windows, multiple fonts, and pull·down menus. In February we attended the GEM Seminar in Monterey, California, where DR began teaching programmers to adapt their software to the GEM environment. What began as an interesting and impressive technical presentation gave way to a marketing brouhaha, which in turn led to a demonstration of DR's flexibility.

Why is GEM so important? DR's John Hiles claims that personal computers with GEM will not only reach the people who read PC, MacWorld, and Scientific American but also will reach those who read Time and TV Guide. Those people will be more at ease with GEM than with standard operating-system interfaces. DR, the company that once ruled the microcomputer roost with its CP/M operating system for 8-bit microcomputers, hopes to set a new standard with GEM. The Digital Research folks want to provide the advantages of the Mac (and more, such as color displays) to people with other computers. Although the new Atari Inc. under Jack Tramiel (former head of Commodore) is the only company that has committed itself to building GEM into its computers, DR is clearly hoping to penetrate the software-rich, business-standard world of the IBM Personal Computer (PC).

To do this, DR has to do two things. First, it must convince people to use GEM, to build it into hardware and to adapt software to it. Second, DR must teach hardware and software developers how to do those things. Programs will not automatically run on a computer that is equipped with GEM; special files must be added, icons must be designed, and program connections must be developed. (By the way, the bindings for GEM are written in C, though Pascal will be added later. If you want to work with GEM, you certainly should learn C.)

DR decided to begin its education effort with seminars. The one we attended in Monterey was followed by one in London. The seminars had three goals: to continue to pitch GEM, to demonstrate some of the fundamentals of GEM programming (and hand out a software toolkit full of programming utilities and sample code), and to show doubters that GEM is real. That last goal may seem unnecessary, but the fate of Desq, Visi On, and Windows seems to show that such software environments have been jinxed. Visi On disappeared and almost took one of yesterday's largest microcomputer software firms (VisiCorp) with it. Desq has lapsed into limbo, and Microsoft Windows, from one of today's largest software companies, has been repeatedly delayed. In fact, because GEM competes with Windows as much as it does with the Macintosh, DR was clearly happy to be handing out kits and discussing a real product when Microsoft was still months away from its planned summer release of Windows.

To stress the importance of the seminar, DR handed out a list of the attending companies. These were broken into three groups: software houses, original equipment manufacturers (OEMs), and the press. In all, more than 200 people from 30 OEMs and 105 people representing various software
firms were there. However, not everyone came with firm intentions to adapt to GEM. In fact, many would only admit coming to have a look at it or check it out. The list of firm commitments is short but substantial. Atari, ACT (makers of the Apricot computers), Commodore, Northern Telecom, and Texas Instruments have all bought licenses to use GEM. Atari has already employed the license to put GEM in its new ST series of computers. We've heard rumors that Atari isn't alone. The software companies—known at the seminar as ISVs (independent software vendors)—who have announced that they will write to GEM are Blue Chip, Chang Labs, Hayden, Lifetree, Matrix/Systems Group, ProVue, Ouadratron Systems, Schoenburg and Hoxie, Software Products, Spinnaker, and Thorn EMI.

Most of the two-day seminar was devoted to explaining GEM architecture and to walking through GEM program code. Throughout the sessions, the DR team demonstrated GEM running on a variety of IBM machines including a PC AT, a PC XT, and an IBM PC with two floppy-disk drives and 256K bytes of memory. (The PC AT used IBM's advanced graphics adapter with the 640- by 200-pixel resolution.)

A description of GEM's VDI (virtual device interface), which allows programs to think they have control of the terminal when they are in fact being handled by GEM, was followed by a short discussion of fonts. As Lee Lorenzen, senior software engineer for DR, explained, DR is only providing a sans-serif font called Swiss (which looks like Helvetica) and a serif font (which looks like Times-Roman) but is encouraging third-party fonts. In fact. the folks from DR started referring to IFVs (independent font vendors).

Tom Rolander of DR explained some of the tough technical stuff, walking through the code of a sample GEM application he had written (a simple paint program). Then DR's Tim Oren began a detailed overview of the RCS (resource construction set). On Friday morning we completed the RCS overview and then quickly learned how to use the Icon Editor from Greg Morris of DR (he wrote the editor). Rolander returned to walk us through some more C listings for a simple desk accessory.

Friday afternoon's discussion of marketing set off a small explosion. Have you ever seen a room loaded with loud, hostile, and sometimes profane programmers? Except in software project-status meetings, of course. We witnessed one after the DR marketing team presented the licensing facts about GEM. Basically, we were told that there will be two ways for software developers to work with GEM. They can develop GEM-compatible applications and sell them to people who already have GEM on their computers. That's no market at all right now: No one has GEM. Or they can pay DR a license fee that will allow them to sell the application and GEM in a bundle. This license costs $1000 per product per year (with no guarantee that it won't rise)—so far, not so bad. But then DR mentioned that GEM would only run on IBM (PC, PC AT, and PC XT) equipment. It wouldn't even run on compatibles like the Compaq. Why? Because DR didn't want it to. DR deliberately wrote GEM—crippled it—so it wouldn't run on clones. Again, why? Because DR wanted hardware manufacturers to pay OEM license fees to have GEM run on their computers. All OEMs except IBM, that is.

DR didn't mention this until the final hours of the seminar. In fact, the DR marketing people didn't hand out the sheets detailing licensing until just before this session. Did they anticipate the attendees' reactions? The software developers certainly didn't anticipate having to support different GEM versions of their applications for every compatible and clone. What had seemed up until then a crowd of programmers willing to give GEM a shot quickly changed. While not everyone objected to the IBM constraint, there were a number of hostile questions from the audience. In fact, when one person asked how many thought GEM's inability to run on the Compaq was a serious limitation, 50 to 60 percent of the attendees raised their hand. DR responded that it has to make some money on the product and OEM fees are a place to do so. While some developers felt this was reasonable, many others seemed to think they'd been bushwhacked.

Gary Kildall. the president and founder of DR. tried to calm the attendees. Discussions after the conference centered on the marketing plans and what a pain they were. Things looked black for GEM.

Then DR changed its mind. In late February, the folks in Monterey decided to change the code in GEM that checks for machine type. Now, GEM will run on IBM compatibles and clones. Imagine, a sizable software company that really pays attention to its developers and makes major changes because of what it hears.

We were impressed by GEM, as were a number of the developers at the seminar. Everyone went home with two big binders full of some useful information and some fluff, a lot of C code, an invitation to a CompuServe GEM support group, a toolkit disk, and a list of toolkit bugs. While GEM had been in beta test for a couple of months, the toolkit had just reached the beta-test stage and had a number of bugs. For instance, in a certain circumstance, if you tried to drag something out of a menu and then accidentally dropped it on a divider line, the entire computer system would hang and have to be reset

GEM lets you have the same kind of fun as working with a Macintosh and yet lets you step back into the IBM PC world with a quick exit instruction. GEM even has a limited multitasking facility (it can handle some background processes). It is reasonably quick and thorough, but it does have limitations. For example, it has some arbitrary limits, such as a maximum of four open windows at a time and no more than six desk accessories (and a memory-limit size for those).

At press time DR was planning to release its own GEM applications, including GEM Draw (April), GEM Write and GEM Paint (June), and GEM Graph and GEM Wordchart (July).

How will GEM impact the microcomputer world? Right now that depends mainly on DR, Atari and Apple. Can DR convince developers to work in a GEM world? Will Atari be able to produce huge numbers of inexpensive GEM machines, as Tramiel claims? And finally, how will Apple respond? If people can have the Macintosh juice in a cheaper computer, or on an IBM PC-compatible, will they continue to buy Macs? Does Apple have the next evolution or revolution (like a cheaper or more powerful Mac) up its sleeve? If so, the Cupertino Corps may well find that GEM's imitation has confirmed Mac ideas and put Apple out in front of the microcomputer race. If Apple isn't ready to take the next step, it may be run over by a horde of "Macalikes" egged on by a smiling DR.