Advent of Computing - Episode 85 - Visi On, the PC GUI

Episode Date: June 26, 2022

More Visi-fun ahead! Today we are looking at Visi On, a visionary user interface developed for home computers. Along the way we will discuss smalltalk, portability, and how the slick graphics over at Xerox were adapted to run on smaller machines.   Selected Sources:   http://toastytech.com/guis/vision.html - Toasty Tech's Visi On page, with screenshots and downloads for emulation   https://archive.org/details/byte-magazine-1983-06/page/n255/mode/2up - A Guided Tour of Visi On   https://archive.org/details/RosettaSmalltalkACM1979/mode/1up - Rosetta Smalltalk  

How would you make a computer more accessible? How would you make a machine easier to use in general? Luckily, we don't have to answer that question in the dark. We actually have a very rich tradition of attempts to draw from. Some attempts, if you can believe it, have actually been successful. The standard we've all become accustomed to is simply called WIMP. Windows, Icons, Menus, and Pointer. The last one isn't plural, crucially.

There have been many attempts to, quote, move past WIMP, but those tend to not move very far forward. Part of this is probably historical baggage that hinders change, and part of it is the fact that WIMP just kind of works. It's simple to use, easy to understand, and relatively robust. It might be the bare minimum needed for an easy-to-use computer. WIMP first shows up in the 70s at Xerox. At least, that's when the full package first comes together in a recognizable way. There are, of course, earlier examples of pieces of the puzzle, but staying firm, 70s, Xerox, we get WIMP. At the time, these fancy graphical interfaces were so complicated that they took custom hardware and really meticulous, really, frankly, clever programming.

But that's not very accessible. No, rather, for this new paradigm to do any good, it had to get into the home. Something about a computer on every desk springs to mind. Of course, the jump to the desk would take a few passes to get right. Most big changes do. But what was the actual spark that made the GUI and WIMP interfaces in general drop down to microcomputers? We can say that, you know, accessible computers would be nice. It's part of the tides of change. But that's not a very satisfying answer. What we

need are specifics. What we need is a case study. For that, I would like to present VisiCorp's Vizion. Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 85, Vizion, the PC GUI. Today, we're going to be building on the background established in the last episode. Last time, we took a look at the rise, coast, and fall of VisiCalc, the first computer spreadsheet program and what some would call the first killer app. While today's discussion isn't a direct continuation,

the story of VisiCalc is important to establishing background that will inform the development of Vizion. It's a little bit weird because they're not really connected software, but they're all in the same soup. So, as per usual, part one isn't totally necessary to enjoy this part, but I recommend it to maybe increase your enjoyment a little bit. Now, before we get started, I have two quick announcements to make, and these are actually the same announcements from last episode. The first is that I still have a poll for the next bonus episode up over on Patreon. That's going to be an episode released in July for patrons only. That's going to be an episode released in July for patrons only.

Right now, the lead is a certain very obscure programming language that may or may not be related to Lisp. I swear, for whatever reason, my patrons seem to be masochists for weird programming languages. So, if you want to get in on that poll, then head on over. It should be up for another week or so after this episode drops. The second announcement and one that is a little more urgent time-wise is that I'm going to be a keynote speaker at the ACM's Human 2022 workshop. That's on the 28th, so right after this episode drops. That's held in Barcelona, Spain, and also virtually. You can find information from some links that I'm posting all over my social media right now,

or just look up ACM Human 22. That's going to be starting in the afternoon in Barcelona. In my time, it's very early in the morning. You can get tickets to attend the whole conference or just the workshop online. I'm going to be giving a talk about Engelbart, early links, and edge-notch cards, which I think will be pretty cool to see. Anyway, let's get back to the topic at hand.

Vizion has always been a point of fascination for me. I first learned about Vizion in my high school computer lab. You see, at home, I only had dial-up internet. So when I had free time at school, I'd surf the net and download any large files I could find for later use and enjoyment. One of my absolute favorite sites was toastytech.com. You might have visited it if you're the same kind of computer nerd that I am. This is one of those personal websites, the type that was common prior to the rise of the internet's current monoculture. That's a separate discussion, but suffice to say, Telsy Tech was pretty cool.

What made this personal website so cool to my young self, you may ask? Simple. The Graphical User Interface Gallery. The site's admin has built up this entire section to show off screenshots of old operating systems. Each page is complete with a short description of the system and commentary on each screenshot. Everything's categorized by manufacturer and even capped in a nice timeline. Plus, the site has links to disk images and emulators that can run most of the featured operating systems. That was a huge draw for me, especially when I was able to get onto a broadband connection. The most revered system on the entire site, and the one that captivated me the most was always Vizion.

The site's admin, the mysterious Nathan, sang Vizion's praises on the main page of the GUI gallery. Unlike most of the other operating systems, Toasty Tech actually hosted copies of Vizion's install disks, available for direct download. As far as I was concerned, that enshrined Vizion as a cut above the rest. You wouldn't use precious disk quota for just any old software, right? The provenance of Vizion was also fascinating to me. It was made by a spreadsheet company, of all things. It predated any other graphical system for home computers. It technically made public appearances on microcomputers before any competition. It handily predates Windows and, I guess, technically predates the Apple Lisa.

That's a little bit confusing, though. We'll get back to the timeline once again later on. But despite that, it looked really close to modern operating systems. Sure, there are quirks. There's always bound to be quirks, but they never looked awful to me. It's more like a soft patina than an intrusive rust. To put the final touch on my obsession, when I first found out about Vizion, it wasn't easy to emulate. The operating system has very particular hardware requirements. It needs specific types of mice, specific processor specs. It even has strange copy protection. I spent way too long trying to

make my own install disks and get it running on a physical machine. I even found a mouse that, in theory, should have been compatible. It was only years later that I was able to get Vizion running in an emulator for myself. And personally, I think it was worth the wait. Vizion presents a captivating approach to the new graphical era. It's a stepping stone that many other operating systems had to tread on to succeed. And just to sweeten the pot, there's the possible Windows 1.0 connection. a stepping stone that many other operating systems had to tread on to succeed. And just to sweeten the pot, there's the possible Windows 1.0 connection.

