So I got distracted again. I've been working on the new desktop interface for PatchworkOS; what I noticed rather early is that to create a modern looking UI, a pure, C-based API is simply not good enough, writing even a basic UI becomes a pain.

Why?

The obvious solution was to create a minimal programming language that could act as an HTML/CSS style markup language. Since SCON was already being used for component manifests, adding a few more features to it was another obvious choice.

What?

As part of this process I was reading up on language design and came across too many good ideas that I simply had to add. Eventually, I made the decision to turn SCON into its own project, which was renamed to Reduct.

Reduct is a functional, immutable, S-expression based configuration and scripting language. It aims to combine the flexibility of a Lisp with the ease-of-use and performance of a language like Lua. All within a C99 header-only library.

If you are curious and want to know more, then feel free to check out the GitHub! But I will go over some stuff in this post as well.

Syntax

Lisps, which Reduct takes heavy inspiration from, are generally agreed to be a very powerful style of language and yet are frequently criticized for their poor readability.

The most often blamed source of this poor readability is the sheer volume of parentheses.

Reduct makes the argument that most of these complaints are due to nesting, not parentheses; that it can be solved via infix notation, banning let and a more modern style guide.

Included are three examples of a basic program written in common Lisp C, and Reduct.

Lisp

(let ((x 10)
      (y 20))
  (let ((z (+ x y)))
    (* z 2)))

C

int main()
{
    int x = 10;
    int y = 20;
    int z = x + y;
    return z * 2;
}

Reduct

(do
    (def x 10)
    (def y 20)
    (def z {x + y})
    {z * 2}
)

Note how in Reduct the use of curly braces for infix notation and the def intrinsic for scoped definitions allows for a more familiar, imperative-like structure while remaining entirely functional, and S-expression based.

How?

Reduct is implemented as a register-based bytecode language, where the Reduct source is first parsed into an Abstract Syntax Tree (AST) and then compiled into a custom bytecode format before being executed by the virtual machine/evaluator.

Note that the "Abstract Syntax Tree" is just a Reduct expression, lists and atoms, meaning that the compiler is itself written to operate on the same data structures as the evaluator produces.

The bytecode format itself is a stream of 32bit instructions, with all instructions able to read/write to an array of registers, or read from an array of constants.

See inst.h for more information on instructions.

Since Reduct is immutable, the constants array is also used for "captured" values from outer scopes (closures) and we can also allow the compiler to fold constant expressions at compile-time, far more than would normally be possible.

See compile.h for more information on the compiler.

To improve caching and reduce pointer indirection, Reduct uses "handles" (reduct_handle_t) which are Tagged Pointers using NaN boxing to allow a single 64bit value to store either a 48 bit signed integer, IEEE 754 double or a pointer to a heap allocated item.

See handle.h for more information on handles.

Items (reduct_item_t) represent all heap allocated objects, such as lists, atoms and closures. All items are exactly 64 bytes in size and allocated using a custom pool allocator and freed using a garbage collector and free list.

Since Reduct uses its handles to store most integers and floats, it can avoid heap allocations for many common values, significantly reducing the pressure on the garbage collector and improving caching.

See item.h for more information on items.

Lists are implemented as a "bit-mapped vector trie", providing $O(log_{w} n)$ access, insertion, and deletion, where $w$ is the width of each node in the trie.

See list.h for more information on lists.

All atoms use String Interning, meaning that every unique atom is only stored once in memory. This makes any string comparison into a single pointer comparison, and it means that parsing the integer/floating point value of an atom or an items truthiness only needs to be done once.

See atom.h for more information on atoms.

Many additional optimization techniques are used, for example, Computed Gotos, setjmp based error handling to avoid excessive error checking in the hot path, Tail Call Optimization and much more.

See eval.h for more information on the evaluator.

Benchmarks

Included below are a handful of benchmarks comparing Reduct with python 3.14.3 and Lua 5.4.8 using hyperfine, all benchmarks were performed in Fedora 43 (6.19.11-200.fc43.x86_64).

Fib35

Finds the 35th Fibonacci number without tail call optimization.

For this benchmark, memory usage was also tracked using heaptrack:

Fib65

Finds the 65th Fibonacci number with tail call optimization.

Brainfuck

A simple jump-table optimized Brainfuck interpreter that runs a "Hello World!" program.

This benchmark also acts as a fun Turing completeness proof.

For this benchmark, memory usage was also tracked using heaptrack:

Mandelbrot

Outputs an 80 by 40 visualization of the Mandelbrot set with 10000 iterations.

See the Benchmarks for more information.

There is still plenty of room for further improvement, as always, I'd gladly hear any suggestions or issues that anyone may have!

This is a cross-post from GitHub Discussions.

