You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
Sarah Jamie Lewis 45ca864b66 windows cmd 2 weeks ago
.idea Initial Commit 3 weeks ago
src start of linked list windows rendering 2 weeks ago
.gitignore Initial Commit 3 weeks ago
Cargo.lock boo update 2 weeks ago
Cargo.toml diss command 2 weeks ago
README.md update readme 2 weeks ago
arch.md allocator + windows test 2 weeks ago
booos-small.png graphics, strcmp, basic shell, wallpaper 2 weeks ago
booos.png graphics, strcmp, basic shell, wallpaper 2 weeks ago
charset.asm graphics, strcmp, basic shell, wallpaper 2 weeks ago
display.asm Initial Commit 3 weeks ago
graphics.asm boo update 2 weeks ago
kernel.asm windows cmd 2 weeks ago
strings.asm diss command 2 weeks ago
util.asm diss command 2 weeks ago
wallpaper.png graphics, strcmp, basic shell, wallpaper 2 weeks ago
windows.asm windows cmd 2 weeks ago

README.md

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.

BooVM

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.

TODO List

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