Advent of Computing - Episode 157 - Only S1 Users Will Survive!

Episode Date: May 11, 2025

The S1 operating system can do it all! It can run on any computer, read any disk, and execute any software. It can be UNIX compatible, DOS compatible, and so, so much more! But... can S1 ship? Today we are talking about an operating system that sounds too good to be true. Is it another example of vaporware? Or is S1 really the world's most sophisticated operating system?  

The S1 operating system is an OEM's answer to product differentiation, a system house's answer to continuity, and a programmer's dream come true. No other operating system in the world even comes close to all the features and functionality of S1." Have you ever heard of S1? In 1984, ads for the operating system hit print. That quote is just the beginning of one full page spread. S1 was at once impressive and mysterious.

It could do anything and everything. Want to run it on an 8-bit microcomputer? Sure. Want to replace Unix on your big beefy workstation? Why not? You can even keep all your old Unix software. The list of features is truly staggering. In fact, that list may be too good to be true. We've seen this before, big claims from new companies. Back in 1968, there was this little startup called Viatron, and they claimed that they were positioned

to topple IBM. They designed a new computer so cutting edge, it required a whole new phrase. The microprocessor, they called it. But when Bush came to shove, Viatron crumbled. Their microprocessor was impressive, but was actually just a scaled down computer. Sure, the hardware was impressive for the time, but not nearly as good or as useful as their press made it sound. Sometimes when things sound too good to be true, well, that's because they simply aren't true. But when it comes to S1, the story is far more complicated than it first appears.

Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 157, Only S1 Users Will Survive. As a software developer, stories of vaporware will always get me excited. Vaporware is software that gets announced and either fails to materialize or, when it finally shows up, doesn't really go anywhere. It just disappears as quickly as it appears. From an outsider's perspective, this is simple, right? It's just a list of cases where companies over-promise and under-deliver. And in the case of true vaporware, catastrophically under-deliver. But let me tell you, as an inside man myself, that's not always the case. I've written a lot of code that's never seen the light of day.

I mean that both professionally and working on personal projects. Not every program makes it into general circulation. Not every announcement is followed by a release. Software can transform into vapor for any number of reasons. A marketing department can get overeager and overpromised when it's realized that the company can't deliver, they reel things back in. A project can get hit by budget cuts and fall behind. Interest in a project can wane, or some insurmountable technical issue could be discovered. Or maybe plans had some fatal fault from the start. I've even been in cases personally where I've completed an entire project for a company

and then our marketing department didn't really know how to sell the thing. All this is to say that vaporware, from my perspective, is a very, very complex topic. These are all hooks from classic sagas, refrains from well-loved war stories. In fact, if you catch a programmer in a bar, which is an easy thing to do, it's likely that they'll tell you the tale of when their software turned into Vapor. Now, there's another line here that I think really takes the cake. That's Vaporware that was never Vaporware at all. I'm talking about software that appears and then just as quickly disappears.

It hits the press cycle, ads get plastered, reviews come in, it launches, and then silence. It's software that's almost in a vaporous state. Today we'll be looking at one such program. It's an operating system called S1. I found out about this operating system while browsing old issues of computer world. I was looking for something else and came across this short article claiming there was this portable system called S1. It was claimed to run on just about any computer out there.

It could run all kinds of software, read any kind of disk, but as the article claimed, it was vaporware. It never actually existed. Looking deeper, I found that no, S1 did exist. Or at least, it was real in some form. Today we're hitting the trenches to find out just what S1 was, what happened to it, and why it was claimed to be vaporware. But first, it's time for my announcement corner. Announcement 1 for today is, I have confirmed I'm going to VCF West this year. That's going to be the first weekend of August.

I'm going to be giving a talk, and I'm pretty sure it's going to be the first weekend of August. I'm going to be giving a talk and I'm pretty sure it's going to be on some of the emulation software I've been working on. So if you want to come out, as always, I love meeting listeners and I highly recommend going to VCFs anywhere. They are wonderful events. And point two, I'm actually about to hit a big podcast milestone this year. I'm getting very close to half a million all-time downloads, which is really exciting. I never thought I'd be anywhere close to those kinds of numbers. So I'm planning, pretty well ahead of time, a bit of a celebration.

I don't know exactly what it will be yet, I'm open to options and considerations. I was thinking about maybe doing another Q&A show, but I still have a little time, I think a couple of months at least, to scheme and plan. So if you have any recommendations, hit me up and I'll start to solidify my plans. Alright, that's all I got, so let's begin our dive into S1. Given the name, I think it's only appropriate to start at square one. In 1965, Byte runs a column titled S1 Exists. It's pretty bold to start things off with, right?

It opens like so, quote, For over a year, I've heard stories about the S1 operating system. It's supposed to be totally portable, multitasking and multi-user, and better and friendlier than Unix. The article continues, quote, The world is obviously ready for another operating system. Unix isn't going to do the job. Digital research is in the doldrums. MS-DOS is boring. The Modula 2 operating system is exciting, but it's taking forever to get the operating system implemented on anything but Lilith, a machine designed especially to run Modula 2."

