Advent of Computing - LIVE from VCF West - Wait, Is That Really UNIX?

Episode Date: August 3, 2026

It's no secret that I've been fascinated by odd UNIX clones for a while. When I got invited back to speak at VCF West this year I decided to share that fascination with a captive audience. In this talk we look at Idris and CROMIX, and ask the simple question: why would you want UNIX free UNIX? VCFed will be posting the video version of this presentation in the coming weeks. I'll add a link here once that's up. SEE my slides, here: https://docs.google.com/presentation/d/1v21An2jTGbKn4HV7Orr7xQcjnj3Cju_iMgNX50UcjeI/edit?usp=sharing Install Co-Idris: https://github.com/hansake/Whitesmiths-Idris-OS Install ST-Idris: https://github.com/9nut/IDRIS-OS-for-Atari-ST And DEFINITELY install CROMIX: https://www.sydneysmith.com/wordpress/run-cromix/

I want to start off just by, I guess, starting at how I got stuck in this rabbit hole. I like to read old newsletters, the rougher the better. I think they're interesting as time capsules. And a while back, I was reading this 1981 article called Unix on a Micro from the Sig Small newsletter. It's, as the title says, about a bunch of really early microcomputer versions of Unix. The asterisk is very important here. this article immediately struck me for a few reasons. One, very clearly not edited.

Someone wrote this together and sent it off in the mail without a second thought, which I kind of love. It makes it really endearing. There's misspellings. There's names of Unix variants that are spelled differently in different lines. So no knock against the author. That just immediately made me really like the article. And two, it's full of references to Unix Variants Variants.

that either don't exist, I can find nothing on, existed very briefly, or were withdrawn from market due to gossip reasons. So it's great. It's like an industry rag kind of piece that I just really like. To explain why I like this so much, I should introduce myself. Hi, my name is Sean Hasse. I'm the host of the Admin of Computing Podcast. I cover computer history with a special focus on the obscure and untold parts of history. I'm a freelance historian. I'll write for you if you have something that interests me enough. I'm also a talented software engineer looking for a job. I will send references on request. Most importantly, though, I love gossip, and I have an enduring fascination for the human faculty of choice.

These last two are the important ones today. This leads me to ask a lot of why questions, specifically, why would you do that? And it also leads me to look at very, very weird little niches to ask those questions in. So as soon as I read this article, my immediate reaction was, well, Cornelia, why would someone like Unix asterix on a micro?

It's a period paper, so it doesn't explain why, but it is a really good dive into this bizarre rabbit hole of things that aren't quite Unix. But to set the stage, we need to talk about what Unix is. Anyone here?

know about Unix? Yeah, anyone here like using Unix? Oh, you're all liars. We're all familiar, but I just want to give a quick Unix in a nutshell. Let's call the Sean's edition. So

Unix starts out with these two gents. Ken Thompson and Dennis Ritchie, in the 60s, they're working at Bell Labs and they're part of this project called Multics, which is this huge multi-agency initiative to make an operating system that's time shared. So it can support multiple users and multiple processes,

makes it more efficient to use expensive hardware. It's also notable because it's one of the first large-scale operating systems written in the high-level programming language. Now, the project drags on and, crucially, Bell Labs, where these two gents work, pulls out of the project. That means that people at Bell no longer have access to Maltics. You know, that might not have been a big deal,

but Ken and Dennis, they quite liked using Multics. It turned out it was a really nice programming environment, and since they didn't have Multics anymore, well, programming just wasn't the same. So they decided, why not just make our own Multics, just like a little one, just for us? That can't go poorly. That can't become a lifelong career.

Of course, it did become a lifelong career. So in 1969, Unix is born. That's often known as Epoch Zero. It's the beginning of the Unix epoch. It takes a little bit to grow, but by 73, it's roughly recognizable. At this point, it's pretty stable. It's fully multitasking, fully multi-user, so it can do similar things to what Multics was planned to do

and what Multics eventually does. At this point, Unix is also completely written in the C programming language. This is a high-level language designed for system programming and specifically designed for writing Unix. So there's this really close association, this kind of tying at the hip of Unix and the C programming language. Should be clear to C at this point,

