Let’s build an OS!
In an old Reddit thread someone once asked, “If you were locked in a room with a PC with no OS, could you write one from scratch?” Among all the joke replies, someone actually answered that question – Kragen Javier Sitaker, who worked for Canonical (the company that publishes Ubuntu) at the time.
Sitaker’s approach took a number of steps to implement the base functionality that’s needed to get an OS up and running, though this hinges on there being a functioning IBM PC-compatible BIOS. He then piggybacked off the bootloader to implement his base features.
On the previous spread we alluded to the BIOS providing base access to devices. This is done via interrupts, and enables the minimal bootloaders to get an OS kernel up and running, and indeed enable the kernel to bootstrap itself into life. Interrupt calls cover everything from writing to the screen (10h), read/write to storage devices (13h), serial port access (14h), read the keyboard (16h), and access the PCI bus (1Ah).
Using the Intel 8088 ah and al registers, you could print a “!” character to the screen using screen function 0Eh and interrupt call 10h in assembler like so: mov ah, 0x0e ; function number = 0Eh : Display Character mov al, ‘!’ ; al = character to display int 0x10 ; call INT 10h, BIOS video service
You hopefully get the picture, or else trust us that you can get the BIOS to do basic stuff, otherwise how else do you think BIOS menus were created and managed?
To get anywhere with this, the first thing you need is a way to enter machine code into the computer and jump the processor to it. This is called a machine code “monitor.” They used to be all the rage, but for some reason have fallen out of favor with the kids, but Sitaker wrote a super-basic one in C like this: int main(int argc, char **argv) { for (;;) { char c = getchar(); if (c == ‘.’) return 0; char d = getchar(); putchar(((c & 0xf) ≤≤ 4) | (d & 0xf)); } }
The getchar() and putchar() are BIOS interrupt calls. If you want to look it up, AH = 01h, Int 21 reads a character with echo, while for getchar() and AH = 02h, Int 21 writes a character to standard output.
In the magic scenario you have to hand, translate this into assembly, and then machine code and somehow get it onto the bootsector of your floppy. Let’s do some hand-waving and pretend that’s part of the rules.
With this, the PC would now boot the super-basic machine code monitor into memory and run it. At this point you’d want to write the monitor to the main area of the floppy, but enhance it with “modern” features like backspace, displaying what you’re entering, and other basic editor features. Displaying areas of memory, changing the target address, and interrupting looped code would all be on your To Do list. Adjust the first-stage bootloader to JMP to this new monitor on the floppy, and you’re cooking with machine code.
Typing pure machine code octal by octal is no fun, even in your swanky feature-ladened monitor. So the next step is to create a basic assembler. We’ll start to plough through these, but the assembler lets you code with case-sensitive letters for instructions. Write this in your monitor and save it to a blank area on your floppy.
But even assembly is a pain, so
to speed development of your proto OS you’ll first want to develop a high-level language, Sitaker used Forth, but it really doesn’t matter. If you’re wondering, Sitaker has a 66-line, self-compiling Forth working example here https:// github.com/kragen/ stoneknifeforth.
With that safely on your floppy, you’ll want to create a minimal file system so you can create, load, and develop new commands in your Forth editor without the worry of overwriting things. You’ll then want a basic set of commands for managing those files – delete, move, rename, list files, and copy. A basic compression tool would help speed things along, and why not redevelop your assembler and implement a text editor rather than editing memory directly?
Currently, and we’ve not mentioned it, everything here is running in Intel’s 16-bit real mode, which is sort of the 8088 fallback mode. That’s right, it’s not very good. If you wanted to go on and develop this further you’d want to re-compile everything now to work in 32-bit protected mode, which enables full memory space access, along with strict memory and I/O protection.
You can go to set the screen via the BIOS to 640x480 in 16 bits, develop libraries to draw primitives, manage these as windows, create a desktop system to keep them all on, monitor a mouse pointer, and Bob’s your proto-OS.
Enter the Arch
To put all this “fun” behind us but continue on our quest for a working operating system, we’re going to continue with Arch Linux. Arch has a reputation among Linux distros for being in-depth and has coined the meme “I use Arch btw,” as some users tend to throw it around as a mark of superiority. It’s a very nuts and bolts distro, expecting you to do much of the configuration, and you’ll need to install a GUI desktop, if you want one. But it has the best documentation on the planet, and its software repositories are the most up to date, with it generally being the first distro to make new kernels and software available via its rolling update system.
So if truth be told, this guide isn’t going to be much more than a targeted rewrite of the core install guide (which you should check out at https://wiki.archlinux.org/ index.php/installation_guide). We’ll focus on installing on a VirtualBox machine and so specify settings and cut some corners to fit that.
“In the magic scenario you have to hand, translate this into assembly, and then machine code and somehow get it onto the bootsector of your floppy.”