The Purpose of Our PC Utilities

To port UNIX, we needed to devise methods to: Load large 32-bit protected-mode programs (that is, the BSD kernel); load the initial root filesystems; and communicate information onto our early UNIX system to augment its capabilities as we port increasing numbers of utilities.

An initial UNIX port to a brand-new architecture with no native software can be a miserable task for the inexperienced. One of the authors has done this for other architectures and survived, but we don't recommend it because it forces you to write absolute code for the purposes outlined above, only to abandon it for the UNIX code, which eventually provides the same function. Writing absolute code is difficult to debug (because there is no debugging environment), time consuming (one needs to support and initialize the entire machine in addition to the above functions), and subtle (tiny machine-dependent characteristics thwart the development effort). These concerns, especially when working with a processor as complex as the 386, arise when the port is most vulnerable -- when there is little project history.

One of the advantages of porting an operating system to a popular machine like the PC lies in the wealth of previously written program development software. (In other words, someone else has already suffered to our art.) We chose to use Borland's Turbo C and Microsoft's MASM, primarily because they "were there," and also because they were appropriate to rapid PC program prototyping. While these programs do rely on a few object library primitives in Turbo C, they are reasonably portable to other MS-DOS C implementations, and on the whole are not restricted solely to Turbo C (or MASM, for that manner).

Another advantage of the 386 PC environment is that MS-DOS and it's applications programs run on the absolute machine, and do not rely on memory management, relocation, or protection. Thus, we could write programs that would ultimately usurp control from the MS-DOS operating system without regard for it's functions and strategies. An operating system that makes extensive use of memory management mechanisms, such as System V UNIX, would have made it more difficult to write and debug an absolute program loader. In this case, we would have spent more time defeating those mechanisms than we would have spent writing absolute programs in the first place!