it's a system for programmers by programmers. It's first and foremost, a really nice place to write code and a really nice place to write C, which ends up being a pretty good language, and it's all free. The asterix in this presentation are very important. Unix is only kind of free. So Bell Telephone,

technically owns Unix because it was written at Bell by Bell employees. But Bell has history. There have been multiple antitrust lawsuits brought against Bell in its long and storied history, and one of those resulted in a consent decree. What matters about the consent decree is Bell agreed to only turn a profit selling telephone stuff. It's kind of difficult to argue that an operating system

counts as telephone stuff, legally speaking. So as a result, there's going to be some recurring issues with Bell trying to sell Unix. That doesn't really matter until 73 when Ken Thompson and Dennis Ritchie start to talk. They start to give presentations and publish about this cool new operating system they wrote and this cool new programming language and other people start saying, hey, I think I'd like that. This Unix thing sounds like a good idea. So how are you supposed to get Unix if the owners of Unix can't sell Unix?

Well, there are two ways. One is through at-cost source distribution. This is kind of the first method, and I think the funniest method. People would write into Bell and be like, hey, I would like the source code for Unix. If Bell liked them, if they were a college institution or a research outfit, Bell would say, okay, so they'd call up Ken and say, hey, you've got to run off some source code for Unix. Unix and ship it out. So Kim would physically send tape archives of Unix over with a letter explaining how to compile it,

always signed Love Kim. The other option was to attempt to license the Unix source code from Bell Labs. This wasn't a thing that was in the Bell telephone catalog, so all of these licenses were bespoke. The license terms varied depending on how lawyers at Bell felt on a given day. So there's kind of a fraught path to licensing the source code for Unix. The result of this is Unix source code ends up in the wild. So there are a lot of people that get exposed to a bunch of C software that makes up Unix.

It also makes it kind of hard for Bell to control the Unix source code on their own because they don't have a really strong mechanism here. The kind of neat knock-on effect is Unix spreads through really weird channels, including my favorite Lion's Commentary on Sixth Edition Unix. It's a textbook about Unix that includes the full source code for Unix. Because why not? He has the source. Kim sent it to him. And it's the biggest corpus of C code at the time.

So it's a great example of how to program. This brings us up to 79, which is when I'd say Unix reaches full material. By this point, there's a lot of available software for Unix, and there's a pretty substantial user base. This is when I'd say it becomes useful and stable to the point where a lot of people are interested in using Unix, not just as an oddity or as, you know, looking at interesting source code, but as a work-a-day kind of operating system. 79 is also when Unix gets a new compiler called the Portable C compiler.

This is crucial because Unix has always had this promise of portability. C is a high-level programming language. It doesn't make any assumptions about hardware. So in theory, you can compile Unix to run on any kind of hardware. The portable C compiler makes that even easier than ever to do. So in 79, future looks bright. You can run Unix on anything you want, right? Bell's still under antitrust, though.

So they can't go out and say, hey, would you like to buy Unix? That's not strictly legal unless they do some tricks, which they figure out how to do later, but there's this period where Bell just isn't selling Unix, but people still want it. That leads to this thing called the Unix Wars, because if Bell's not going to sell Unix and a bunch of people want Unix, well, that's a market opportunity now, isn't it?

This is a graphic I've shamelessly stolen from Wikipedia. I'm fine stealing it because this isn't very accurate, but it gives us an idea of the scope that's going on. All these different companies are licensing the Unix source code and making distributions. So they'll modify the source code to work on a target platform, they'll add or remove features, they'll compile it, and then they'll go out

and either sell or distribute that software. So this is how people actually get access to Unix. Note how wide it is, but also note this weird thing in the middle. These dotted lines indicate Unix compatible systems, that have no AT&T software, no software from Bell Labs. That's important because things like Linux, there's no license for the Unix source code associated with Linux, because it doesn't have any Unix source code.

It just happens to be able to act exactly like Unix. Now I said I don't like this graphic. That's because it's not big enough. Starting around 78 or 79, there are actually many, many attempts to make Unix clones clones that have zero Unix source code in them. Of course, we know about me. I love the faculty of human choice.

So why would you do this? Why would you want Unix with no Unix? Well, people like Unix software. By 79, there's a pretty good corpus of Unix software, which kind of really just means there's a lot of software written in C. If something's in C, like 99.9% of the time, that means it's going to be compilable under Unix. huge corpus of code, very useful.

