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

Terminal I/O
45 Shells and UCL
46 UOS API, the Application Side
47 UOS API, the Executive Side
48 I/O Devices
49 Streams
50 Terminal Output Filters
51 The TTerminal Class
52 Handles
53 Putting it All Together
54 Getting Terminal Input
55 QIO
56 Cooking Terminal Input
57 Putting it all together, part 2
58 Quotas and I/O

59 UCL Basics
60 Symbol Substitution
61 UCL Command execution
62 UCL Command execution, part 2
63 UCL Command Abbreviation


Download sources
Download binaries


This series of articles will deal with writing an Operating System (O/S) from the ground up. The design for this O/S started a long time ago and was named the UOS early on. To be honest, I don't recall exactly what UOS original meant. Probably, in hubris, it was something like Ultimate Operating System. But, nowadays I call it the Universal Operating System, for reasons that should hopefully become obvious.

Now, you might wonder why anyone would want to write an O/S. Aren't there enough out there already? Yes, there are many out there, although for modern computers, there are really only two choices: Windows and Linux. Both have benefits and problems. Linux is free for instance, although some variants of it are not, while Windows will set you back a minimum of $100. Linux is inherently unfriendly for the average user, even with a Graphical User Interface (GUI) slapped onto it. But I'm not going to write a long review of either operating system here. Instead, let me list the goals of UOS:

1) An operating system where the basic components are free and freely available.
2) Well documented for general users, programmers, and system administrators.
3) Reliable.
4) Secure.
5) Portable across diverse hardware platforms.
6) Able to run popular software under emulators.
7) Multi-user, multi-tasking.
8) Component architecture.
9) Scalable.

Despite appearances, I'm not a software socialist who thinks there is something wrong with people or companies making money from software. My interests in a free O/S are purely practical. First, I don't necessarily want to have to support an O/S, which is what would happen if I sold it to people. Second, an open source/open architecture approach helps leverage all the other developers that are out there and can contribute, because I simply can't write UOS in my spare time while maintaining a job and a family (not to mention a social life). So, if someone can add something of value and charge people for it, I'm all for that.

We won't go into the UOS specification in detail here so that we can get into the "good" stuff right away. You can go read the spec at your leisure. But a Cliff-notes overview will be helpful before we get started. UOS is a "component opearting system", meaning that the various parts of the O/S are contained in discrete components that hook together through a well-defined interface. Not only is this better programming practice than writing a monolithic program, but it also allows the individual components to be swapped out with better ones, depending upon need. For instance, for an embedded system, there is no need for file systems and often no need for security. Using these components would only increase the footprint (size) of the embedded O/S, but would likely cause unnecessary performance overhead. Also, it means I can write a basic, functional, free version of a Memory Management component without a lot of effort, but someone who wants to spend countless hours writing a high-performance highly-optimized version can do so and swap out my version for his without having to worry about the rest of the O/S. Further, he can write the component in any language he wants (even BASIC), so long as the interface conforms to the specification. In other words, we each get to leverage off of each others' work.

In the next article, we will discuss some basic terminology and ground rules for the rest of the series of articles. Then we'll jump right in to the guts of UOS.