This paints, I think, a really cool picture. According to this article, around 1985, the microcomputer market was at a turning point. Unix is difficult to use, and there's a bunch of issues with running it on small machines. DOS isn't really up to snuff, and a slate of other options aren't ready for use quite yet. In other words, there's a great opportunity for a new operating system. Now we must ask, was that actually the case? Let's take these options point by point, starting with Unix. Why would Unix not be up to the

task? Well, luckily, we've spent a lot of time talking about small Unix distributions here on the show. You could say it's a bit of a special interest of mine. One of the greatest aspects of Unix is its portability. With a few simple modifications, it can be made to run on just about any computer. That is, as long as the computer has the right memory management hardware. The critical circuit that Unix really wants access to is called an MMU, the Memory Management Unit. Many microcomputers in this period, which were going to be in the mid to early 80s, were missing those circuits. To get Unix to work on these smaller systems, you needed to cheat. And cheat many programmers would. Unix and its relatives and derivatives have always been great operating systems.

Folk have always wanted to move it to whatever computer they had access to. A big reason for that is another ability word, compatibility. You can, after a pretty short fashion, run a UNIX software on any computer that runs UNIX. You can get big server software to run on your home micro, and that's some powerful stuff. But the cheats required to run UNIX on these early home computers led to some strange systems. Some took the Unix source code and they hobbled it. The main example is that of Xenix,

a version of Unix that Microsoft ported to a number of different computers, including the IBM PC. On hardware without an MMU, like the IBM PC, Xenix lost a lot of the tricks that made Unix powerful and functional. It could kind of multitask, and it could almost handle multiple users, but not very well. Performance was also highly impacted. A Computer World article from 1985 describes the issue as a larger failure. Quote, when Unix hit the streets,

users rejoiced at the prospects that compatibility and portability might be, at least to some extent, just around the corner. It now appears, however, that instead of compatibility, vendors are modifying, refining, and even reinventing the wheel." This gets even more apparent when we look outside of thoroughbred versions of Unix. There were some new operating systems written from scratch to be Unix compatible. I've seen

these called look-alikes or act-alikes before. I think either term is pretty apt. Here we see things like Idris or Coherent. These were both operating systems that could run on small computers and run UNIX software. There were some caveats though. Well, there were quite a few caveats, but it technically worked. You got UNIX without any of the Unix source code. A second reason to push Unix onto micros was language support. Unix has always been the homeland of the C programming language. In fact, C was developed specifically to write Unix. The two are tied at the hip. If you have a system that can run Unix, then you have a superb environment for programming C. Also, if you have a system that can run Unix, then you have a superb environment for programming C. Also, if you have a C compiler, you can bootstrap Unix.

That compiler and that environment also open up access to a lot of existing compilers and tools for other languages. There are a lot of compilers that are just written in C. And you kind of gotta remember here, if you have Unix software, you can get it to run on any Unix machine. However, Unix wasn't for everyone. It's notorious for being a finicky system. The classic joke here is that Unix is user-friendly, it's just picky about who its friends are. To use Unix, you almost have to be a programmer. Its only interface in this period was the command line. You had to type out incantations and memorize flags by heart.

This was compounded by the fact that Unix itself was pretty complex, and each command tends to only do a very small, very specific thing. That's the Unix philosophy in a nutshell. You get a huge set of tools, each specialized, that you can plug together to do all kinds of great things. That only really clicks for so many people. And even then, it only works if you spend the time learning about all those tools. You can't really sit a new user down at a Unix prompt and expect them to know how to write an essay.

Turning away from Unix, we have MS-DOS, or, as delivered by IBM, PC-DOS. Both are roughly the same thing, give or take. If Unix is a tool, then DOS is a lot closer to a toy. At its core, DOS does only two things. It lets you manage files and load programs. In fact, the two could be merged, since programs under DOS are just special files that you manage. And that's a complete tour of DOS are just special files that you manage. And that's a complete torr-a-DOS.

That's actually pretty much it. DOS doesn't support multitasking. In fact, it always loads programs into the same location in memory. It can't handle multiple users. It doesn't even have a memory manager. I think the most sophisticated things it can do all involve like printing. And as far as compatibility, well, DOS is DOS. A DOS program can run on any DOS machine, but that doesn't give you a whole lot. If you have a PC, you can run PC software that dates all the way back to 1981.

Today, that's pretty impressive. It lets us run old video games and all kinds of cool software very easily on modern computers. But in 1984, that's not much. Don't get me wrong, with the spread of the PC, this compatibility becomes pretty important. Companies are able to target a huge market segment by just targeting a Microsoft DOS PC. But this isn't even close to the compatibility gains you get from something like Unix. That lets you run software that goes all the way back to the early 70s and lets you run