According to folklore, Vizion directly inspired the development of Windows. Now, that's a story that may or may not be true, but I think it's too good to pass up investigating. There's going to be a lot of ground to cover here. The big picture question in this episode will be, how did the GUI come over to home computers? But tucked inside, we have a lot of little specifics to tackle. How did VisiCalc, a spreadsheet program, pave the way for this type of transition? Once we get to Vizion, how does it stack up to other graphical systems? And finally, what's the whole deal with the Windows 1.0 connection anyway? We're starting off in what Dan Bricklin, co-creator of VisiCalc, calls the Middle Days.

This is when VisiCorp was at its zenith, we're talking roughly around 1981 or so. At the time, VisiCalc was running on every home computer under the sun. What started on the Apple II had expanded, eventually reaching even the IBM PC. This spread was made all the better thanks to the soon-to-explode PC clone market. The overall market cap for VisiCalc was the entire home computer market. It must have been hard for VisiCorp to imagine anything but growth. When VisiCalc launched, Bricklin and Bob Frankston, the other mind behind the program, were working out of a basement office. In 1979, they moved to a more official office in downtown Cambridge, Massachusetts. That office would expand and expand until they occupied an entire floor of a high-rise.

VisiCorp was ascendant, flush with cash, and ready to court new projects. This is where the company kind of got weird with it. VisiCalc had been such a huge success that it created an entire new kind of software. So why not repeat that? Why not create all kinds of office productivity software? These new programs broadly fell into two camps. Software that could roughly complement VisiCalc and new office software that was meant to compete with existing products. Of course, each program came packed with the Visi prefix, so sometimes the software is just called VisiSoftware or VisiPrograms. Now, this isn't to say that there was some grand unified plan here. From what I've read, it sounds like the cadre

of Visi programs weren't well coordinated. The programs that could share data with VisiCalc did so via a somewhat awkward mechanism, the Data Interchange Format, or DIF. VisiCalc had a native file format, one which is actually very well documented. It was meant to be somewhat usable outside of VisiCalc, at least a little bit. You can actually find old articles about parsing VisiCalc sheets in BASIC. This feature, if we can call it that, falls into the cool-but-hacky category. The official way to shuttle data around was with diff files. VisiCorp was so into this format that they would even start publishing it as a standard.

What made diff so nice, at least in theory, is the fact that it was a fully textual data format. VisiCalc had initially dropped data into binary files, which, while nice for VisiCalc, can kind of suck to deal with. Diff files were just text. You had a header describing the kind of data, followed by the data itself. Simple, easy to handle, and easy to standardize around. Internally, the plan was to use diff as a way to pass VisiCalc data to other Visi programs. The most high profile of these was probably VisiTrend slash Plot.

Now, we don't really have information on the development history of this program. The same will be true for many ancillary programs in this story. This is one of those times where we must indulge in history via reference manual. Trend slash plot was a weird bundle of two programs, Vizzy Trend and, perhaps in a shocking upset, Vizzy Plot. I know that at least Vizzy Plot was sold separately from this bundle on some platforms at some point, so it's all nice and confusing brand-wise. The overall point of this package was that you could take your spreadsheets, massage the data a little bit, and get plots and projections. VisiCalc on its own couldn't do

any sort of fancy graphics. It was just a nice souped-up text mode application, after all. It also couldn't do complicated things like regressions automatically. Sure, you could build up a sheet that could do forecasts, but that'd be a lot of work. These programs could also work on their own native data. In theory, you didn't even need VisiCalc to make plots, but I think it's pretty clear that in practice, TrendPlot was meant to fill in some of VisiCalc's missing features, but, you know, not in some nice integrated way. TrendPlot was still a totally separate program. It was purchased separately and used separately. You had to do a three-step process of opening VisiCalc, exporting data, and then

opening TrendPlot to actually get, well, trends or plots. Definitely workable, but we can do better. The other broad category of Visi stuff was all the random office software that wasn't directly connected to spreadsheets. This is where we run into such timeless classics as VisiWord, VisiFile, VisiSchedule, and, of course, VisiSpell. Now, there's not a whole lot exciting here. These are pretty run-of-the-mill office products. These are pretty run-of-the-mill office products. Vizzy Word, for instance, is just a word processor. It looks for all the world like any other text editor out there.

Crucially, this was hitting shelves after other word processors were in existence. This whole slate of Vizzy programs weren't exactly innovations, they were more an attempt to cash in on the Visi brand. Just slap the name on, and if someone's used VisiCalc, then of course they can get the rest of the package deal. So that's the rough position that VisiCorp was in after this initial boom. They were comfortable and trying to spread out to offer a larger set of office software. On its own, that's a fine strategy. There's nothing earth-shattering here. It's just fine. I think that's the best way to characterize this period before things really start getting weird. Now, there was a drive to do more. For that drive to make sense, we need to introduce another computer that came to market in 1981.

The Xerox 8010 Information System, better known as the Xerox STAR. The STAR was Xerox's second generation graphical computer. Back in the earlier part of the 70s, Xerox had developed a machine called the Alto at PARC, their Palo Alto Research Center. The Alto was never commercially successful, but would become one of the most influential and forward-thinking machines ever built. It was the first machine built from the ground up to use a mouse. Its standard output was a black and white bitmapped graphics display. It even had Ethernet back when the protocol was just being developed. The Alto was technically designed as a tool for desktop publishing, but that's just a cover story.

This machine was really a testbed for new technology, for personal computing, and for graphical user interfaces, or GUIs. As such, the Alto didn't have much polish. It was more like a collection of ideas than a coherent product. But there was promise there. One of the most exciting programs on the machine was Smalltalk. Now, this can get a little confusing. Smalltalk on the Alto was a programming language and an environment and a user interface all wrapped into one. When you see big glossy photos of the Alto running a desktop environment that looks kinda modern, that's Smalltalk.

So, what's special about this language mashup? The biggest line item is the fact that Smalltalk is object-oriented. That's the big language feature that most programmers will mention, even if they only have a passing familiarity with Smalltalk. In this context, an object is a special data type. Each object is defined by some class which specifies what types of data the object contains. A cat class, for instance, might specify that a cat has four legs, a tail, a head, and it can meow and eat food. You can then use that class definition to create a new cat object. Some of its properties, like its little legs, are just normal variables. Other properties, like its powerful meow, are actually functions that can be invoked. That's the really generic

