Copyright © 2015,2019 by Alan Conroy. This article may be copied in whole or in part as long as this copyright is included.

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 Command execution
62 Command execution, part 2
63 Command Abbreviation
64 ASTs
65 Expressions, Part 1
66 Expressions, Part 2: Support code
67 Expressions, part 3: Parsing
69 Expressions, part 4: Evaluation

UCL Lexical Functions
72 TProcess updates
73 Unicode revisted
74 Lexical functions: F$CONTEXT
75 Lexical functions: F$PID
76 Lexical Functions: F$CUNITS
77 Lexical Functions: F$CVSI and F$CVUI
78 UOS Date and Time Formatting
79 Lexical Functions: F$CVTIME
81 Date/Time Contexts
83 Lexical Functions: F$DELTA_TIME
84 Lexical functions: F$DEVICE
86 Lexical functions: F$DIRECTORY
87 Lexical functions: F$EDIT and F$ELEMENT
88 Lexical functions: F$ENVIRONMENT
90 Lexical functions: F$EXTRACT and F$IDENTIFIER
92 LIB_FAO and LIB_FAOL, part 2
93 Lexical functions: F$FAO
94 File Processing Structures
95 Lexical functions: F$FILE_ATTRIBUTES
97 Lexical functions: F$GETDVI
98 Parse_GetDVI
99 GetDVI
100 GetDVI, part 2
101 GetDVI, part 3
102 Lexical functions: F$GETJPI
104 Lexical functions: F$GETSYI
106 Lexical functions: F$INTEGER, F$LENGTH, F$LOCATE, and F$MATCH_WILD
107 Lexical function: F$PARSE
110 Lexical Functions: F$MODE, F$PRIVILEGE, and F$PROCESS
111 File Lookup Service
112 Lexical Functions: F$SEARCH
115 Lexical Functions: F$STRING, F$TIME, and F$TYPE
116 More on symbols
117 Lexical Functions: F$TRNLNM
118 SYS_TRNLNM, Part 2
119 Lexical functions: F$UNIQUE, F$USER, and F$VERIFY
120 Lexical functions: F$MESSAGE
121 TUOS_File_Wrapper
122 OPEN, CLOSE, and READ system services

UCL Commands
124 Symbol assignment
125 The @ command
126 @ and EXIT
127 CRELNT system service
128 DELLNT system service
129 IF...THEN...ELSE
130 Comments, labels, and GOTO




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, although for modern computers, there are really only two choices: Windows and Linux. Both have benefits and problems. For instance, Linux is free, 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/virtual machines.
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) - at least in a timely fashion. 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 programming 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.

The purpose of these articles is to bring you along for the ride. My hope is that it will help you to better understand operating systems in general, and UOS in specific. Along the way we will talk about general programming issues, philosophies of software design, and some general hardware architecture issues. Although having some programming experience is essential, you need not be an expert. You could skip past most of the code and read the descriptions to comprehend the design, tradeoffs, and general concepts. In fact, some articles will contain no code at all.

In most treatments of operating systems, the authors jump right into the gory details of the kernel - addressing details of process scheduling, memory management, and hardware considerations for a specific platform. I will be taking a more "organic" approach. We leave the details of specific hardware largely "under the hood" of the HAL (Hardware Abstraction Layer), which we won't discuss in detail until the end of the UOS articles. We will simply discuss what the HAL provides to us and deal with code that is abstracted from hardware details. I will also usually start with the high level code, such as the user interface. We'll write some high level code and then drill down to the internals necessary to support that code. This will provide a concrete foundation to the greater concepts. Further, I'll do my best to avoid covering code that is irrelevant to the current concept being discussed. This means that we will revisit some code several times over the course of these articles as we expand it to support new functionality that comes with our consideration of new concepts.

Finally, my goal is to publish a new article every other week. Sometimes this will not be possible as this is a project that I'm doing in my "spare" time. This time is split fairly evenly across coding, testing/debugging, writing technical documentation, and writing these articles. You can join the UOS Facebook group to be notified when a new article has been posted, and also be able to ask for clarifications.

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.