omfggg this is SERIOUSLY awesome! a question tho, which scheduler are you using for this? is this open source?

@sudu @sudu Haha, I’m really glad you’re excited about it. 😄 That said, I should clear something up before I accidentally get credit for a feature that simply doesn’t exist.

Right now, PefiaOS doesn’t actually have a scheduler. None whatsoever. No multitasking, no processes, no threads, no preemption. Nothing along those lines. Everything runs in a single thread, and each operation finishes before the next one begins.

The flow is pretty straightforward. kernel_main initializes the framebuffer, heap, input, networking, and the rest of the basics, then hands everything over to wm_run(). From there it’s basically one giant for (;;) loop living inside wm.c. It checks the keyboard and mouse, figures out which window currently has focus, sends input to it, redraws the screen, and then does it all over again. That’s the whole story, really.

Funny enough, there aren’t any hardware interrupts wired up yet either. Even networking is completely polled. That’s actually the reason I ended up writing clock.c around rdtsc and the RTC just to handle TLS/TCP timeouts. Without a PIT or APIC timer interrupt firing, there wasn’t any reliable notion of time to lean on. Bit of a hack? Maybe. But it works.

The “applications”, the browser, terminal, notepad, and explorer, aren’t separate tasks in the operating-system sense. They’re really just structs exposing things like paint, key, and click callbacks, all invoked from that one window manager loop. So if, say, the browser calls a blocking net_fetch(), everything else just waits. The UI freezes until that call comes back. If you’ve noticed the screen stop updating while a page loads, yep, that’s exactly why.

A proper scheduler would change all of that. To get real multitasking, the next big pieces would be setting up a PIT or APIC timer along with an IDT, writing a context-switch routine that saves and restores registers and stacks, and then layering a scheduling policy on top. Round-robin would probably be the obvious first step, and honestly it’s not a massive amount of code. Maybe around a hundred lines for a simple implementation. Challenging, sure, but definitely manageable.

One more thing. I haven’t open-sourced the project just yet. The plan is to release the full source when the project is ready. Every line that’s in there today is code I’ve written myself, and I’d rather publish it properly than trickle pieces out along the way.

this is a very structured way to approach a project like this. hats off. do you have any file system stuff too? thatd be honestly mind blowing haha

also, how are you handling the UI rendering? dirty pages stuff or just redrawing the whole screen line by line everytime?

@sudu Yeah, both are there. The filesystem layer exists, although I’ll be the first to admit it’s pretty basic at the moment. Right now it’s an in-memory, read-only VFS built around a VNode tree. The File Explorer browses it through a clean abstraction, so from the user’s perspective you get real directories, files, and an Explorer UI. The catch is that everything disappears after a reboot since nothing is written to disk yet. The nice part is that Explorer only talks to the VFS interface, so I can drop in a proper FAT32 backend later without having to rewrite the UI.

Rendering is also fairly simple. It’s full-scene redraw, but it’s event-driven rather than running every frame. The entire system is single-threaded and fully polled. There’s no scheduler or interrupts yet, so everything runs cooperatively inside one main loop. It only redraws when something actually changes, like a keypress, a mouse click, dragging a window, or the browser doing some work. When that happens, it composites the whole desktop from back to front directly into the VESA framebuffer, then draws the mouse using a save-under sprite.

I haven’t implemented dirty rectangle tracking or double buffering yet. Those are probably the next logical improvements. That said, redraw-on-event has been more than fast enough for a desktop where most of the screen stays unchanged most of the time.

uh huh, i see. amazing. also for the terminal, are you using your custom bash (not sure what you would wanna call it), or the bash command parsing itself? How do you handle commands? are they hardcoded?

(lmao i feel im asking too many question haha). Also i see you’ve managed to get the CSS rendering in the browser. Congratulations!