thousand-foot view of object-oriented programming. Smalltalk itself puts a bit of a twist on the usual formula. An object in Smalltalk can technically only send and receive messages. This is a small and a subtle difference, but it has some important implications. If you have a Smalltalk cat object, let's say, you wouldn't just grab it by the tail. That's rude. You have to use Smalltalk as intended. Instead, you'd send a message asking for its tail. It could then reply with a message containing its tail. Maybe a bit of a macabre example here, but let's just stick with it for now. This ends up being a very practical platform for graphical systems. This message passing system is fantastic for classes that may or may not have responses

to certain commands. Let's say you pass a message to the cat asking it to bark. The cat object will get the message and see, yeah, I don't know how to bark. So instead of responding or trying to do something, it just does nothing. In most other languages, if you try to make a cat bark, you get some kind of error. But in small talk, you get to choose how a message is handled. You can also choose just not to handle it. Now, let me get a little more concrete. Let's say you have a class for a button and a button object on the screen. When you go to click it, you have some fancy code that will send it a message to the effect of, you got clicked, deal with that. Your higher level

code here doesn't care what happens when the button is clicked. All it has to do is dispatch the message. The button receives that message and then does whatever it needs to do in order to handle the event. That can range from animating the press, to firing off some of its own code, to doing nothing. The actual smarts here is embedded in such a way that you can easily add as many buttons as you want.

Each does its own thing without changing the larger system. You don't have to have any special cases, and that's really a powerful way to program. The Alto Smalltalk system leveraged this to create a consistent and easy to program user interface. The consistency part here is really nice. You just need to build up a library of classes for useful user interface elements. Buttons, menus, windows, pointer, perhaps, text boxes, and so on. Any element that a programmer will need to use. When it comes time to program, you just grab those classes,

fill out some details for what each specific element does. You find a spot on the screen and boom. This way, every program will have buttons that look the same and act the same. They might have different details on what actions occur when you press them, but you get this nice unified view. That goes a long way towards creating a comprehensible system. Despite this slick programming and some slick hardware to back it up, the Alto remained a behind-the-scenes kind of success.

Programmers and computer nerds seemed to like it, but the Alto didn't make inroads in the market. This is where the Xerox Star comes in. The Star was Xerox's attempt to adapt the Alto's technology into a workable product. The target was simple. The Star would offer a complete integrated office environment. Everything you needed to do in an office, from word processing to typesetting to filing data to analysis, would be handled from the star's unified graphical interface. Now, there's also a possible connection here that I have to deal with. Fumbling the Future,

a wonderful book by Douglas Smith and Robert Alexander, chronicles how Xerox got really close to dominating the home computer market. There's a passage in the latter part of the book that gives oblique reference how VisiCalc was such a big deal because it targeted non-computer users like managers and C-level folk. So there's this implication that maybe, maybe, VisiCalc had an impact over it in Xerox, right? This is one of those really tempting trains of thought, and also pretty hard to look into. Hence why I wanted to address it here. This question actually becomes a bit of a mess. Initially, the star shipped without a spreadsheet. It seems like that was remedied pretty early on, but I'm not sure of the exact date.

The specifics of the star's onboard software are a little muddy. The implication I've seen around the net, and particularly in the article The Xerox Star, a Retrospective, is that a spreadsheet was added after customer complaints. I 100% believe that, but I've had a hard time finding any contemporary articles that complain specifically about the star lacking a spreadsheet. So I would like to caution against calling VisiCalc an inspiration for Xerox. It's much more likely that VisiCalc shaped the office market while the star was trying to get its footing. Also, just to be 100% clear, I'm not knocking Fumbling the Future.

It's a great book I recommend you reading. Just when I hit that passage, it kind of got my gears spinning in a weird way. Development of Vizion started in early 1981. This is right in the middle of this tableau of new Xerox hardware, an influx of cash at VisiCorp, and a growing pile of Visi programs. The overall plan was, once again, simple. Create a unified platform for VisiCorp products to live inside. Seems like that couldn't be very hard, but that very simple goal can be deceiving. Vizion would become a complex and very powerful system in no time flat. In 1983, William Cullman, the manager of the Vizion project, was interviewed for an

article in Byte titled, A Guided Tour of Vizion. That's a bit of a misleading name. The interview deals with Vizion's internals and the system in general, but a large section is devoted to the software's development history. This is probably one of the best peeks behind the Visi-Curtain I've been able to find. Coleman explains that the overall plan was to hit three targets. The appearance of multitasking, ease of learning, and the ability to transfer information between programs. This first goal, I think at least, is pretty fun to think about. The new system, initially called Project Quasar, but really quickly renamed to Vizion,

was going to be a multitasking operating system. There would be threads running in the background to handle things like device drivers and file operations and even the mouse. When it came to actual programs, actual office applications, that part wasn't technically a multitasking environment. Users would have one program running at a time, but set up in some kind of windowed environment so it looked like more than one program was running. Users could switch between, say, a spreadsheet and a text editor with ease, but each program would only be running code when the user was actually interacting with it. A spreadsheet in the background wouldn't keep crunching numbers, for instance. Goal two, ease of learning, is just a different phrasing of a

really common goal during this era, an accessible user interface. I think this was an attempt to recapture some of the magic of VisiCalc. Anyone could learn to use that spreadsheet with relative ease. That was what made VisiCalc such a big deal for the time. It could target more than just computer nerds. Vizion was going to take a pass at that same wide market segment. And finally, we have goal three. Easy inter-program data transfers. This is almost a direct response to the whole diff woes that VisiCorp was facing.

An integrated office should be just that, integrated. You should be able to copy and paste data between applications. That could include moving graphs into a text document, copying numbers from a word processor into a spreadsheet, or any permutation you can think of. This kind of interoperability would only be possible in a system that can actually run more than one program at once, or at least a system that can pretend to multitask. We can see an overlap of goals building up here. So how would the system be built? Well, that gets much more complicated. In general, the secret sauce would be well-structured and well-designed software. The specifics take us back to Smalltalk. You see, there was a specific reason I brought up