People also don't really like Bell and AT&T. Part of this is that the licensing is difficult, so it's not always entirely possible or feasible to get access to true blue Unix, or True Bell Unix, I guess. Also around the late 70s, people start getting into these really sad, tiny computers. That ends up being crucial here. It turns out that Unix, despite being,

very portable, doesn't really work that well on micro computers. So I'm going to run through a couple examples of these strange Unix clones. The ones that I've picked out are special because they're fully preserved. So everything I talk about today, you can go find disc images for, I'll have QR codes, you can scan them, and you can run these not quite Unix things on your own, which I encourage doing. It's quite a trip. The first example I want to talk about is this thing.

thing called Idris written by Whitesmiths Limited. The history of Idris goes back to the birth of Unix, all the way back to 69. The same year Unix is created, this guy named PJ Plager is hired at Bell Labs. Now, initially, he isn't in the full orbit of Unix, but he starts to get pulled in over the years. In 74, he becomes good office buddies with Brian Kernighan,

who, if you know, C, you know this. guy, KNRC, the first de facto standard for the C programming language, while the K is Kernagan. I also believe in this period that Plager contributed to one of the C compilers at Bell, I don't have really firm confirmation, but I have my suspicions that I'll back up later. Now, Plagher and Kernigan become such good friends over coffee and complaining in the office. That leads in 74 to this book called The Elements of Programming Style that is a fun read, In my head, it's kind of them complaining over coffee

and then writing it in a book and being like, oh, really, this is how you have to format numbers, because why would you do anything else? It's just wrong. Also, oddly enough, it's in Fortran, not C, but, you know, C is about a year old at this point. Four years later, in 78, Plager leaves Bell Labs. It's one of my favorite quotes from him.

He says, he felt like he didn't have a future there, and he better move on before they asked him to move on. He now enters a kind of interesting period of floating around. That same year, he starts working at this firm called Yorden Inc. He's hired on on a contract. Now, Jordan's a consultancy firm. Ed Yorden, the founder, does seminars. He does books, and he'll contract out to do consulting for companies on programming

and on software development practice. He doesn't sell software. Plager comes on to write a C compiler. It's not entirely clear on the sources if Yorden hired him specifically to do that or if Plager was hired and was like, hey, Ed, we're doing compilers now. I like to think it was the second because that's funnier,

but the sources are out. Also, this is why I think the Plager contributed to see compilers at Bell because he writes this compiler in a week. It would be kind of weird if someone just came off the street and it's like, oh, I can do a compiler, and a week later they deliver it. So I think he had a little insider information.

This doesn't work out very well for him at Yorden. They don't really sell the compiler very well. So he leaves. That same year, he leaves Jordan and found Whitesmiths. This is another compiler outfit. So if Yordan's not going to sell his compiler, well, he'll write another compiler. Maybe he'll spend two weeks this time, and actually get some sales.

And it ends up working. He's running this compiler company out of his house. One of his first sales, he actually gets a call from a company in Jersey, and they're like, hey, come demo your compiler, and we'll buy it. And he says, no, come to my office. And he didn't think it through, and so they show up at his house asking to see his compiler. But things go well because people really want see compilers in this period. So, you know, Blager gets excited.

He thinks, you know, if I can sell a C compiler, I bet I could sell my own version of Unix. People like C, Unix is C. How hard could it be? So he goes into the ring. He tries to license Unix from AT&T. How do we think this goes? It doesn't go well. The negotiations fail.

Again, best intention. right? How hard can it be to write something like Multics? Well, how hard could it be to write something like Unix? So Plager decides to write Idris. I think the tagline for this operating system should be this quickly snowballs because it leads to some wild software. In quarter century of Unix, Plager was quoted as saying, I had to decide whether I wanted to fight to sell Unix

or whether I'd just bite the bullet and knock it off. So he's going in very clear-eyed to the pre-eyed to the pre-ed. prospect of, I'm just going to make my own Unix. How hard could it be? And specifically, he wants to fill this lower niche. There's these new microcomputer things. I bet they'd be interested in buying Unix. No one else is selling Unix for microcomputers. What's the worst that could happen? So the worst that could happen is that multitasking couldn't work. Remember that? Multitasking is a core thing that makes Unix useful. To explain a little bit about why it's so complicated to do multitasking.

