r1ck

ShellyForever — a 64-bit OS written entirely in x86-64 NASM assembly (with AI assistance)

Why I built this

I hate Unix commands. ls, cd, rm, mv, cp — two- and three-letter cryptic abbreviations that made sense to someone in 1971 and have just been carried forward ever since because “that’s how it’s always been.” I wanted a shell where the commands actually describe what they do, without needing to memorize a decades-old convention. So instead of complaining about it, I designed my own command set and built an OS around it from the ground up.

ShellyForever (currently v0.1.1) is a 64-bit OS written completely from scratch in x86-64 NASM assembly. No C, no existing kernel, no BIOS libraries beyond boot-time disk/keyboard calls. It boots and runs on real hardware, not just in an emulator. The name’s a commitment, not just a name — I plan to keep updating it forever.

To be upfront about how this was built: the assembly code itself is almost entirely AI-written. My part was designing the shell and commands — what each one should be called, how it should behave, what made sense to me as the person who’d actually be typing them — then having the AI implement that in asm and iterating with it on bugs and logic.

How it’s built

• Bootloader (boot.asm) — 512-byte boot sector. Starts in 16-bit real mode, loads the kernel off disk, switches to 32-bit protected mode, builds its own minimal page tables, switches to 64-bit long mode, jumps into the kernel.
• Kernel (kernel.asm) — everything else:
  • A VGA text-mode driver (writes directly to 0xB8000) with scrolling
  • A polled PS/2 keyboard driver (decodes scancode set 1, handles shift, backspace, enter)
  • rush, the custom shell — prompt, line editor, a tokenizer that understands quoted strings, and a command dispatcher
  • An in-memory filesystem tree rooted at /home, with recursive copy/move/delete
  • A simple name = value int64 variable table
  • A built-in line editor for file content

The commands (no more ls/rm/cd)

Command Example What it does cf cf docs, cf … change folder mkf mkf docs make a folder mkfl mkfl a.txt "text" make a file with content (-force/-silent/-info/-test) del del a.txt delete a file (requires auth) rname rname old.txt new.txt rename a file or folder owrite owrite a.txt "new text" overwrite a file’s content in place cpy cpy docs docs_backup copy a file/folder (recursive) mov mov docs archive move/rename a file/folder (recursive) show show “hi”, show a print a message or a variable list list list current folder contents view view a.txt print a file’s content find find notes.txt search every drive for a name, print its path lookfor lookfor “todo” notes.txt grep a file’s content, with optional line range edit edit a.txt built-in text editor <n> = <value> a = 5 set a variable rmv rmv a remove a variable vars vars list all variables calc calc 1 + 2 * 3 evaluate a math expression rr rr script.rsh run a rush script file prs prs, prs kill 1 list/kill running scripts auth auth sdown elevate for one dangerous command current current print current path wipe wipe clear the screen dscan dscan scan drives for existing volumes fmt fmt data format a drive with a volume label mount mount data mount a formatted drive under /data/ label label old new rename a mounted drive’s label ali ali gs list create a command alias alis alis list aliases color color cyan change output text color sync sync save the filesystem to disk rboot rboot save and restart (requires auth) sdown sdown save and shut down (requires auth)

Some quality-of-life extras: command history and scrollback (arrow keys), ; to chain commands on one line, ~ to pipe one command’s output into another, $ for comments, and .rsh script files for automation.

Known limitations

No interrupts yet (keyboard/disk are polled), no real memory allocator (flat identity-mapped first 2MB), no ACPI (shutdown uses emulator magic ports on QEMU/Bochs/VirtualBox, halts cleanly on real hardware/anything else), and fixed-size file/folder tables for now.

Code

github.com/TheServer-lab/ShellyForever

Happy to go deeper on the boot process, the on-disk filesystem format, or the AI-assisted workflow if people are curious. Feedback welcome, especially from anyone who’s done bare-metal x86-64 work.