Smalltalk earlier. It wasn't just to give a nice example of how Xerox was doing things. Smalltalk was crucial to the development of Vizion. To be 100% clear, Vizion wasn't written in Smalltalk itself. It actually used a combination of C and assembly language. But it would take many cues from Xerox's favorite language. Vizion went through a number of design stages. Coleman lists four in total, ranging from an initial design doc to a prototype, and then on to the final product. Sometime during this cycle, VisiCorp brought in outside help from a small company called

Rosetta. Now, this is part of the story where we're missing a little bit of connective tissue. We know that at least one employee from Rosetta was brought in to design Vizion. We know why they were brought in, at least roughly, but we don't have the full story. What we can say is that sometime early on in Vizion's development, maybe as early as 1981, but at least by 1982, Vizicorp hired Scott Warren and maybe one of his co-workers named Dennis Abe. I know, this is some nice detail here. The reason for this connection all comes down to small talk. Specifically, Warren and Abe may have been some of the first people working with the language outside Xerox. This is one of those fascinating but barely documented chapters in digital history.

Here's the best telling I can give. Sometime in the late 70s, Warren got his hands on a few research papers discussing this new language called Smalltalk. The full language spec wouldn't be released until 1980, but there was enough in academic journals to piece something together. was enough in academic journals to piece something together. Warren figured it should be possible to create an implementation of small talk for, well, smaller computers. You could call it small small talk if you're a little creative. Warren and Abe called this new version of the language Rosetta Small Talk. Once again, this is where we have some known unknowns. This language first shows up in a 1979 paper published with the ACM. That has both Warren and Abe as authors. However, the only other source we can go off here is the old Rosetta website,

which appears to basically be Warren's personal webpage. There's no mention of Abe on there, so the second author may have been somewhat disconnected from the project early on. Back to what we do know. Rosetta Smalltalk was an impressive piece of code. Alan Kay, one of the minds behind the original Smalltalk at Xerox, even found it remarkable. From an archived email thread,

This was an excellent redesign and implementation of Smalltalk 72, even found it remarkable. From an archived email thread, quote, this was an excellent redesign and implementation of Smalltalk72, i.e. instead of being slavish to what we had done at Park and making a literal copy, they came up with a very interesting set of improvements to Smalltalk72, most of which really helped the end user. End quote. So it may be better to think of Rosetta as a language and an environment inspired by small talk. At the time, programmers at Xerox were bashing bits on relatively powerful machines. The Alto, for instance, used a totally custom processor built up from small logic chips. It was a very custom and very impressive device. Rosetta targeted Z80 computers. There's a slight disparity in power here, to say the least. The system described in the 79 Rosetta paper is, essentially, a stripped-down

version of the Altos environment. This is complete with classes and objects, threading and windows, even a cursor. The paper provides screen grabs showing multiple windows, each with their own separate data. Windows can even overlap. Impressive indeed. Like with the larger version of Smalltalk, Rosetta is all about message passing. It benefits from all the same encapsulation and reusability that made the Alto so impressive. The 79 paper gives more than just an overview of the language and its fancy UI. It also goes into detail on the thinking behind the system. This is where we see an interesting connection starting

to form. Warren and Abe don't just position Rosetta's small talk as some fancy new programming environment, but an integrated tool that can be used to make a computer more useful. To quote, Imagine a personal computer that could store, retrieve, and edit almost any information that its owner was interested in. Notes, drafts of papers, phone lists, structured files of data, pictures, simulations, music, and so on. Suppose it could be used as an interactive desktop calculator for any problem domain. How could the user, not a computer specialist, cope with the immense variety of data formats, language rules, and processing conjunctions found among so many diverse application packages?

End quote. The solution that Warren and Abe settled on was to adapt Smalltalk to the task. This is an approach we've already seen, using object-oriented programming to generate consistent interfaces and then applying that to the problem of integrated software environments. Creating a full office in a single digital box. This is exactly what the Xerox Star was supposed to do, and it's exactly what Physicorp was looking for. There are a few more details in the Rosetta Smalltalk paper as to why Smalltalk made such an exciting option for this specific task. This is actually given in a list, which I'm going to consolidate a little bit for our purposes. First off, Smalltalk provides a conversational and

interactive interface. This point on its own is where we see a big difference between contemporary home computing and the Smalltalk approach. The most visible contributing factor here is Rosetta Smalltalk's windows. That's right, despite targeting such small hardware, Rosetta was a fully windowed environment. From the screenshots I've seen, this looks like it was probably rendered using special text characters, if anyone knows better than I'd love to be proven wrong. The user was presented with a series of overlapping windows, each containing their own data.

The big benefit here, and the benefit to these graphical environments in general, was an increase in productivity. By presenting separate programs in separate windows, it was now possible to do two things at once in a very visual way. You could have a window up showing a graph and a separate window up displaying a program, maybe another for data. What makes this all the more interesting, and something that we'll get back to a bit later, is this concept of illusion.

I know I've said this before when talking about timesharing. Illusion is a key tactic for making computers more useful. The trick in timesharing is to have a computer switch between tasks so rapidly that us slow humans can't tell what's going on. It gives the appearance that more than one program is running at the same time. But that has a limiting factor, and I don't mean technically. Old school timesharing systems used text-based interfaces. So yeah, you could have multiple people using a machine. You could have a programmer running in the background. But you couldn't easily switch

between your text editor and a debugger, for instance. Even in a system like Unix, you have to memorize keystrokes to do that kind of multitasking. Smalltalk has the advantage that all your tasks are on screen. They're broken up in easy-to-understand boxes. You can switch tasks by clicking on the proper box. Simple, easy, and really hard to mess up. The illusion part here is that you don't really need to be multitasking in the older sense of the word. A system like Rosetta was able to only run whatever task was currently in the foreground. So you might have a text editor and a debugger loaded up,

but only one would be actively running. As a human, you can't debug and edit text at the same time. That's just a physical limitation. So the computer can cater to that limitation. It still allows you to switch between tasks and get more work done, but it saves you some code complexity and some computing cycles. The next line item I want to highlight is the concept that Warren and Abe called, quote, one language level. This is kind of a specific feature to early Smalltalk systems like the Alto and Rosetta. The basic idea is that the actual platform is written in Smalltalk, so two are its programs,

