> Intel's 80386 processor was the first to include memory management hardware and thus be capable of running a full UNIX operating system That's not correct. T

> Intel's 80386 processor was the first to include memory management hardware and thus be capable of running a full UNIX operating system That's not correct. The 80286 had sufficient memory management hardware for full Unix. What it did not have was sufficient memory management hardware for reasonable demand paging, but it was fine for swapping systems. AT&T USG has a port of System V Release 2 for 80286, for example. There was also Xenix, which has enough licensed code in it from AT&T that I'd count it as a Unix. There was also System V Release 3 fro 80286, but I don't think that was ever released. When AT&T was developing SVR3 for their own 3B line of processors they wanted to also port it to Intel processors. They hired Interactive Systems Corporation (ISC) to do that, with the contract calling for porting to both 80286 and 80386. I worked at ISC at the time and was on the 80286 port team. We did get it working, but where having problems getting the scheduler to behave reasonably under heavy load. Somewhere in the middle of trying to figure out what the heck was going on with the scheduler, we and AT&T realized (1) 80386 was so much better than 80286 that a lot of 80286 Unix users would upgrade to 80386 systems, and (2) those that are happy with the 80286 Unix systems and not planning on leaving 80286 probably would not find upgrading from SVR2 to SVR3 to be worth the effort. It wasn't all that clear that there was much of a market for 80286 SVR3. The 80286 port was then dropped. I was moved to work on the 80386 port and also to a newly formed team to add support for running 80286 SVR2 binaries on 80386 SVR3. That was a fun project. Kind of like Wine, but easier because (1) it was just going from SVR2 Unix to SVR3 Unix instead of Windows to Unix, and (2) we had full source code to SVR2 and SCR3 unlike the Wine developers who don't have Windows source.