COMPUTERS ARE BAD is a newsletter semi-regularly issued directly to your doorstep to enlighten you as to the ways that computers are bad and the many reasons why. While I am not one to stay on topic, the gist of the newsletter is computer history, computer security, and "constructive" technology criticism.
I have an M. S. in information security, more certifications than any human should, and ready access to a keyboard. This are all properties which make me ostensibly qualified to comment on issues of computer technology. When I am not complaining on the internet, I work in engineering for a small company in the healthcare sector. I have a background in security operations and DevOps, but also in things that are actually useful like photocopier repair.
You can see read this here, on the information superhighway, but to keep your neighborhood paperboy careening down that superhighway on a bicycle please subscribe. This also contributes enormously to my personal self esteem. There is, however, also an RSS feed for those who really want it. Fax delivery available by request.
First, after lengthy research and development I have finally followed through
on my original vision of making Computers Are Bad available via Gopher.
Check it out at gopher://waffle.tech/computer.rip.
Let's talk a bit more about GUIs. I would like to begin by noting that I am
intentionally keeping a somewhat narrow focus for this series of posts. While
there were many interesting GUI projects across a range of early microcomputer
platforms, I am focusing almost exclusively on those GUIs offered for CP/M and
DOS. I am keeping this focus for two reasons: First, these are the
microcomputer platforms I am personally most interested in. Second, I think the
landscape of early CP/M and DOS GUIs are an important part of the history of
Windows, because these are the GUIs with which Windows directly competed. A
real portion of the failure of Windows 1 and 2 can be attributed to Microsoft's
lackluster effort compared to independent software vendors---something quite
surprising form the modern perspective of very close coupling between the OS
and the GUI .
Let's talk, then, about my personal favorite GUI system, and one of the most
significant examples of stretching the boundary between operating system and
application by implementing basic system features on top of an OS that lacks
them... but first, we need to take a step back to perhaps the vintage software
I mention most often.
VisiCalc is, for most intents and purposes, the first spreadsheet. There were
"spreadsheet-like" applications available well before VisiCalc, but they were
generally non-interactive, using something like a compiled language for
formulas and then updating data files offline. VisiCalc was the first on the
market to display tabular data and allow the definition of formulas within
cells, which were then automatically evaluated as the data they depended on
changed. It was the first time that you could change one number in a
spreadsheet and then watch all the others change in response.
This is, of course, generally regarded as the most powerful feature of a
computer spreadsheet... because it allows for the use of a spreadsheet not
just as a means of recording and calculation but as a means of simulation.
You can punch in different numbers just to see what happens. For the most part,
VisiCalc was the first time that computers allowed a user to "play with
numbers" in a quick and easy way, and nearly overnight it became a standard
practice in many fields of business and engineering.
Released in 1979, VisiCalc was one of the greatest innovations in the history
of the computer. VisiCalc is widely discussed as being the "killer app" for
PCs, responsible for the introduction of microcomputers to the business world
which had formerly eschewed them. I would go one further, by saying that
VisiCalc was a killer app for the GUI as a concept. VisiCalc was one of the
first programs to truly display the power of direct manipulation and
object-oriented interface design, and it wasn't even graphical. It ran in text
We have already, then, identified VisiCalc's creator Dan Bricklin and his
company VisiCorp  as a pioneer of the GUI. It is no surprise, then, that this
investment in the GUI goes beyond just the spreadsheet... and yet it would
surprise many to hear that VisiCorp was also the creator of one of the first
complete GUIs for DOS, one that was in many ways superior to GUIs developed
By 1983, VisiCorp had expanded from spreadsheets to the broader world of what
we would now refer to as productivity software. Alongside VisiCalc were
VisiTrend/VisiPlot for regression and plotting , word processor VisiWord,
spell checker VisiSpell, and proto-desktop database VisiFile. The problem was
this: each of these software packages were fully independent, any
interoperation (such as spell checking a document or plotting data) requiring
saving, launching a new program, and opening.
Of course this was a hassle on a non-multitasking operating system, although
multitasking within the scope of a user was sufficiently uncommon at the time
that it was not necessarily an extreme limitation. Nonetheless, the tides
were turning in the direction of integrated software suites that allowed
simultaneous interoperation of programs. In order to do this effectively, a new
paradigm for computer interface would be required.
In fact this idea of interoperation of productivity software is an important
through-line in GUI software, with most productivity suite developers struggling
with the same problem. It tended to lead to highly object-oriented,
document-based, componentized software. Major examples of these efforts are the
Apple Lisa (and the descendent OpenDoc framework) and Microsoft's OLE, as
employed in Office. On the whole, none of these have been very successful, and
this remains an unsolved problem in modern software. There is still a great
deal of saving the output of one program to open in another. I will probably
have a whole message on just this topic in the future.
In any case, VisiCorp realized that seamless interoperation of Visi
applications would require the ability to run multiple Visi applications
easily, preferably simultaneously. This required a GUI, and fortunately for
VisiCorp, the GUI market was just beginning to truly take off.
In order to build a WIMP GUI there are certain fundamental complexities you
must address. First, GUI environments are more or less synonymous with
multitasking, and so there must be some type of process scheduling arrangement,
which had been quite absent from DOS. Second, both multitasking and
interprocess communication (which is nearly a requirement for a multitasking
GUI) all but require virtual memory. Multitasking and virtual memory management
are today considered core features of operating systems, but at this point in
time they were unavailable on many operating systems and so anyone aiming for
a windowed environment was responsible for implementing these themselves.
Released late 1983, VisiCorp's Visi On GUI environment featured both of these.
Multitasking was not at all new and as far as I can tell Visi On multitasking
was cooperative (it is very possible I am wrong on this point, it is hard to
find a straight answer to this question), so the multitasking capability was
not especially cutting edge. What was quite impressive is Visi On's
implementation of virtual memory complete with page swapping, which made it
practical to have multiple applications running even if they were heavy
applications like VisiCorp productivity tools.
Beyond its implementation of multitasking and virtual memory, Visi On was a
graphics mode application (i.e. raster display) and supported a mouse. The
mouse was used to operate a fundamentally WIMP UI with windows in frames,
drop-down menus at the top of windows, and a cursor... fundamentally similar to
both pioneering GUIs such as the Alto and the environments that we use today.
Visi On allowed multiple windows to overlap, which sounds simple but was not to
be taken for granted at the time.
Perhaps the most intriguing feature of Visi On is that it was intended to make
software portable. Visi On applications, written in a language called Visi C,
targeted a virtual machine called the Visi Machine. The Visi Machine could in
theory be ported to other architectures and operating systems, making Visi On
development a safer bet for software vendors and adoption of Visi On software a
safer bet for users. This feature was itself quite innovative, reminiscent of what
Java much later.
For the many things that Visi On was, there were several things that it was
not. For one, Visi On did not embrace the raster display as much as even other
contemporary GUIs. There was virtually no use of icons in Visi On, although it
ran in graphics mode it was, visually, very similar to VisiCorp's legacy of
text-mode software with GUI-like features.
One of the most significant limitations of Visi On is reflective of the basic
problem with GUI environments running on existing operating systems. Visi On
was not capable of running DOS software.
This sounds sort of bizarre considering that Visi On itself was a DOS
application. Technically, it make sense, though. DOS was a non-multitasking
operating system with direct memory addressing and no hardware abstraction. As
a result, all DOS programs were essentially free to assume that they had
complete control of the system. As a result, DOS applications would freely
write to memory anywhere they pleased, and never yielded control back to the
system . In short, they were terrible neighbors.
While some GUI systems found ways to coexist with at least some DOS
applications (notably, Windows), Visi On did not even make the attempt. Visi On
was only capable of running applications specifically built for it, and all
other applications required that the user exit Visi On back to plain old DOS.
If you wonder why you have never heard of such a revolutionary software package
as Visi On, this is one major reason: Visi On's incompatibility with the
existing stable of DOS applications made it unappealing to most users, who
did not want to live a life of only VisiCorp products.
The other big problem with Visi On was the price. Visi On was expensive to
begin with, retailing at $495. It had particularly high system requirements in
addition. Notably, the use of virtual memory and swapping required something to
swap to... Visi On required a hard drive, which was not yet common on PCs. All
in all, a system capable of running Visi On would be a huge expense compared to
typical PCs and even other GUI systems that emerged not long after.
Visi On had a number of other intriguing limitations to boot. Because it was
released for DOS 2 which used FAT12, it could only be run on a FAT12 system
even as DOS 3 made the jump to FAT16... among the many things Visi On had to
implement to enable multitasking was direct interaction with the storage.
VisiCorp required a Mouse Systems mouse, which was standard as of release but
was soon after obsoleted (for most purposes) by the Microsoft mouse standard,
so even obtaining a mouse that worked with Visi On could be a hassle.
In the end, Visi On's problems were at least as great as its innovations...
cost of a working system most of all. Visi On was the first proper GUI
environment to market for the IBM PC, but many others followed very quickly
after, including Microsoft's own Windows (which was, debatably, directly
inspired by Visi On). More significantly at the time, the Macintosh was
released shortly after Visi On. The Macintosh was a lemon in many ways, but did
gain appreciable market share by fixing the price issues with the Lisa
(admittedly partially through reduced functionality and a less ambitious
The combination of Visi On's high price, limitations, and new competition were
too much for VisiCorp to bear. Perhaps VisiCorp could have built on its early
release to remain a technical leader in the space, but there were substantial
internal issues within VisiCorp that prevented Visi On receiving care and
attention after its release. It became obsolete very quickly, and this
coincided with VisiCalc encountering the same trouble: ironically, Lotus 1-2-3
was far more successful in taking advantage of the raster display (by being
available for common hardware configurations unlike Visi On), which lead to
VisiCalc itself becoming obsolete.
Shortly after release, in 1984, VisiCorp sold Visi On to CDC. CDC didn't really
have much interest in the software, and neither enhanced it nor marketed it.
Visi On died an ignominious death, not even a year after its release... and that
was the end of the first GUI for the IBM PC. Of course, there would be many
 Of course you may be aware that non-NT Windows releases (up to Millennium
Edition) similarly consisted basically of Windows running as an application on
DOS, although the coupling became tighter and tighter with each release. This
is widely viewed as one of the real downfalls of these operating systems
because they necessarily inherited parts of DOS's non-multitasking nature,
including an if-in-doubt-bail-out approach to error handling in the "kernel."
Imagine how much worse that was in these very early GUIs!
 The Corporate Entity Behind VisiCalc went through various names through its
history, including some acquisitions and partnerships. I am always referring to
the whole organization behind VisiCalc as VisiCorp for simplicity and because
it's the best name out of all of them.
 This view of regression and plotting as coupled features separate from the
actual spreadsheet is still seen today in spreadsheets such as Excel, where
regression and projection are mostly clearly exposed through the plotting tool.
This could be said to be the main differentiation between spreadsheets and
statistical tooling such as Minitab: spreadsheets do not view operations on
vectors as a core feature. Nonetheless, Excel's inability to produce a simple
histogram without a plugin for decades was rather surprising.
 There were DOS applications that produced a vestige of multitasking, called
TSRs for Terminate and Stay Resident. These were not multitasking in any
meaningful way, though, as the TSR had to set an interrupt handler and hope the
running application did not change it. The TSR could only gain control via an
interrupt. When the interrupt occurred, the TSR became the sole running task.
Of course, these limitations made the "multitasking-like" TSRs that existed all
the more interesting.
To begin with, a reader emailed me an objection to my claim that Smalltalk has
never been used for anything. They worked at an investment bank you have heard
of where Smalltalk was used for trading and back office systems, apparently at
some scale. This stirred a memory in me---in general the financial industry was
(and to some extent is) surprisingly interested in "cutting edge" computer
science, and I think a lot of the technologies that came out of first-wave
artificial intelligence work really did find use in trading especially. I'd be
curious to hear more about this from anyone who worked in those environments,
as I know little about finance industry technology (despite my interest in
their weird phones). Also, I am avoiding naming this reader out of respect for
their privacy and because I neglected to ask them if it's okay to do so before
going to publish this. So if you email me interesting facts, maybe do me a
favor and mention whether or not you mind if I publish them. I'm bad at asking.
And now for something completely different.
Years ago, at a now-shuttered Smith's grocery store in my old home of Socorro,
New Mexico, I did a dramatic double-take at a clearance rack full of Firewire.
This Firewire was basically a steel cable used like a skewer but, well, floppy.
The name got a chuckle out of me and this incident somehow still pops into my
mind every time I think about one of my "favorite" interconnects: IEEE 1394.
IEEE 1394 was developed as a fast serial bus suitable for use with both storage
devices and multimedia devices. It was heavily promoted by Apple (its original
creator) and present on most Apple products from around 2000 to the switch to
Thunderbolt, although its popularity had decidedly waned by the time
Thunderbolt repeated its mistakes. FireWire was never as successful as USB for
general-purposes usage. There are various reasons for this, but perhaps the
biggest is that FireWire was just plain weird.
What's it called?
IEEE 1394 was developed by several groups in collaboration, but it was
conceived and championed by Apple. Apple refers to it by the name FireWire, and
so do most humans, but Apple held a trademark on that name. While Apple made
arrangements to license the trademark to a trade association for use on other
implementations in 2002, long after that most PC manufacturers continued to use
the term IEEE 1394 instead. I am not clear on whether or not this was simple
aversion to using a name which was strongly associated with a competitor or if
these implementations were somehow not blessed by the 1394 Trade Association.
In any case, you will probably find the terms FireWire and IEEE 1394 used with
roughly equal frequency. For further confusion, Sony uses the term i.LINK to
refer to IEEE 1394 on their older products including cameras and laptops.
Wikipedia says that TI also refers to it as Lynx, but I haven't seen that name
personally and cursory internet research doesn't turn up a whole lot either.
The lack of a single, consistent brand identity for FireWire might be seen as
its first major mistake. My recollection from FireWire's heyday is that there
were indeed people who did not realize that FireWire devices could be used with
non-Apple computers, even though "IEEE 1394" interfaces were ubiquitous on PCs
at the time. I think this must have negatively impacted sales of FireWire
peripherals, because by the time I was dealing with this stuff the only storage
peripherals being sold with FireWire were being marketed exclusively to Apple
users by historically Apple-associated brands like Macally and LaCie.
What does it look like?
Further contributing to compatibility anxiety was the variety of physical
connectors in use. The major FireWire connectors in use were (most commonly)
called Alpha, Sony, and Beta. The difference between Alpha and Beta was one of
speed, as Alpha was designed for FireWire 400 (400Mbps) and Beta for FireWire
800 (800Mbps). Even this change, though, required the use of so-called
"Bilingual" cables with Alpha on one end and Beta on the other.
The Sony standard, which worked only with FireWire 400, was smaller and so
popular on mobile or otherwise low-profile devices. A number of laptops also
used this smaller connector for reasons I'm not completely clear on (the Alpha
connector is not significantly larger than USB).
The result was that practical use of FireWire frequently required adapters or
asymmetric cables, even more so than USB (where the device connector was
inconsistent) since both ends had a degree of inconsistency involved. The
hassle was minor but surely didn't help.
Just to make things more fun, FireWire could be transported over twisted pair
(UTP) and efforts were made towards FireWire over single mode fiber. I'm not
aware of any significant use of these, but the idea of running FireWire over
UTP will become significant later on.
Is it cooler than USB?
Unlike USB and other contemporary peripheral interconnects, FireWire had
complex support for management and configuration of the bus. Unlike USB which
was 1:1 computer to device, FireWire supported arbitrary groups of up to 63
devices in a tree. While there is a "root node" with some centralized
responsibility in the operation of the bus, any device can send data directly
to any other device without a copy operation at the root node.
This meant that FireWire was almost more a network protocol than a mere
peripheral interconnect. In fact, it was possible to transport Ethernet frames
over FireWire and thus use it as an IP network technology, although this wasn't
especially common. Further supporting network usage, FireWire supported basic
traffic engineering in the form of dedicated bandwidth for certain data
streams. This was referred to as isochronous mode, and its ability to guarantee
a portion of the bus to real-time applications is reflective of one of
FireWire's major strengths (suitability for multimedia) and reminds me of just
how uncommon this is in common computer systems, which makes me sad.
Despite the common perception in the computing industry that opportunistic
traffic management is better^wmore fun^w^weasier to implement, FireWire's
allocated bandwidth capability turned out to be one of its most important
features, as it fit a particular but important niche: camcorders.
The handheld camcorders of the early 2000s mostly used DV (digital video),
which recorded a digital stream onto a magnetic tape (inexpensive random-access
storage was not sufficiently durable or compact at the time). In order to
transfer a video to a computer, the tape was played back and the contents of
the tape sent directly back to the computer, which recorded it. USB proved
incapable of meeting the task.
It's not quite as simple as USB being too slow; USB2.0 could meet the data rate
requirements. The problem is that USB (until USB 3.0) was polling-based, and so
reliable transfer of digital video from a tape relied on the computer polling
sufficiently frequently. If it didn't---say because the user was running
another program during the transfer---the video would be corrupted. It turns
out that, for moving digital media at original quality, allocated bandwidth
Note that FireWire is effectively acting as a packetized video transport in
this scenario, just with some extra support for a control channel. This is very
similar to later video technologies such as HDMI.
Did the interesting features become a security problem?
The more complicated something is, the more likely it is that someone will use
it to steal your credit card information. FireWire is no exception. Part of
FireWire's performance advantage was its support for DMA, in which a FireWire
device can read or write information directly from a computer's memory. This
was a useful performance optimization, especially for high-speed data transfer,
because it avoided the need for extra copies out of a buffer.
The problem is that memory is full of all kinds of things that probably
shouldn't be shared with every peripheral. FireWire was introduced before DMA
was widely seen as a security concern, and well before memory management units
that provided security protections on DMA. On many real FireWire devices,
access to physical memory was completely unrestricted. Every FireWire device
was (potentially) a memory collection device.
What happened to FireWire?
Consumer adoption was always poor outside of certain niche areas such as the DV
video transfer use case. I suspect that a good portion of the issue was the
higher cost of FireWire controllers (due to their higher complexity), which
discouraged FireWire in low-cost peripherals and cemented USB as a more, eh,
universal solution. Consumer perceptions of FireWire as being more complex than
USB and somewhat Apple specific were likely an additional factor.
That said, the final nail in FireWire's coffin was probably a dispute between
Apple and other vendors related to licensing costs. FireWire is protected by a
substantial patent portfolio, and in 2002 Apple announced a substantial
$1-per-port licensing fee for use of the technology. Although the fee was later
reduced, it was a fiasco that took much of the wind out of FireWire's sails,
particularly since some major partners on FireWire technology (including Intel)
saw it as a betrayal of previous agreements and ended their active promotion
In summation, FireWire seems to have fallen victim to excessive complexity,
costly implementation, and licensing issues. Sound familiar? That's right,
there's more commonality between FireWire and ThunderBolt than just the name.
While Apple stopped supporting FireWire some years ago, it continues to see a
few applications. IEEE 1394 was extended into embedded and industrial buses and
is used in the aerospace industry. It also continues to have some use in
industrial automation and robotics, where it's used as a combined transport for
video and control with machine vision cameras. That said, development of the
FireWire technology has basically stopped, and it's likely these uses will
fade away in the coming years.
Last of all, I have to mention that US cable boxes used to be required to
provide FireWire ports. The reason relates to the conflict of cable providers
and cable regulators in the United States, which will be its own post one day.
The modern GUI, as we understand it, can be attributed almost entirely to the
work of Douglas Engelbart.
In fact, it is rather surprising to me that so much can be attributed to one
person. I have said before that the technology industry moved so quickly that
nearly every significant innovation can be attributed to multiple, parallel
efforts. In fact this is probably true of the GUI, but any parallel efforts
have been deeply forgotten in comparison to Engelbart's pioneering work.
In 1968, Engelbart presented to a conference a demonstration of a project he
had built while at SRI. Generally based on Vannevar Bush's  conceptual
design for the "memex," Engelbart's effort put together nearly all of the
major aspects of a modern GUI system. There was a mouse, there were windows,
buttons, hyperlinks, menus, everything you could want. The GUI, to a remarkable
degree, was just invented all at once.
Of course Engelbart was not precognizant. He made a number of missteps, many of
which would be repeated by the XPARC work on the Alto which was closely based
on Engelbart's demonstration. Most amusingly, Engelbart found it unlikely that
computer users would want to use a mouse with one hand when the keyboard
requires both. As a solution he proposed (and used) a one-handed, chord-based
keyboard. Despite the best efforts of many dweebs, one handed text entry has
never caught on .
More profoundly, though, Engelbart failed to anticipate the complete lack of
interest in actually implementing the concepts he demonstrated. Despite the
amazing impact of his demonstration on the audience, the technology was complex
and difficult to build, and bore little resemblance to the text-mode,
command-oriented environment which was the respected norm in business
Engelbart invented the modern GUI in 1968. It would not be available on the
market until 1981.
From our comfortable position today it is hard to imagine how this could be.
GUIs seem to be the obvious progression in computer interfaces. Yet, during
Engelbart's work his vision was regarded as largely academic, not practical.
GUIs as a concept were closely tied to cybernetics and artificial intelligence,
fields which attracted a great deal of graduate students but very few actual
users. The GUI was cool, it was interesting, but it was not practical.
This situation is perhaps most exemplified by Smalltalk. Smalltalk was
developed at XPARC (that's the Xerox Palo Alto Research Center) as a teaching
language, and was best known for being an early object-oriented language and
for its frequent implementation in highly GUI-centric virtual machines. Major
implementations like Squeak couple Smalltalk with graphical development and
debugging environments which are surprisingly cutting edge, and yet completely
You see, Smalltalk, despite its innovations, has basically always been
constrained to academia. Most CS students are exposed to Smalltalk at some
point (probably in a programming language theory course), but no one actually
uses it for anything. The situation was largely the same for all graphical
environments through the course of the '70s and to a good degree into the '80s.
Many new technologies fall into this trap to some degree, being the subject of
a great deal of excited research but never bridging the gap into wide-scale
implementation. For example, basically the entire field of computer usability.
What unstuck the GUI and pushed it into the world of industry? Basically Steve
Jobs, although he too suffered a few false starts. The Lisa was technically
advanced but a commercial failure, the Macintosh was a commercial success but
relatively primitive. Nonetheless, the Macintosh was essentially the next major
step from Engelbart's demo, and it established many of the norms for GUIs for
years to come.
The relative success of the Macintosh compared to the costly but significantly
superior Lisa is a rather unfortunate situation. For the most part, the Lisa
was the more innovative and capable machine. The Macintosh was essentially a
compromise, stripping out the most interesting features of the Lisa to achieve
a low price and more gentle learning process. To be quite honest, the Macintosh
sucked, which is why we far more often talk about its various successors.
I will probably devote an entire post to this, because I want to do the topic
justice and did not intend to take it on here. But the Lisa was a document
interface, while the Macintosh was a program interface.
This is actually the same paradigm we discussed in a previous post, of
functional vs object-oriented user interfaces. Graphical operating systems that
we use today are nearly entirely functional, with the operating system's role
fundamentally being the launching and management of programs. It might be hard
to picture anything else. But most early GUI research actually did envision
something else, a fully object-oriented interface that is nearly entirely
structured around documents and data. The Lisa was document-oriented, and
Microsoft made various efforts towards a document-oriented Windows experience.
But document-oriented interfaces were ultimately unsuccessful, and none survive
Despite the disappointing compromise of the Macintosh, it set the trend for most
GUI systems to follow. The Macintosh interface was WIMP (Windows, Icons, Menu,
Pointer), it had drag-and-drop file management (although it opened a new window
for every folder the user descended into, an especially irritating element of
early GUI operating systems that was fortunately cast off by the new
millennium), and it used icons on a desktop as the primary entry point at menus
at the top for access to commands.
In the eyes of most, the next major step from the Macintosh was Microsoft
Windows. Windows was introduced in its first version only a year after the
Macintosh and a few years after the Lisa. Early releases of Windows, and to a
degree all releases of Windows outside of NT, were simply applications which
ran on top of DOS. This was a logical decision at the time, to build GUIs on
top of a better established foundation, but it also imposed significant
In part as a result, the early versions of Windows were primitive and simply
not that interesting. They were correspondingly unsuccessful, which is why you
virtually never hear any mention of Windows 1.0 or 2.0.
The reason for the poor performance of Windows 1 and 2 is actually a
surprisingly interesting and surprising one. It wasn't because Windows was
inferior to the Macintosh; this was a factor to a degree but the Apple world
was already highly differentiated from the PC world and the PC world had a
formidable hold in the business world that ought to have conferred a big
advantage on PC software.
It was more that early releases of Windows failed because they were inferior to
other DOS GUIs.
The '80s PC world
Before we can get into the history of PC GUIs, we ought to devote some
discussion to the context in which they were developed. Although IBM and others
developed multiple operating systems for various generations of their personal
computers, and thus for their many clones, by the '80s there was a high degree
of consolidation on CP/M (for non-IBM small computers) and DOS (for IBM small
computers and their clones). CP/M bears mentioning more so than other non-IBM
operating systems of the time because, as a result of happenstance, CP/M was
highly influential on the design of DOS which was intended to have a high
degree of similarity to ease transition from one to the other.
We could almost say that DOS was a new version of CP/M, but the process was
politically and technically rocky and various features of CP/M fell off the
truck on the way to DOS. In the same way, some features of CP/M were carried
into DOS even though they probably shouldn't have been. A number of DOS's
oddities can be attributed to its origin as Microsoft Imitation CP/M Product.
So of the early non-Apple GUIs, most (but not all!) were intended to run on top
of CP/M or DOS.
The thing is, CP/M and DOS were both primitive operating systems by modern
standards. CP/M and DOS were not multi-tasking. They did not employ virtual
memory, but instead addressed all memory directly. As a natural result of these
two prior facts, they provided no isolation between running programs, and so
the primitive "multitasking-like" behavior that could be implemented was very
prone to problems.
If we were presented with this situation today, we might declare that
development of a GUI environment on top of these operating systems is simply
impossible. And yet...
 If the name Vannevar Bush is familiar to you, there could be any number of
reasons as he had a prominent career. Perhaps most notably, as director of the
OSRD, he was a major figure in the early development of nuclear weapons.
 The obvious solution to this problem, of integrating the mouse into the
keyboard, was popular on '90s laptops but is largely forgotten today. A small
group of trackstick devotees have managed to keep them on "business" laptops,
a great benefit to myself. I cannot imagine life without a trackstick mouse,
the only civilized way to move the cursor with both hands on the home row.
 In fact, Apple launched several different independent GUI operating systems
in a span of a few years in the early '80s, the Macintosh being the only one
that survived. One day I will write about these.
A brief interlude from the topic of GUIs to talk about perhaps one of the most
infamous of all GUI programs, Microsoft PowerPoint.
PowerPoint is ubiquitous but often criticized in most industries, but I have
never seen more complete use and abuse of PowerPoint than in military. I was
repeatedly astounded by how military programs invested more effort in preparing
elaborately illustrated slides than actually, well, putting content in them.
And that, in a nutshell, is the common criticism of PowerPoint: that it allows
people to avoid actual effective communication by investing their effort in
Nonetheless, the basic idea of using visual aids in presentations is obviously
a good one. The problem seems to be one of degrees. When I competed in
expository speech back in high school my "slides" were printed on a plotter and
mounted on foam core. More so than the actual rules of the event, this imposed
an economy in my use of visual aids. Perhaps the problem with PowerPoint is
simply that it makes slides too easy. When all you need to do is click "new
slide" and fill in some bullet points, there's nothing to stop the type of
presenter who has more slides than ideas.
Of course that doesn't stop the military from hiring graphic designers to
prepare their flowcharts, but still, I think the basic concept stands...
As my foam core example suggests, the basic idea of presenting to slides is
much older than PowerPoint. I've quipped before that Corporate Culture is what
people call their PowerPoint presentations. Most of the large, old
organizations I've worked for, private and government, had some sort of
"in-group" term for a presentation. For example, at GE, one presents a "deck."
Many of these terms are anachronistic, frozen references to whichever
presentation technology the organization first adopted.
Visual aids for presentations could be said to have gone through a few
generations: large format printed materials, transparent slides, and digital
projection. Essentially all methods other than projection have died out today,
but for a time these all coexisted.
Printed materials can obviously be prepared by hand, e.g. by a sign painter,
and this was the first common method of presenting to slides. Automation
started from this point, with the use of plotters. As I have perhaps mentioned
before the term "plotter" is a bit overloaded and today is often used to refer
to large-format raster printers, but historically "plotter" referred to a
device that moved a tool along vectors, and it's still used for this purpose as
Some of the first devices to create print materials from a computer were pen
plotters, which worked by moving a pen around over the paper. HP and Roland
were both major manufacturers of these devices (Roland is still in the
traditional plotter business today, but for vinyl cutting). And it turns out
that presentations were a popular application. The lettering produced by these
devices was basic and often worse than what a sign painter could offer (but
requiring less skill). What really sold pen plotters was the ability to produce
precise graphs and charts directly from data packages like VisiCalc.
The particularly popular HP plotters, the 75 series, had a built-in demo
program that sold this capability by ponderously outlining a pie chart along
with a jagged but steeply rising line labeled "Sales." Business!
These sorts of visual aids remained relatively costly to product though until
projection became available... large-format plotters, board to make things
rigid, etc. are not cheap. Once you buy a single projector for a conference
room, though, projection becomes a fairly cheap technology, even with the
methods of producing slides.
The basic concept of projection slide technology is to produce graphics using
a computer and then print them onto a transparent material which serves as film
for a projector. There are a lot of variations on how to achieve this. Likely
the oldest method is to produce a document using a device like a plotter (or
manual illustration, or a combination) and then photographically expose it on
film using a device that could be described as an enlarger set to suck rather
than blow. Or a camera on a weird mount, your choice.
In fact this remained a very common process for duplication for a very long
time, as once a document was exposed on film photochemical methods can be used
to produce printing plates or screens or all kinds of things. There is a
terminological legacy of this method at least in the sciences, where many
journals and conferences refer to the final to-be-printed draft of a paper as
the "camera-ready" version. In the past, you would actually mail this copy to
them and they (or more likely their printing house) would photograph it using
a document camera and use the film to create the plates for the printed journal
If you've seen older technical books or journals, you may have seen charts and
math notation that were hand-written onto the paper after it was typewritten
(with blank spaces left for the figures and formulas). That's the magic of
"reprographics," a term which historically referred mostly to this paper to
film to paper process but nowadays gets used for all kinds of commercial
printing. This is closely related to the term "pasting up" for final document
layout, since a final step before reprographic printing was usually to combine
text blocks, figures, etc produced by various means into a single layout. Using
For presentations, there are a few options. The film directly off the document
camera may be developed and then mounted in a paper or plastic slide to be
placed in a projector. If you are familiar with film photography, that might
seem a little off to you because developed film is in negative... in fact, for
around a hundred years "reversal films" have been available that develop to
positive color, and they were typically used to photograph for slides in order
to avoid the need for an extra development process. Kodachrome is a prominent
example. Reversal films are also sometimes used for typical photography and
cinematography but tended to be more complex to develop and thus more
expensive, so most of us kept our terrible 35mm photography on negatives.
This approach had the downside that the slide would be very small (e.g. from a
35mm camera), which required specialized projection equipment (a slide
projector). The overhead projector was much more flexible because the "film
frame," called the platen, was large enough for a person to hand-write on. It
served as a whiteboard as well as a projector. So more conference rooms
featured overhead projectors than slide projectors, and there was a desire to
be able to project prepared presentations on these devices.
This concept, of putting prepared (usually computer-generated) material on a
transparent sheet to be placed on an overhead projector, is usually referred to
as a "viewgraph." Viewgraphs were especially popular in engineering and defense
fields, and there are people in the military who refer to their PowerPoint
presentations as viewgraphs to this day. There are multiple ways to produce
viewgraphs but the simplest and later on most common was the use of plastic
sheets that accepted fused toner much like paper, so viewgraphs could either be
printed on a laser printer or made by photocopying a paper version. When I
worked for my undergraduate computer center around a decade ago we still had
one laser printer that was kept stocked with transparency sheets, but people
only ever printed to it by accident.
In fact, these "direct-print" transparencies were a major technical advancement.
Before the special materials were developed to make them possible, overhead
transparencies were also produced by photochemical means and use of a document
camera and enlarger. But most large institutions had an in-house shop that
could produce these with a quick turnaround, and they were still popular even
before easy laser printing.
Not all projection slides were produced by photographing or copying a paper
document, and in fact this method was somewhat limited and tended not to work
well for color. By the '70s photosetting had become practical for the
production of printing plates directly from computers, and it was also used to
produce slides and transparencies. At the simplest, a photosetter is a computer
display with optics that focus the emitted light onto film. In practice, many
photosetters were much more complicated as they used shifting of the optics to
expose small sections of film at a time, allowing for photosetting at much
higher resolution than the actual display (often a CRT).
Donald Knuth originally developed TeX as a method of controlling a photosetter
to produce print plates for books, and some of TeX's rougher edges date back to
its origin of being closely coupled to this screen-to-film process. The
photosetting process was also used to produce slides direct from digital
content, and into the early '00s it was possible to send a PowerPoint
presentation off to a company that would photoset it onto Kodak slides.
Somewhere I have a bin of janitorial product sales presentations on slides that
seem to be this recent.
The overhead projector as a device was popular and flexible, and so it was also
leveraged for some of the first digital projection technology. In fact, the
history of electronic projection is long and interesting, but I am constraining
myself to devices often seen in corporate conference rooms, so we will leave
out amazing creations like the Eidophor. The first direct computer projection
method to become readily available to America's middle management was a device
sometimes called a spatial light modulator (SLM).
By the 1980s these were starting to pop up. They were basically transparent LCD
displays of about the right size to be placed directly onto the platen of an
overhead projector. With a composite video or VGA interface they could be used
as direct computer displays, although the color rendering and refresh rate
tended to be abysmal. I remember seeing one used in elementary school, along
with the 8mm projectors that many school districts held on to for decades.
All of these odd methods of presentation basically disappeared when the
"digital projector" or "data projector" became available. Much like our modern
projectors, these devices were direct computer displays that offered relatively
good image quality and didn't require any of the advanced preparation that
previous methods had. Digital projectors had their own evolution, though.
The first widely popular digital projectors were CRT projectors, which used a
set of three unusually bright CRT tubes and optics. CRT projectors offered
surprisingly good image quality (late-model CRT projectors are pretty
comparable to modern 3LCD projectors), but were large, expensive, and not very
bright. The tubes were often liquid cooled and required regular replacement at
a substantial cost. As a result, they weren't common outside of large meeting
rooms and theaters.
The large size, low brightness, and often high noise level of CRT projectors
made them a bit more like film projectors than modern digital projectors in
terms of installation and handling. They were not just screwed into the
ceiling, rooms would be designed specifically for them. They could weigh
several hundred pounds and required good maintenance access. All of this added
up to mean that they were usually in a projection booth or in a rear-projection
arrangement. Rear-projection was especially popular in institutional contexts
because it allowed a person to point at the screen without shadowing.
Take a close look at any major corporate auditorium or college lecture hall
built in the '70s or '80s and there will almost certainly be an awkward storage
room directly behind the platform. Originally, this was actually the projection
booth, and a transparent rear-projection screen was mounted in the wall in
between. Well-equipped auditoriums would often have both a rear projection and
front projection capability, as rear projection required mirroring the image.
Anything that came in on film would often be front-projected, often onto a
larger screen, because it was simpler and easier. Few things came in on film
that someone would be pointing at, anyway.
You may be detecting that I enjoy the archaeological study of 1980s office
buildings. We all need hobbies. Sometimes I think I should have been an
electrician just so I could explain to clients why their motor-variac
architectural lighting controller is mounted in the place it is, but then
they'd certainly have found an excuse to make me stop talking to them by that
The next major digital projection technology on the scene was DLP, in which a
tiny MEMS array of mirrors flip in and out of position to turn pixels on and
off. The thing is, DLP technology is basically the end of history here... DLP
projectors are still commonly used today. LCD projectors, especially those with
one LCD per color, tend to produce better quality. Laser projectors, which use
a laser diode as a light source, offer even better brightness and lifespan than
the short arc lamps used by DLP and LCD projectors. But all of these are
basically just incremental improvements on the DLP projection technology, which
made digital projectors small enough and affordable enough to become a major
presence in conference rooms and classrooms.
The trick, of course, is that as television technology has improved these
projectors are losing their audience. Because I am a huge dweeb I use a
projector in my living room, but it is clear to me at this point that the next
upgrade will be to a television. Televisions offer better color rendering and
brightness than comparably priced projection setups, and are reaching into the
same size bracket. An 85" OLED television, while fantastically expensive, is in
the same price range as a similarly spec'd projector and 100" screen (assuming
ALPR here for more comparable brightness/color). And, of course, the
installation is easier. But let me tell you, once you've installed an outlet
and video plate in the dead center of your living room ceiling you feel a
strong compulsion to use it for something. Ceiling TV?
So that's basically the story of how we get to today. Producing a "deck" for a
meeting presentation used to be a fairly substantial effort that involved the
use of specialized software and sending out to at least an internal print shop,
if not an outside vendor, for the preparation of the actual slides. At that
point in time, slides had to be "worth it," although I'm sure that didn't stop
all kinds of useless slides to impress people with stars on their shoulders.
Today, though, preparing visual aids for a presentation is so simple that it
has become the default. Hiding off to the side of slides is seen as less effort
than standing where people will actually look at you. And god knows that in the
era of COVID the "share screen" button is basically a trick to make it so
people don't just see your webcam video when you're talking. That would be
There are many little details and variations in this story that I would love to
talk about but I fear it will turn into a complete ramble. For example,
overhead based projection could be remarkably sophisticated at times. You may
remember the scene at the beginning of "The Hunt for Red October" (the film) in
which Alec Baldwin gives an intelligence briefing while unseen military aids
change out the transparencies on multiple overhead projectors behind
rear-projection screens. This was a real thing that was done in important
Slide projectors were sometimes used in surprisingly sophisticated setups. I
worked with a college lecture hall that was originally equipped with one rear
projection screen for a CRT projector and two front projection screens, both
with a corresponding slide projector. All three projectors could be controlled
from the lectern. I suspect this setup was rarely used to its full potential
and it had of course been removed, the pedestals for the front slide projectors
remaining as historic artifacts much like the "No Smoking" painted on the front
Various methods existed for synchronizing film and slide projectors with
recorded audio. A particularly well-known example is the "film strip" sometimes
used in schools as a cheaper substitute for an actual motion picture. Late
film strips were cassette tapes and strips of slides, the projector advanced
the slide strip when it detected a tone in the audio from the cassette tape.
Note 2: I have begrudgingly started using Twitter to ramble about the things
I spend my day on. It's hard to say how long this will last. https://twitter.com/jcrawfordor.
When we look back on the history of the graphical user interface, perhaps one
of the most important innovations in the history of computing, we tend to think
of a timeline like this: Xerox, Apple, Microsoft, whatever we're doing today.
Of course that has the correct general contours. The GUI as a concept, and the
specific interaction paradigms we are familiar with today, formed in their
first productized version at the Xerox Palo Alto Research Center (XPARC).
Their production version, the Alto, was never offered as a commercial product
but was nonetheless widely known and very influential. Apple's early machines,
particularly the Lisa and Macintosh, featured a design heavily inspired by the
work at XPARC. Later, Microsoft released Windows 3.11 for Workgroups, the first
one that was cool, which was heavily inspired by Apple's work.
In reality, though, the history of the GUI is a tangled one full of controversy
("inspired" in the previous paragraph is a euphemism for "they all sued each
other") and false starts. Most serious efforts at GUIs amounted to nothing, and
the few that survive to the modern age are not necessarily the ones that were
most competitive when originally introduced. Much like I have perennially said
about networking, the world of GUIs has so ossified into three major branches
(MacOS-like, Windows-like, and whatever the hell Gnome 3 is trying to be )
that it's hard to imagine other options.
Well, that's what we're about to do: imagine a different world, a world where
it's around the '80s and there are multiple competing GUIs. Most importantly,
there are more competing GUIs than there are operating systems, because
multiple independent software vendors (ISVs) took on the development of GUIs
on top of operating systems like CP/M and DOS. The complexities of a GUI, such
as de facto requiring multi-tasking, required that these GUIs substantially
blur the line between "operating system" and "application" in a way that only
an early PC programmer could love.
And that is why I love these.
Before we embark on a scenic tour of the graveyard of abandoned GUIs, we need
to talk a bit about the GUI as a concept. This is important to comprehend the
precedents for the GUI of today, and thus the reason that Apple did not prevail
in their lawsuit against Microsoft (and perhaps Xerox did not prevail in their
lawsuit against Apple, although this is an iffier claim as the Xerox vs. Apple
case did not get the same examination as Apple vs. Microsoft).
What is a GUI?
I believe that a fundamental challenge to nearly all discussions about GUIs is
that the term "GUI" is actually somewhat ill defined. In an attempt to resolve
this, I will present some terminology that might be a better fit for this
discussion than "GUI" and "TUI" or "graphical" and "command-line." In doing so
I will try to keep my terminology in line with that used in the academic study
of human-computer interaction, but despite the best efforts of one of my former
advisors I am not an HCI scholar so I will probably reinvent terminology at
The first thing we should observe is that the distinction between "graphics"
and "text" is not actually especially important. I mean, it is very important,
but it actually does not fundamentally define the interface. In my experience
people rarely think about it this way, but it ought to be obvious: libraries
such as newt can be used to create "gui-esque" programs in text mode (think of
the old Debian installer as an example), while there are graphical programs
that behave very much like textmode ones (think of text editors). Emacs is a
good example of software which blurs this line; emacs simultaneously has traits
of "TUI" and "GUI" and is often preferred in graphical mode as a result.
To navigate this confusion, I use the terms "graphics mode" and "text mode" to
refer strictly to the technical output mechanism---whether raster data or text
is sent to the video adapter. Think about it like the legacy VGA modes: the
selection of graphics or text mode is important to user experience and imposes
constraints on interface design, but does not fundamentally determine the type
of interface that will be presented.
What does? Well, that's a difficult question to answer, in part because of the
panoply of approaches to GUIs. Industry and researchers in HCI tend to use
certain useful classifications, though. The first, and perhaps most important,
is that of a functional UI versus an object-oriented UI. Do not get too tangled
in thinking of these as related to functional programming or OO programming,
as the interface paradigm is not necessarily coupled to the implementation.
A functional user interface is one that primarily emphasis, well, functions.
A command interpreter, such as a shell, is a very functional interface in that
the primary element of interaction is, well, functions, with data existing in
the context of those functions. On the other hand, a modern word processor is an
object oriented interface. The primary element of interaction is not functions
but the data (i.e. objects), the available functions are presented in the
context of data.
In a way, this dichotomy actually captures the "GUI vs TUI" debate better than
the actual difference between graphics and text mode. Text mode applications
are usually, but not always, functional, while graphical applications are
usually, but not always, object oriented. If you've worked with enough
special-purpose software, say in the sciences, you've likely encountered a
graphical program which was actually functional rather than object oriented,
and found it to be a frustrating mess.
This has a lot to do with the discovery and hiding of functionality and data.
Functional interfaces tend to be either highly constrained (e.g. they are only
capable of a few things) or require that the bulk of functionality be hidden,
as in the case of a typical shell where users are expected to know the
available functions rather than being offered them by the interface. Graphical
software which attempts to offer a broad swath of functionality, in a
functional paradigm, will have a tendency to overwhelm users.
Consider the case of Microsoft Word. I had previously asserted that word
processors are usually an example of the object oriented interface. In
practice, virtually all software actually presents a blend of the two
paradigms. In the case of Word, the interface is mostly object-oriented, but
there is a need to present a large set of commands. Traditionally this has been
done by the means of drop-down menus, which date back nearly to the genesis of
raster computer displays. This is part of the model or toolkit often called
WIMP, meaning Windows, Icons, Menus, Pointer. A very large portion of graphics
mode software is WIMP, and the WIMP concept today is exemplified by many GUI
development toolkits which are highly WIMP-centric (Windows Forms, Tk, etc).
If you used Office 2003 or earlier, you will no doubt remember the immense
volume of functionality present in the menu bar. This is an example of the
feature or option overload that functional interfaces tend to present unless
functionality is carefully hidden. It makes an especially good example because
of Microsoft's choice in 2007 to introduce the "ribbon" interface. This was a
remarkably controversial decision (for the same reason that any change to any
software ever is controversial), but at its core it appears to have been an
effort by Microsoft to improve discoverability of the Office interface through
contextual hiding of the menus. Essentially, the ribbon extends the object
oriented aspect of the interface to the upper window chrome, which had
traditionally been a bastion of functional (menu-driven) design.
Menu-driven is another useful term here, although I tend to prefer "guided" as
a term instead (this is a term of my own invention). Guided interfaces are
those that accommodate novice or infrequent users by clearly expressing the
available options. Very frequently this is by means of graphical menus, but
there are numerous other options, one of which we'll talk about shortly. The
most extreme form of a guided interface is the wizard, which despite being
broadly lambasted for Microsoft's particularly aggressive use in earlier
Windows versions has survived in a great deal of contexts. A much more relaxed
form would be the "(Y/n)" type hints often shown in textmode applications.
"Abort, Retry, Fail?," if you think about it, is a menu . This guidance is
obviously closely related to discoverability, basically in the sense that
non-guided interfaces make little to no attempt at discoverability (e.g. the
Another useful term is the direct manipulation interface. Direct manipulation
is a more generalized form of WYSIWYG (What You See Is What You Get). Direct
manipulation interfaces are those that allow the user to make changes and
immediately see the results. Commonly this is done by means of an interface
metaphor in which the user directly manipulates the object/data in a fashion
that is intuitive due to its relation to physical space . For example,
resizing objects using corner drag handles. Direct manipulation interfaces are
not necessarily WYSIWYG. For example, a great deal of early graphics and word
processing software enabled direct manipulation but did not attempt to show
"final" output until so commanded (WordPerfect, for example).
This has been sort of a grab basket of terminology and has not necessarily
answered the original question (what is a GUI?). This is partially a result
of my innate tendency to ramble but partially a result of the real complexity
of the question. Interfaces generally exist somewhere on a spectrum from
functional to object-oriented, from guided to un-guided, and in a way from
text mode to graphics mode (consider e.g. the use of Curses box drawing to
replicate dialogs in text mode).
My underlying contention, to review, is this: when people talk about "GUI vs
TUI," they are usually referring not to the video mode (raster or text) but
actually to the interface paradigm, which tends to be functional or object
oriented, respectively, and unguided or guided, respectively. Popular
perceptions of the GUI vs. TUI dichotomy, even among technical professionals,
are often more a result of the computing culture (e.g. the dominance of the
Apple-esque WIMP model) than technical capabilities or limitations of the two.
What I am saying is that the difference between GUI and TUI is a cultural
Interface Standardization: CUA
In explaining this concept that the "GUI vs TUI" dichotomy is deeper than the
actual video mode, I often reach out to a historic example that will be
particularly useful here because of its importance in the history of the
GUI---and especially the history of the GUIs we use today. That is IBM
Common User Access, CUA.
CUA is is not an especially early event in GUI history but it's a formative one,
and it's useful for our purposes because it was published at a
time---1987---when there were still plenty of text-only terminals in use. As
a result, CUA bridges the text and raster universes.
The context is this: by the late '80s, IBM considers itself a major player
in the world of personal computers, in addition to mainframes and mid/minis.
Across these domains existed a variety of operating systems with a variety of
software. This is true even of the PC, as at this point in time IBM is
simultaneously supporting OS/2 and Windows (2). While graphical interfaces
clearly existed for these systems, this was still an early era for raster
displays, and for the most part IBM still felt text mode to be more important
(it was the only option available on their cash cow mainframes and minis).
Across operating systems and applications there was a tremendous degree of
inconsistency in basic commands and interactions. This was an issue in both
graphical and textual software but was especially clear in text mode where
constraints of the display meant that user guidance was usually relatively
minimal. We can still clearly see this on Unix-like operating systems where
many popular programs are ported from historical operating systems with
varying input conventions (to the extent they had reliable conventions),
and few efforts have been made to standardize. Consider the classic problem
of exiting vim or emacs: each requires a completely different approach with
no guidance. This used to be the case with essentially all software.
CUA aimed to solve this problem by establishing uniform keyboard commands and
interface conventions across software on all IBM platforms. CUA was developed
to function completely in text mode, which will be somewhat surprising
considering the range of things it standardized.
The most often discussed component of CUA is its keyboard shortcuts. Through a
somewhat indirect route (considering the failure of the close IBM/Microsoft
collaboration), CUA has been highly influential on Windows software. Many of
the well-known Windows keyboard commands come from CUA originally. For example,
F1 for help, F3 for search, F5 to refresh. This is not limited just to the F
keys, and the bulk of common Windows shortcuts originated with CUA. There are,
of course, exceptions, with copy and paste being major ones: CUA defined
Shift+Delete and Shift+Insert for cut and paste, for example. Microsoft made a
decision early on to adopt the Apple shortcuts instead, and those are the
Ctrl+C/Ctrl+V/Ctrl+X we are familiar with today. They have been begrudgingly
adopted by almost every computing environment with the exception of terminals
and Xorg (but are then re-implemented by most GUI toolkits).
The keyboard, though, is old hat for text mode applications. CUA went a great
deal further by also standardizing a set of interactions which are very much
GUI by modern standards. For example, the dialog box with conventional options
of "OK" and "OK/Cancel" come from CUA, along with the ubiquitous menu sequence
of File first and Help last.
While being graphical by modern standards these concepts of drop-down menus and
dialog boxes were widely implemented in text mode by IBM. From a Linux
perspective, this is rarely seen and would likely be a bit surprising. Why is
I contend that there is a significant and early differentiation between IBM
and UNIX interfaces that remains highly influential today. While today the
dichotomy is widely viewed as philosophical, at the time it was far more
UNIX was developed inside of AT&T as a research project and then spread
primarily through universities and research organizations. Because it was
viewed primarily as a research operating system, UNIX was often run on whatever
hardware was available. The PDP-11, for example, was very common. Early on,
most of these systems were equipped with teletypewriters and not video
terminals. Even as video terminals became common, there were a wide variety
in use with remarkably little standardization, which made exploiting the
power and flexibility of the video terminal very difficult. The result is that,
for a large and important portion of its history, UNIX software was built
under the assumption that the terminal was completely line-oriented... that
is, no escape codes, no curses.
IBM, on the other hand, had complete control of the hardware in use. IBM
operating systems and software were virtually always run on both machines and
terminals that were leased from IBM as part of a package deal. There was
relatively little fragmentation of hardware capabilities and software
developers could safely take full advantage of whatever terminal was standard
with the computer the software was built for (and it was common for software to
require a particular terminal).
For this reason, IBM terminal support has always been more sophisticated than
UNIX terminal support. At the root was a major difference in philosophy. IBM
made extensive use of block terminals, rather than character terminals.
For a block terminal, the computer would send a full "screen" to the terminal.
The terminal operated independently, allowing the user to edit the screen,
until the user triggered a submit action (typically by pressing enter) which
caused the terminal to send the entire screen back to the computer and await
a new screen to display.
This mechanism made it very easy to implement "form" interfaces that required
minimal computer support, which is one of the reasons that IBM mainframes
were particularly prized for the ability to support a very large number of
terminals. In later block terminals such as the important 3270, the computer
could inform the terminal of the location of editable fields and even specify
basic form validation criteria, all as part of the screen sent to the terminal
Ultimately, the block terminal concept is far more like the modern web browser
than what we usually think of as a terminal. Although the business logic is all
in the mainframe, much of the interface/interaction logic actually runs locally
in the terminal. Because the entire screen was sent to the terminal each time,
it was uniformly possible to update any point on the screen, which was not
something which could be assumed for a large portion of UNIX's rise to
As a result, the IBM terminal model was much more amenable to user guidance
than the UNIX model. Even when displaying a simple command shell, IBM terminals
could provide user guidance at the top or bottom of the screen (and it was
standard to do so, often with a key to toggle the amount of guidance displayed
to gain more screen space as desired). UNIX shells do not do so, primarily for
the simple reason that the shells were developed when most machines were not
capable of placing text at the top or bottom of the screen while still being
able to accept user input at the prompt.
Of course curses capabilities are now ubiquitous through the magic of every
software terminal pretending to be a particularly popular video terminal from
1983. Newer software like tmux usually relied on this from the start, and older
mainstays like vi have had support added. But the underlying concept of the
line-oriented shell ossified before this happened, and "modern" terminals like
zsh and fish have made only relatively minor inroads in the form of much more
interactive assisted tab completion.
IBM software, on the other hand, has been offering on-screen menus and guidance
since before the C programming language. Well prior to CUA it was typical for
IBM software to use interactive menus where the user selects an option,
hierarchical/nested menus, and common commands via F keys which were listed
at the bottom of the screen for the user's convenience.
While many IBM operating systems and software packages do offer a command line,
it's often oriented more towards power users and typical functions were all
accessible by a guided menu system. Most IBM software, especially by the '80s,
provided an extensive online help facility where pressing F1 retrieved
context-aware guidance on filling out a particular form or field. Indeed, the
CUA concept of an interactive help system where the user presses a Help icon
and then clicks on a GUI element to get a popup explanation---formerly common
in Windows software---was a direct descendent of the IBM mainframe online help.
The point I intend to illustrate here is not that IBM mainframes were
surprisingly sophisticated and cool, although that is true (IBM had many
problems but for the most part the engineering was not one of them).
My point is that the modern dichotomy, debate, even religious war between the
GUI and TUI actually predates GUIs. It is not a debate over graphical vs text
display, it is a debate over more fundamental UI paradigms. It is a fight of
guided but less flexible interfaces versus unguided but more powerful ones.
It is a fight of functional interfaces versus object oriented ones. And perhaps
most importantly, it is a competition of "code-like" interfaces versus direct
What's more, and here is where I swerve more into the hot take lane, the
victory of the text-mode, line-oriented, shell interface in computer science
and engineering is not a result of some inherent elegance or power. It is an
artifact of the history of computing.
Most decisions in computing, at least most meaningful ones, are not by design.
They are by coincidence, simultaneously haphazard but also inevitable in
consideration of the decades of work up to that point. Abstraction, it turns
out, is freeing, but also confining. Freeing in that it spares the programmer
thinking about the underlying work, but confining in that it pervasively, if
sometimes subtly, steers all of us in a direction set in the '60s when our
chosen platform's lineage began.
This is as true of the GUI as anything else, and so it should be no surprise
that IBM's achievements were highly influential, but simultaneously UNIX's
limitations were highly influential. For how much time is spent discussing the
philosophical advantages of interfaces, I don't think it's a stretch to say
that the schism in modern computing, between the terminal and everything else,
is a resonating echo of IBM's decision to lease equipment and AT&T's decision
to make UNIX widely available to academic users.
Some old GUIs
Now that we've established that the history of the GUI is philosophically
complex and rooted in things set in motion before we were born, I'd like to
take a look at some of the forgotten branches of the GUI family tree: GUI
implementations that were influential, technically impressive, or just weird.
I've already gone on more than enough for one evening, though, so keep an eye
out for part 2 of... several.
 It is going to take an enormous amount of self-discipline to avoid turning
all of this into one long screed about Gnome 3, perhaps the only software I
have ever truly hated. Oh, that and all web browsers.
 Menus in text mode applications are interesting due to the surprising lack
of widespread agreement on how to implement them. There are many, many
variations across commonly used software from limited shells with tab
completion to what I call the "CS Freshman Special," presenting a list of
numbered options and prompting the user to enter the number of their choice.
The inconsistency of these text mode menus get at exactly the problem IBM was
trying to solve with CUA, but then I'm spoiling the end for you.
 This is a somewhat more academic topic than I usually verge into, but it
could be argued and often is that graphical software is intrinsically
metaphorical. That is, it is always structured around an "interface metaphor"
as an aid to users in understanding the possible interactions. The most basic
interface metaphor might be that of the button, which traditionally had a
simple 3D raised appearance as an affordance to suggest that it can be pressed
down. This is all part of the puzzle of what differentiates "GUI" from "TUI":
graphical applications are usually, but not always, based in metaphor. Textmode
applications usually aren't, if nothing else due to the constraints of text,
but it does happen.
 This did lead to some unusual interaction designs that would probably not
be repeated today. For example, in many IBM text editors an entire line would
be deleted (analogous to vim's "dd") by typing one or more "d"s over the line
number in the left margin and then submitting. The screen was returned with
that line removed. This was more or less a workaround for the fact that the
terminal understood each line of the text document to be a form field, and so
there was some jankiness around adding/removing lines. Scrolling similarly
required round trips to the computer.