some truly sophisticated software. The bottom line is that DOS was fine, but it wasn't very much. You didn't really get anything special from it. Think of it as the most basic option possible. There's also the simple fact that DOS only ran on x86-based computers. In the early 80s, it still wasn't clear if x86 would be THE platform of the future. It was popular, sure, but there were still other options. The monoculture hadn't quite formed yet. We can see this pretty simply by looking at vendor market share. In 1984, PC compatibles make up less than 50% of

the market. The Amiga, Commodore 64, Apple II, Macintosh, Atari ST, and even some older machines still have considerable market share. The PC was winning, but it hadn't won out. It was completely conceivable that a newcomer would explode onto the scene. In that scenario, it makes sense to care about portability. In other words, something like Unix looked really enticing. That is, if you overlooked all its blemishes from a user's point of view. Of course, the picture gets even more complicated. In 1982, Intel announces the 80286. The market lags a bit, but in 1984, IBM launches the IBM AT. This brings, among other things, an MMU to the PC platform, because the 286 has an MMU. That means you can run

just normal Unix on a PC. It's a little small, but it can do all the multitasking you could ever want. This is also a big era of transition as far as what a user is seeing on a computer. The Lisa hits shelves in 1983, Apple's first graphical machine. That's followed by the Mac in 84. In 1985, Microsoft Windows 1.0 makes its own transition from a vaporware saga to real software that you can buy in a box. We're very much dealing with this rapid transitionary period. So really, it's not just a matter of Unix's personal issues. Things are just up in the air in general.

The field is shifting. So again, there's space for innovation. Allow me to introduce one of the most bombastic operating systems fighting for market share in this period. In 1984, a wild ad hits magazines and newsletters. Its text reads something like this, quote, Unix is a dinosaur. CPM and MS-DOS are toys.

Multi-solutions presents the world's first fourth generation operating system, a serious operating system for today and tomorrow. S1. S1 is the only operating system worthy of the title, The Next World Standard. Only S1 does it all. No other operating system comes close, cuts development time from man years to man months. In time, only the best will survive. S1." Wow. I think that's all I can say. I've seen ads for software that are in your face. And to be frank, I kinda dig it.

I'm just waiting to be told that S1 can get rid of embarrassing stains on your shirt collars. This new operating system explodes onto the scene, marketed as the DOS and UnIX killer. There's also a certain frantic quality to these ads. It would be reproduced for a number of years. The background is just the letters S1 in huge font with a list of features superimposed. Those features range from portability to bitmap, images, and windowing, real-time to networking, multitasking, and much, much more. That last bit's a quote. It literally ends with much, much more. There are very few details, just a vague list of qualities, and a simple attestation that S1 is the best operating system in the world. If that doesn't pique your curiosity, then, well, what are you doing here?

While exciting, this presents a bit of a problem. S1 promises the entire world. It can do anything, run on any system, and run any software. Even looks cool while doing it. But can it deliver? What even is S1? And where did such an advanced system emerge from? It's fair to say S1 is obscure. I consider myself something of an expert in obscure operating systems, and I had never heard about S1 until I started working on this episode. I've really had to put my nose to the grindstone. S1 was sold by a company called MSI.

And no, it's not that MSI. This stands for Multi Solutions Incorporated. The company was founded by Robert Knight, a programmer, and Charles Lombardo, a businessman, in 1982. I've actually been able to get in touch with Knight. We've exchanged a few emails, which have helped me fill in a few blanks and hook onto some leads for the episode. Lombardo, however, I can't find hide nor hair of. This episode has been put together from a bit of that correspondence with Knight, plus a pile of research from contemporary magazines, newspapers, and a few newsletters. I think that's holistic enough that we can piece together the story.

I want to start off with a simple fact that we need to focus on. That's that S1 actually existed. It was a functioning operating system. It was sold to a number of clients. It ran on a number of computers both at MSI and outside their corporate offices. I want this to be clear because we're going to run into quite a few bits of press that call S1 vaporware. Those allegations are wrong, but I want to try and understand why those allegations were laid out in the open. Before MSI, Robert Knight worked as a programmer and lecturer at Princeton. There, he developed a language called SL, the system language. The details of SL sound very, very similar to C. SL was designed to be a machine-independent system programming language, perfect for things like operating systems or compilers.

It also has a focus on portability. We've talked about these types of languages on the show quite a few times, things like BCPL, C, and Bliss. There are a few different approaches here. The core problem with these portable languages usually comes down to how memory is handled. Memory manipulation is the beating heart of programming, and not all machines treat memory and data in the same way. Bliss gets around this by having no data types. You can only declare generic spots in memory to store data. SL, however, takes the C approach. These two languages have very strictly defined variable types. An integer in SL is always 16 bits of data, always with the same byte order and signing conventions.

SL also has a concept of pointers, a mainstay of C. There is an extra layer here called IL, the internal language. Knight told me that the SL compiler output programs in IL, which would have worked as an intermediate format. From there, IL could be transformed into an executable binary. That kind of two-step is actually pretty common to more modern compilers. Something like LLVM or even the TypeScript transpiler do a similar dance. It adds flexibility and is really good for portability. Let's say you have a number of compilers that all output IL. That IL code is machine independent, but pretty simple all things

