Advent of Computing - Episode 149 - IDRIS Is Not UNIX

Episode Date: January 5, 2025

This episode we are taking a trip back to UNIX world. We're looking at IDRIS, the first clone of UNIX. It was supposed to be highly compatible, but use no code from Bell Labs. IDRIS ran on everything from the Intel 8080 up to the IBM System/370. There was even a version that could run MS-DOS programs. Sound too good to be true? Well, that may be the case. Selected Sources: https://archive.org/details/aquartercenturyofunixpeterh.salus_201910/page/n196/mode/1up - A Quarter Century of UNIX https://github.com/hansake/Whitesmiths-Idris-OS - Co-Idris disk images and executables

Whitesmiths Limited of New York were the first to market a look-alike Unix for the LSI 11, which users could run without obtaining a license from Bell. Here is a short description of their Idris system from the Spring 1980 issue of the Whitesmith Software Catalog. Quote, The LSI 11 Idris operating system is a multiprocess resident operating system for the DEC-LSI-11 microcomputer. It supports file systems compatible with Unix v6 operating system and accepts Unix system calls except ptrace. The system includes an assembler, loader, text editor, command interpreter shell,

librarian, and sufficient additional utilities to permit the development and maintenance of new programs that operate under the system. On an LSI 11 with 60 kilobytes of memory and sufficient secondary storage, the system enables the PDP 11 compiler from Whitesmiths Ltd to replicate itself and the operating system which is predominantly written in C." Welcome back to Advent of Computing. I'm your host, Sean Haas, and this is episode 149, Idris is NOT Unix. And that's right, we're in for another unix episode at least kinda let me explain

That quote from the opening is from a 1981 article in an ACM newsletter The article is simply titled unix on a micro and it's kind of cursed now. I mean that with all due respect I really like this article. It's just weird. The premise is simple. It's a quick survey of different ways to run Unix, you know, on a microcomputer. That sounds pretty boring, yeah? Well, if you remember the Xenics episode that I ran about six months ago, then you know, at least you have an idea of what we're in for.

In 1981, Unix didn't really do microprocessors. The state of hardware just wasn't quite up to the task, not yet at least. I actually ran into this article when I was working on that Xenix episode, and since then, it's been sticking in the back of my head. One reason for that is that way back in the day I went through a bit of a Unix phase. It was just as I was getting really into computers. I was comfortable with my old hand-me-down DOS machine and had just gotten my hands on some kind of Pentium. A friend's family was throwing the thing out, so I decided to help them out, save them a trip to the dump, you know.

Very considerate, if I do say so myself. I had read in some textbook or something about this thing called Unix, and I was immediately fascinated. I would eventually get a copy of Linux format and get into the Nix world, but that wasn't Unix. Ever since then, the idea of Unix on small hardware has fascinated me, and here's this paper that's right at the start of that phenomenon. What makes Unix on a Micro so neat is that it's full of vaporware, bad information, and

disappointment. It straight up mentions that one Unix was about to be released, and then the company went bankrupt and so it never came out, but it does exist somewhere, I'm sure. I don't think the paper is even proofread, there's a bunch of spelling errors and grammar errors all throughout it. You may call me a trash man because I love this kind of garbage. I love this kind of weird gossip. My initial plan was to pick out three of these unixes that were particularly interesting and cover them grab bag style. I even had the three picked out. But as soon as I started researching, I ran into an issue. I got stuck on the first Unix. It turns

out that even footnotes can carry some weight. This episode, I'm going in blind and learning everything I can about just one of these strange micro-Uniqs likes. The topic for today is Idris, what's purported to be the first clone of Unix. There's no end goal here, no real lesson to learn. Let's just have some fun digging into some strange and perhaps improbable software. I'm gonna be frank here. At first I thought Idris was another example of vaporware. That's one of the reasons that it really hooked me. All of the service level details make Idris sound fake, make it sound like a hoax.

It was a Unix compatible and written in C. It ran on a dozen different platforms from the PC to the Vax, the Mac to IBM's System 370 mainframes. There was a version that was just a DOS executable that could also run DOS programs. There was a version for the Atari ST that came on a ROM cart. To top things off, the first photo I ran into, and the only photo I have ran into that shows anything purporting to be Idris, is a tiny low res picture of Unix running on an Atari computer. That sounds, quite frankly, fake. It sounds like vaporware, or some story that was made up for a good laugh.

I think the biggest red flag for me is the list of platforms. There's no way that's real, right? Well, dear listener, Idris is very much real. You can even find archival software. I've even been able to run Idris on my very own computer. It's sitting on the floor next to me. I'd turn it on, but it would bleed into the microphone. So what's sitting on the floor next to me. I turn it on but it would bleed into the microphone. So what's going on? Well, let me warn you, the details get even more unbelievable in spots.

The story of Idris should sound somewhat familiar to long-time listeners. It's another Unix clone that grows out of a company making a CD compiler. Everything starts with the founding of a company called Whitesmiths. The company was formed by Mark Krieger, Gabriel Pham, and PJ Plager in... probably 1978. I say probably 78 because I don't have a direct primary source here. There's some later recollections that say 78, but they're much later. Copyright and trademark records all set a date in the early 80s, but there are interviews and ads from 1979. I'm settling on 78 because that's when their first product was launched and that just