Let me lay out a scenario. So when you load up a process, well, you've got to give it some RAM. It has to have some space for the code itself. It also has to have some space for data, you know, some working memory. So you can just give a process memory. Any good operating system can allocate memory. You load up the process and you're like, hey, here's your chunk. Play nice, please.

And then you can just leave it unsupervised. right? So bingo, bango, bongo, you got a couple processes running in memory. It might switch back and forth. That's not really important. The important thing is they have plenty of space. So there's a few scenarios that this can lead to. One is the good case where the process respects the boundaries and just works with its own memory that it was handed. I mean, you told it, please only use this region of memory. So it's going to do that, right? That's good. This is a happy process. There's also a less desirable scenario where a process can just kind of point off into space

and just start accessing random memory. But that's not ideal. That's fine though. As long as it's not being used by anyone else, it's just losing some bits. Who cares? There's a worst case scenario. That's where a process overrides another process is memory. That kills the process and kills your computer.

This can happen for any number of reasons. could be malicious code. It could also just be a bug. Bugs are very, very easy to write. So this kind of scenario, the worst case, can happen very often. The solution that some very smart people arrived at is called a memory management unit. This is a neat little device that sits between a processor and memory and mediates access. It's kind of like a jail warden. It prevents you from going outside the bounds or doing anything too nasty. It does this by mapping. The entire inner workings of MMUs are really complicated and really interesting. Basically, it can trick a process into thinking that it has the run of memory, but it's actually just restricting it to a very narrow scope.

Crucially, though, MMUs are hardware. You can't really make an MMU working software. You need to have a physical device that controls memory access. As a result, Well, Unix needs an MMU to function, but that's fine because it was written on mini-computers. It was written on these systems that have MMUs. And Idris initially is targeting the PDP-11. That's a mini-computer. It has an MMU. So we're fine.

I'm just going to include this slide. It's a photo from an advertisement for Idris. I'm sure this isn't foreboding at all. In 1981, something bad happens. IBM releases the PC, which doesn't have an MMU chip. Now, they could be forgiven. The PC was cool, it was very popular, not very sophisticated, and a lot of microcomputers in the period weren't.

It wasn't common to have MMU chips on early microcomputers. And then in 1980-something, I think around 83 or 84, just going off advertisements, Whitesmiths released this software called Co-Idriss, which is a version of their bespoke Unix clone for the IBMPC. That's where we reach a bit of a problem. Now, Co-Adress is really wild software. Like I said, you could say that Idris snowballs quickly.

So it is Unix on a micro. There should be an asterisk there. It's not really Unix, but it's fully Unix compatible. You can compile Unix software and run it on Idris. It can do multitasking in full. multi-user operations without an MMU because the PC physically doesn't have any memory protection. It can also run Microsoft DOS software natively, which is wild. You can literally use DOS edit or use your favorite Microsoft DOS editor to write C and then use Idris's C compiler to compile it

into an executable. So how is this all possible? Well, I'm not going to explain the DOS thing, the source code, well, not the source code. The disk images are out there. You can figure that out for yourself. It's very funny. What I do want to explain is how the non-MMU operations work. The trick here isn't Idris. And this is something that I find really interesting.

Instead of having Idris do anything tricky, the compiler that ships with Idris does a little side of hand to prevent bad operations. So to explain this, let's talk about a, C compiler. That's really simple, right? Here's an easy line of code. X equals 100. This is telling the computer to take some address, let's call it 1, 2, 3, 4, call it X, and then put a value in it. But compilation isn't really a science, it's more of an art. So there are many different ways you can instruct a computer to accomplish that one line of code. One option is to use absolute addressing.

So in this scheme, this code would compile to something that just says, oh, well, I know X is it, address one, two, three, four, just write to address one, two, three, four. Easy. That's very straightforward, but because we're in a multitasking environment, you have no guarantee your program will be loaded into the same location every time. So that means that your little X, that could be anywhere. That could lead to a bad scenario. That could lead to something that might just be annoying or might kill your computer. So we can't use absolute addressing if we don't have an MMU. Funnily enough, an MMU can actually trick a process into doing this correctly, but that's not an option for the PC. What Idris uses is, well, what Idris' compiler uses is relative addressing.