considered. When you want to target a new platform, you only have to rewrite your single IL compiler. That way, porting a language to a new system is easier than rewriting all your different compilers. The real sleight of hand here would come from writing your first stage compiler in a language that can be compiled down to that intermediate format. Then as soon as you have the compiler for that format, your IL compiler, you can port the first stage compiler over to the new platform. So in just a few steps, well, in just two steps, you can get up and running on a totally new computer. Knight then uses SL to start writing

his own operating system, and that is S1. So let's just assess where we are so far. S1 is supposed to be as portable as all Git out. According to Ad Copy, S1 can be ported to run on a new machine in a period of quote, man months instead of man years. SL sets up a great foundation for that kind of portability. All you have to do is port the IL compiler, presumably work out some hardware drivers, and you're done. As we move on, we'll be talking about a few other features of S1 that make portability even easier. But for now, this is a big point in favor of the operating system, and this

method of portability using an intermediate step is a little more sophisticated than the C-style portability that Unix employs. So again, point to S1. This takes us up to the founding of MSI. Knight teams up with Lombardo to bring this radical new operating system to market. And the marketing, well, we already got a taste of it. It's kind of wild. I quoted one of S1's first ads earlier. Let me list out some of the claims made by MSI. Portability was always a top-line feature. S1 was supposed to run on every computer under

the sun. But the list gets a lot more wild than just one claim. Most of this section is just going to be looking at all of these claims. In general, features of S1 fall into two categories. Parity with Unix and then wild features that don't normally show up on microcomputers. Or well, in software outside of research. In the wide view of things, this makes good sense. Or at least, to my addled industry ghoul brain, this makes a lot of sense. When you go head to head with a competitor, you often try to reach parity with their product

and then provide some differentiating factor. That way users see that you just have a strictly better product. So they go, oh well, I could get Unix or I could get S1 which works the same and has more features. You should choose S1, at least that's the theory. So we get some of the expected features. S1 is multitasking and multi-user, just like Unix. You can run multiple programs at one time, and multiple users can share a computer over, say, a terminal. S1 supports networking, so you can connect up multiple machines, and users can even log in over a remote connection.

S1 has memory management and virtual memory. Again, features crucial to Unix stability and power. That's all expected. If someone says they're going after Unix's market share, they better be able to multitask. S1 goes a step further. It claims to be, quote, Unix source compatible. further. It claims to be quote, Unix source compatible. Now, this gets tricky. So, let's talk about why Unix programs are portable. Classically, everything in Unix is written in C. When Unix is ported to a new platform, the C compiler comes along. That allows you to take any C code and compile it to run on your new platform.

Put another way, all versions of Unix are source code compatible. A program written in C can be compiled on a PDP-11 version of Unix, or on PC-Xenix, or even something more exotic. The source is the key, and the C compiler is the key. MSI is saying that you can take C code written for Unix and compile it under S1. We already know this sort of thing is, very broadly speaking, possible.

Both Idris and Coherent, two Unix-like operating systems from this era, were source compatible with Unix. They did this by simply having a C compiler and then supporting all the same system calls that Unix exposed. Thus, you could take a Unix program and have it up and running without Unix. In theory, S1 could do the same thing. At least, that's what's claimed. But this has to be handled carefully. In Idris, for instance, you had access to all the same system calls as Unix, but by different names. You couldn't just call printf to print a formatted string, you had to use the idris equivalent. In practice, that meant you would

have had to make extensive changes to get a Unix program to run under idris. This would get better as the operating system matured, eventually names would fall online, but early releases kind of missed the mark. We don't know if S1 had a similar problem. If the operating system really was source compatible, then it could be viewed, or at least marketed, as strictly better than Unix. You could just replace Unix with S1. But this is just the start. S1 wasn't just Unix compatible.

It was marketed as the ultimate compatible operating system. It could read any type of disk and any type of file system. Those claims showed up in ad copy all the time, but the real wild claim was that S1 could actually run software for any operating system. That included Unix and DOS. Again, it's strictly better than all the rest. For me, this is where things kind of jump the shark. Maybe I'm jaded, the whole portability thing I've come to expect from reading so much about so many bizarre Unix compatible systems. so many bizarre Unix compatible systems. Limited compatibility is fine and all, right? We see that, we use that all the time. But saying it's universal, that sounds too good to be true.

That said, I've read enough to think that S1 actually stood a chance at delivering on this promise. And I know, that sounds wild. This piece comes from two articles written by John Little, one of MSI's system programmers. One article was in Computer Design Magazine, the other was in I.O. Magazine. Now, there is an issue here. That's that IO is a Japanese magazine in the Japanese language. I can read hiragana on a good day. I would say my reading comprehension skills are around the level of a very young child. So I had to use some software to auto-translate it. There may be some small inaccuracies, but the broad strokes sound correct compared to