makes the most sense with the chronology. This kind of confusion isn't too strange. The start date of a lot of old computer companies can be hard to nail down. I found this especially true with software companies. My personal theory is it's because writing code is easy and coming up with ideas is easy, but paperwork is a little more time-consuming. Sadly, we know almost nothing about Krieger and FAM in this period. Krieger would eventually leave the company to work at UniPress. When it comes to Plager, however, we actually have a lot of good information. I'm going to be using Plager as my point of view character here, but that doesn't necessarily mean he was the most important person at the company.

But that doesn't necessarily mean he was the most important person at the company. It's just that we have actual information on Plager. Prior to Whitesmiths, he worked at, drumroll please, Bell Labs. So he's coming direct from the heart of Unix territory. Specifically, he was hired by Bell in 1969. According to tradition, that's the year that Unix was born. It's literally the start of the Unix epoch. So, Plager is in the epicenter of the phenomenon. At least, it seems that way if you just look at his resume. In an interview for the book, A Quarter Century of Unix, Plager explains that he was more on the periphery.

He spent his first few years at Bell wandering between labs and projects. By 74, he settled into the Murray Hill office, where the authors of eunuchs lived and worked. This is where Plager struck up a friendship with Brian Kernigan. As he put it, quote, Brian and I were really very good at drinking coffee and shooting the bull several times a day, end quote. That's a pretty classic style of office friendship any salary worker will be instantly familiar with. Kernigan ends up becoming a crucial figure in the spread of the C programming language and Unix. In 1978, he co-authors a little book called

The C Programming Language with Dennis Ritchie. This is usually just called KNRC, named after the author's initials. It's also the first book on the new language and becomes the first rough standard for C. Kernigan is also a big figure in the development of Unix. As always, C and Unix are tied at the hip. He develops Auck, a string processing tool that's the wonder and bane of many Unix programmers, even into the modern day. According to some traditions, Kernigan came up with the name Unix itself, and may be responsible for the popularity of the Hello World program.

In short, he's a big deal. He's also how Plager gets connected to the Unix world. It sounds like Plager and Kernigan became fast friends because, in short order, they co-authored a book. That book, The Elements of Programming Style, was published in 1974. This is something of a style guide for programmers with classic elements of hacker humor. It teaches such lessons as, quote, make sure special cases are truly special and 10.0 times 0.1 is hardly ever 1.0. What's interesting is that despite coming from inside the walls of Bell Labs, the elements

of programming style makes no mention of the C programming language. The book uses Fortran as its example language. C had yet to hit it big on the outside. It wouldn't make much sense to publish a book about programming style that uses a language only a handful of programmers really knew. In this same time period, 74-75, Plager may have worked on the C compiler. Now this is a little speculative. He at least learned and worked with the language while at Bell.

I haven't found a direct claim by Plager, but he implies that he got some compiler experience at Bell. I haven't found a direct claim by Plager, but he implies that he got some compiler experience at Bell. But his time at the lab was drawing short. As he put it, quote, I felt that I didn't have a future there and that I'd better move on before they asked me to move on, end quote. He'd get a job lecturing about programming for a few years. That worked for a time, but wasn't really what he wanted to do. He wanted to get back to Unix. He wanted to get back to software. In 1978, Plager started doing some contract work under a company called Yordon.

At this gig, he ends up, under contract, writing a C compiler. This is also where he meets Krieger and Fam. This phase though doesn't last very long. Before 78 is out, the trio bails and forms Whitesmiths. Their first office was an apartment in New York City, and that's the setting for many stories from Whitesmiths early days. Before we go on, I should explain the name. Krieger explains it like this in an interview with Infoworld. This is also the only interview we have with Krieger. Quote, it was made up by Bill Plager.

The name Whitesmiths was viewed as the opposite of Blacksmiths. A blacksmith worked in hard goods and a whitesmith worked in soft goods, a la software. We also discovered that Wh whitesmiths in the Middle Ages were the tin and silver workers, the workers in fine products." You gotta love that kind of stuff, right? That's a pretty classic hacker-style joke, and a little bit groan-worthy, perhaps. But at the same time, the cleverness has frustrated me to no end, since whitesmiths are a real thing, and show up in the historical record, it can be a little hard to search for sources about the company.

Now, the core business plan for whitesmiths all revolved around C. By 78, the language had broken containment. Folk knew about C and they wanted to start using it. But that was tricky in this period. Unix came with a C compiler, but Unix at the time only supported a few platforms, namely the PDP-11 and Interdata-8. That's not a big spread. But actually getting a copy of Unix was a bit of a strange process. The licensing process was a shifting target, and not everyone could license Unix. The C compiler that Plager wrote at Yordon was actually one company's attempt to get

