5 ms·

Lots of comments here telling you what it was used for, but its probably also useful to know that SCO was an x86 port of AT&T System V UNIX. There were lots of

Lots of comments here telling you what it was used for, but its probably also useful to know that SCO was an x86 port of AT&T System V UNIX. There were lots of these, including the AT&T SVR4 port, Solaris/x86, NCR MPRAS, Xenix, SCO OpenServer, UnixWare, DELL UNIX, NEC PC-UX/V, ISC PC/IX etc etc. Linux had (has?) the iBCS module since enabling some binaries from some of these platforms to run "natively" since around 1994: https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Sta...

tzs 6y ago
I'd replace PC/IX with 386/ix. PC/IX was based on System III, not System V, and it was for the PC XT which did not have protected mode. 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.
- nineteen999 6y ago
  Thank you for the correction and the wonderful story. I am too young to have done anything other than DOS programming on 16-bit x86, so I can only imagine how frustrating trying to get a multiprocessing UNIX system running with a limited number of a 64KB pages would be.
Nursie 6y ago
Solaris/x86 was an odd one. I played around with it a bit in 98/99 when I got it mailed out for free under a student license. Very restrictive on hardware support and IIRC it was available on and off, disappearing from view entirely at times. I knew of that, Xenix and the two SCO flavours, but the others are news to me!
- nineteen999 6y ago
  Yeah the Solaris/x86 releases were really inconsistent, with Sun dropping support at various times and then reinstating it later. NCR MPRAS was the oddest duck I ever had to support - fairly vanilla SVR4, but there was bits of NetBSD code cut and pasted in (eg. some of arp cache code, or at least the header files). It was used for running a Teradata data warehousing solution for a poker machine/lottery corporation I worked for. I actually managed to get gcc 2.95.2+binutils running on it and managed to compile and package up a lot of GNU utilities etc for it.

tzs 6y ago

I'd replace PC/IX with 386/ix. PC/IX was based on System III, not System V, and it was for the PC XT which did not have protected mode. 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.

nineteen999 6y ago
Thank you for the correction and the wonderful story. I am too young to have done anything other than DOS programming on 16-bit x86, so I can only imagine how frustrating trying to get a multiprocessing UNIX system running with a limited number of a 64KB pages would be.

Nursie 6y ago

Solaris/x86 was an odd one. I played around with it a bit in 98/99 when I got it mailed out for free under a student license. Very restrictive on hardware support and IIRC it was available on and off, disappearing from view entirely at times. I knew of that, Xenix and the two SCO flavours, but the others are news to me!

nineteen999 6y ago
Yeah the Solaris/x86 releases were really inconsistent, with Sun dropping support at various times and then reinstating it later. NCR MPRAS was the oddest duck I ever had to support - fairly vanilla SVR4, but there was bits of NetBSD code cut and pasted in (eg. some of arp cache code, or at least the header files). It was used for running a Teradata data warehousing solution for a poker machine/lottery corporation I worked for. I actually managed to get gcc 2.95.2+binutils running on it and managed to compile and package up a lot of GNU utilities etc for it.