This is where it just looks at the distance between your operation and your data point, and it says, okay, computer, take my current operation address, add 12 to it, and that's where I want you to write. What's cool about that is this is relocatable, so it doesn't matter where you load your process. This is not what Idris uses, it's what Idris's C compiler uses. So on the PC, Idris doesn't even know this is happening. The compiler just makes safe executables. And this surprisingly enough works. This is good enough for stable multitasking.

Here's where you can get the disk images for Co-Idriss. Here's my poor, long-suffering IBMPS2 running it on an 8086 processor. And you can do full multitasking. You can do full C compiling. It works exactly like Unix, which is kind of the point. It's just a little bit slow and running on an IBM PC. Now, I said Idris snowballs, and I really do mean that. In the same period at reaching more towards the tail end of the 80s,

Whitesmith releases Mac Idris, which we don't have much information on the few newspaper articles that mention it, but it would be similar to Co-Idriss, where it allows you to run Unix and Mac software side-by-side on a compact Mac. There's also supposedly Idris for the Atari ST that even had a port of X-Window,

so it has a full graphical user interface. Here's a blurry cryptid style photo that supposedly shows it running on an ST. Now, this is where I'm, would have stopped this section last year, but earlier this year, someone actually found the floppy disks for ST Idris.

Here, is it running in an emulator? And if you have an Atari ST, scan this and you can go install it yourself. Again, not a whole lot to look at, because it is just Unix, kind of. But the fact that this is real and was able to be dug up is fascinating to me.

All right, so before we do my last case study. I want to do one more, just quick. We don't have discs for this. In 1979, Ed Yorden decides that he also wants to get in on the Unix game. Don't know why, because this is just a flash in the pan. I like to think he saw that Plager was doing it and was like, you know, maybe he was right about the C compiler. Maybe I should give this a second shot. So he hires a contractor to write his own clone of Unix. In 1980, it's released as Omnix. It runs on the Z80. So this is an 8-bit clone of Unix,

which is crazy. If you know anything about Unix, it usually needs 16-bit processors or more. So running it on something that small is really neat. That's really out of the ordinary. In 1981, Jordan withdraws Omnics from the market. This is done, according to industry gossip, because it's too buggy to sell.

He actually buys back discs. So, you know, maybe it is impossible to run, Unix on an 8-bit microcomputer. So let's move on to my final case study. This is Chromimco Chromix. Cut right to the chase. Scan the QR code now to get disc images to run Chromex in an emulator or on real hardware.

Again, not a whole lot to look at. It's Unix-like it can compile C-source code. But what's the emulator that this is running on? Why? It's a Z80 simulator. Chromix is an 8-bit Unix clone. So it is possible, maybe just not with a contractor and a year turnaround.

Now, Chromex is fascinating, in part because where it comes from. Crom-Imco, as a lot of you in the crowd maybe know, is a hardware company or was a hardware company. They made 8-bit microcomputers back in the day. They're not really a software company, but they did ship a little bit of software. Specifically, their machines came with this operating system called C-DOS, which is an improved version of CPM.

The business model was pretty simple. They just put a boot sector and a few files on all their floppy disks, so that way, whatever disk you have at hand, you can boot up your ChromeMECO computer. They start shipping C-DOS with their new Z2 computer. It's a Z-80 machine in 1977. But as the 70s drag on, Cromimco wants to beef up their hardware.

They want to move into these 16, maybe these new 32-bit systems. So they start talking with Motorola about this new 68K chip. But there's a lot of delays. Motorola is pretty slow with rolling out these new processors. But never fear. Cromo's doing some groundwork to get ready. C-DOS as an upgraded version of CPM isn't that capable. You're not going to be able to get the most out of this new

Motorola hardware. So Crememco decides they'll go license another operating system. They attempt to license Unix. You've got to always go big, right? This negotiation fails for an interesting reason that is all

about Crememco's business model. AT&T wants $100 for each disc that has Unix on it. Cremco wants to put a boot sector in a few files on all of their disks so you can always load up into Unix. So that would mean their floppy disks would be at least $100. So they back out from negotiation.