other articles I've read. I just want to put this out there as a bit of a caveat if I start talking nonsense. Okay, so the trick to S1's arcane power was modularity. S1 is a fully modular operating system. What exactly does that mean? A module in this context is simply an independent program. It's a chunk of code that's wrapped up in a very specific way and ready for use. What's important and what separates a module from a normal program is standardization and isolation. A module does not expose any of its innards, and it talks to other modules

over a standard calling procedure. The result is that a module can function in its own little world and then call out in a very predictable way to another module. This allows you to do things like replacing modules, having secret ways you implement certain functionality, and really kind of building up software like you're working with Lego bricks. S1 uses modules for everything, and I really do mean everything. Little gives a list of core modules, and it ranges from terminal management and graphics down to file access and even task scheduling.

This type of design is wildly flexible, because you can pick and choose which modules you want to load. You can also swap out modules very easily or even add modules written by some third party. Modularity is one of the ways that S1 was able to be ported so easily. There are only a handful of modules that care about specific hardware. Any hardware dependent code is restricted to just those modules. So in practice, that's the only code that needs to change. Write a new IL compiler, update a few modules, recompile, and you're done. That's, in some cases, probably less than a man-month of work. This also makes development easier to handle. Since each

module is independent, you don't get developers stepping on each other's feet quite as much. But hey, that's an added plus that users wouldn't even know about. The design here also lets S1 be something of a chimera. You can load in just the bare essentials and create a very small version of S1. Or you can load in just the bare essentials and create a very small version of S1. Or you can load up everything and have a do-it-all install. You get to pick and choose exactly how it acts, what it can do, and what it can run. Since file management is a module, and so is disk access, in theory, S1 gets to read any file system. All you need to do is write a module for that file system or for that disk system. As long as the module works and talks to

S1 correctly over standardized procedures, you're done. So adding support for DOS's FAT12 would be simple. The same goes for any of Unix's bizarre file systems. As far as software compatibility, well, we already heard the Unix option. But what about for other systems like DOS or CPM? According to Little, S1 used a virtual machine for that trick. Now, caveat time! This is only stated in that Japanese article I had to translate. As with all things S1, we don't have a whole lot of fine detail, but what we do have is not only fascinating, but doesn't sound entirely unreasonable. What exactly is a virtual machine and how does it make S1 the universal operating system? Put simply, it's software that lets you pretend you have another smaller computer inside your

computer. That machine, called a guest, is then controlled via software on the real computer, called the host. You can use this fake machine to run another operating system, and then run software written for that system. So on S1, you could run Lotus123 by running DOS inside a virtual machine. There are a number of different ways to make this happen, and we don't know exactly what S1 was doing. One approach is full-on emulation. That's where you have a 100% software-defined computer. Think of something like the video game emulators you

can use to play NES games on a computer or on your phone. That has the upshot of giving the host machine complete control over every aspect of execution, but it can be slow. On the other side of the spectrum are, well, arcane tricks. There are some wild ways to trick software into thinking it's running on its own machine, but I don't really want to get into all that. Let's just say it's possible to isolate and run an operating system without emulation and leave it at that. The upshot is, since it's running on actual hardware, you get better performance, but at the risk of stability, at least in some cases. Another option comes in the form of hardware features. Some computers have built-in support for virtualization.

These are features that help isolate software and then control its execution. One example, and the one I'm familiar with, is Virtual 8086 mode. This is a feature of x86 chips that starts to show up with the 386. It lets you wall off a single process and run it as if it was on a real 8086.

You can use that to do something like running MS-DOS from inside a more sophisticated operating system. But as I said, I'm not sure which approach S1 used. I guess it used the arcane software tricks because emulation would have taken a lot of time to work out, and S1's initial hardware targets didn't offer hardware-level virtualization support. Plus, we've actually seen software-based virtualization before on the show.

Coidris, my favorite Unix clone, used a weird type of software-backed virtualization to run Microsoft DOS programs. That's showing up in the same era as S1, but then again maybe S1 did use emulation. We really just don't know. What we're looking at is a feature that sounds very sophisticated, but it's also well within the realm of what's possible. Competitors were doing this in some capacity. S1 is just bringing all of these wild and very powerful features together.

It's a really good strategy, but it also means there are many possible points of failure. Now, this is all flashy stuff. S1 can read any disk, run any software. It can be your Unix, your DOS, and so much more. But it can also do some other really cool tricks. One is how S1 handles multitasking. The Unix multitasking model is fairly simple. When a program starts, it's spawned as a process.

Unix uses preemptive multitasking, which means each process gets so many clock cycles to run before it's interrupted, put to sleep, and then another process is given a turn to execute. The number of clock cycles you get is determined by your priority. Processes can also go on to spawn child processes, which fall under all these same rules. You run, you sleep, you run, you sleep, you run, you sleep, you run, and eventually you complete. You end. Processes can also be put into a waiting state if they're waiting for, say, a disk drive to be available. There are more complications, but that's the most basic rundown. Now, this approach for multitasking doesn't work for all cases.

