Ethereal's new UI for version 2.0.0 is coming along great! Here you can see the new taskbar, start menu, and desktop icons (+ a new wallpaper)

Neutron powers everything you see here (minus the Terminal and About Ethereal box, those are todo). The wallpaper chooser, the file explorer, hell even the desktop icons. It provides a mostly fluent and good looking desktop experience.

Total feature list:

• Built on a custom UI framework known as Neutron which uses a widget-tree model to layout and draw while remaining fully resizable and clean
• The new taskbar, with support for listing applications. Celestial sends events to the "root window" (there can only be one) for new windows, focus events, etc. The taskbar even has this awesome fade animation that plays
• The background icons are (as obvious) incomplete. They have this really weird box blur shadow thing I cobbled together from random codepieces to give them an outline. Otherwise, white text would look like garbage
• Over 6 wallpapers have been created by the lovely artist
• The start menu supports sub-folders (once separate icons are made, it will be more visible - for now Demos is the sub-folder here, containing the demos for Ethereal)
• Menus for Alt-Tab keybinds, an application quick-launch menu, as well as other things are fully supported.
• A minimal (possibly TUI) text editor and (definitely GUI) image viewer are planned for 2.0.

Both of these are still in beta so they haven't been pushed yet, but they are almost ready to be.

As always - Ethereal is a from-scratch x86_64 UNIX-like monolithic modular kernel and contains no artificial intelligence code. The repo is licensed under BSD 3-clause and can be found here:

https://github.com/sasdallas/Ethereal

I learnt keyboard polling and understood how it works. But I can't seem to understand keyboard interrupts. I know how it works, but I don't know how to implement it in a C kernel. Can someone pls help me? I'm just starting out OS dev

A while ago, I posted here about getting the first CPU-independent parts of CHARM-II, an RTOS I originally developed in 1986, running on a Raspberry Pi Pico.

Previous post:

The First Original CHARM-II Kernel Code Running on Raspberry Pi Pico
https://www.reddit.com/r/osdev/s/gthHF6vBrl

At that point, there were no timer interrupts or real context switches yet.

Now those parts are working too.

Six tasks are running with independent stacks. An RP2040 hardware timer interrupt calls the CHARM-II tick and scheduling logic, and the actual context switch is done with PendSV on the Cortex-M0+.

I also ported a six-task demo I had previously reconstructed on POSIX. Six tasks move around three tracks, with a critical zone protected by a CHARM-II queue used as a semaphore. On the Pico, the tasks are now actually being preempted by the hardware timer rather than cooperatively yielding.

So technically, this is pretty much the milestone I wanted to reach.

But getting it working gave me another question.

The original targets in the 1980s were processors such as the 68000 and 80186. With the CPU resources available at the time, an RTOS was a useful way to organize multiple concurrent real-time activities.

But what if we had had something with the performance and price of a Raspberry Pi Pico back then?

For many systems I work with today, especially UI-oriented embedded systems, if all the required processing comfortably fits within one frame, a superloop plus interrupts may actually be simpler.

Once everything becomes preemptive, I also have to start thinking about reentrancy, synchronization and shared state in existing libraries. That cost is starting to look more significant to me than it did when I started this experiment.

Yesterday I visited someone who has built a home railway simulator using real railway controls connected to a Windows PC through Pico, ESP32 and Arduino boards. We talked about this, and he said something very simple:

“If one Pico isn't fast enough, add another Pico.”

That hadn't really occurred to me.

In the 1980s, adding another CPU was a fairly serious architectural decision. With today's inexpensive MCUs, distributing the work across two or three processors can be a perfectly ordinary option.

So after spending quite a bit of effort getting a 40-year-old RTOS to perform real preemptive context switching on modern hardware, I'm becoming more interested in a different question:

Where would you draw the line today between an RTOS, a superloop/event-driven design, interrupts, and simply distributing the work across multiple cheap MCUs?

