how do i always forget about the readme
This commit is contained in:
1 parent
f882d339fb
commit
3dacbd32c8
2 files changed
+53
-53
No files matched your search
Binary file not shown.
@@ -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.
|
||||
|
||||
|
||||
Reference in new issue
Block a user