and the user interacts with everything using small snippets of Smalltalk code. It's kind of like a programmer's wonderland. Also note that this is putting Rosetta closer and closer to an independent implementation of the Alto. Rounding things out, we have extensibility and modularity. Some nice $10 words to throw around. Now, this is a feature that's also in line with the Programmer Wonderland view of a desktop, while also providing more practical usefulness. In Smalltalk, you don't really add in new programs per se. Instead, you add new classes. I know it's a tiny

distinction on paper. The general idea is that a class exists within the larger small talk environment. It will have access to anything global, any predefined libraries, and any other classes you've already defined. That last one is the key here. Let's say you've already worked up a pile of classes for user interface components. You know, those buttons and menus and such that I talked about earlier. Now you need to make a new program that has a bunch of buttons and menus. To start out, you make a new class. It's going to be a game, so let's call it Sean's Cubicle Maze. Everything in Small Talk is already a class, so you're already handling classes to do anything anyway. When it comes to

interface building, all you have to do is call up a button class, just like any other class. It's all right there in the environment. Here's how things get even cooler. In my cubicle maze game, I implement a class for reading level files. It's some slick code that can slurp in a file and turn it into a maze level. A few weeks later, my friend Lars wants to make his own maze game. Sean's cubicle maze is already in the environment, so he can just pull up my level file class. Thus, time is saved and redundant code is eliminated. Better still, both of these games will be able to handle files in the same way. Let's say I find a bug in my file code. Maybe it can only read files up to 100k.

If I fix that, then both of these maze games will get the update. It's all just in the environment, after all. Thus, Lars' game could get an update without him even knowing. As interfaces were getting more complicated and programs larger, this kind of language design was a huge deal. That's kind of the nuts and bolts of what Warren and Abe were doing. In some, we have a tiny version of Smalltalk on tiny hardware that ports over all the important features of the Alto. But there's a weird little peripheral thing I kind of have to point out. Pun intended here. Rosetta Smalltalk may or may not have been using a mouse. I know, I've been on this ambiguous pointing device kick since last episode,

but allow me to explain. When describing windows, the 79 ACM paper has this little line mixed in. Quote, We turn our attention from one activity to another by pointing at the window of interest with the cursor. The window we select can then receive our keyboard input. End quote. Ah yes, a cursor.

It's used to select windows. That's a familiar interface design we can all relate to. A selected window can get data from the keyboard. Perfectly normal future tech. But the paper makes no mention of a mouse. The reference manual for Rosetta Smalltalk, which is published in 1980, does describe the use of a mouse in detail. So here's my theory. I think there's some fun fudging going on. I bet that by 79, Warren and Abe had a working implementation

of Smalltalk. They just didn't have everything working right. Maybe they didn't have a mouse. Maybe the actual interface wasn't 100% there yet. Either way, by 1980, those issues were resolved. Hence, when writing the ACM paper, they made a tactical decision to just not mention any mice. My point here is we should be a little bit careful about reading the 79 paper at face value. This is kind of a lesson in scrutiny in general, I guess. There may be some other details that are fudged or omitted. The broad brushes remain impressive, no matter how incredulous we choose to be. Warren and Abe had small talk running on a microcomputer. They were the closest

to catching up with Xerox. Apparently, VisiCorp also noticed this. As for this new working relationship, we know very little. On Rosetta's old website, which, once again, I basically think is Warren's homepage, we have one paragraph of information about the VisiCorp connection. Here's the start of that. Quote, I teamed up with VisiCorp, publishers of the pioneering VisiCalc, to build their next generation product. End quote.

Warren goes on to note that he architected most of the big features of Vizion. And that's all the narrative we get about its connection. It's a little underwhelming, but it does give us a place to start. I think it makes good sense that Vizicorp would have been interested in Rosetta. Here's my guess as to how things went down. The Rosetta Smalltalk paper is published in the ACM's newsletter in 1949. In 1981, the Xerox Star is announced. VisiCorp then scrambles and starts looking for a way to compete in the microcomputer market. They go looking for someone, anyone who's on the same tip as Xerox. They find Rosetta. A few contracts are signed and Vizion gets underway. This is where we can get

into the real nitty-gritty of Vizion. Coleman's Byte interview gives us some good detail on the operating system's internals. This is going to be a little technical, but I think it's important to get into these guts to really get a sense of how impressive Vizion is. First off, Vizion wasn't written in small talk. Instead, it used a mix of C and assembly language, but its design was informed by this C of small talk it grew out of. While C isn't designed as an object-oriented language, similar concepts and features can be implemented. That's the general approach that was taken with Vizion. In general, we can think about Vizion as an onion. It's built up from many layers. This was partly done for the sake of portability and partly done to enable some pretty cool programming feats of strength.

At the bottom, we have ViziHost. And yes, every layer does in fact follow the Visi-naming convention. VisiHost is the lowest level part of Vizion. This is where we get things like hardware drivers and basic I.O. control over the computer. VisiHost works with the actual computer system, in this case an IBM PC running MS-DOS. And it deals with anything near the hardware. It also provides a set of calls for accessing that hardware. This is the only part of Vizion that has to care about what specific hardware a machine has, and also the only part that uses any assembly language. The next level up is the Vizion Operating System, aka VOS. I really don't like this name, and that's for a

number of reasons, but this is what Coleman calls this layer, so we're going to stick with it for now. VOS is what you would normally call a kernel, or at least something similar to that. In most operating systems, you have this thing called a kernel. It sits between your software and your hardware. It manages resources and coordinates operations. But Vizion is kind of doing its own thing over here. Usually, a kernel will provide a standardized programming interface for things like allocating memory, grabbing files, getting keyboard inputs, starting new processes, that sort of stuff. MS-DOS provides part of this interface for the user already.

So that's one layer we're dealing with. VisiHost also provides its own fancy programming interface. So that's another side layer to this growing onion. VOS runs on top of VisiHost. It uses VisiHost's programming interface, but also provides its own programming interface. It all seems very confusing and redundant at first, so why would anyone do this? It all comes down to portability. The VisiHost level implements a set of very standard, low-level hardware calls.

