A Port of “The Last True Unix” to x86

He is on a linux box now of course, but that last osr5 install was actually migrated to new hardware twice before finally getting the app onto linux.

There was much to like and dislike about SCO.

Even back before the later lawsuit people took over, it was a bit ridiculous to ship a system where you had to pay extra (after already paying $1200 or so, in '92 dollars) just to get a compiler, and extra again for tcp. They tried to justify it that most installs didn't need that stuff so by splitting them off you could pay less for just that parts you need. But that kind of doesn't wash when the most basic subset was already ridiculous.

But I liked it in most other ways. It was limited and annoying by todays standards, and definitely osr5 failed to advance and became terrible to use in comparison with everything else after a while, while still somehow demanding a big price tag.

But earlier, it was as good or better than anything else at that same time. People did a lot with it. I did a lot with it.

One thing that was wonderful from a small custom back end software seller point of view, practically zero support overhead. You install the box and your software, and forget about it. The customer calls when they want something new or when some hardware breaks. Proper administration was what they would call neglect today. One guy could have 150 customers out there and spend 1% of his time supporting past installs.

And 10 years after doing your first install, your latest install used practically identical steps and knowledge. All those 150 systems that were installed spread over a 10 or 15 year period, they all worked the same way. They were all practically identical to each other even though version numbers and hardware drivers changed.

That is a level of efficiency and low overhead that we'll never see again.

Today you might be able to magic up 150 servers in a few seconds and a few lines of cloud orchestration config code, but tomorrow everything you learned to do that today will be different, and you better stay actively on top of monitoring them, none of this fire & forget like ye olden dayes.

IIUC, each of the many field locations could run the software locally on either (if the location needed only one simultaneous user) an 8088-based Sperry PC running MS-DOS, or (if multiple simultaneous users) an 80286-based Sperry PC, running Xenix, with terminals hanging off it.

Yes, there was `hack` on these Xenix '286 systems. :)

I think the official terminals might've been the popular Wyse WY-50, but there were also some unusual Tatung terminals kicking around the same organization.

IIUC, the field location PCs had modems for infrequently sending data back to HQ (maybe sharing the main voice POTS line for some locations, after business hours).

I imagine that the ability to use cheap PC hardware and dumb terminals made economic sense. Compared to a centralized minicomputer, and a bunch of dial-up dumb terminals and dedicated phone lines.

You could build gcc by means of the "hidden" C compiler in SCO Open Desktop, which was used to rebuild spaces.c and then relink the kernel when changing the configuration \o/

https://en.wikipedia.org/wiki/Coherent_(operating_system)

Not sure why that's something to hope for, SCO (now Xinuos) is a big supporter of FreeBSD and OpenServer5+6 and Unixware7 are still supported and maintained.

The original SCO made SCO Xenix, later branded SCO Unix. Meanwhile, another company called Caldera Systems had been spun out of Novell to keep working on the Linux version that Novell had originally done, back when they had a grand plan to challenge Microsoft on all fronts from applications down to the OS level.

As Linux really took off, though, SCO kind of saw the writing on the wall. They sold their Unix business to Caldera and renamed themselves Tarantella, after a... frankly, I don't remember what it was, anymore, but it was a program they made that had become the bulk of their business.

I'm not sure when Caldera renamed themselves to SCO, but by the time the litigation started flying, Caldera Linux had failed in the market and most of its original staff had left the company. The people now in charge decided that their best asset was IP relating to "real Unix," and the rest is history. Strange, strange history.

The sort of ironic footnote lost to history at this point is that the original Caldera Linux you could get back before they went all troll was, in my recollection, actually a pretty promising distribution. I played with it for a while and was pretty impressed.

386/ix was ISC's port of System VR3 to the 80836. Actually, it was the official port of System VR3 to that processor, done under a contract from AT&T (and maybe Intel...I don't remember for sure).

There was also a port of System VR3 to the 80286 as part of that same contract.

The source for both ports was System VR3 on the AT&T 3B2. The memory management on the 3B2 was close enough to that of the 386 that the people working on that part of the port had no problems.

Not so for the 286 port, which I was working on. We tried treating segments as 64 KB pages, and it worked if you didn't push it hard.

But if you ran a load test with 20 processes that where each large enough so that only a few could be resident simultaneously, and those processes were all compute bound it got into this pattern that was fair in the very long run, but very unfair in the short run.

You'd have one process get something like 90% of the CPU, and a couple others getting about 4% each, and the remaining 2% would be split evenly among the other 17 processes.

It would stay this way for something like a half hour, then you'd get a minute of heavy thrashing, and then that would clear up and you'd be back to the way it had been, except which process was getting the 90%, which two were getting 4% each, and which 17 were evenly sharing 2% would have changed.

So if you took a long enough view, it was fair.

Something in the 3B2 paging system algorithms apparently did not like very large page sizes, and the other programmer and I working on the 286 port were having no luck figuring it out.

Fortunately, AT&T came to their senses and realized there wasn't much demand for a 286 port, dropped it, and I got moved to the 386/ix project, where I added a simple in-kernel debugger and a dynamic device driver loading system.

AT&T hadn't asked for dynamic device driver loading, but the total size of the kernel including all the device drivers that needed to be included was getting bigger than the boot code we had could handle, and the people dealing with the boot code claimed it was obtuse and ugly assembly code that would be very hard to rewrite to handle large kernels, and so I somehow ended up being assigned making drivers dynamically loadable so we could ship smaller kernels.

I got it working well, but then the boot bastards went ahead and rewrote the boot code, getting rid of size limits, and my dynamic device loading was no longer needed.

I also didn't quite escape the 286. I was half the team that did the 286 Unix binary compatibility for 386/ix. That was essentially a Wine-like thing, /bin/i286emul, a 386 process that knew how to load a 286 process into its own address space, set up its memory space, and start it running, with i286emul handling the traps when the 286 code tries a system call and figuring out how to translate between the 286 system calls and the corresponding 386 Unix calls.

ISC was a fun place to work.

I knew of that, Xenix and the two SCO flavours, but the others are news to me!

Probably for nostalgia or a challenge or who knows what.