Education OS, hope in a few years it will become a normal kernel
  • C 99.8%
  • PowerShell 0.2%
Find a file
2026-07-21 09:54:19 +03:00
firmware First commit 2026-07-21 09:29:30 +03:00
scripts First commit 2026-07-21 09:29:30 +03:00
src Doom 2026-07-21 09:51:56 +03:00
tools First commit 2026-07-21 09:29:30 +03:00
create_ext4_disk.bat First commit 2026-07-21 09:29:30 +03:00
debug_ext4.ps1 First commit 2026-07-21 09:29:30 +03:00
LICENSE Initial commit 2026-07-21 09:27:11 +03:00
README.md Update README.md 2026-07-21 09:54:19 +03:00
test_qemu.py First commit 2026-07-21 09:29:30 +03:00

vsh-OS

A tiny from-scratch x86-64 operating system: a gnu-efi UEFI bootloader that loads an ELF kernel which brings up the GOP framebuffer, renders an 8x16 font, shows an animated color-cycling banner, runs a scrolling console with a blinking cursor and Up/Down command history, serves a FAT32/VFAT RAM disk, exposes Linux-style /proc and /dev virtual trees, supports Ctrl+C program interruption, and hosts a small shell vsh plus 26 coreutils in a custom .bin format:

ls cat cd pwd echo touch mkdir rm(-rf) cp mv head wc file yes
mount umount lsblk df free uname date sleep ps whoami hostname clear
vsh reboot poweroff halt

reboot/poweroff/halt go through a minimal ACPI implementation: the bootloader saves the RSDP from the EFI configuration table, the kernel walks XSDT/RSDT to the FADT, scans the DSDT for the \_S5 package (SLP_TYP values) and uses PM1a/PM1b control ports for S5 shutdown; reboot uses the FADT reset register with 8042-pulse and triple-fault fallbacks.

Everything is built on Windows with the MinGW-w64 binutils/gcc from MSYS2 — no make, no cross-compiler download. UEFI apps are PE and UEFI's calling convention is the MS x64 ABI mingw already uses, so the bootloader compiles straight to .efi. The kernel and programs are compiled by the same mingw and converted to ELF/flat binaries with objcopy.

Layout

src/common/     bootinfo.h (loader->kernel handoff), vshabi.h (kernel<->.bin ABI)
src/boot/       bootloader.c              -> BOOTX64.EFI (PE/UEFI, gnu-efi headers)
src/kernel/     kio console kbd fat32 exec vsh kernel  -> kernel.elf
src/user/       ulib + ls cat cd echo mount umount     -> *.bin
src/include/    8x16.h  (IBM VGA 8x16 CP437 font, 256 glyphs)
tools/          mkfat32.c (host: format+populate FAT32), fatcheck.c (host verifier)
scripts/        build.ps1, run-qemu.ps1
gnu-efi-4.0.4/  headers only (downloaded, no git)

Build

powershell -ExecutionPolicy Bypass -File scripts\build.ps1

Produces in build\: BOOTX64.EFI, kernel.elf, the .bin utilities, fat.img (data disk) and esp.img (bootable UEFI disk with \EFI\BOOT\BOOTX64.EFI, \kernel.elf, \fat.img).

Run (UEFI / QEMU + OVMF)

powershell -ExecutionPolicy Bypass -File scripts\run-qemu.ps1

Needs qemu-system-x86_64 on PATH and OVMF firmware (the script searches QEMU's share\ for edk2-x86_64-code.fd / OVMF_CODE.fd / OVMF.fd; drop firmware in firmware\ if not found).

Real hardware

dd/Rufus the raw build\esp.img onto a USB stick and boot it in UEFI mode. Keyboard input uses the legacy PS/2 (i8042) controller, so enable "USB Legacy Support" in firmware for USB keyboards to appear.

Kernel command line

The bootloader reads \cmdline.txt from the ESP and hands it to the kernel (cat /proc/cmdline shows it, like Linux). Tokens:

token effect
init=/bin/vsh.bin program the kernel spawns (and respawns on exit)
video=1280x720 ask GOP for that 32bpp mode before ExitBootServices
banner=VivaOS text of the animated rainbow banner
quiet suppress kernel boot messages

The shell itself is a userspace program (/bin/vsh.bin). exec supports nesting (the caller's image is saved/restored around the child), so vsh inside vsh works, and exit returns to the parent shell - the kernel acts as init and respawns the top-level shell, re-reading /etc/hostname and motd.

Boot / memory model

  1. Firmware runs BOOTX64.EFI.
  2. It opens the boot volume, loads kernel.elf (by PT_LOAD program headers) to a fixed base, loads fat.img into RAM, reserves the .bin window (0x400000), allocates a heap, grabs the GOP framebuffer, ExitBootServices, and jumps to the kernel entry (bootinfo_t* in RCX).
  3. The kernel serves the FAT32 image from RAM, reserving the top text row for the animated banner and scrolling the console below it.
  4. vsh reads a line (PS/2), resolves cmd -> /bin/cmd.bin, and the loader maps it at 0x400000 and calls its entry with (argc, argv, sys). Programs reach all services through the sys_t function-pointer table.

Honest limitations

  • Storage is a RAM disk. Writes (echo hi > f, etc.) mutate the in-memory FAT32 image and persist only until reboot — porting a real AHCI/NVMe/USB block driver (or "stealing" Linux's) is out of scope and GPL-encumbered.
  • Input is PS/2 only (no USB HID stack). Works in QEMU and with firmware USB legacy emulation.
  • Runtime is currently unverified on this machine (no emulator was available while writing it); every component compiles, links, and the on-disk FAT image is validated by tools\fatcheck.exe, but end-to-end boot needs QEMU/hardware.

qemu -kernel kernel.elf?

Not supported as-is. qemu-system-x86_64 -kernel uses the Multiboot 1 protocol and boots into VGA text mode without a linear framebuffer — but the whole point here is the GOP framebuffer + 8x16 font, which Multiboot 1 can't provide. The framebuffer path needs UEFI (this project) or Multiboot 2 via GRUB (-append gives the cmdline, and GRUB sets up the framebuffer). A Multiboot2 header + a second framebuffer/cmdline entry path can be added if you want that boot style — ask and it'll be wired in.

Contribute

I really want this kernel become more usable using YOUR help, you can contact me in discord - vivchikalt