From Coleman's description, I'm guessing that these are calls to, say, get a single character from the keyboard or plot a single pixel to the screen. Really basic stuff. VOS then provides an actual interface a programmer would like to use. Stuff like calls to get whole strings from the keyboard, or make new windows. You know, slightly more useful functions. Those higher functions are implemented by using calls to VisiHost. To port Vizion, you would just need to port the VisiHost component to a new platform.

Your new spiffy computer might plot pixels to the screen in a different way, or use a different keyboard interface. VisiHost is the only part of the system that cares about those low-level operations. VOS can just rely on VisiHost's judgment to build up more meaningful functions. Another little wrinkle here is that VisiHost handles process management. Technically speaking, VOS is just a process, or in Visi terms, an activity running under VisiHost. Now, Coleman doesn't go into very much detail here. The confusing part, for me, comes from two specific features that Vizion offers. The first is multitasking, and the second is virtual memory. Those are both implemented in

software. My guess is that the Vizihost layer implements the basic building blocks required for those features, then VOS handles putting those blocks together. But since we don't have the fine detail, I very well could be wrong. Alright, so on to the next layer, the Visi machine. And thus, we enter a far deeper level of speculation. Here's what Coleman says about the Visi machine. Quote, the Visiachine spec is the specification for all of these high-level services, the VisiOps, the Bits, and all of the higher-level functions that Vizion provides

through the service's windows. For a product sitting on top of the VisiMachine, it is as if the product is running all by itself in its own virtual machine, in its own virtual memory, in its own virtual memory, so it has as much memory as it wants, and all the product is doing is communicating with Vizion.

End quote. Just to get this out of the way, ViziOps are Vizion's library calls, and bits, spelled B-I-T-S, are what interface widgets are called on Vizion. So a button is a bit. I know, a little annoying. Now, Coleman is describing something very interesting and really heavy-duty here, but we don't have the fine technical details either. The Vizi machine appears to be a full virtual machine environment, as in, a software-defined

computer. Programs like spreadsheet and text editors would then be compiled specifically for the VisiMachine. This is a really complicated architecture already. That said, it gives us two big advantages. Process isolation and even more portability. Each user process, the actual programs you use, is siloed into its own tiny virtualized computer. To the program, it appears it has its own custom hardware to run wild on. That means that it can't interact or interfere with other programs except as the VisiMachine deems fit. It also means hardware access is only possible by going through the VisiMachine. This is a smart way to ensure the programs play nice.

I'm not entirely sure here, but I also think this makes Vizion fault-tolerant. If an error occurs in a program, if your spreadsheet crashes, then that error shouldn't propagate outside its virtual machine. If a program hangs, then only that program should hang. Once again, this is where more detail would help, but this is how other VM-based systems tend to work. The VisiMachine approach also offers superb portability. The virtual machine is implemented as a specification. superb portability. The virtual machine is implemented as a specification. That could be implemented on any hardware you like. IBM PC, Apple Mac, some DEC machine. Whatever has the requisite horsepower and hardware. The actual program that runs under the Visi machine can then run exactly the same on any hardware, as long as that hardware implements the full VM spec.

exactly the same on any hardware, as long as that hardware implements the full VM spec. This isn't a solution unique to Vizion. Java famously uses a similar design called the Java Virtual Machine, or JVM. It's a spec for a software-defined computer that allows for process isolation and portable bytecode. Some early timesharing systems and some big IBM software also fall into this camp. Now, here's my galaxy brain speculation about the VisiMachine. I think it was partly implemented as a way to simulate custom hardware. During Vizion's development, there were only three examples of graphical personal computers. The Xerox Alto, the Xerox Star, and the Three Rivers

Computing Company's PERC. The last here is obscure but included for completeness. Each of these machines used custom-built hardware that was designed for graphics. These machines were built from the ground up to be graphical workstations. machines were built from the ground up to be graphical workstations. Further, they all had custom-built processors. Xerox wasn't using off-the-shelf microprocessors to drive their futuristic publishing dreams. As such, there was a huge level of control over the hardware side of things. Hardware and software could be designed to work together instead of as totally isolated projects. By contrast, Vizion was targeting normal, run-of-the-mill commodity microprocessors. Nothing customer-tailor-made there.

You had an IBM PC and that's what you got. By building up all these layers and creating a whole virtual machine, Vizion can reap some of the same benefits of custom hardware. It's still not the same thing, but it goes a long way towards that bespoke feeling. That's most of the under-the-hood stuff that's going on with Vizion. The only other piece to mention is the object-orientedness of the system. The claim that Warren makes as well as Coleman is that Vizion used C that was written to an object oriented standard. C isn't really an object language. I mean, it's just not. My best guess here is that they meant that they were building up some kind of

data structures that they could treat like objects. Or maybe there's some magic in the Vizion machine that we just don't know about. With the back end out of the way, I want to move into the more actual user-visible parts of Vizion. My point in taking so much time on the back end is to explain that Vizion isn't just some fancy graphical program. It's a complex system that was trying to adapt larger ideas for smaller computers. Early Vizion development relied on prototypes, just as VisiCalc did. The only one of note that I want to shout out is the Apple III prototype. Coleman briefly mentions that there was a full GUI running on the Apple III at some point.

It's a bit of a footnote, but one that I would love to see uncovered someday. That's just deliciously weird. By the latter half of 1982, the prototype phase was over and Vizion was close to completion. That's when the world got their first glimpse of this program. Vizion was demoed at Comdex in the fall of 1982. Comdex was a trade show that was originally held in Vegas, and a chance to show off all things digital and new. Apparently, this demo was a smash hit,

but as with much of the story, details are scant at best. This is also where we hit the Windows connection. Supposedly, Bill Gates saw the Vision demo, freaked out, flew back to Washington, and started the effort that would become Windows 1.0. Now, this quickly turns into something of a research mess. This quickly turns into something of a research mess. Do you realize how many Bill Gates interviews and biographies include the word vision? Turns out that vision and Vizion are spelled the same way, and that word shows up in basically all of the sources on Gates I can find.

Another reason for the research mess is that Vizion wasn't the only micro-GUI game in town, or rather, it wasn't the only GUI in development. Around the same time, Apple had started work on a machine called Lisa. This would be their entrant into the arena. The Lisa was a custom-built machine with a slick user interface. Think something close to the later Macintosh, but a little more rough around the edges. The Mac was also technically under development during this time period, but there's a bit of a fraught history there.

