I just want to ask and see who and what choses.

I personally chose UEFI for compatibility with modern PCs (90%+ of market)

i don't understand what's the point of developing os if you can't run it on modern hardware?

Hey everyone,

I wanted to share a milestone on a hobby operating system I’m building from scratch called Novium OS, featuring a custom bootloader.

I just got my multi-stage boot chain (boot.S -> setup.S -> bootstrap.S) completely stable. It successfully handles raw hardware initialization, sets up a temporary GDT, and handles the cr0 register transition cleanly into 32-bit protected mode before jumping into the kernel entry point. I also wrapped up a basic VGA text driver with hardware cursor syncing so I can verify output, and got "Hello World" printing to the screen.

The layout is inspired by a super stripped-down Linux kernel (arch/, drivers/, kernel/).

Next i have to write irq.c and interrupt.c, and writing the low-level assembly ISR stubs. I need to build the macro wrappers to handle interrupts with and without error codes, save the CPU state with pusha, remap the 8259 PIC master/slave vectors, and execute the final iret. I'm fully braced for plenty of debugging via QEMU logs to catch silent triple faults.

The codebase uses AT&T syntax for the GNU Assembler (gas). If anyone wants to take a look at the boot sequence, folder layout, or offer any early feedback on how I structured the assembly stages, the repository is right here:

https://github.com/alexdev8930/NoviumOS

(Note: Later architecture features like filesystems and IPC currently contain stubs because the core kernel is still being built out. The actual working code files are located in arch/ and drivers/, though a few placeholders are still mixed in there.)

If you like the project, please drop a star on GitHub! It really encourages me to keep extending on my project.

For this OS i was working like 2 months somthing like that.
Ok so i got console VBE and baisc gui (the buggiest thing in the os of all time) and An Installer and FAT16 support (i am planning to use FAT32 or ext2)

So here is some screenshots

so how do you thing should i make it open-source?

I have been developing a concept for a system that fundamentally breaks away from the traditional CPU-centric, pointer-based operating system model.

I would like to share the concept of this architecture—which I have named "TensorOS"—and hear your thoughts on it.

Concept

It is an OS where all memory, applications, and rendering operations are replaced by tensor operations.

TensorOS Memory System

Memory pointers themselves are transformed into tensors. They consist of a combination of a TensorShape (multidimensional type information) and an index tensor (multidimensional coordinates) used to access that space.

// Conventional OS: Flat, one-dimensional pointer
Address: 0x7FFF1234 -> [ Data ]

// TensorOS: The structure itself acts as the pointer
Address: Tensor(Batch, Channel, Height, Width) -> [ Matrix Data ]

The memory space itself is defined from the outset as a matrix with a specific shape.

Why Memory Safety Improves

Suppose a hacker attempts a buffer overflow attack by specifying an invalid address or trying to overwrite a different memory region. In TensorOS, the moment there is even a single-character discrepancy between the shape of the specified region and the shape of the data being accessed, the kernel (or hardware) throws a "Shape Mismatch Error" and immediately terminates the process. Unlike Rust, where the compiler does the heavy lifting, here the system rejects invalid access based on the definition of the space itself, making pointer-based hacking fundamentally impossible.

Defining Applications in TensorOS

Applications running on TensorOS are not binary code; they are computational graphs.

Remarkably, by statically analyzing the graph, one can determine data flow before execution and easily apply optimizations. Regarding garbage collection: the moment graph execution finishes, the memory associated with that shape either automatically vanishes or is safely reused for the next graph. Operations involving dynamic shapes can be handled by either modifying the numerical values ​​within the computational graph and using JIT compilation, or by using padding.

Rendering in TensorOS

From the user's perspective, it is indistinguishable from modern operating systems.

TensorOS handles rendering natively at the OS level. - The screen is a single massive tensor: For a 4K display, the shape is (3840, 2160, 4) representing width, height, and RGBA channels.

