Go to file
Sarah Jamie Lewis 45ca864b66 windows cmd 2021-11-14 22:06:37 -08:00
.idea Initial Commit 2021-11-08 18:19:34 -08:00
src start of linked list windows rendering 2021-11-14 21:29:42 -08:00
.gitignore Initial Commit 2021-11-08 18:19:34 -08:00
Cargo.lock boo update 2021-11-12 15:37:02 -08:00
Cargo.toml diss command 2021-11-13 15:27:56 -08:00
README.md update readme 2021-11-12 15:39:15 -08:00
arch.md allocator + windows test 2021-11-14 16:49:45 -08:00
booos-small.png graphics, strcmp, basic shell, wallpaper 2021-11-12 01:32:30 -08:00
booos.png graphics, strcmp, basic shell, wallpaper 2021-11-12 01:32:30 -08:00
charset.asm graphics, strcmp, basic shell, wallpaper 2021-11-12 01:32:30 -08:00
display.asm Initial Commit 2021-11-08 18:19:34 -08:00
graphics.asm boo update 2021-11-12 15:37:02 -08:00
kernel.asm windows cmd 2021-11-14 22:06:37 -08:00
strings.asm diss command 2021-11-13 15:27:56 -08:00
util.asm diss command 2021-11-13 15:27:56 -08:00
wallpaper.png graphics, strcmp, basic shell, wallpaper 2021-11-12 01:32:30 -08:00
windows.asm windows cmd 2021-11-14 22:06:37 -08:00


Philosophy of Boo OS

Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one. - Design Principles Behind Smalltalk

Boo OS is a meditation on recursive complexity and the curse of simplicity. In an age where computers are so powerful, it is sometimes healing to start again.

I have often been stuck between my desire to build either an operating system, a shell, a language or an ide. None of those categories ever quite fit the hole I was intending them to fill.

After much introspection and research I finally decided that what I really needed was something different.

Inspired by smalltalk, Boo OS is "image" based, the entire system can be dumped and reloaded to the same state.

Eventually my plan is that Boo OS contain all the essentials necessary for self modification. It should be possible to (safely) modify the operating system from within the operating system and have the changes take effect.

How that will look is undecided. For now, Boo OS is coded entirely in Boo Bytecode Assembly Language and assembled using a Rust based assembler. One of my first targets for a real application is an Assembler written in Boo Bytecode, run on BooOS and outputting a Boo Bytecode image.


Boo OS is written in Boo Bytecode which is run by the Boo Virtual Machine (BooVM). BooVM and Boo Bytecode is inspired by various retro computing architectures with minimal instructions, but a focus on integrating with the core systems.

As such. the BooVM offers minimal integration with the outside world. Interaction is limited to:

  • Reading and Writing BooVM images to/from the Host OS
  • Exposing The State of the Keyboard and Mouse
  • Offering a Framebuffer for Display Output
  • (Provisional) Reading and Writing "Files" from the Host OS OR Loading and Interacting with a generalized File System that can be loaded by both operating systems (i.e. some kind of virtual disk image)

Why Write a Custom VM?

Why Not? This is a meditation on recursive complexity. I was already set on writing a new language and building one from the ground up on a custom instruction set seemed like a great idea.

The longer version is that I looked into many options for the base of this project. They fell into two main categories:

The first featured existing ISA emulations (e.g. QEMU) and existing production ready language virtual machines (e.g. JVM, Lua) - I decided that using an existing architecture wasn't in the spirit of the project. Further, both of these options would require extra work to integrate a framebuffer display and input up to the extent where I would be writing an OS for an existing architecture. I wanted to keep the wrapping interface to the host OS as simple as possible.

The second category featured older reto architectures, emulators and the like. I rejected this approach because there are some details I don't want to care about, like scanlines and cartridge layouts. This approach would also make interaction with the Host OS a project in itself likely requiring forking and significant rework resulting in a custom emulator any way.

After research, designing and implementing an assembler for some custom bytecode and building a small VM to run it seemed to be the simplest option and provides me with a lot of freedom moving forward, and lends itself to infinite experimentation.


The below represents some ideas for projects to tackle within Boo OS.

  • Print Strings to the FrameBuffer
    • Set Framebuffer Position Helper Function
    • put_char Helper Function
  • Memory Management
    • Heap Design
    • Implement Helper Functions alloc and free
    • Memory Safety
  • Keyboard Input
    • Designing Input Interaction (Register Based)
  • Create a Console Shell to Interact with the System
    • At first this shell will be limited to pre-programmed commands
    • But, it should quickly all the construction of new commands from old ones
    • Finally, the shell should facilitate saving and loading of disk-images
  • Write a Bootstrapped Assembler Application in Boo Bytecode Assembly