around the Unix issue. To quote again from a quarter century of Unix, I worked around the clock for a week. It wasn't the greatest compiler in the world, but it was adequate. And along the way I learned where the market was, because people would come to me and say, we don't want all that Unix stuff, we just want C." Unix and C were tied at the hip, and not everyone liked that. Hiring a contractor to write a C compiler, that may sound a little heavy handed, but I think that should give us an idea of how desperate some

companies were. When WhiteSmiths started up, their main business plan was, accordingly, to make a fully commercial C compiler. They wanted to bring a compiler to market that could be bought off the shelf, like any other software, one that would exist outside the Unix ecosystem. That, however, had its own issues. For one, C wasn't actually standardized yet. ANSI-C, the first official standard, isn't pinned until 1989. As such, any C compiler was going to be a little non-standard. C itself is a very simple language. You don't need a whole lot of a standard to tell you how to place curly braces and how pointers work. But that's only part of the equation. C as an application language relies on a set of libraries, a set of standardized libraries. These provide support for things like printing to the screen, loading files, string processing,

and any kind of system call you might want to make. That's sometimes called libc, the C standard library. Early versions of whitesmith compilers have a bit of a reputation for using strange, non-standard names for their libc functions. You won't find the classic printf, for instance. I bring this up because when you poke around for accounts of these compilers, you will mainly find this complaint even once their compilers switch to using standardized names. Complaints aside, Whitesmiths actually gets their first customers fairly quickly, yet again proving that the market was ready for C without Unix. Plager gives this fun description of the sale, quote,

They said, we see you're doing C compilers. We're in the market for one. Can you come down to Philadelphia? But I said, no, I'm too busy. You want to talk, you come here. And they did. They sent three people up to New York and we sat in this little apartment on West 79th Street and we told them what we're planning. And they said, we want what you've got. We want everything you say you're gonna do for the next three years." End quote. This is while Weitzman's first C compiler is still under development, yet within a few months, they would deliver, initially for the PDP-11. But the great thing about C is that it's meant to be portable, and since Whitesmith's C was separate from

Unix, it could be ported pretty quickly. By 1980, the company offered a compiler for the PDP-11, the Intel 8080, the DEC VAX, and the Motorola 68000. That's running the gamut from 8-bit processors to 32-bit mini-computer. What's neat is that in this lineup were a number of cross-compilers. Plytemps sold a compiler that ran on the PDP-11 but would output binaries for the 8080. Who would want that? Well, in a word, businesses. This let software houses work using a PDP-11 then ship software for microcomputers. You could use a more sophisticated environment for development but still sell programs to CPM users.

This ended up working as a business plan fairly well. In 1980, Krieger estimated they had sold between 225 and 250 licenses. It's hard to estimate revenue from that, since those were licenses for a whole pile of different products. But we know that their CPM version of the compiler sold for around $600 in 1980, which is just under $2500 after inflation, so there's some good money here. But, dear listener, Whitesmiths wasn't a one-trick act, and we know that Unix and C are tied at the hip. You see, this compiler was just the opening act for a much larger project. We glossed over an important point a little earlier. In 1978, there was still resistance to Unix. Why was that? Why weren't nerds the world over ready to embrace the Unix future?

How could they be so deluded? Well, porting and licensing were two main issues, as I mentioned. Unix was written in C, so it was portable in theory. In practice, early versions of Unix didn't really like to move around. Licensing was also restricted to universities and research outfits. Even then, a license could be pretty expensive. Unix just wasn't really commercialized. It also lacked a certain maturity.

That's a buzzword you hear a lot around computing, and it's one that's kind of hard to quantify. Eventually, as a language or operating system or computer ages and grows, it hits this stage where things just click. Stuff works. There's enough support that you don't need to jump ship to solve problems. There's enough software that you can really get comfortable.

There's enough experience around that you can actually learn the system. You can hire someone who's, say, a Unix sys admin. In the 70s, Unix wasn't quite there yet. It was still missing a lot of the features that we know and love today. A big shift happened at the end of the decade. To quote, the advent of version 7 in 1979 brought new attention to Unix. Many of the previous rough spots had disappeared. The maximum file size had grown to 1 gigabyte, and a standard I.O. library had been introduced. During this period, microcomputers running Unix appeared, and Unix lookalikes such as

Whitesmith's Idris and Mark Williams' Coherent emerged." David Friedler in Unix in the Marketplace for Byte Magazine. So what was so great about this new version of Unix? The file system bump was one thing, but that's small potatoes in the grand scheme. Many have said that v7 is when Unix becomes Unix, when it becomes recognizable. It's when C's STDIO library is first introduced, which has such hits as printf, all file handling routines, and even introduces null to the language. malloc is also introduced, the now familiar memory allocation call. Environmental variables show up for the

first time. So does the Boren shell, which is still the default interface for most Unix-like systems. That includes your favorite Linux distro. Another huge change, and perhaps the most consequential, was that v7 Unix shipped with a new C compiler. It was called PCC, the Portable C Compiler. As the name suggests, this new compiler was designed specifically to be portable. All machine-dependent code was minimized and packaged together. That way, parting the compiler was as easy as rewriting one or two files. In turn, this made V7 Unix itself more portable, since Unix had

