386BSD at last!

So, Friday I was looking at the 386BSD repository (as you do) and noticed something quite interesting...

boot.exe

...wtf is a boot.exe? It is a DOS utility that allows you to boot an 386bsd kernel. Similar to (and the basis of?) the utility that used to ship in early FreeBSD cds.

After a brief test in VirtualBox (as you do) I set up an 86Box machine to test it out -and then another, and another, and so on.

Ignoring all of the dead ends and tangents, what I did can be summarized thusly:

1. I cloned the 386BSD 1.0 repository inside of WSL
2. I created a tar file (three, actually -a base, X386 and source) and put it on an iso
3. I created a new 86Box machine, with a 504mb (no larger -or 386BSD's install crashes) drive.
4. I added a second 504mb drive to that machine.
5. I attached that drive onto a working FreeBSD 2.0 86Box machine.
6. Booting into FreeBSD, I mounted the iso I created and the 386BSD drive and untarred all of the archives onto it
7. After shutting that down, I booted the 386BSD machine and from dos typed boot 386bsd.sma wd1a
8. I ran through the install process from the secondary hard drive to install 386BSD to the first
9. I "enjoyed" my new 386BSD 1.0 installation!

...mind the quotes. The install is very rough, and I had to do some things I'm not proud of (ln /usr/bin/true /usr/sbin/sendmail) and some things I shouldn't have had to do (cp /etc/MAKEDEV /mnt/etc/MAKEDEV) (cd /mnt/dev;MAKEDEV

...and the included source does NOT compile, though I can't rule out a fuck-up on my part.

There's quite a few subtleties to all of this; missing directories, odd permissions and at this moment it only seems to work with extremely specific 86Box machines (NEC Pentium, to be exact). Also the TERM variable seems to be set to xterm which is a complete W.T.F. Then there's the question of setting the date (you can, but it doesn't persist)

...but at this point, that's all trivia; the important thing is that I have a "working" configuration.

"Working"

The missing bits

Way way
Back back in the day, BSD was poised to take over the world.

But unexpectedly they smacked the bear on the nose and wound up in a year's long lawsuit which put the future of BSD in peril. 

In the end, everything was resolved with USL asking the CSRG (those responsible for BSD) to create a redacted release. This release was missing a few files and could not be compiled into a working release.

The open source projects (NetBSD, FreeBSD) scrambled to replace the missing parts and eventually released legally clean and unencumbered versions of their BSD-based operating systems.

Several years later, "historic unix" was released openly by Caldera (before they became the SCO group?), which put the formerly contested files out into the open.

A couple of years later, in 2004, a list of the contested files was released by Groklaw.

Here is the list, as far as I'm able to piece together:

Six Missing Header Files:

sys/sys/buf.h

sys/sys/proc.h

sys/sys/shm.h

sys/sys/tt y.h

sys/ufs/dinode.h

sys/ufs/inode.h

“Restricted Files” (26 files):

sys/kern/init_main.c

sys/kern/kern_clock.c

sys/kern/kern_exec.c

sys/kern/kern_exit.c

sys/kern/kern_physio.c

sys/kern/kern_sig.c

sys/kern/kern_synch.c

sys/kern/subr_rmap.c

sys/kern/sys_generic.c

sys/kern/sys_process.c

sys/kern/sysv_shm.c

sys/kern/tty.c

sys/kern/tty_subr.c

sys/kern/vfs_bio.c

sys/kern/vfs_syscalls.c

sys/sys/buf.h

sys/sys/proc.h

sys/sys/shm.h

sys/sys/tty.h

sys/ufs/dinode.h

sys/ufs/inode.h

sys/ufs/ufs_bmap.c

sys/ufs/ufs_disksubr.c

sys/ufs/ufs_inode.c

sys/ufs/ufs_vnops.c

usr.bin/cpio/cpio.c