For instance, preemptive multitasking doesn't give any time guarantees. You can't say a program will run within 10 seconds. The actual duration and timing will vary depending on things like system load. If you need strict timing, then you have to use real-time scheduling, which is a very different approach. This makes Unix a bad choice for anything that's very time-sensitive. Scheduling is a core part of an operating system. As such, systems tend to only use one scheduling approach. S1, however, has it all. That is the theme of the show, right? One is good, but all is better. S1 offers four different schedulers to choose from. Everything is modular, so you can pick

and choose whatever scheduling module suits your needs. You can decide on Voluntary Dispatch, Round Robin, Priority, or Dynamic. Voluntary here is more often called Cooperative. It requires a process to tell the operating system when it's ready to sleep. Older versions of macOS use this approach. Round Robin gives each process an equal amount of time spread over slices. This is the closest to old-school time sharing that was being used on mainframes and some minis. Priority is better called real-time. This gives hard time guarantees and other real-time goodies. Dynamic is preemptive, just like Unix's model. This, I would like to underline, is not normal. But for S1, it's totally possible. Task scheduling is handled by a module, so you get to

it's totally possible. Task scheduling is handled by a module, so you get to choose which one you want when you set up the system. Again, S1 is chimeric thanks to its module system. It's just very clever design. The module system also enables a trick with your software. When you set up S1, you link together whatever modules you want to use. You can also, I believe, load some modules on the fly. A little sketchy on if that's possible, but it sounds like you might be able to do it. Now, what we have more detail on is linking modules to user programs. If you wanted to write a program that uses the printer, but your S1 install doesn't load the printer module, you can link that module to your program.

Modules are just generic packages of code, so there's nothing special or sacred about them. That, dear listener, I think is a hint at something. In the I.O. article, Little is running down a list of advantages to S1. Here is one of the line items, again translated from the original Japanese. Quote, By using this type of OS, the boundary between OS and application program becomes blurred. In other words, most of S1's functions can be freely added to S1 itself and to application programs."

I think S1 may have been using something like a microkernel. The core part of an operating system, the part that actually runs the whole show, is called a kernel. Systems like Unix and older versions of Windows use what's called a monolithic kernel. In that design, everything except for application programs are packed inside the kernel. It's an older and less nuanced approach, a little less flexible too. But S1 has distinct modules. Those can be loaded and unloaded as needed, at least in some cases. That's much more similar to a microkernel. Now microkernels would have been pretty sophisticated at the time. They were used in some research

or some pretty cutting edge operating systems. And oddly enough, the Amiga also used a microkernel-based operating system. It's one of those designs that's not entirely new in the 80s, but it's pretty darn modern. Even if S1 isn't actually using an honest-to-goodness microkernel, it's using a lot of the features and ideas that show up in these more modern designs. It's using a lot of the features and ideas that show up in these more modern designs. With all of these features, I gotta say, I'd really like to try out S1. Who wouldn't? It's extremely sophisticated software. It can do everything Unix can do, and everything DOS can do, plus much, much more.

In fact, you can even use your old Unix software. That sounds like a winner to me. But I don't determine the market, much to my displeasure. Let's look at why we don't all remember using S1 in the 80s. If I had to pick a single point of failure for the story, I'd have to go with Market Strategy. The first big showing of S1 was at 1984's Comdex. Let me read you this excerpt from the Star Ledger's coverage.

It's a longer quote, but I think it sets us on good footing. Here is the Ledger discussing Lombardo's presentation. Quote, Accompanying slides alternatively depicted Unix, AT&T's software operating system, as a dinosaur, a fat naked man, the emperor has no clothes, he told the audience, and a house of collapsed cards. The reaction? Quote, the reception of the audience to multi-solutions was lukewarm to negative, quote, said an industry analyst who wished to remain unidentified.

Quote, their presentation was fluffy and not very substantive, and it was more aggressive than most people do." The article continues, "'It's a calculated, abrasive approach,' said Lombardo, explaining, "'I need to make a lot of noise to get attention first and then I can show you how great my product is. You know, there are a lot of grapes that are juicy and plump that never make great wine because they

were never noticed, maybe." Think about that for a minute. MSI is going after Unix very explicitly. They're taking on a giant. Their product, perhaps, is technically superior to Unix. It's at least using a more modern design, and their marketing theme is more or less, UNIX SUCKS! It's abrasive, it's loud, and it's self-assured. We've seen a pile of reasons as to how this stance could be justified. From what I've seen, S1 on its own could make a claim to be more sophisticated and perhaps even better than Unix. If you're talking about microcomputer Unix in this period, then 100% yes, S1 is definitely a better option. That is, if S1 is actually available.

The matter of availability is tricky. The first ads for S1 show up in 83 or 84. By that time it could supposedly run on the Z80, Intel 8080, 8085, and the Motorola 68000. Those ads claimed that by the end of 84 the 8086, 8088, 8186, and 8286 would be added to that list. It was the everything operating system after all. But those aren't computers. Those are just processors. It's impressive, but where's the execution?