to be compiled from C. This all combined to form a snowball kind of effect. Unix could now be ported to more platforms more easily. That meant more people could be exposed to Unix. In turn, that meant more software could be written for Unix, which would make Unix a more enticing platform. More people would get experience with Unix. The final piece is that Bell Labs started to promote Unix and started to publish documentation and articles about Unix. You can actually get user and programmer manuals now. This was a mature ecosystem.

This is what maturity looks like, and this is how Unix starts to really pick up steam. Then how does this open up doors for clones? That gets into the complex realm of Bell and their antitrust dealings. Bell was subject to a number of court rulings that prevented them from selling anything unrelated to telecom stuff. They had to be a phone company, or else. That's why Bell could never directly sell Unix. They could license it in a number of circumstances, but not sell it directly. We saw one way this worked a few months ago when we were discussing Microsoft Xenics.

In that case, Microsoft acquired a license to the Unix source code. Microsoft then turned around, worked up a binary distribution, and sold that on to other companies that would actually sell disks. It's layers on layers. In practice, not everyone could work up such an agreement. As Plager explains in A Quarter Century of Unix, quote, I really wanted to sell Unix. I spent some time talking to the Bell lawyers before I realized that, because of the consent decree, they just weren't gonna do it. Marketing was a dirty word, a dangerous dirty word, and I had to decide whether I wanted to fight to sell Unix or whether I just bite the bullet and

knock it off. It wasn't an easy decision. My goal was to fill the lower niche." This would have been around 78 or 79, the same time frame where V7 was being finalized and released. Also, incidentally, the same time that Microsoft was negotiating their own license agreement. Companies could, in some cases, get license agreements. Institutions could make their own distributions of Unix or use existing ones like BSD. But when it came to the smaller end of the market, small offices and home users, there wasn't really an easy way to get access to Unix.

Plager wanted to fill that gap. It's worth noting here that licensed Unixes, like Zenix, wouldn't hit shelves until the early 80s. These distributions did target microcomputers, but in most cases had severely limited feature sets. The PC version of Zenix, for instance, couldn't do memory protection or multitasking. So even if you waited around for a thoroughbred version of Unix, it may not have been that useful. That means that the big value proposition was availability. So while Whitesmith was slowly accruing customers for their C compiler, they started up another project. That project was called Idris. I seem to remember reading that it was named after some Persian god, but I can't find that exact statement now, and I also can't find a Persian god that

matches that name. Inspiration aside, this was planned to be a fully functional and cross-platform clone of Unix. But what exactly is meant by Unix compatible here? That gets complicated really quick. First off, we aren't talking binary compatibility. You couldn't take an executable compiled under Unix v6 and move it over to an Idris machine and just run it. I mean, first there's the simple fact that Idris ran on different computers than Unix did. And second, there's the

fact that addresses and system calls wouldn't line up. Instead, you could take source code written for Unix and compile it under Idris. Of course, that would be done using Whitesmith's C compiler, which, as we discussed, had some pitfalls. Not all library functions lined up exactly, but that's not really a knock in this period. The standards around that were changing quickly as Unix was growing, so I don't think there would have been a perfect solution here. In practice, that meant that Unix programs would need a little touch-up before compiling for Idris. This was further complicated. Idris started development just before v7 hit the scene. As such, all the initial compatibility features of Idris were built to match

Unix v6. That could lead to some more practical issues with to match Unix v6. That could lead to some more practical issues with migrating Unix code to Idris. However, in general, Idris worked the same way as Unix. There are some huge caveats there, but we'll get to that eventually. Idris had an equivalent set of system calls. It used memory in a near-identical way. Idris could read and write the same file systems as Unix. If your disk drive's lined up, then you could write a floppy from a Unix machine and read it under Idris. Files are also handled the same way, and you have all the

superficial things like a similar shell and commands with the same names. Then, what was the difference? That gets to some really interesting and really weird little details. First, let's start with memory. If you remember the Xenics episode, you probably know where I'm going. Unix has very few hard and fast system requirements. One of those is that it requires a memory management unit or MMU. That's a circuit that's used for memory protection and virtual memory. It's what keeps processes from touching each other, and it can be used to trick processes into thinking they're running in their very own isolated chunk of memory. Unix also uses the MMU so it can load programs anywhere in memory. This is a neat sleight of hand. You can configure an MMU to map a so-called

logical address of memory to some physical location inside your chips. When Unix loads a program, it allocates some memory for the program. That can be anywhere. Then it sets up the MMU to expose the start of memory in that address as zero. That way a program can be loaded anywhere without issues with pointers or addressing. That's pretty fundamental to how Unix works. This means that traditionally Unix cannot run on computers without MMUs. The IBM PC doesn't have an MMU.

PC Zenix got around this by crippling Unix. It can't protect memory, it can't load multiple programs, it can't swap. It's missing a lot of Unix. In general, ports of Unix to these smaller platforms have some kind of compromises to get around the MMU issue. Idris, on the other hand, doesn't contain a single line of Unix code. It doesn't have to have the same pitfalls. Idris was able to operate either with or without an MMU. One of the reasons for this is that the first platform Whitesmiths targeted was one of the smaller