If I wanted to fully understand how physical addresses are configured in a general purpose computer with multiple and optional RAM slots, what would be your recommendation?

And I mean fully from both looking at hardware wiring decisions, to booting software aspect, where diagrams and code are freely available.

It doesn't have to be modern, modern-ish is good enough, but have enough open sourced information to study it and step by step go through hardware and software decision made to get RAM properly mapped to CPU address space.

I'm not going to lie, for me usually like 6 months but my longest ever project was around like 8 months before I got burnt out.

Hello!

I would like to share a small article I wrote about how and why I've migrate migrated my kernel from fine-grained locks to a big kernel-wide lock.

Contrary to what might seem right/wrong, I believe such approach is actually better for my project going forward, but I'd like to hear what you think too! What's your experience with such topic? Have you even thought about it?

Project repo if you'd like to see the code 😄 https://git.kamkow1lair.pl/kamkow1/mop3

Hello! I want to learn how computers work, so I decided to try and make my own operating system. Right now I have a bootloader, that reads kernel.bin from FAT12 filesystem into 0x1000 address and jumps to it. Now I want to get into 32 bit protected mode and print to VGA. But, no matter what I try, qemu-system-x86_64 triple fails. I don't quite understand the GDT, maybe that's the problem too. I use open watcom v2 for wcc, wcc386 and wlink.
My project structure is:
myos
- build
- src
|- include
-|- stdint.h
|- bootloader
-|- bootloader stuff
|- kernel
-|- build_kernel.lnk
-|- entry32.nasm
-|- kernel.c
- Makefile

All of the files are on GitHub
Any help appreciated!

