Porting Unix to the 386: a Practical Approach (1991)(informatica.co.cr)
informatica.co.cr
Porting Unix to the 386: a Practical Approach (1991)
http://www.informatica.co.cr/unix-source-code/research/1991/0101.html
31 comments
In 1992 a friend and I ported BSD/Net2 to the Mac II, and found (weeks into the project!) that kernel functions like fork() and exec() and all of TTY were missing. We thought we were screwed, but found 386BSD and grabbed its versions. I don't know if other BSD ports (like NetBSD) did the same or wrote theirs from scratch. We were certainly indebted to Bill Jolitz for saving our project!
The NetBSD and FreeBSD projects grew out of the collection of patches that people wrote for 386BSD, they didn't start from Net2.
As a side note, I wrote https://en.wikipedia.org/wiki/Macintosh_II#Memory_limit after I realized how misleading the Apple documentation about this was, causing much confusion.
More specifically, 386BSD.
There had already been commercial UNIX System V ports to 80*86 (including the 8088) such as the AT&T 6300 Plus (and, arguably, SCO).
There had already been commercial UNIX System V ports to 80*86 (including the 8088) such as the AT&T 6300 Plus (and, arguably, SCO).
Indeed, one of the first 386 OSes was Xenix. In retrospect, I really wished that DRI added GEM and native 32-bit application support into Concurrent DOS 386. GEM would probably be built into the kernel, with virtual 8086 mode used to run legacy 16-bit GEM apps and developers could write new 32-bit GEM (and even command-line) apps. It would be far more interesting than DR-DOS and probably a good competitor to even OS/2 2.0.
Xenix was also ported to a variety of other architectures as well. At my very first programming job, we had a Z8000 running a very early (V7-like) Xenix port. Its performance was not impressive; a 386 could run rings around it. Also, the segmented memory architecture limited processes to 64K instructions and 64K data.
At a later job, we had several projects that we put together on the 386 version of Xenix; one of those is still in service today. It had moved to OpenServer relatively early on, and stayed that way until early this summer; my task was to get it running on a modern Linux. I was very (pleasantly) surprised to discover that the Unify database is still available, even for RHEL7 - and it was possible to directly take the database files from the old system and use them unmodified on the new one.
I wonder what prompted Microsoft to give up on Xenix? AT&T wanting too much money, or perhaps Not-Invented-Here syndrome? Windows could have been an X desktop.
At a later job, we had several projects that we put together on the 386 version of Xenix; one of those is still in service today. It had moved to OpenServer relatively early on, and stayed that way until early this summer; my task was to get it running on a modern Linux. I was very (pleasantly) surprised to discover that the Unify database is still available, even for RHEL7 - and it was possible to directly take the database files from the old system and use them unmodified on the new one.
I wonder what prompted Microsoft to give up on Xenix? AT&T wanting too much money, or perhaps Not-Invented-Here syndrome? Windows could have been an X desktop.
wonder what prompted Microsoft to give up on Xenix
They reassigned the Xenix devs to OS/2 and sold Xenix to SCO (who were a real company back then).
They reassigned the Xenix devs to OS/2 and sold Xenix to SCO (who were a real company back then).
I ported a large Fortran codebase for mech eng analysis to Xenix from VMS back in the late 80s. We needed more than 640K, so DOS wouldn't do, and this was before Windows. I had to write a device driver for the 68000 based graphics card. That was my first real C coding experience. Fun! I didn't know about BSD at the time, but it looks like Xenix was System V [1].
[1] https://en.wikipedia.org/wiki/Xenix
[1] https://en.wikipedia.org/wiki/Xenix
Did you have a means of using extended or expanded memory?
There were memory libraries like DOS/16M that would allow use of extended memory and 80286+ Protected Mode without a lot of source changes. Informix, Lotus, etc. used it for their Protected Mode product line on DOS starting in the late 1980s.
There were memory libraries like DOS/16M that would allow use of extended memory and 80286+ Protected Mode without a lot of source changes. Informix, Lotus, etc. used it for their Protected Mode product line on DOS starting in the late 1980s.
The authors explicitly said they want to build something more free: "We hope to see those interested in this technology build on it in both commercial and noncommercial ventures."
And they did port Unix (Berkeley flavor) to the 386. I remember using it in the nineties, it was a great adventure. And its progeny FreeBSD is arguably the best alternative to Linux, should something go terribly wrong.
I was just clarifying the title, not casting any aspersions.
My first UNIX environment was System V on AT&T's 3B series. We subsequently moved to Sun 3s with BSD. I strongly preferred the latter.
My first UNIX environment was System V on AT&T's 3B series. We subsequently moved to Sun 3s with BSD. I strongly preferred the latter.
Here is actually a port of UNIX v7 to i386: http://www.nordier.com/v7x86/
Hmm... 386BSD -> FreeBSD/NetBSD -> Darwin/macOS (aka OS X). I wonder how much of that original work remains in the OS I use daily 26 years later?
There might not be that much - the 386BSD project concentrated specifically on the 386 implementation, whereas Mac OS X was initially launched for PowerPC.
That and the kernel is mach, using only the BSD userland.
Remember OSX's direct ancestor was NeXT, which ran on higher end Motorola 68K.
Remember OSX's direct ancestor was NeXT, which ran on higher end Motorola 68K.
It is a hybrid kernel. There are parts of the Darwin kernel (xnu) other than mach that run in ring 0. This is unlike the Hurd, for example.
> which ran on higher end Motorola 68k
And Intel 486, HP PA-RISC and Sun SPARC
And Intel 486, HP PA-RISC and Sun SPARC
Right, but the BSD components got a big makeover post-NeXT, largely thanks to FreeBSD (but also NetBSD and OpenBSD).
Its interesting that it took so long for Intel 32 bit operating systems to be developed. The Compaq 386 first came out in 1987. This is dated 1991.
BSD had a slow start, not "Intel 32 bit operating systems": other flavors of Unix were delivered before 1991.
SCO UNIX was delivered in 1989: https://en.wikipedia.org/wiki/OpenServer#Versions
BSD was slow because in the early 1990s they had a major constraint before working on ports: they had to get rid of AT&T code whose licenses were very expensive and blocking distribution. The cleaning was complete in June 1991.
Source: https://en.wikipedia.org/wiki/Berkeley_Software_Distribution...
SCO UNIX was delivered in 1989: https://en.wikipedia.org/wiki/OpenServer#Versions
BSD was slow because in the early 1990s they had a major constraint before working on ports: they had to get rid of AT&T code whose licenses were very expensive and blocking distribution. The cleaning was complete in June 1991.
Source: https://en.wikipedia.org/wiki/Berkeley_Software_Distribution...
There was 386/ix from Interactive Systems Corporation too [1], I was using it on a PC in 1988.
[1] https://en.wikipedia.org/wiki/Interactive_Systems_Corporatio...
[1] https://en.wikipedia.org/wiki/Interactive_Systems_Corporatio...
Sco unix was for the 286
There were SCO Xenix versions for the 8086, 80286, and then the 386. I only remember SCO UNIX for the 386.
Nop, SCO UNIX started with 386. The SCO company was delivering the Xenix OS for 286.
Altos Computer Systems released its Altos 386 2000 computer running Unix in 1987 https://classictech.wordpress.com/computer-companies/altos-c...
when did x86 add mmu support? it would have been pretty hard with segments (maybe not...oh yeah, you would have had to swap segment registers on demand alot*)