PDP-11 models that did not have a memory management unit. So then, how does Idris operate without that circuit? Things are a little vague, but we have a general idea. Documentation calls it a quote emulated MMU or a software MMU. Now, I don't know how it does protection, but I do know how it handles very primitive virtual memory. Normally, every time you reference an address, the MMU will map that request over to a physical place in memory. So, if you ask for address 0, the MMU goes to its little table and passes you over to some other address. This is all done at runtime, while the program itself is being executed.

Idris does that mapping, that address swapping trick, on load time. That means that when Idris loads a program, it looks through the binary file and replaces any references to addresses with some magic mapped address. Idris itself finds, using software, every time you ask for something like address 0 and rewrites it to reference some other address. That will work. It's a little finicky, but it will function. The issue is that once you modify that program, it can't easily be moved

to another location. Idris is rewriting all the addresses to match some load address. That's not truly relocatable, but that's how Idris is able to work on smaller machines. On its own, that's quirky and neat. But check this out. Idris was also a real-time operating system. Now, I know that probably doesn't hit very hard for most of you. The short story is, that's weird. Unix isn't real-time. Most operating systems aren't real-time. It's actually pretty hard to be real-time. So, what's up with that? to be real-time. So, what's up with that? First, let me cover the basics. Real-time is one of those phrases that's been reused for a few different things over the history of computing. In this period and in this context, real-time means a very specific type of process scheduling.

In a real-time system, operations are guaranteed to either run at a specific time or run in a specific amount of time. This is often handled using events. You'll set up certain tasks to be executed after some event occurs. Say you need to check a bus for a signal every 100 milliseconds. You set your system clock to generate an event every 100 milliseconds. You set your system clock to generate an event every 100 milliseconds, then you tell the operating system to run your bus checker whenever that event fires. That's often complemented with very predictably timed operations. You might know that that

task will take 10 time chunks to run. Real-time systems are meant for things like industrial machines, think factory equipment, communication systems, anything with very tight and predictable timing constraints. This is in contrast, in most ways, to more user-oriented machines. Unix is a time-shared environment. It doesn't really care that much about timing, more about splitting resources relatively fairly between processes and users. Idris is interesting because it could work as both a real-time and more traditional time-shared system. To quote from one volume of Unix World, Idris uses a, quote, hybrid scheduler, which provides

the benefit of event and priority-driven schedulers by establishing a priority between processes' priority and the time quantum to which it is allocated, Idris can adjust priorities as these time quantums expire. A built-in mechanism ensures a kind of fairness relative to how long a given job must wait in order to run." That is to say, Idris had a very sophisticated process management system. It implemented something similar to Unix's process system, plus expansions for real-time processing. That's not only unusual, that's fairly complicated. All of this was paired with highly portable code. The fact that Idris was written

in up-to-date C, that Whitesmith's C compiler was portable, and that it didn't need an MMU, meant Idris could run on just about anything that ticked. They started with the PDP-11 and LSI-11, the microchipped version of the same computer. This was followed up with a version for the Intel 8080 and Zilog Z80, then the Motorola 68000, DECVAX, and Intel 8086. That spread meant that Idris ran on just about any hardware you wanted. I've also seen it stated that Idris ran on IBM System 370 mainframes, but I don't know if I believe that. I haven't seen any sources to back that up. In that lineup, the Intel chips stand out to me.

The 8080 because of its tiny size, and the 8086 because of the PC, or the 8088 if you wanna pick nits. The PC part we'll get back to. As for the 8080 claim, we know very little here. After that time, claim it was able to run on any quote, bank-switched 8080 or Z80. One of the issues with 8-bit computers is their memory space. To be clear, it's very small. Bank switching was one way to access larger amounts of RAM. The idea of an 8-bit Unix is also wild to behold, but there's just so little information

here. We will find that that's the case with many of the ports of Idris. The 68000 port is also worth mentioning for a few reasons. Firstly is the fact that that chip shows up in the Apple Macintosh and Atari ST. It ends up being well positioned for the home. And secondly, because the 68000 is used in many early Unix workstations. Here I'm talking about things like Sun's workstation, or the NeXTcube, SGI machines, the list is actually pretty large.

These were all computers meant for heavy use in offices that all ran some type of Unix. So it's interesting to see that Idris would also be compatible with that type of computer. That's just about all the finer details that matter, which means I can introduce a bit of a complication to Whitesmith's business plan. The goal of Idris was to be a cheap way to get Unix on a computer. How cheap? Well, that depended on the platform and the package.

Idris could ship as a minimal install, with a C compiler, with added tools, and even all the way up to source code. The cheapest versions were around $500, with some distributions bumped up to $1000. You could license source code, but that was much more expensive. If we were in 1978, that would be a really good deal. Licensing Unix from Bell came at various costs over the years, but the number that I usually see quoted is $20,000. That's a pretty rough estimate, but I think it's clear to see that Idris was a very good value proposition. Idris was also the first clone to market, so it was well positioned to be a real winner.