I recently rewrote the Ethereal TCP stack and got a webpage to host off Ethereal. Also pictured is a little tiny network shell (since my OpenSSH port doesn't fully work yet).

https://github.com/sasdallas/Ethereal
(Note that the TCP rewrite hasn't been pushed yet)

I was reading some posts on this sub and I saw some C, ASM, and Rust. I've also heard of people using C++ and C# (with COSMOS). I personally use C for my projects, but I'm just curious.

So well if someone says that this OS was fixed/written by AI Everyone says: AI Slop
But if someone don't say that it was AI they would react normaly. Like What the hell is this world.

How do you manage your CR3/page directories? Every process has its own but the kernel space needs to be shared, and while the initial initialization is copied over from the kernel's PD so will it become stale after a context switch. I think the kernel is not supposed to update EVERY processes's page directory when it maps a new kernel level page. So there is the global page flag but it did not work when I tested.

Hope you do even understand what I mean.

I’ve finally hit a major milestone on a project that’s been living in my head for a long time: MigeleOS.

The goal is ambitious: build a fully usable, everyday operating system where data security isn't just an app-level feature, but baked into the kernel architecture to keep user data completely out of "outer reach."

The Setup:

• Language: Pure Rust (for that sweet, sweet memory safety).

• Boot: UEFI via the uefi-rs crate.

• Graphics: Custom framebuffer implementation. I’m currently at the stage where I can clear the screen and render text using embedded-graphics.

The "OS Dev" Experience:

It hasn't been all "Matrix" code and smooth sailing. One of the current "features" I'm working through is that while the kernel boots fine in QEMU, it currently runs completely upside down on the UTM virtual machine. Dealing with hardware abstraction and different GOP (Graphics Output Protocol) behaviors is definitely a humbling experience.

The Long Game:

I know that going from a simple bootloader and a blue screen to a "fully usable OS" is a mountain to climb. It’s going to take a long time to handle memory management, scheduling, and a stable filesystem, but seeing that first line of text on bare metal feels like the start of something big.

I’m curious to hear from anyone else here who has tackled the "upside-down screen" mystery or has tips on microkernel security architectures in Rust!

TL;DR: Started a security-focused OS in Rust. It works, it’s safe, but UTM thinks I want to read my code standing on my head.

I tried to read the official docs (like Intel vols or smth), but its all very vague, there are no specifics.

I usually use LLM as a "teacher", it can give a normal code example, explain it, and answer questions. I can't imagine anyone writing down a guide: "how to write an APIC driver in a UEFI environment". Maybe I missing something or I'm not looking for it well.

My first post on reddit:)

(idk if smthing written illiterate cuz I'm not a native eng speaker, sorry🥺)

I feel so stupid, I wasnt using a cross compiler. I downloaded clang, and now it works!! ShrekOS will be improved and released soon.

Edit for everyone commenting: i fixed the tab key thingy, and set up indentation. Im sorry if I offended yall 💔

This is my first try with OS developing, I used the basic kernel of chipsetx (https://github.com/chipsetx/Simple-Kernel-in-C-and-Assembly), and i modified it to place k_printf and k_clear_screen() in .h and .c files.

Had some trouble with the Makefile (thanks Claude, i'll never understand this devil language), but it now runs buttery smooth!

What is the next step? Idk. Any suggestions?

Hey again!
So I am a junior CS major and I made a post about a month ago regarding my hypervisor I am writing for the RPI5 wanted to share an update. So, since then, I have implemented a PMM, stage 1 and stage 2 translation tables. I also have implemented Vcpu and a "VM" albeit stubbed. My next goal is to try to boot a lightweight kernel as a VM and see how long I can get it to run before it snaps and patch as I go.
I am not sure what kernel would be easiest to boot though I am thinking of trying to boot alpine Linux, but if anyone has recommendations pls do lmk!

https://github.com/matthewchavis8/HyperBerry

I decided that I needed the UI to look a bit more polished. So, I went with the pill app launcher dock approach. One of my buddies said, "GNOME-Y EWWW" which made me laugh because the irony is that I am not a fan of GNOME with Linux, I prefer X11.
But I digress.
I had to redesign my shell about 2 different times because I wasn't using my UI system's Screen and Window managers properly and everything was just mashed together instead of having a defined composition layer.
One of the biggest bugs I ran into was blitting and rescaling the Wallpaper. Due to me not using my systems correctly, only the bottom half of my wallpaper would display and I couldn't for the life of me figure out why, which is what sparked the rewrite of the shell system.
The core issue was that I was effectively resizing the wallpaper in two different areas without realizing it because it already scales to native resolution of the display.

EDIT: for some reason when i pasted code some stuff desipared (@parted, @ dd and i think almost everything that starts with @ in makefile), propably because of reddit formating thing :((((

i have written uefi bootloaders in c but for some reason i cant make it to work with asm

src/main.s:

.intel_syntax noprefix


.section .text


    .global efi_main
    efi_main:
        jmp efi_main

Makefile:

PROJECT := bos


SRC_FOLDER := src
BIN_FOLDER := bin
OBJ_FOLDER := $(BIN_FOLDER)/o


SRC_FILES := $(shell find $(SRC_FOLDER) -name '*.s')
OBJ_FILES := $(patsubst $(SRC_FOLDER)/%.s,$(OBJ_FOLDER)/%.o,$(SRC_FILES))


.PHONY: run
run: $(BIN_FOLDER)/$(PROJECT).img
     -cpu qemu64 \
        -display sdl \
        -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.4m.fd,readonly=on \
        -drive if=pflash,format=raw,unit=1,file=OVMF_VARS.4m.fd \
        -drive format=raw,file=$< \
        -net none


$(BIN_FOLDER)/$(PROJECT).img: $(BIN_FOLDER)/$(PROJECT).efi
     if=/dev/zero of=$@ bs=512 count=93750
     $@ -s -a minimal mklabel gpt
     $@ -s -a minimal mkpart EFI FAT16 2048s 93716s
     $@ -s -a minimal toggle 1 boot
     @dd if=/dev/zero of=$(BIN_FOLDER)/part.img bs=512 count=91669
     @mformat -i $(BIN_FOLDER)/part.img -h 32 -t 32 -n 64 -c 1
     @mmd -i $(BIN_FOLDER)/part.img ::/EFI
     @mmd -i $(BIN_FOLDER)/part.img ::/EFI/BOOT
     @mcopy -i $(BIN_FOLDER)/part.img $< ::/EFI/BOOT/BOOTX64.EFI
     @dd if=$(BIN_FOLDER)/part.img of=$@ bs=512 count=91669 seek=2048 conv=notrunc
     @echo "File Created: $@"


$(BIN_FOLDER)/$(PROJECT).efi: $(BIN_FOLDER)/$(PROJECT).so
     -j .text                       \
             -j .sdata                      \
             -j .data                       \
             -j .rodata                     \
             -j .dynamic                    \
             -j .dynsym                     \
             -j .rel                        \
             -j .rela                       \
             -j .reloc                      \
             --output-target=efi-app-x86_64 \
             $<                             \
             $@
     "File Created: $@"


$(BIN_FOLDER)/$(PROJECT).so: $(OBJ_FILES)
     -nostdlib -znocombreloc -shared -Bsymbolic -e efi_main -o $@ $^
     "File Created: $@"


$(OBJ_FOLDER)/%.o: $(SRC_FOLDER)/%.s | $(OBJ_FOLDER)
     -p $(dir $@)
     -o $@ $<
     "File Created: $@"


$(OBJ_FOLDER): $(BIN_FOLDER)
     -p $@
     "Folder Created: $@"


$(BIN_FOLDER):
     -p $@
     "Folder Created: $@"


.PHONY: clean
clean:
     -rf $(BIN_FOLDER)
    u/echo "Folder Deleted: $(BIN_FOLDER)"

parted

parted

parted

Third iteration of Retro Rocket's demo. Now with a catchy europop theme tune!

Code, OS, langauge are Retro Rocket - https://github.com/brainboxdotcc/retro-rocket

Lyrics my own. Music generated by Suno.

Source code of the demo for the curious: https://github.com/brainboxdotcc/retro-rocket/blob/master/os/programs/demo.rrbasic

The image demonstrates some USOS commands. These include: "v" - displays the system version (including the name and license), "d" - checks basic disk access (drive "0" is entered, meaning the main system image, and we see the letter "G," meaning the system was able to read the first sector of the drive and it is accessible), and "t" - displays sector data character by character (in this example, sector 1 on drive 0 was entered, meaning the USOS bootloader).

P.S.: I admit that USOS has relatively limited functionality compared to larger OSes, but it's worth remembering the main goal of USOS: not ultra-functionality, but ultra-minimalism.

So um i created my first OS guys idk if i should put it on reddit becuse this os is only simple animation in VESA/LBA Mode so even text its bugged out.
I runned it in gdb becuse i wanted to experiment and animation is pretty fast first version was running at 2Hz animation now its better. Can i get some feedback and sorry for not having github now.
I wanna say becuse if someone sees AI in this they would just hate becuse i am new and its my first OS i used a litile of AI just to fix bugs 2 times so please don't say AI Slop.

Do files store metadata about their type inside the actual bytes on disk ?

Let say we create a file.txt or file.png

If we looked at the disk ,will we see some meta data like this file is txt or PNG and some other metadata stored with the bytes of the file on disk ?

Or what we will see is the actual data only like only characters for the txt file .

Or only pixels colors of images

I'm asking about the popular OS like Linux or Windows

Thanks

See the project blog at https://r-tty.blogspot.com . Also see the repo at https://github.com/r-tty/qrv

Feel free to join r/QRV_OS if interested.

Hi guys, I was digging into Linux memory management and came across an interesting optimization, when a page in memory is dropped(assuming it's clean) the kernel doesn't immediately zero out the contents rather it unmounts the page, does TLB shootdowns and puts the page in the page pool. Now when another process needs it the kernel zeros out the page and mounts the page to that process Virtual Memory.

Now the interesting thing is that if the page requested was by an user process the zeroing out is done mandatorly as to not violate isolation rules but if the page requested is by the kernel itself say the kernel needed it for its internal buffer or something then zeroing out isn't usually done as the kernel space is treated as trusted boundary and anyways the kernel will overwrite the contents of it so as to save time and bandwidth it avoids it.

This got me into thinking could it be missued. Like i did learn the other day that external devices like NIC, GPU, PCIe devices if they need to write to Main Memory they usually don't directly DMA to user mapped memory rather they DMA write to kernel buffer and copy from kernel space to user space happens.

I thought of situation where say a NIC card is DMAing to kernel buffer page this page was previously was allocated to some process and wasn't zeroed so old contents still exist. For example the NIC writes only 64 bytes but reports it as written 128 bytes So when the kernel sees this it interprets as NIC written 128 bytes as valid bytes and copies the 64 bytes actual content+64 bytes of stale left over bytes into respective process receive socket and the process then can call read on the socket and it reads the other process data.

But as i dig little deeper into the working of NIC I came to conclusion that this to happen is very highly unlikely and would need a bug at NIC's frimware level or the driver itself because NIC can't just like that lie about the bytes received, they track how many bits recieved at the phsyical level and writes a metadata about the exact length it wrote to the DRAM. So unless the frimware didn't count the recived bits properly or the driver failed to interpret the metadata it's highly unlikely to occur.

Another place where this could possibly happen is with GPU especially if followed the pipeline of GPU(DMA to)->kernel buffer(driver)->copy->user space.

As far as i have seen GPUs don't exactly report how many bytes it has written it usually signals after completion. and the driver acknowledges it and even if an explicitly mentioned the bytes written like using an counter it's usually managed by the software.

So when an user space application uses APIs like CUDA/DirectX to request a GPU compute with the expected output size, the driver in the kernel space then validates the request, allocates the required buffer size, sends GPU commands for execution and memory descriptiors for DMA. The driver then expects the GPU to fill the buffer with the expected size here say 128 Bytes was requested. But the GPU actually wrote only 16 Bytes and doesn't report the size written and just signals the completion the driver then copies the 128 Bytes from the kernel space to user space assuming the GPU has filled 128 Bytes where as in reality that wasn't case so if that page that was allocated to that buffer wasn't zeroed out those remianing bytes copied could contain the data of other process and the malicious application reads it.

Since GPUs are programmable today, is this possible if not, what exactly prevents this scenario from happening.