In 78, they're still waiting on the 68K, but they launch a new microcomputer called the Z3. This is still a Z80 machine. It uses an S-100 bus, but it's a super micro. It can support 16 megabytes of RAM, which is, for the period, crazy to consider. And it launches with Unix. Asterix are important. Always remember that. So how the Z3 works, how it's able to handle 16 megs is through a mechanism called bank switching.

Normally the Z80 has a pretty small memory space, but their computer can fit multiple banks of RAM. Specifically, it has memory cards that each hold a few kilobytes of RAM. So you can load this thing up with a full 16 meg. sitting between the processor and memory, these banks of memory, is what's called the MCU, the memory control unit. It's kind of a very, very simple MMU. It allows the Z3 to switch which banks it shows the processor. So I think it's easy to imagine what goes on here, right? If you have a processor loaded, or excuse me, if you have a process loaded in memory, it shows up in the memory space, but it's actually on one of these banks.

If you want to unload the process, for instance, if it's not running and you want to run another, well, you just switch the bank out. Now, the process isn't even in memory, so a rogue process can't even corrupt its data space. It's fully protected because it's taken off the memory bus. A little ham-fisted, but it functions. As I said, these are all physical banks of memory, which I just find kind of funny. Bank switching, I think it's easy to think about it as like, oh, it's an abbey. kind of method, but no, this is physically turning off cards.

As I said, it's primitive, but it's just enough for memory protection needed for multitasking. Chromix uses this mechanism for running multiple processes safely. So that's kind of the how it acts like Unix. So that's it. We have an 8-bit Unix compatible on a microcomputer. That's super cool, right? Right. Well, asterix. Chromix is only kind of Unix-like.

First of all, it's not written in C. Chromics itself is written in Z80 assembly language. That's remarkable because Unix compatible as a rule are written in C, because Unix is written in C. So this is kind of its own thing. It also doesn't come with a C compiler. You have to buy a C compiler separately, which I mean makes sense. Chromics isn't written in C, so you're not going to be needing a C compiler to do any system maintenance or extensions.

But the whole point is kind of to be able to compile C. So it kind of sucks to have to go buy a separate disk that has your compiler on it. It also looks and acts like Unix, but only kind of the set of tools that come with Chromics are a little different. It uses L instead of LS. It uses D instead of PWD, and some of the special characters don't line up the up and down directory characters aren't dot, dot, and dot.

So it's a little strange. So what's the point here? What's Cromimco really selling besides, oh, well, this looks kind of like Unix, doesn't it? So imagine, if you will, you have a C program. I already gave you guys a C program, so we all have a C program in the audience, You can feed that into a few different compilers.

What matter for us right now is you can feed it into ChromeMCO's own Chromix C compiler, or you could feed it into the official AT&T Unix C compiler. They'll get different outputs depending on what you use. On the Chromics side, you can get a program for CDOS, a program for Chromix, so you can run it on your little micro. If you're using an official Unix compiler, you get a Unix program that you can run on your nice big powerful mini computer the crucial thing here is the C program can come from anywhere this could be something that already exists it could be Vi it could be your

favorite text editor it could be some simulation software one of your buddies at a university wrote you can go down this path and run it on your mini or you can run it on your little microcomputer you could also author a program from your microcomputer. And this is one of the selling points that Chromimco used for Chromex. Is you have a bunch of Unix programmers, you have a big mini computer, but you don't have a lot of terminals or you don't want to stress your mini out, or maybe you don't even have a mini. You want to be able to distribute C software on your own. So you get a bunch of ChromeMCO computers, load them up with Chromex, your developers can use those as development environments and then

ship C code that goes off and runs on some mini-computer. computer. So really, what Krammko is selling here, and their reason for making a Unix clone, is this flexibility. Yeah, you get the most out of your new hardware, but you also have a much more flexible environment than a micro-running CPM. This is really just the tip of the iceberg. These three, well, these two and a half Unix clones are just the ones that are relatively well-preserved. If you look under the hood, there are actually a pile of different clones. There's some that we know. There's Linux.