The most full account of the Vizion Gates story I could find comes from Hard Drive by James Wallace and Jim Erickson. It's one of about a dozen biographies of Bill Gates, but perhaps one of the earlier bios. It was published in 93, so it's relatively early in the chronology. Hey, this is the closest I could get after going on quite a long search. According to Hard Drive, quote, after going on quite a long search. According to Hard Drive, quote, In the summer of 1981,

Steve Jobs had given Gates a peek at a prototype of a new computer Apple was developing, the Macintosh, which used GUI concepts developed at the Xerox Research Center. Later that year, Microsoft formally began a GUI project of its own,

called Interface Manager. End quote. That kind of blows the whole Vizion connection out of the window, so to speak. Instead, Hard Drive explains that the Vizion demo inspired Gates to push development of their existing GUI project. This Interface Manager eventually became Windows 1.0, so there is a connection, but it's not the nice direct relationship that makes a tidy story. The bottom line is, the simple story here is a bit of a myth. Hard drive pulls its sourcing from contemporary newspapers and interviews with people connected to Gates, so it seems trustworthy enough. It's likely a game of telephone went on at some point,

and the myth made it to the wider web. This is one of those myths that even I got taken in by. I guess my face isn't exactly free from egg in this instance. However, I think this highlights how much of a threat Vizion was for the time. It was impressive enough to scare Gates into action, or rather, into a little more action. Hard Drive points out multiple times that Gates wanted to release Windows before Vizion could hit the market. So what did the system actually look like? What made a demo of Vizion so impressive? Just to start with, Vizion looked good. The entire interface is this

crisp monochrome, which was pretty standard fare for the era. It has everything you'd want in a GUI. You get overlapped windows, applications, a little mouse pointer, and everything's driven by a series of menus. That's all simple enough, but we also have a few unique bits to address. First of all, Vizion didn't use icons. Everything was communicated using text. This looks a little strange to the modern eye, especially when you minimize windows. Minimizing windows just turned them into small text boxes up in the corner of the screen. The boxes are unadorned with just the name of the application visible.

The application launcher follows the same text-only routine. You just get a window that displays a list of applications installed on your system. It's nothing flashy, but it works well enough. Better still, the entire graphics layer runs on top of this Visi machine, so everything's safe, isolated, and, at least in theory, portable. The windowing system in Vizion is also somewhat unique. In the current era, windows tend to have a menu, title bar, and grabbable area up at the top edge. This design already existed when VisiCorp took to the GUI challenge. The Xerox Star may have been the first computer to implement the whole top edge UI. Windows could be moved by

simply dragging the title bar. A Vizion window has four separate components. The title bar at the top, the window's content in the middle, and then the status and menu bars at the bottom. The title bar and contents are, well, just what they sound like. The menu bar is a little different though. It provides application-specific options only. The status bar, just above the menu bar, is a single line used for displaying short messages and what layer you are at on a menu. The menu bar is also context-sensitive, meaning that it changes items depending on what's going on. For instance, when you first open Vizion Calc, the menu initially has two items, Create and Revise. Once you have a sheet loaded, the menu bar changes to items like

Enter, Calc, Cut and Paste, Replicate, and so on. Hovering the pointer over a menu item will often pop up a short description in the status bar. Some actions, such as copy and paste, will drop you to a sub-menu. However, this isn't the hierarchical fare that we're used to with drop-down menus. This actually changes the content of the menu bar itself. In this mode, the status bar is also used to show what level on the menu you're currently residing at. We're always tied to this single line affair. It's honestly a little annoying.

For actually controlling Windows, you have the fancy main menu bar. This is a menu bar that's always displayed across the bottom of the screen. You see, windows don't have their own dedicated buttons for moving or resizing or minimizing. All those actions are accomplished via the main menu. This is all topped off with a fine layer of cruft. For instance, if you wanna resize a window, you click the frame action. Then you're prompted to click the target window, then the upper left corner, followed by the new lower right corner. Workable, but it's a lot of clicks for a

really simple action. The menu also connects us to one of Vizion's cooler features, a full hypertext help system. VisiCalc was supposed to have online help initially, so I can only imagine that this was the realization of that older dream. Vizion's help is fully context sensitive. When you hit the big help action, you're prompted to click on what you need help with. Then a window pops up to aid you. It's pretty robust and it means you should never need the physical manual. This is backed up with a slick series of tutorial programs that walk new users through the Vizi experience. The final big feature provided by Vizion itself is what's called the Archives. This one is

a biggie and one of the reasons Vizion was made in the first place. The archive is a file abstraction layer that allows for cross-programmed data transfer. This is accomplished by a pretty tricky mechanism. So a document in Vizion is composed of multiple underlying files. By this I mean actual DOS files on the DOS file system. Let's take a spreadsheet as an example. That has numerical slash textual data, as in the literal contents of the sheet. There are also equations, and then formatting information, which is a totally different beast. Vizion will store those types of information as different physical files,

but then the archive groups them into one larger document. Under Vizion, you get one file, but if you drop down to DOS, you might see a small handful. Here's the power move that the archive enabled. Vizion called it the transfer. You could copy from one program to another, and in a pretty smart way. Vizion would only transfer over parts of the archive that made sense to drop into that target program. So if you copied from VisiCalc to VisiWord, you'd only get textual data, for instance. This also means that, in theory, you could open VisiCalc data in VisiGraph.

You'd just be opening the part that the archive deemed fit. That wasn't implemented, but the possibility's there. The emphasis was placed on transferring data instead of, you know, opening files in different apps, but it's tempting. My reading of this feature makes it seem like that could have been accomplished pretty easily. Completing the total package, we have the elephant in the room, the actual Office software. Vizion was sold as a standalone product. To get any use out of it, you had to buy into actual application software. As near as I can tell, there were only three programs on offer. Vizion Calc, Vizion Graph, and Vizion Word.

Confusingly, these were also sometimes called Vizicalc, Vizigraph, and ViziWord, which were also non-Vision compatible products. So, yeah, what can I tell you? There's some confused marketing. These programs were, broadly speaking, unrelated to earlier Visi programs. We're talking total rewrites here. However, there was some compatibility built in. You could convert from old VisiCalc sheets to new Vizion calc archives, for instance. Same for graphs. In general, the new calc seems to be built such that it's similar to the older program, just with all the added spit and polish of Vizion itself. This leads us to the problem with Vizion, or rather, the problems plural. There's a good reason this operating system is so obscure, so here's some of the bad.

