1 Introduction
2 Ground Rules

Building a File System
3 File Systems
4 File Content Data Structure
5 Allocation Cluster Manager
6 Exceptions and Emancipation
7 Base Classes, Testing, and More
8 File Meta Data
9 Native File Class
10 Our File System
11 Allocation Table
12 File System Support Code
13 Initializing the File System
14 Contiguous Files
15 Rebuilding the File System
16 Native File System Support Methods
17 Lookups, Wildcards, and Unicode, Oh My
18 Finishing the File System Class

The Init Program
19 Hardware Abstraction and UOS Architecture
20 Init Command Mode
21 Using Our File System
22 Hardware and Device Lists
23 Fun with Stores: Partitions
24 Fun with Stores: RAID
25 Fun with Stores: RAM Disks
26 Init wrap-up

The Executive
27 Overview of The Executive
28 Starting the Kernel
29 The Kernel
30 Making a Store Bootable
31 The MMC
32 The HMC
33 Loading the components
34 Using the File Processor
35 Symbols and the SSC
36 The File Processor and Device Management
37 The File Processor and File System Management
38 Finishing Executive Startup

Users and Security
39 Introduction to Users and Security
40 More Fun With Stores: File Heaps
41 File Heaps, part 2
42 SysUAF
43 TUser
44 SysUAF API

UCL
45 Shells and UCL

Glossary/Index


Download sources
Download binaries

Ground Rules

In the first article, we described the basic idea behind the Universal Operating System (UOS). In this article, we will discuss some ground rules that we will follow for this series.

Why write UOS? Besides being a fun and education exercise, I've been disappointed by every other Operating System out there and want something better. Perhaps the best O/S I've seen was RSTS/E (within the constraints of the hardware limitations imposed by the 16-bit PDP-11), followed closely by VMS. Both of these Operating Systems were designed by brilliant engineers at Digital Equipment Corporation, and well-documented. In my entire career, I only found one bug in either of those Operating Systems. Not surprisingly, then, those systems have a huge influence on the design of UOS. In fact, we can take the VMS documentation and use it as a specification for UOS - with some alterations.

One of the first things that many will notice is my use of Pascal sources to illustrate the algorithms. This is for several reasons. First, it provides for examples that are easier to read (for most people) than languages such as C, C++, or assembly. Second, thanks to tools such as FPC, the compiled code will run on multiple platforms, which isn't possible with assembly. And third, I have a large library of Pascal code that will help speed up the process rather than having to write everything from scratch. Of course, UOS could be coded in any sufficiently modern compilable language. In fact, I expect it will end up being coded in multiple languages.

I see two extremes in software: either it is difficult to use because it provides a lot of flexibility and power, or it is simple to use because it doesn't. This applies to programming interfaces for programmers and user interfaces for users. What we want in UOS is all the power and flexibility possible, but also a simplified user interface that defaults all the options to safe and sane values. The best way to implement this "best of both worlds" approach is to provide two interfaces: the flexible one, and a simplified layer over that which translates the simplified interface into the more flexible one. We will discuss this dual approach as we go.

Now to define some terms.
Component: Any stand-alone code that can be dynamically loaded and used in UOS. In Windows terms, a component would most likely exist as an EXE or DLL.
Kernel: In most operating systems, this refers to the basic part of the O/S that contains such things as memory management, file systems, and hardware access. In UOS, these are all separate components. The Kernel is responsible for loading the components, coordinating activity between them, and providing an interface for them to the rest of the system.
Shell: The user interface for an operating system. Some systems have multiple shells. In the case of Windows, for instance, there is the Windows GUI and command-line box.
Store: Anything that we can store data on and read it back from. A common example of a store is a hard disk. But there are other stores as well, such as floppy disks, files, and memory. Stores have a generic interface in UOS, which allows us to deal with them in a general fashion. For example, a file system could exist on a store that is a disk partition, or in RAM (eg a RAM Disk), or even within a file that exists on another store (a container file). Stores can be fixed in size (such as a disk), or expandable (such as a file).
Managed Store: A store that keep tracks of what areas of the store have been used, and allows us to allocate/deallocate areas of the store. Heaps are an example of a managed store.

In the next article, we will dive into our first UOS component, and you might be surprised which one we pick.