Updates trickled out from articles, trade shows, and updated ads. S1 was getting better and better. It would sell for between $200 and $1,000, and you could call MSI to get more information. S1 even shows up in some computer catalogs. But where are the disks? I can't find any actual install media. I can't find any first-hand accounts of people outside MSI actually using and having copies of S1.

So square this in your head. No one actually has a physical copy of S1 in their hands. The marketing is saying S1 is the best thing since sliced bread and it's gonna destroy the entire market. It's even gonna go punch Dennis Ritchie in the face while it's at it. I think you can see how that would spell disaster. And let me tell you, the ads just get wilder and wilder. There's this poster that supposedly was up either in one of MSI's booths or just around in a trade show.

It's reproduced in a 1985 issue of PC World, and I think this one is the pinnacle. The ad is a painting. It shows two stone tablets labeled S and 1, sitting atop a mountain and struck by lightning. Big bold text to one side of the tablets says, Surely it will come to pass. The tablets contain, The Ten Commandments, Of Multi Solutions Incorporated,

To read from the sacred stones. Thou shalt have no OS before S1. Thou shalt not take the name of S1 in vain. Thou shalt not grep. Thou shalt not sag. Thou shalt not rat for. It continues thusly, listing Unix programs that thou shalt not run. I'd rate this as tacky at very best.

I mean, the parody and cutting remarks kinda write themselves, right? I don't know how you wouldn't see this. Surely it will come to ship. Thou shalt not see a demo release and all that. I can understand having this kind of enthusiasm about a product. I've worked on software that I've wanted to scream from rooftops about. It happens. But it put MSI, I feel, in an impossible situation.

S1 has to not only ship, but it has to be the best thing since sliced bread. They literally have ads that say, in the coming revolution, only S1 users will survive. You can't have a mediocre product if your marketing is like that. mediocre product if your marketing is like that. When S1 doesn't absolutely destroy the market in 1984, or even 85, well, that leads to the wrong kind of talk. The very PC World article that reproduced that poster perfectly outlines this problem. One of the magazine's editors, Robert Lund, went out to learn more about S1. They met Lombardo at a later Comdex show, but didn't get the answers they needed. The editor was looking for a review copy to actually get their hands on S1.

And that makes sense. S1 sounds like the way of the future, just give us some software." Lombardo responded that no, as a policy they didn't give review copies of S1. Quote, "...our staff will be spending all their time answering phones and giving magazine reviewers technical support if I release copies. We don't have the resources for that. Besides, your reviewers couldn't understand it. It's unlike anything they've seen." That is pretty bad. I mean, look, I'm not allowed to talk to clients at my job.

I've before been at companies that have told me after certain incidents to never answer the phones at my job. Even I can see how bad that response is. In the worst case, this means Lombardo didn't actually have anything to ship, that S1 was vaporware. Either that, or he just didn't know what he was doing. Even Windows 1, a program that was believed to be vaporware for something like four years, they shipped review copies. It was just practice. Telling the editor of a major magazine that they simply couldn't understand your software. That's beyond the pale.

This whole interaction got Lunn very, very interested in S1, but not in a very flattering way. Lunn started talking to other journalists and other industry insiders trying to find information about this operating system. What he found was nothing, just more stories of empty promises and people being confused and baffled by S1's marketing and by meeting Lombardo. LUN even went as far as talking to one of MSI's direct competitors. Now, this needs just a small introduction. There was another operating system in this period called PIC. It's very mysterious

and very poorly preserved, but it did exist. I have floppy disks for it on my shelf. PIC. It's very mysterious and very poorly preserved, but it did exist. I have floppy disks for it on my shelf. PIC OS was among S1's targets. There are some S1 ads that explicitly say it's better than PIC and can even read PIC OS disks. The creator of PIC was MrPic. His first name was Dick. I am not even joking. That is his name, and that's how he chose to name his software. When reached for comment, Dick Pick had this to say about S1, quote, It's easy for companies to lay out buzzwords like multitasking, but delivering the goods is no trivial pursuit. Lombardo is a loose cannon anyway. As long as he doesn't aim his guns at me, I don't care."

The competition didn't really think S1 posed a threat. It was more a curiosity than anything. In another tale, this time from Byte Magazine, Jerry Pornell was trying to see S1 for himself. He made it all the way to an MSI booth at some trade show, only to be told, sorry, no demo today. Supposedly the MSI reps had a computer all set up and ready, but it was quote, lost on a truck or something. But there is a silver lining here. When folk did experience S1, they were impressed. It's just that, for some reason, that wasn't the easiest thing to do. Pornell's article in Byte is actually titled, S1 Exists.