There's Linux. There's also coherent, which is one of the better developed Unix clones. That one's written in C and can target many different platforms. But there's also very obscure ones like UNOS or OS1. And as I said, if you go through the documents, there are many, many attempts at getting Unix to run on the micro. I've just outlined two of the tricks that folk were using to try to get over how small hardware was at the time, but there are quite a few different ways that folk attempted to get Unix to run at home. So to go back to the question that we started off today with,

why would one want Unix on the micro? Well, by the time microcomputers really get into Vogue, Unix is a very proven and very well-loved system. The design principles are sound, and people just like using Unix. It's a great environment. But licensing is tricky. There are a lot of issues with getting Bell or AT&T or Western Electric or whoever is licensing at the time to license Unix. That makes it not always easy or even feasible to get access to Unix on your platform.

And microcomputers in this period just can't really do Unix. In theory it's portable, but in practice, hardware limitations make it difficult to have Unix at home. So for all these reasons, we get a panoply of very odd attempts at running Unix on micros. That's what I have for you today. If you like this talk, I host a podcast. Every two weeks I put out presentations roughly similar to this. It's called Admin of Computing. You'll probably enjoy it.

Give it a listen. Thank you so much for listening. And also, go download some Unix. It's fun. Who doesn't love Unix? Do I have any questions? Any scathing critiques? Back there.

Run. That would us be a great question. I noticed you didn't mention Xenix. Yes, because Xenix is a licensed product. Yeah, it uses AT&T source code. It actually can't really multitask. It does, oh, I didn't prep it so I, forget the trick, but it has like a single foreground and background task that they're hard-coded.

Yeah, they're licensed, which is why I didn't choose to cover it. Thank you. We got to get you. Oh my God, so many things. Okay. I should start by saying that increasingly a large part of my day job is trying to get Unix and C abstractions to work on modern embedded systems that don't have MMUs because they're too cheap to. How do you do it? What's your trick?

We're exploring that, but it's a whole thing. I'd love to talk to you after a few. Okay, okay. The question I have along those lines is how close were they able to get in terms, like of the systems that you've surveyed, in terms of the finicky abstractions like fork or actual process text sharing, you know, some of these raison d'etra features of Unix. I'll say that I'm interested in this, at least in part,

specifically because the original Unix, I've read some of the research Unix source in assembly, and it didn't, as far as I could tell, use an MMU either. Like, they just had one process resident at a time. They used the rest of RAM maybe as a cache. I don't even think they did that. They just went out to disk and swap. Every quantum would actually just take this one process

and replace it wholesale with another process every, like, 10 milliseconds. And I guess they were just like, yeah, sure, it's interactive. It's fine. So you don't even need one necessarily to do the full Unix. It's just nice. It's what makes it more stable. and useful. Because if you have to swap everything,

you're going to have a bad day. Oh, yeah, they had a bad day. I don't know how well these are at Fork and T. So the real reason is the text editors that ship with these versions of fake Unix are miserable. So it's really difficult to write sample programs on them, and they don't always import text well.

Idris, though, you can use a DOS editor with it as long as you get the mount point correct, so you can write test programs for it relatively easily. I think, I'm not sure I understand the answer. My question was about the forked syscall. Yeah, that's what I'm getting to. Okay, sorry, sorry. I'd have to sit down and try to.

Oh, you don't know because the text editors suck. Yeah, because the text editors suck, so it's been hard for me to test that out. I encourage you to try it. I think it would be funny. It would be funny. All right, I'll pass this off. What sources were you using to find out, like, old versions of, like, non-unuchs were available?

Like, were there, like, newsletters you were looking at or, like, other places? So the source that started me off was that Unix on the Micro article. From there, just a lot of Googling and a lot of looking at old byte, old Comp Gazette, Interface Age, and there are a few other sources. Internet Archive through their full text search, if you have any of the names, which are kind of repetitive, you can find old articles

where people will mention this kind of stuff. A lot of this isn't very well documented, but Chrome and Idris, we have full scans of their documentation, so you can find a whole lot of details on them. Well, your talk has sort of reinforced my belief that Unix is a platform with a, 50 plus your identity crisis.

What do you think the future of the platform is going to be like moving forward? Because we're sort of in the Unix-like era with Linux Mac OS being what everybody is most familiar with at the moment. Where do you think it's going before we cease to see something recognizable if it ever was? I mean, going back to the earlier question about research Linux, I don't think, well, research Unix, excuse me. Research Linux would be a trip. I don't think