So what's the complication here? Well, we've already seen one, Xenix. There were actually a number of officially licensed Unix distributions that show up in the very early 80s. Xenix is a bit of an odd duck here due to Microsoft's business model at the time. They prefer to license Xenix to computer manufacturers, so the fee would be wrapped up in a larger bundle. The prices I've seen quoted are between 500 and 800 so it's in the same ballpark as Idris. There were a number of other official Unixes in that same sub $1,000 price range. Then there's the matter of Mark Williams Coherent, another Unix clone made at a dietary supplement company. This was another 100% Unix-free Unix system.

It offered similar compatibility features. It ran on microcomputers. It came out in 1980 and cost around $500. The point is Idris hit the market just before competition emerged. There are a number of reasonable options all at a similar price point, all with similar features. That's a recipe for a tough time. To win out in this kind of market you usually need some differentiating factor, something that sets you apart from the competition. But when it comes to compatible systems, that gets tricky.

The whole reason to buy a Unix compatible system is to run Unix software. You just want Unix. Everything has a C compiler, runs some text editor, and can execute your favorite version of Fortune. You can't shake things up too much, or you risk breaking compatibility. This may be one of the reasons that Idris goes the real-time route. It sounds like early versions of the operating system already had some real-time features, but as it matured, more features were added.

Idris became more and more real-time-ish in order to court a market niche. At least, that's my reading from the very few sources I have to work with. I want to spend the rest of the episode looking at a few particularly strange expressions of Idris. This is, I think, the other way that quitesmiths try to make Idris stand out. But before I go on, I want to drop in a story. This is one of those little tangents that I think is worth the time. You see, paired programming may have been invented during the development of Idris. Plager is often credited as the creator of paired programming, much to the chagrin of many a

practitioner. The concept here is simple. Two heads are better than one. In paired programming, you sit down two programmers in front of one screen. One programmer drives, actually typing. The other shoulder-surfes. They watch and critique. When the driver gets sick of this arrangement, the programmers switch chairs. When done well, this can be a pretty sweet setup. It's a way to collaborate, in real time, on tasks that can't be broken up into separate units. You can bring double the experience to a challenge. And, if there's an imbalance of experience, it can serve as a way to help train the less experienced programmer.

That is, assuming communication is clear and respectful, paired programming can just as easily end in some impromptu bare-knuckle boxing. You may choose to avoid pairing on Monday mornings, specifically. The story of pairing comes to us from The People Wear Papers by Larry Constantine. Quote, It took P.J. Plager, though, to really teach me about the benefits of visibility. Shortly after he starred at Whitesmiths Limited, I visited him at their New York quote-unquote headquarters, a small apartment in Manhattan.

Somewhere off in one of the rooms, there lurked a mini-computer. Stuffed in a closet in order to keep the clatter down was a printer. And around what should have been the living room were scattered several terminals. At each terminal were two programmers." According to Plager, this practice not only increased productivity, but actually saved Whitesmith's money. The code that came out of these pairs was better quality. So, when we're talking about Idris, don't just imagine some programmers working in an apartment in New York. Also imagine that they're working in teams.

One of the reasons I'm drawn to these weird Unixes is because they always defy expectations in some way. Coherent is interesting to me because it's a total clean room style implementation. Bell was even considering suing Mark Williams company over Coherent, but their own tests proved that it didn't use a single line of Unix's source code. Xenix is interesting because of how it handled small platforms. Sure, it compromised a lot of crucial features, but it was Unix, and it did work on an IBM PC. You just have to stretch your definitions of work a little.

I hope I've already shown why Idris is interesting. If I haven't convinced you, then don't worry, I still have a trick or two up my sleeve. Idris ran on just about everything that included Microsoft DOS and Mac OS. That's right, there was a version of Idris that ran as an application. This I think is the wackiest side of the system. Why is this so wacky? Simply put, operating systems don't really play along with each other. When you run an operating system, it gets full control of the computer. In fact, it has to have that.

The whole job of an operating system is to allocate resources to running processes and manage computer hardware. You can't really have two operating systems competing for the same hardware. That just doesn't really make sense. Now there are ways to make this happen. One common approach is to use an emulator. This will present a fake computer that you can run some other operating system on. In this setup you have a host operating system, whatever's running on the real computer, and then a guest, the operating system that's trapped in your little emulation cage.

There are some very sophisticated ways to do this going all the way back to the mainframe days. IBM famously had an entire system just for pulling this trick. Today we commonly use things like Docker or VMware to do the same thing. But that's all big and modern stuff. And all this relies on tricking the guest into thinking it's running alone on a computer. That's not the case for these guest versions of Idris. I'm going to kick things off with the DOS version, since that's the best preserved. In fact, we have full documentation and disk images for this. I've even been playing around with this version of Idris.

The program is called Co-Idris. Once installed, you can boot into DOS as usual. Then you type Idris and boom! You're in the Unix world! You can quickly switch between DOS and Idris. You can even run DOS software from inside Idris itself. And this is all happening on an Intel 8088 processor. That, dear listener, shouldn't be going on. That's weird. This is the kind of thing that I wish I could have experienced as a teenager.