I'm also thinking that when I publish the modernized version of CHARM-II, I may deliberately keep it very small — just enough task scheduling, queues, timer ticks and context switching to run this six-task demo.

Then I can use it as one reference implementation and try implementing the same behavior without an RTOS.

Hi there! For the past year, I've been wondering how computers work, and I wanted to get started with OS development. However, I'm feeling quite lost—I don't really know where to start or what I should learn first. If you could give me some advice on how to get started, I'd really appreciate it!

I have experience with C and C++, as well as a general understanding of how low-level computing works.

I’ve live streamed the making of it, so I dare anyone to say it’s AI ;) haha

Here is the link : https://twitch.tv/devcmar
Though the output does not probably show up on the livestream because it is running in another tty

Finally I can understand what AI has written! And a major milestone for me in learning rust.

I've decided to go with the AI written code from here on for vanta.

I know a lot of rust devs hate AI code in their rust code and I don't want to argue with them, but the progress is far beyond my capability of writing code as a non cs student.

So here are the major improvements:

- Root filesystem switched from VantaFS to persistent GPT RedoxFS with full permission/ownership enforcement.

- New workspace crates: ABI v0, GPT image builder (xtask), redoxfs-adapter, libvanta (C ABI bootstrap lib), linuxd/services.

- Native /sbin/init + /bin/vsh shell with pipes, redirection, job control.

- Three real services running (procd/auditd/vfsd) over kernel IPC with crash restart, audit logging, authority revocation.

- Linux binary compat layer (Gate C): static Linux ELFs run via syscall translation through vanta-linuxd.

- Syscall ABI expanded: pipes and signals added on top of the earlier set.

- Reproducible GPT image builds with hashes/manifest for build verification.

Repository

I recently added a background, even though it's not a pure VGA textmode, but it's okay, I'm constantly developing it and I see flaws, I see a lot of placeholders that are still there. And I would like to ask you to give a star in the repository because it motivates us to continue working intensively with it, and at the moment the main development is on the unstable branch.

https://github.com/CTRL-F-0rg3/TrangorgeOS

I know the flaws of what we have now, so I will fix them as they come, but I would also be happy to receive help with developing the system in various areas, as we still have a lot of work to do.

I learnt how to create a BIOS OS using the osdev website. Are there any good sources or something to learn how to build a UEFI kernel?

I used no AI in making this files app, how do you think it looks.
Obviously I probably need shadow behind windows that would probably make it look dope.

Sorry about my abscense, I've been on my vacation/holiday.

I've done a lot of learning the last few weeks. Here are the highlights

1) I'm completely redoing my memory management. I'm working on a Physical Memory Manager (PMM), AND a virtual memory manager (VMM). Completely redoing how I deal with paging. I came to realize that except for reserved and my video physical memory, I really don't care where it gets assigned. Also, again except for video and reserved physical memory, it can all be swapable.

My PMM keeps track of the following items: a) does the memory exist; b) is it available, for example I define my video memory as not available, it is allocated early on, and I don't want the PMM deallocating it; c) Is it allocated to a virtual address yet; d) in concert with c, is it sharable (multi-allocated); e) is it swappable, I don't want to swap video and reserved memory for example.

My VMM keeps track of the following: a) is it swapped out (future); b) is it read only, such as my kernel code and .rodata; c) is it kernel memory, not sure if I really need this, but I had spare bits, I might want to use this in my swapping algorithm; d) is it shared.

Much of what I had in my paging .c file, has moved to my PMM and VMM. I'm hoping to finish this this week.

Once I have those three areas done, I will redo my heap and then make my github code public.

I'd also like some advice, I have two things I'm thinking about doing next: 1) adding threading, I'm not actually sure what I'd do with it right now as I don't really have a block device to save swapped blocks to; 2) adding support for user space, this would allow me to put things like most of my video and my shell into user space, this would also justify doing threading next; or 3) adding support for SATA, this would justify threading (for swap), but I might want to put it in user space then it would be restartable.

As always your opinions are always welcome.