necessarily Unix has ever had a super firm identity outside of the standard live and like the actual system calls that are available, right? Because research Unix is vastly, vastly different from what people outside of Bell

saw. I don't know what the future will hold. I assume better and better Linux distributions but also we haven't really seen a huge fracturing of the environment like we saw in the 80s, right? Because mainly there's BSD flavors like Mock and like OS10. I guess it's just Mac OS now, right? And there's Linux flavors.

But I mean, outside of like real-time Linux kernel builds, it seems, I'm no expert here, but it seems like the Linux kernel is basically just the Linux kernel. So I don't know, maybe more rust. When you were explaining Chromex's angle for selling their product, it made sense to me. The first thing I thought was, wow, this could really impact the future of computing and programming, enabling people to just program at home. And yet I feel like Chromex is a rather obscure name.

Why do you think Chromix remained obscure? That's a good question. In part, I think it's because it targeted Cromimco hardware specifically. So you had to have the MCU card to run it. So there's a limited install base just because of that. And also since it's written in assembly, you can't really port that. So once Cromimco did get 68K processors, they actually rewrote Chromex to work with a 68K.

I think I'd have to do more research. I assume that also led to some kind of fracturing of the software base because you'd have to have a different standard, well, you'd have to have different bindings on the standard lib to be able to work with 68K hardware because there will be some assembler

no matter what you do. But, yeah, that would be my assumption without doing further research. But from MIMCO put out newsletters for Chromex users. So you could go through that archive and actually work out like what the community gripes about adoption were. Cool. Thank you. Yeah, of course. Very interesting talk. Thank you. I'm just curious from your research, did you find any feedback or reviews from the original authors of AT&T Unix on these Unix clones?

I have not. That would be really interesting to run into, but I haven't really seen anything by Thompson or Richie talking about Unix clones. I should do some digging because that would be really, really funny to read. I assume it's either, oh, yeah, this is great, or oh, geez, why would you do this? Especially on some of the technical choices or compromises, right? Well, like with Xenix to an earlier question, Xenix just stripped almost all the memory management code from Unix and replaced it with its own.

So there are some, even within the licensed distribution, some really odd choices. Thanks. So I don't really know the technical details of it per se, but I do know that the 286 had some sort of weird MMU that wasn't really a fully capable MMU that like... Protected mode, yes.

Right, yeah, like for example, yeah, and it's not like classic protected mode, but like it's a weird 286 protect mode or something. But I know that like, you know, most Unix clones that expected to have an MMU, like they all targeted the 386 because that's the first one that had like a proper MMU. Are you aware of any Unix clones at all

that tried to make use of the 286's weird sort of stunted MMU? That's a really good question. So I know Xenix isn't a clone because it is licensed, so it's official. But Xenix targeted the 8086, and they had a separate distribution for 286. I haven't seen much written about the 286 distribution

besides the fact that it exists, and we have disc images. And a lot of these Unix clones, if they target micros, they target either Z80 or 8086. I think once we get... 286 or really any kind of protection because like with Chromex as soon as you have just a little bit of hardware you can do memory protection so I suspect that there wasn't really a point in having these clones anymore coherent I believe does have a 286 build that's available but that's also a much

better written clone and a much more fully fledged system I think he was first let's see I'd like to tell you about a bunch of weird ball thing Good. Sort of contemporary with Chromix. Morrow Designs had a thing called Micronix that required their own Z-80 card with an MMU on it. Oh, cool. Take a look at that.

What was it called? Micronix. Micronix. M-I-C-R-O-N-I-X. Micronics. All right, I'll look that up. Okay, that's one. Number two, now we're going to get into some things

that actually are real, you know, they've got AT&T and T Unix Heritage. on them. HPUX on the integral PC. Oh, yeah. It didn't have much of an MMU, the compiler generated stack probes. Really?

Yes. Weird. When you did a function call, it'd make sure you could do that, right? But if you wanted to write code that just trailed through all of RAM, you could. Okay.

We're out of time. Okay. I can tell you about some more of your... Yeah, please do. All right. Well, thank you so much.