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 were reliable, feature-rich, 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.

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.

I want to make it clear that, though this is partially for educational purposes, I will be taking a practical approach instead of an "ivory tower" approach. If we were talking pure theory, we could simplify a great many things. Instead, we are going to tackle the challenges, trade-offs, and decision making required by any software developer who wants to write software for the real world.

Pascal
One of the first things that many will notice is my use of Pascal sources to illustrate the algorithms. This is for several reasons. In olden days, operating systems were written in assembly code. By the 1970s, some of them were written using languages that were glorified assemblers, such as Bliss and C. We will use a high-level language, Pascal, to write UOS. The reasons for avoiding assembly include the fact that it is harder to write assembly than high-level languages, which means it takes longer to code, debug, and test. Second, assembly is specific to a hardware platform. Thus, if you want your operating system to run on multiple hardware platforms, you must rewrite it in an assembly code for each of those platforms. A high-level language allows you to write it once and compile it for different target platforms. Here's an example of some Pascal code and what it would look like if we wrote it in assembly:

In Pascal:


    P := Pos( HT, S ) + 1 ;
    while( S[ P ] <> HT ) do inc( P ) ;

In assembly:


    lea eax,[ebp-$918]
    mov edx,[ebp-$10]
    call @UStrFromLStr
    mov edx,[ebp-$918]
    mov ecx,1
    mov eax,$62f890
    call Pos
    inc eax
    mov [ebp-$8],eax
    jmp A
loop:
    inc dword ptr [ebp-8]
A:
    mov eax,[ebp-$10]
    mov edx,[ebp-8]
    cmp byte ptr [eax+edx-1],9
    jnz loop

Obviously, the Pascal is shorter and easier to read. The assembly code is specific to the Intel iAPX CPUs. I'd have to write different assembly code to accomplish the same on an ARM CPU. Thanks to tools such as FPC and Delphi, the same Pascal code can be compiled to run on multiple different hardware platforms.

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. But there are other reasons I will be using Pascal. First, it is easier to read than C or C++. It was designed as a teaching tool and I will be using this series of articles as such. Second, I have a large library of Pascal code that will help speed up the process rather than having to write absolutely everything from scratch. Third, I don't have a lot of spare time to devote to this, so I need to use every possible advantage to work on UOS. One advantage is that I write Pascal code about 10% faster than other languages, such as C++. Finally, one advantage that Delphi and FPC have over C++ is that we can "hook" into certain features, such as memory management.

Not only do compilers target specific hardware platforms, but they also target software platforms - specifically operating systems. When memory is requested for heap, for instance, a call is made to the operating system to allocate physical memory. Which operating system call is made depends upon which operating system is being targeted by the compiler. Thus, code compiled for an Android won't run on Windows. Since there are no compilers that target UOS at this moment, we have to be careful not to use any features of the compiler which would result in a call to the operating system. Our code for UOS has to run stand-alone. Therefore, we have to override the memory manager to use our own memory management code rather than calling to an operating system (we will cover this in a future article). This cannot be easily done with most compilers and is a major reason for using Pascal. But we also have to be careful of other features of Object Pascal provided by Delphi and FPC. For instance, we cannot use the halt statement as that calls the operating system to end the running image. We can't use any of the file statements or functions since they, too, call the operating system. Thus, we cannot use reset, rewrite, append, read, write, blockread, blockwrite, seek, eof, eoln, filepos, filesize, assignfile, closefile, (or any others I've forgotten). Also, we dare not use any Windows-specific units, such as Windows. Exceptions are also handled by Windows, so we cannot use them - and we must be careful not to generate any. Nor can we use any DLLs that come with Windows or the compiler. This means we'll have to be careful in writing our code, in whatever language - and we'll address situations as they come up.

Terminology
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 track 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.