Chris Zamara & Nick Sullivan

The mid-1980s was the era when the personal computing vendors ended their war on themselves. In the belligerent phase, every time a vendor released a new computer, it was incompatible with everything that came before it. In “Where Are The Killer Apps?”, I showed that Commodore VIC-20 software does not run on the Commodore 64, or any other computer made by the same company or another company. The same was true for Apple: try running Apple 1 software on an Apple ][, Apple ///, Lisa, or Macintosh (or these days, try to run Macintosh software from a decade ago on a Macintosh); of Sinclair: you cannot run ZX80 software on a ZX81, Spectrum, or QL; and Tandy/Radio Shack: you cannot run TRS-80 Model I software on a TRS-80 Model II, on a TRS-80 Color Computer, or a Model 100.

For individual customers, this meant a huge upheaval whenever they bought a new computer (which was only once every decade or so at the time), as all of their programs, and all of their data, and most of their peripherals, and half of the BASIC keywords they had learned and all the memory locations to PEEK and POKE, all stopped working with the new system. It also meant huge questions for potential new customers: will software houses still support this computer six months from now? How about peripheral makers? Will my investment pay off?

So then came the era when the vendors made peace with themselves, and they started making compatible model families, which could all (more-or-less) run the same software, and use the same peripherals. They finally learned the lesson of IBM’s System/360, and of course the runaway example of the compatible model family is the IBM PC and its legion of clones. Alongside that, TRS-80 Model III and IV both run TRS-80 Model I software; The ZX Spectrum 128k, +2, and +3 all run ZX Spectrum software; the Macintosh remained compatible with its original model’s software up until Mac OS X 10.5; and all versions of the Amiga could more-or-less run anything designed for the original Amiga 1000.

Now it was safer for customers to buy into a platform, because it looked more likely that they would still be able to get applications (OK, let us be honest, games) and peripherals for the computer a few years out, and that the next time they bought a computer, they might be able to get one that can still use all those games and peripherals. But what would make any one platform more compelling than the others; what gets a customer to hitch their cart to Apple’s horses instead of Commodore’s? By the mid-1990s, all of the platforms that were still on the market had roughly compatible capabilities, with sound being the weird outlier: Apple Computer had settled the suit with Apple Corps and were allowed to play sounds on their computers; PCs were starting to transition from either beeps-only or CD-quality Sound Blasters to CD-quality integrated sound chips; Atari had integrated MIDI capabilities into the ST line all along; Amiga was the laggard, with its 1985 standard-setting Paula chip still the only option in the final CD32 model.

The vendors needed killer apps, but they needed a particular, very constrained, kind of killer app. Something that made their platform more compelling, but that did not crowd out independent software vendors. Something that made everybody else’s software better on their computers, and also made their own software better on their computers.

For a brief period, it looked like this killer app was going to be interoperability, and empowerment. Each platform supplied its own, unique way to interconnect software into a platform-wide automation capability that let the vendor’s customers write scripts, or record macros, that used first-party and third-party software in concert to perform complicated tasks. It was a beautiful time; perhaps the last time that the computer vendors trusted us to know what we wanted and enabled us to go the last mile ourselves.

Windows 95 supplied Windows Script Host, which could communicate with any app on the platform using COM. Apple provided Open Scripting Architecture, which apps could integrate with to make their capabilities available to people who wrote AppleScript. Two other platforms—IBM and Microsoft’s ill-fated OS/2, and Commodore’s ill-fated Amiga—adopted an interpreted language from IBM as the interface to their interoperability features: Rexx.

Amiga Rexx (ARexx) was not actually Commodore’s idea, it was created by William S. Hawes as a third-party product, but Commodore saw the value and incorporated it into AmigaOS 2.0 and every subsequent release, from 1990. Rexx itself is a nice, PL/1-like language with some interesting features: it does not have arrays or dictionaries, but it does have “stem variables”, so the variables named a.1 and a.2 are associated through the stem a, and if another variable i has the value 2, then the value of a.i is whatever you assigned to a.2.

What sets ARexx apart and makes it a candidate for empowerment feature of the (last) century is the idea of the command host. Just like AppleScript’s tell application "Finder" instructs the script interpreter to send a message over to the Finder app, ARexx’s address 'DPaint' tells the interpreter to connect to the port for the DPaint app. The app does whatever the Rexx script requests, and then replies to the message.

What the application receives is a message containing the string was addressed to it, which it can parse using the same format specifiers that CLI tools use in the AmigaDOS shell: the first word is the command name (i.e. the verb) and everything else is a modifier, or parameter. In this way, the syntax is relatively free, but still relatively programming-like, avoiding the trap of feeling like natural language but interpreting input in surprising ways. This problem befell AppleScript, where author Matt Neuberg described it as the “English-likeness” monster.

In this way, ARexx acts as the universal glue that makes Amiga applications part of a powerful suite of interconnected tools, designed, assembled, and controlled by the person using the computer. During this period where a platform vendor’s agent has more access to the apps and content on a computer than its customers do, the suppliers would be well served by remembering a time when they tried to empower their customers, and make sure that the world of computing did not turn out like Nineteen Eighty-Four.

Cover photo by the author.

Back to top