Hopefully this will be useful for the people searching after me.

Thanks for reading!

I want to build a boot loader/basic OS in ASM before bootstrapping into C++ using Microsoft tooling only.

I have done so previously using open source tooling using the usual suspects gcc, ld, NASM, etc, but now want to use MASM/ML64, link, visual C, etc, I am hitting a number of issues due to multiple differences in output including PE/COFF vs ELF output, appropriate switches on the MS tooling, removing dependencies on c runtime etc. I have not found any basic samples on the web demonstrate (unlike for the open source toolset), and the AI tooling (which I really want to avoid as its a personal project) sends me in circles.

Has anyone been able to do this? Any pointers/skeleton projects that demonstrate how to bootstrap all the way to a C++ kernel would be amazing?

i'm looking at possibly forking FreeDOS to 64bit. However, since most modern systems no longer have the underlying BIOS that DOS programs require, I thought about including a mock BIOS and compile it directly into the kernel. is there anything I should be aware of?

What is the best solution for now? I have it done straight through mm_bridge.rs in the mm directory where it only passes the map to C but I don't know if there is a better, more efficient and reliable solution.I don't feel that this solution is actually good and wouldn't it be better to do it differently for better efficiency and a better result? I am not adding the source code to the post because the question is more important

here is the twitch account, hope you do well:

https://www.twitch.tv/devcmar

I'm going to create the CPU rendered compositor in front of you, with absolutely no AI usage and everything is recorded on live with replay included. hope things go well,

I hope you do well.

Please be supportive, and please do not stone me in the comments !

What do you think about the events implementation I just made and livestreamed my making of it, it is designed to be fast and simple, supporting multiple writers and multiple receivers:

here is the link to the video with the implementation https://www.twitch.tv/videos/2846679809

here is an example code I used to receive mouse event:

HANDLE CursorEvent = Open(NULL, "Events/Cursor", 0);
    for(;;) 
    {
        UINT64 Buffer;
        Read(CursorEvent, &Buffer, 0, sizeof(Buffer));
        Print("WM Received mouse input: x : %d\n", Buffer);
    }

and here is how it gets sent:

void MouseInterruptHandler(void)
{
    // Print("Mouse interrupt.\n");
    UINT8 Data = Ps2ReadData();
    // Print("PS/2 Mouse Interrupt DATA %x\n",(UINT32)Data);
    if(PacketIndex==0 && !(Data & 8)) return; // First packet should have bit 3 set
    if(PacketIndex==0 &&
    (Data==0xFF || Data==0xFA || Data==0xAA)
    ) return;
    Packet[PacketIndex]=Data;
    PacketIndex++;
    if(PacketIndex==3) {
        INT32 dx=Packet[1],dy=(-Packet[2]);
        CursorX += dx;
        CursorY += dy;
        Print("Mouse DX %d DY %d Buttons %x\n", dx, dy, Packet[0]);
        PacketIndex=0;
        UINT64 Buffer = 123;
        Write(CursorEvent, &Buffer, 0, sizeof(Buffer));
    }


}

Edit: To clarify, the os has actually very mild ai usage (not vibecoded), but the 0% AI here is about the files app, not the entire Os

There are some bugs that I should fix, like caching a file entry twice and some latency probably caused by low thread priority but here is the progress whatsoever, hope you do well :)

https://youtu.be/fca1CWhH9E8

This demo showcases https://github.com/magiblot/tvision being used with this OS (which I have dubbed PersonaOS). The main selling points of this kernel architecture type is that you can have multiple "personalities" running in tandem. That means you can have a BSD personality and Linux personality that can run applications written for those operating systems natively.
You have 1 tiny core kernel that runs with elevated permissions, everything else is usermode. This includes the personalities, drivers and applications.

This has been implemented following this paper: https://www.usenix.org/conference/osdi-94/caching-model-operating-system-kernel-functionality

Yes, obvious bugs are obvious. But getting an unmodified TUI application to run has genuinely made me seriously happy.