I was actually able to get Doom running under co-Idris via DOS. It's, I don't know what else to say. This is cool software. And the use case here, at least I think, is relatively clear. Sometimes you need to use two different operating systems. I've had to do this before professionally. One time I had to write a program for Windows, but all of my tools ran on Linux. I have friends that have done app development on Windows targeting

iOS and Android. In all those cases, you're not only being very professional, but you also need access to multiple operating systems. Co-Idris would let you do something like write DOS software using Unix tooling. That's actually something I do routinely. I'll write DOS programs using Linux. It's a real treat because Unix-like systems have really good programming tools. I'm sure there are more mundane reasons to do this setup also. Maybe you just have to run Lotus 1, 2, 3, but also have access to some specific networking tool. Whatever the case, co-idris could have been a very, very powerful office

tool. So, how does it work? What's going on here? Well, it's not emulation. Nothing so simple. My understanding of Co-Idris is being stitched together here from a number of sources, its documentation, a 1984 PC Magazine article, some gossip in the talk tab of a Wikipedia article, and my own experience playing around with the platform. I know, how's that for a bibliography? First of all, you can set up co-idris in a few ways. You can make an entire hard drive partition for idris to use. In that case, I think you might be able to boot right into

Idris, but that's not the primary use case for this setup. If you go the partition route, you can actually have a nice isolated space for Idris to work with. You can even set up a swap partition, which is a Unix trick used to increase its effective memory. So, that's something I wasn't expecting, but Idris can actually swap on a PC. The other option is to use a disk image. At least that's what I'd call it. The documentation literally just calls it a quote-unquote large file. Very technical stuff here. It's just a file that acts kind of like a disk drive. When co-idris is set up like this,

the image is mounted as a drive. That may sound exotic, but Unix actually has the tooling to do this already. You can take a disk drive, copy all its contents into an image file, and then mount that file as a disk. In fact, that's exactly how co-idris is doing this. When you start co-idris, you specify a path to mount as the root file system. That can be a partition, a disk drive, or just a file. That disk, be it partition or image, has all of idris installed on it. That's where Unix lives. The DOS program, idris.com, is just 46 kilobytes. That's simply not big enough for a whole Unix install. So what I think is going on is that the DOS side simply kicks things off. It loads the disk image and starts executing Idris

from that image. At that point, execution is handed over to Idris completely. This is possible because DOS is dead simple. First of all, DOS offers no protection of any sort. A program simply takes over the whole computer at any time it feels like. That's how programs normally function under DOS. They're loaded to a set memory location and DOS just jumps there. You can run DOS programs from co-address because the requirements to run DOS programs are also very low. DOS provides almost no runtime support, like being honest here, many programs just ignore the fact that DOS even exists. The runtime support that is there is handled by interrupt calls, which DOS sets up when it boots.

Co-idris just leaves those in place. Then it can pretty simply execute a DOS program. Returning to DOS is, similarly, a simple affair. When a normal DOS program wants to exit, it just calls up an interrupt routine to say, hey, I'm done. The routine then tries to load command.com off the boot disk. Basically, whenever you go back to DOS, it reloads most of itself into memory. Co-IDRIS does that sleight of hand. The state of IDRIS is kept on the disk image or partition and DOS boots right back up. The final trick is multitasking.

I mentioned earlier that Idris did some strange things to multitask on systems without MMUs. Well, for co-Idris at least, it uses a more simple trick. The compiler that ships with co-Idris is set up to generate code using only relative addressing. That is, the final machine code doesn't reference any address by number. All addresses are referenced by offset within the program. That way, a program can easily be relocated. Thus, you can have multiple programs loaded at once.

Simple. That's it, and it works. Co-idris on its own should be freaky enough to turn your head, but there's more. Whitesmiths just keeps on giving. But to be clear, Co-idris is the best documented and preserved of these oddities. From here out, we're entering the realm of mystery. The next stop on our tour is Mac Idris. This one we know almost nothing about, but we do have a few articles and a little speculation to go off of.

Mac Idris, all one word, ran as an application under macOS. It used the same disk image mechanism we saw with Co-Idris. I would also suspect that it does the exact same image mounting trick here. One funny thing is that Mac Idris is a bit of a latecomer. It's released by Whitesmith's Australian branch in 1989, and that's right, they had an overseas concern by that point. By 89, the Mac had entered a weird phase. It already supported simple multitasking using the multi-finder. That let you switch between Mac programs. And well, Mac Idris is just a program that runs on your Mac.

So you could swap between a running Unix program and a normal Mac program. Imagine switching between Photoshop and Vi. That's gotta have been slick. The late start also means there was competition. In 1988, Apple announced AUX, their own licensed port of Unix. The issue here is that AUX was purebred, so it needed an MMU to operate. Not all Macintoshes had that chip, so there was still space for smaller versions of Unix. That's where Mac Idris shined. It was able to run on hardware as limited as a Mac Plus and Mac SE. But that's about all