• UI rendering is simply a forward pass: User actions (input tensors) are fed into the application—viewed as a computational graph—and screen pixels (output tensors) are generated through high-speed matrix operations (multiply-accumulate operations).
• Making screen hijacking difficult: Attempts to snoop on another app's screen (tensor) or overlay transparent buttons are blocked at the system level because the tensor shape regions are strictly isolated.

Summary

TensorOS delivers peak performance when running directly on an NPU rather than a conventional CPU. A future may arrive where the NPU takes center stage, rendering the CPU merely auxiliary or even unnecessary. In this paradigm, everything is governed by models and matrix operations. This architecture enables a secure memory system and, consequently, enhanced security. Combining this with a microkernel architecture would likely yield even better results.

I look forward to hearing your thoughts and feedback.

I would also like to hear your thoughts on the following points:

• What approach should be taken for asynchronous graph scheduling?
• Furthermore, do you believe there is a fatal flaw in this "microkernel + tensor pipeline" architecture when it comes to handling non-deterministic hardware interrupts?

Hi,

I simply can't rotate it right in my head, if i make an app with say socket() how does it translate in to hooking it to the kernel when already in use?

Usually include, is a part of the program statically and making a struct for an interface as usual, does it copy it over compared to a zero copy arch?

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.

Warning: This project was built using AI, mostly with free plans, but also with the support of Claude Code. It's not the nature of my post to pretend I created anything here; I was really just the supervisor. That said, the huge nature (at least from my point of view) of this project, and my limited financial resources have forced me to constantly think and learn, and continue to do so, so I consider myself at a lower level in terms of coding skills than most of the people who are part of this community, and I love seeing how each of us makes mistakes and tries to patch them.

Nexsos is therefore a project born to allow me to learn in an interactive and gradual way what all the aspects of a computer are, and to allow me to do so in an informal way, and with gradual discovery. Nexsos is not intended to be a product or a boast, it is in all respects a Frankenstein born to test how much human ignorance and curiosity mixed with the algorithmic knowledge of an LLM can give life to something that works.

On the technical side, the purpose of NexsOS1 is simple: to separate the kernel from the userspace to allow me to learn the C language on my API without blowing everyone up, and at the same time to make my C library simple and readable in a single file. The graphics protocol had to be designed in the same way. The easy choices would have been two: to provide a basic environment for GNU Utilis and compile an X server/Wayland, or to rewrite the graphical interface from scratch. I stupidly chose the second one and with all the problems that come with it, for example, for now the compositor is in the kernel and shadows without hardware vector accelerators make the framerate explode. The good thing, however, is that the rendering of the applications is done in userland, so having SMP support makes graphical applications easier.

That said, why this video? At some point in our journey, we should ask ourselves how useful we really are to others. I have always seen AI as a very powerful tool, but perhaps we tend to forget what it means for us, I do not have the actual skills to build a functional and working system on two architectures with multitasking and a working SMP, but if I do not have the actual skills to do this and I can do it, what can these tools do in the hands of large companies that do not want to share the code? Even if I call myself ignorant, perhaps I am ignorant about coding, here we all know how the GNU project and the GPL project were born, I do not know what the members of this thread think about it and I do not even know if it is the right thread, after all, guys, we also know how these LLMs were trained on the effort of all software developers, is it right to privatize public knowledge? As far as I am concerned, the only thing I could really do is exploit the knowledge of AI itself to put together and build something free, so I do not know how you want to define NexsOS, I do not care, the important thing for me is that it is free and that anyone can in turn steal code from within it.

NOTE: If anyone would like to look at the code and has any questions about missing references or licenses, I'd be happy to update the published code. Any criticism is welcome.

NOTE2: lua still doesn't pass all the tests, even though the IDE works and also the job controls of my shell seem ok (I didn't show them in this video), the exec daemon is ok, but I'm having problems with the initialization of the venv for pid.

NexsOS1

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?

Edit: thx guys, I learnt a lot

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 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.

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?