From 3dacbd32c845170c4f34fef11b8f138c991327ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Maksymilian=20Wilczy=C5=84ski?= <maksw@maksw.pl>
Date: Thu, 20 Aug 2026 12:56:26 +0200
Subject: [PATCH] how do i always forget about the readme

---
 OVMF/OVMF_VARS_4M_d.fd | Bin 540672 -> 540672 bytes
 readme.md              | 106 ++++++++++++++++++++---------------------
 2 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/OVMF/OVMF_VARS_4M_d.fd b/OVMF/OVMF_VARS_4M_d.fd
index 4548503a8161dd6c775ff7dbe3b84381951ece02..f5cb6813185b186aed591c47d3f326fa2f946824 100644
GIT binary patch
delta 61
zcmZo@P;3CA7RD`1^G-~bGjiJg-~`hpuE|ywYTG>yGtFRS6mEZbf@%B16U_Z)Z2~N9
Q0<3KUY;6MU%LF(K0Q1Ne8~^|S

delta 56
zcmZo@P;3CA7RD`1^G;0HyUFCV{lN*QOI+<vPnfnlJz?Ibz5T*VrU?RV0xWF;tZf2p
LZ367e1UL);r^6L#

diff --git a/readme.md b/readme.md
index 9bf660e..cbf6b82 100644
--- a/readme.md
+++ b/readme.md
@@ -8,45 +8,30 @@
 
 NT-Lite is a 64-bit operating system kernel written from scratch.
 
-It boots into a shell, loads drivers, launches programs, survives application crashes, runs Doom, plays video, talks TCP/IP, and occasionally reminds you that it is still a hobby kernel.
-
-The codebase is small enough to understand, but no longer small enough to pretend it is just a weekend project.
+It boots into a shell, launches programs, runs Doom, talks TCP/IP, and occasionally reminds you that it is still a hobby kernel.
 
 ## features
 
 - UEFI bootloader
 - real SMP
-- physical and virtual memory managers
-- kernel pool and user heap
+- VAD-based virtual memory, file-backed and anonymous mmap, CoW, reclaim
 - single address-space design with user/supervisor page permissions
-- HAL split from the kernel
 - preemptive priority scheduler
-- processes and threads
-- per-process handles with rights checks
-- process exit state, reaping, and restartable init services
-- events, semaphores, mutexes, queues, named queues, and alertable waits
+- capability-style handles with rights checks, derivation, and revocation
+- rich synchronization primitives
 - IRQL, DPCs, kernel APCs, and user APCs
-- native user-mode exception dispatch
-- Win32 vectored exception handlers
-- minimal runtime-registered SEH substrate
+- user exception handling with structured and vectored handlers
 - async file I/O with events, IOSBs, APC callbacks, and cancellation
-- VFS with IRPs
+- capability-relative VFS with IRPs
+- refcounted mounted volumes with partition arrival/removal
 - page cache with dirty writeback and invalidation
-- AHCI driver, interrupt-driven
-- IDE driver, PIO/DMA
-- FAT32 filesystem driver with VFAT long names
-- USB bus, xHCI, mass storage, and HID
+- USB bus, xHCI, mass storage, hubs, hotplug, and HID
+- audio
 - VMware SVGA display driver
-- drive-number paths such as `0:/apps/shell.exe`
-- PE import resolution and dynamic `.sys` driver loading
-- modular networking through lwIP
-- RTL8139 and RTL816x network drivers
+- dynamic driver loading
 - native BSD-ish socket syscalls
 - DNS resolver syscall
-- length-tracked string-view syscall ABI
-- request-struct based syscalls for larger calls
-- native `NTLSTATUS_*` status codes
-- INI-based configuration
+- four-register syscall ABI with sized request structs for larger calls
 - partial Win32 personality
 - partial (microsoft-level) POSIX personality
 - Doom
@@ -56,18 +41,20 @@ The codebase is small enough to understand, but no longer small enough to preten
 
 ## paths
 
+You thought it would be easy, would you?
+
 ```text
-"apps/shell.exe"      -> current working directory
-"0:/apps/shell.exe"   -> volume 0, native path; works everywhere
-"2:/data/config.ini"  -> volume 2, native path
-"C:\apps\doom.exe"    -> volume 0 through win32.dll; C: maps to 0:, D: maps to 1:, etc.
-"/apps/video.exe"     -> volume 0 through posix.dll
-"/1/apps/video.exe"   -> volume 1 through posix.dll
+"apps/shell_native.exe"             -> current working directory, resolved in userspace
+"/SystemRoot/apps/shell_native.exe" -> system volume through the resource namespace
+"/Device/HarddiskVolume1/boot.ini"  -> system volume through the resource namespace
+"C:\apps\doom.exe"                  -> /SystemRoot/apps/doom.exe through win32.dll
+"\apps\doom.exe"                    -> /SystemRoot/apps/doom.exe through win32.dll
+"/apps/video.exe"                   -> /SystemRoot/apps/video.exe through posix.dll
 ```
 
-Volumes `0`-`7` are available. A volume only works if a filesystem is registered on it.
+Kernel filesystem syscalls are capability-relative; userspace owns the current working directory and resolves named resources through `rssrv`.
 
-The Win32 personality translates drive letters to volume numbers. The POSIX personality maps volumes into a tree.
+`/SystemRoot` is the configured boot volume. Other mounted volumes are discovered through the volume manager and opened by capability.
 
 ## networking
 
@@ -75,7 +62,7 @@ The socket syscalls are BSD-shaped, not BSD-compatible. Same nouns (AF_INET, SOC
 one fixed-size tagged address struct instead of the sockaddr_in/sockaddr_storage casting dance,  
 no htons/ntohl conversions, and DNS resolution is a syscall rather than a userspace library call.  
 That's right microkernel purists, cry some more. Ergonomics.  
-Async is first-class here too, same machinery as the filesystem.
+Async is first-class here too, same machinery as the filesystem. Except the DNS resolver. Ergonomics, am I right?
 
 ## how to build
 
@@ -91,40 +78,56 @@ Async is first-class here too, same machinery as the filesystem.
 
 ## how it looks when built
 
+The ESP is just the boot anchor:
+
 ```text
 efi/boot/
   bootx64.efi
+efi/ntlite/fs/
+  ...
 boot.ini
-drivers/
-  drivers.ini
-  ahci.sys
-  ata.sys
-  fat32.sys
-  lwip.sys
-  pci.sys
-  ps2.sys
-  rtl816x.sys
-  rtl8139.sys
-  usb.sys
-  vmwaresvga.sys
+```
+
+The configured system volume carries the OS:
+
+```text
 system/
   colonel.exe
   hal.dll
   init.exe
+  rssrv.exe
   syscall.dll
   win32.dll
   posix.dll
+  settings.ini
+drivers/
+  drivers.ini
+  ahci.sys
+  ata.sys
+  fat.sys
+  hda.sys
+  lwip.sys
+  ntfs.sys
+  pci.sys
+  ps2.sys
+  rtl816x.sys
+  rtl8139.sys
+  serial.sys
+  usb.sys
+  vmwaresvga.sys
 apps/
   shell_native.exe
   shell_win32.exe
   shell_posix.exe
   doom.exe
   video.exe
+  edit.exe
   httpget.exe
   tcpserve.exe
   udp.exe
   resolve.exe
   ping.exe
+  memtop.exe
 ```
 
 ## screenshots
@@ -167,10 +170,10 @@ Q: Does it really have SMP?
 A: Watch out. It bites.
 
 Q: Is the Win32 layer real?  
-A: Depends how you frame it. Real apps won't run but specifically prepared ones will.
+A: API wise, yes. Binary compatibility wise, close but no.
 
 Q: Are processes isolated?  
-A: No. But IPC is free. Is this how a serious modern OS should isolate processes? No. 
+A: No. But IPC is free. And you can't steal handles. Is this how a serious modern OS should isolate processes? No.  
 Are we a serious OS? No. Is it very convenient? Absolutely.
 
 Q: How often does it crash?  
@@ -180,7 +183,7 @@ Q: Can it recover from a crash?
 A: Works on my machine.
 
 Q: Is this finished?  
-A: It will be once I get a job.
+A: Does it look finished?
 
 Q: Will it corrupt my data?  
 A: It shouldn't.
@@ -188,9 +191,6 @@ A: It shouldn't.
 Q: Why is the path syntax so weird?  
 A: It makes sense to me.
 
-Q: Why both Win32 and POSIX?
-A: NT could do it, why can't I?
-
 Q: Why are the logs so verbose?  
 A: Try debugging an interrupt path with vibes.