we know. We don't have disk images, we don't have screenshots, we don't have manuals. There may be disks still out there. This is something that if it ever surfaced, would be really, really cool to see in action. The final oddity and mystery that I'd like to present is Idris for the Atari ST. Now I was just going to say this existed, but in the 11th hour, I actually found a trove of documents to work off. There were two big articles in Computer Shopper in 1988 that talked all about Idris on the ST.

This was one of the first mysteries about Idris that I ran into when I started working on the episode. The Wikipedia article for Idris is, well, I love Wikipedia, but it's lacking in many regards. Its sources are all broken links. It doesn't cite much, but it has one photo. It's this very low resolution image of something running on an Atari ST. The caption says it's running Idris and X windows, which might be a little hard to believe. The only other information is that it booted off a ROM cart, and it was ported by a third party. That's it. We don't even get a name for the product. This is the kind of hazy digital memory that really gets me excited. I want a cartridge

I can plug in that plays Unix. So here's the scoop. This did exist, but we have scant information. ST Idris, which I've decided to call it for lack of an official name, was a standalone operating system. It wasn't a guest like MAC Idris or CoIdris. It was ported to the ST by Computer Tools International. Whitesmiths already had a version of Idris that worked on the 68000 processor, the very chip inside the ST. Computer Tools took that existing port, wrote custom device drivers, and bundled it up for the Atari machine. From everything

I've read, it sounds like once you booted it up, you were in a very standard Idris setup. At least, as standard as you can call Idris. It did multitasking, multiple users, and even did the whole MMU emulation trick. As for X Windows, well, that's the mystery. One of the articles in Computer Shopper is actually dedicated just to talking about X. That would make you think that, yeah, actually, ST Idris shipped with a graphical interface. We even have that blurry photo, right? Well, not so fast.

In the middle of the article we get this nugget. Quote, an X-Windows package will most likely be packaged with the Atari distributed release of Idris. If not, it's very likely several enterprising programmers will make their own ports." So uh, what, did ST Idris have X windows? I have no idea. All the later mentions of the operating system are just that, mentions. There are no more in-depth articles for me to work off of. All we have is a grainy photo of an ST running something that looks kind of like X. It has a

little X cursor but I don't know what software it's running. It says Idris but I can find nothing else about the photo. And we have this one article that says Idris may have shipped with the software so who's to say? This is one of those things that could very well just remain a strange little mystery. Alright, that does it for our look into Idris. This is one of those times where I feel confident in saying this episode is fully comprehensive. Anything I've glossed over or missed is either a very technical detail or something we simply don't have information on. One of the only avenues I didn't go down was the whole real-time application of Idris. And I know, I know, any Idris heads out there are probably up in arms by this point. The fact of the matter is I ran into a lot of articles saying that Idris was great for embedded in real-time applications,

but didn't mention what those applications were. I think that's just another symptom of this style of poor preservation. One thing that still blows me away is just how poorly preserved Idris is. still blows me away is just how poorly preserved Idris is. Co-Idris is fully preserved with disk images and documentation, and we have disk images for one version of 68,000 Idris. But that's it. That is all the software we have. That's wild to me for a product that ran on so many different computers, had so many different versions, and survived all the way into the 1990s. I think that Idris shows off the true nature of Unix, even though it is a clone. It's small, scrappy, and could run on just about anything. At least, that's the modern view of Unix.

What makes the story so much more compelling to me is that at the time Idris emerged, the late 70s, Unix hadn't quite gained that reputation. It was still small and scrappy, yes, but was still locked on a few platforms. It was hiding out, by and large, inside Bell Labs. Unix was just starting to take hold of the wider world as Idris hit the scene. So it's really cool to see the best parts of Unix reflected in this strange software. Okay, so the final word is that you can actually

use Idris today. I did mention I've been playing around with co-Idris. Well, after some testing, it turns out to be very easy to run. I'll link to a GitHub where all the files are available. Co-Idris is nice enough that you can actually run it in DOSBox. I've personally been running it on my beautiful IBM PS2 model 25. I've finally reached my goal of Unix on an 8086. That said, the environment is pretty rough.

The text editor sucks, it doesn't seem to want to mount DOS images, and it's a little slow on real period hardware. But hey, that won't stop me from having fun with it. Thanks for listening to Abjent of Computing. Before I clock out here, I have a few announcements that I should have done earlier, but I'll do them now. I usually make good by the end. First is, I currently have a poll running on Patreon

for the next bonus episode. So if you want your voice to be heard, or you want to get that bonus episode, you can head over to my Patreon page. I'm also going to be speaking at the Intelligent Speech Conference on February 8th. You can get tickets for that at IntelligentSpeechOnline.com. And then the next weekend, President's Day weekend in the states, I'm going to be going down to VCF SoCal to speak,

maybe do a panel, and definitely mill around the convention all weekend. You can find information about that event at VCFSoCal.com. In the meantime, I'll be back in two weeks with the next piece of Computing's past. You can find links to everything over at AdjunctiveComputing.com that includes the Patreon for the next bonus episode. I think the rough plan is sometime this month, but we'll see how prep for all the other events affects my timeline. Until next time, have a great rest of your day.