Vizion was released at a very inopportune time. The Apple Lisa came out in August of 1983. Vizion hit shelves in December of that year. Technically speaking, these are two very different products. But for consumers, they're just the closest comparable products possible. Each is a GUI system that works with a microcomputer. that works with a microcomputer. Thus, Vizion wasn't the visionary first GUI to the small market. It was something to compare to the Lisa. Xerox ended up being a non-player in this case,

but there was Apple standing nearby to cast just as long of a shadow. There was also the matter of cost, both for the software itself and for associated hardware. Let's start with software. Vizion itself retailed for just under $500, but that price would drop quickly. I'm going to be pulling from a 1984 issue of Byte, early 1984, in order to get a price out that seems reasonable. By that time, a few months after release, Vizion sold for a meager $319. A mouse could be had for $159, thrown another $129 for Vizion Graph, and $249 for Calc. I can't find a listing for the text editor, but it's probably in the same ballpark as Graph.

So, totaled, you're looking at just under $1,000. Let's just cut it at a neat $1,000 for argument's sake. Then there's the actual hardware requirements. We aren't at a place where everyone has a fast computer on their desk yet. We already factored in the mouse, since most users, even if they did have a computer, would have probably had to buy that at the same time as this software. Vizion turned out to be a little picky. It wanted to run on a 100% IBM compatible with a hard drive and plenty of RAM. Vizion also required a CGA or Colored Graphics Array card and a matching monitor. The program didn't display color per se, but it needed the high-res graphics that CGA offered.

The best choice in early 83 was going to be a fully loaded IBM XT. With all the bells and whistles included, that came out to a mean $8,000. That gives you an eye-watering $9,000 to go from zero to Vizion Office. Killer app this may not be. Once again, I'm making this judgment call of including the hardware cost because most consumers would need the hardware too. This is a package deal, so I don't think it's fair to just look at the software costs alone like a lot of advertisements at the time did. Now, the immediate competitor, the Apple Lisa, came in at $9,995. So yeah, Vizion was cheaper, but it still wasn't as competitively priced as earlier Vizi products were. With inflation, it would cost you around $26,000 to get the total Vizion package.

That's getting up there near new car territory. Perhaps worse, Vizion's complexity and intricate programming wasn't very flashy on the outside. I've seen quite a few period articles that compare it to Lotus 1-2-3. When you get down to it, Vizion was targeting the same market. Both were integrated office solutions, designed to be easy to learn and simple to use. Both offered multiple programs under a unified environment. Both used menus. Lotus 1-2-3 cost $500. Lotus 1-2-3 could run on a normal IBM PC or 100% compatible. a normal IBM PC or 100% compatible. Of course, Vizion is so much more than that, but you couldn't have guessed that at a glance. If there had been third-party support for Vizion, if non-Vizi programs were written and sold for it, then I think Vizion would have been able to limp at least.

able to limp, at least. Developer support was, well, all we can really say is it wasn't the best. Vizion applications had to be developed using custom tools that ran under Unix. Software had to be written in a weird subset of C, sometimes called Vizzy C. It's that small-talk style C that I briefly mentioned earlier. There isn't much information about the development environment, and there aren't any third-party programs floating around either. The sum total here is once Vizion got out of the showroom and into market, it just wasn't a very impressive option. Alright that brings us to the end of our Vizzy episodes. I'm gonna be happy to get that prefix out of my mouth for a little bit.

My take is that we're left with a complicated legacy. VisiCalc cracked open a totally new market right as it was emerging, but due to managerial decisions was unable to adapt quickly enough. Vizion was poised to do the same thing, to create a whole new kind of consumer software. Thanks to a number of issues from timing to pricing, things didn't go to plan. If I had to point to any one key failure point, it would be the lack of third-party support. I think that doomed the Lisa, it doomed early versions of Windows, it doomed Xerox, and it also doomed Vizion. A slick GUI is cool and all. Your in-house office software can be pretty nice too. But at the end of the day, these are just platforms.

They're missing their own killer apps. They need a reason to exist in the mind of consumers. Vizion just wouldn't sell well. Once VisiCorp hit the end of the line, Vizion became lost in the corpo shuffle. I think that's a shame. Vizion doesn't just look slick, it's backed up by some slick programming. Now, I will give you a word of warning. It's tempting to say that, oh, Vizion was just ahead of its time. I'd caution against this thinking. As we've seen, there were other

graphical interfaces hitting the home computer market. Portable software, while not entirely ubiquitous, was a consideration in the early 80s. Look no further than VisiCalc, the reigning champ of portability for the time. No, I think Vizion would have been a good fit for the time, or maybe a little later. If it had survived into, say, 1985, if more users had hard drives and more software was written for it, I think Vizion could have flourished. The final tragedy for me is that you can't program new software for Vizion anymore. As near as I can tell, the custom Unix development kit has been lost to the sands of digital time. Maybe it'll turn up one day, or maybe it's doomed to rot away on a shelf somewhere.

I'd love to try my hand at breathing some life into a few new programs, maybe a desktop calculator, or hey, maybe even a simple maze game. Anyway, we can't cry for too long over what could have been. You can try out Vizion for yourself today. I'll include a link to the Vizion page on Toasty Tech, which includes everything you need to get an emulator up and running. And until then, I want to thank you for listening to Advent of Computing. I'll be back in two weeks' time with another piece of computing's past. And hey, if you like the show, there are now a few ways you can help support it.

If you know someone else who'd be interested in the story of computing, then why not take a minute to share the show with them? You can also rate and leave reviews on Apple Podcasts. And if you want to be a superfan, you can support the show directly through Advent of Computing merch or signing up as a patron on Patreon. Patrons get early access to episodes, polls for the direction of the show, and bonus content. You can find everything on my website, adventofcomputing.com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. dot com. If you have any comments or suggestions for a future episode, then go ahead and shoot me a tweet. I'm at Advent of Comp on Twitter. And as always, have a great rest of your day.