He started off as a detractor until he met Robert Knight at Comdex one year. Purnell actually got a demo and walked away as a believer. Apparently in spring 1985, S1 was running on an IBM CS9000 and a Stride 440. Purnell attests to seeing a demo on the IBM machine, it was actually running S1, and the Stride was sitting in MSI's booth. The CS9000 is a Motorola 68000 based machine, and the Stride ran an Intel 286. Those are both pretty different computers, again speaking to S1's portability. This seems to have been the trend.

If you just saw the marketing or interacted with sales and marketing people, then S1 seemed like vaporware. If you saw it running, met night, or got actual details, then you came away with a very different image. It was just a matter of getting the word out in the right way, and Lombardo's marketing approach seems to have not really struck the right chord. Marketing issues aside, there was another problem. For S1, or any operating system to succeed in this period, they needed to get in with

OEMs, Original Equipment Manufacturers. These are the compacts, the decks, the IBMs, the companies that actually make and sell hardware to consumers. There was some market to sell operating systems direct to consumer, but the largest part of the market was cutting deals with these manufacturers. That's what Microsoft did with IBM, resulting in DOS shipping on the PC. MSI wanted to do something similar, but a major deal never worked out. MSI would make licensing and distribution agreements with a number of companies, but

none of them were really heavy hitters. They were going after the likes of IBM and ended up with licensees like Integrated Business Computers and Philips Medical Systems. There's nothing wrong with licensing to smaller companies, but that does go against the bold and brash marketing strategy. Only S1 users will survive the coming revolution and S1 is available via your local IBC rep. Kinda kills the buzz, doesn't it? And it seems that Lombardo knew how dire the situation was.

In the PC World article again, Lund explains that Lombardo wouldn't tell him which vendors would be licensing S1. Again, ouch. But let's take a step back from the gossip and look at the larger picture. In the mid-80s, we reached a turning point. It's true that Unix was a dinosaur and that DOS was a toy. However, that wasn't the whole field. In 1984, the

Mac arrives. Windows, the Amiga, and the Atari ST follow in 1985. All offer users a graphical environment at home. Now, S1 could technically do graphics. At least, it's on the spec sheet. I suspect that any windowing or bitmaps that it could blip were primitive at best, otherwise there'd be screenshots tucked into ads. But this isn't just a matter of capability. Let's look at how these new graphical operating systems were sold. Windows took the tested OEM route. You could buy copies of Windows 1.0 direct, but Microsoft really wanted you to get their software with a new computer. That practice would continue to pick up steam

and really reach its stride with Windows 3.0. When you bought a new PC, it would come with DOS and maybe Windows. Microsoft would form, for all intents and purposes, a monopoly here. They were the operating system provider for PC OEMs. On the other side of the coin, we have Mac OS, Amiga OS, and Atari TOS. These are all in-house affairs. Apple wrote Mac OS to run on their Mac computers, so there was no need to license third-party operating systems. Commodore did the same with the Amiga, and

Atari the same with the ST. That accounts for most, if not all, of the OEMs in the second half of the 80s. Companies like MSI were left picking up much smaller manufacturers. That doesn't make near the same money as a single contract like IBM. In the end, MSI and S1 may have just been doomed because of market forces. There wasn't a lot of space for their business plan. The microcomputer market was ready for more competent operating systems, that much was true, but it ended up coming in the form of graphical systems. Maybe in that sense, the marketing didn't even matter.

S1 could have just been stuck in this weird lurch from the beginning. Alright that does it for the tale of S1. So what have we figured out? First of all, S1 did exist. If the sources are to be believed, and I believe they are, then it was a very sophisticated operating system. It used an approach that at least rhymes with a microkernel. It could be ported to just about any platform and run just about any software. The wild claims made in ads were

all true, and it was all possible thanks to very carefully and thoughtfully designed software and especially designed language. It wasn't vaporware, per se, but from the outside, it definitely looked and acted like vapor. S1 didn't make it very far outside MSI either. According to Knight, there were at least two customers running S1. It worked well enough to demo, it was just never shipped out at any kind of scale. Aggressive and brash marketing made it easy to view S1 as fake, possibly a scam even.

But the few that saw S1 in action immediately learned that the hype was justified. It was exciting software that just wasn't able to catch on. Could S1 have ever made its mark? Well, I think there could have been a chance. There were a few offhanded comments that I ran into while compiling this episode. Some early articles mentioned that S1 was revolutionary because Knight was bringing features usually found on mainframes down to the microcomputer level. We're talking things like multi-user, multi-tasking, virtualization, and modularization. There is another article, much later, that offhandedly mentioned S1 should be careful

about getting stuck on small machines. That it should use its flexibility to court larger systems. Maybe, and this is me speaking here, even pivoting up to mini computers. That would mean taking on Unix in its own ancestral domain. Perhaps in that market, S1 could have been better understood. It could have been used by more experienced users. Perhaps the marketing could have broken that nut. And perhaps the market would have been more pliable. But at the end here, all we can say is that S1 was an impressive feat of software engineering. I, for one, would have loved to run it on my home computer. Thanks for listening to AgriNove Computing.

I'll be back in two weeks' time with another piece of computing's past. computer.