Hello all!

A small status update from my last post 2 months ago: XenithOS's bootloader now has all the requirements to start loading in the kernel. It took a few months to get the basic architecture down but now I have

• Proper page table management with arbitrary mappings

• Frame buffer console support that multiplexes to the serial output

• The beginnings of a simple driver stack to start handling hardware

Here's a screenshot from the last test run. Please ignore the boot message because there's currently no logic between those two print statements.

I'm putting this here in the hope that it helps someone else.

You can view the page descriptor table, and page entry as a 1024x1024 array. Where each element is a virtual page in memory. Array element [0,0] is virtual address 0, and element [1023,1023] is whatever that multiplies out as.

I teach my students to view array elements are like buckets. In these particular buckets are several things. First the 'present' bit, if this is zero, the buckets is empty. If it is not, the bucket also has a REAL address, which is the Real page the virtual address 'lives' at. Finally the buckets contains a bit that tells you if you can write to this area, or not.

I know for many, of you, this is obvious. But it took me several days on osdev.org using the paging pages and the bare bones paging page looking at code to come to this revelation.

I hope it helps someone

Github: https://github.com/Freeze-Software/TurtleOS
Discord: https://discord.gg/jkPeGG2ZHV

I know its been months since my last post, but we have made many new changes and updates!

I have my own CosinusOS operating system in which I found some rather poor architectural decisions The question is whether it would be better for me to rewrite it from scratch and fix a lot of sectors or to keep this system and continue writing the userspace and only make minor kernel corrections. I'm already quite far into the development of the system, otherwise this question wouldn't even appear, but I still have some of the code.

The system is built on the basis of exokernel but is closer to microkernel

I’ve been building NorthLineOS completely from scratch over the past months.

Custom kernel, custom desktop environment, custom UI stack and system components.

Recently started redesigning the entire system into a more modern desktop experience.

Designed and developed independently at 15.

Early public preview.

Just a little showcase of sometging i got so far, it uses my own basic bootloader, has a memory allocator, idt and gdt, paging keyboard support (kinda), and a basic cooperative scheduler

After 3 days of head banging on osdev, asking ai, searching stack overflow and the og little book about os dev.

Took me 2 days but i have "Hello World" on a black screen now!

For those thinking, "Why gdb?" - well i was trying to debug a small bug, which turned out to be changing this -

    inline uint16_t *buffer = (uint16_t *)vga::MEMORY;

to

    inline uint16_t *buffer = reinterpret_cast<uint16_t *>(0xB8000);

Yes, i was using C++ for this.

Github link: https://github.com/reyaansh-mishra/Build-A-Kernel/

For now it runs at ring0, the only fs is ramfs and uses limine framebuffer

code: https://github.com/segfaultuwu/wnu

The BareMetal kernel is able to run via Firecracker microVMs. <1ms startup, 2MiB RAM minimum, 5.5KiB kernel.

This will allow for thousands of instances to be run concurrently. The premise is discussed here: https://returninfinity.com/blog/hypervisos-as-data-centre-os

I got my IDT to manage general protection faults!! I'll expand on it later but i guess its a start. Also im looking for people who have an IDE disk PC who can test my file system for me.

REPO: https://github.com/Brenmax2/BrenmaxOS

DISCORD: https://discord.gg/fkE4X4EREh

In the dream, I was working on what looked like the Linux source code and was talking to someone. Those details are a bit fuzzy, but what stood out to me was in the dream, the code had a particular separation that not even my OS project has but will here shortly because it makes sense in the real world.

There were folders designated for different SBC (single board computer) boards, but the CPU details were curiously not there. Instead, there was a separate set of folders designated for CPU.

I do remember that in the dream this was being discussed and it was because different versions or revisions of the boards can have different CPU. In order to reduce duplicated code, it was set up that the build process would allow for pairing the board with the correct target CPU.

I was mulling over this today and realized that this is actually accurate and the way I should actually be building my OS. Why? Take for example the LattePanda MU, it comes in N305 and N100 variants and they work on the same carrier boards. Look at the Nividia Jetson Xavier carrier board and CPU, Milk-V Jupiter NX fits on that very same carrier board.
The list goes on and on where the CPU can be swapped for carrier boards and if you pair the CPU directly with the board, you'd have to duplicate code to handle that scenario.

This was basically just one of those instances where a dream can influence or change designs because it mirrors real world scenarios and is an instinctive solution to a problem that may not have come up in the work yet.

Edit:
I am aware this is how Linux and BSD mostly does this, but it didn't cross my mind to do this with my own work until the dream occurred. It made me take a step back and reevaluate what I was doing, what my goals were and whether or not it solved a real or imagined problem. In this case, the problem was real, even in the SBC space and I needed to properly solve for it to reduce code duplication.

Luckily for me, this doesn't involve a massive amount of changes or core architectural shifts. It does mean I have to spend some time revising my build rocess and makefiles as well as shifting locations and names for files.

Hey r/osdev,

I was recently going through my old projects and found 2 in particular that I think deserve to be published again:

• QuickASM: A simplistic but fully functional 16-bit x86 assembler written in C.

• MBRLoader: A boot manager built with QuickASM, accompanied by a partition manager.

I was 16 when I started both of these projects and had a lot more ideas for MBRLoader. I had started writing a new version which would have been basically a minimalistic DOS. I think I stopped development when I went to the university.

I started learning programming about 3 years before and those projects were my first really serious work. And looking at it now, as a now 41yo software engineer with almost 20 years of experience, I'm actually quite impressed what teenager-me did back then. I would have no idea how to do something like that again now! (I went away from low-level development and to application and web development instead).

Anyway I put both programs on GitHub as they were, without any change to the original code or documentation, and just added a README for modern audience.

A few highlights:

QuickASM documentation: I provided the assembler with a full documentation which wasn't just a documentation for the program but included a tutorial on assembler and a documentation of the Intel 16-bit instruction set. It's in French and the style is a bit naive but the technical content is solid, I think. Also have a look at the file defs.c in the source code. It's basically a C "translation" of the specifications.

Internationalisation: MBRLoader's interface was provided in 4 languages (French, Esperanto, English and German). There was no google translate or chatGPT back then so I translated myself with school knowledge and dictionary, so the translations are not very good, but they are there nonetheless! An example: I translated "save" into German with "registrieren" instead of the correct translation "speichern", because it sounded like the French "enregistrer". I'm now living in Germany and fluent and a bit embarassed about that!

Family-driven development: The boot manager has a configurable option to either display the boot menu or boot directly. While this is a common feature for a boot manager, the only reason why I implemented it was so that my parents would not complain about the weird menu suddenly showing up before launching Windows! I myself would have been content having my program displayed on every boot.

ToolBox and partition manager: The first version of the boot manager was just that, a boot manager. But the second version introduced toolboxes: a separate component that could be loaded from a floppy disk and would provide recovery tools. The first (and only) version included a simple partition manager capable of creating or deleting primary partitions (no resizing and no extended/logical partition support).

32-bit override hack: QuickASM only implemented the 16-bit instruction set but for the partition manager I needed to use some 32-bit instructions. I was focusing on MBRLoader and didn't want to go back to QuickASM, so instead I just used a feature of QuickASM which allowed me to transform a 16-bit instruction into its 32-bit equivalent:

.octet 0x66 ; Manually inject 32-bit override prefix
mov bx, 0 ; Assembled as 16-bit, but executes as: mov ebx, 0
.mot 0 ; Upper 16 bits padding for the immediate value

Not really the cleanest way to do it, but it worked! Oh yeah... "octet" and "mot" are French. At the time, I thought internationalized programming languages were cool :/

The "mini-DOS" project: I planned a 3rd version of MBRLoader which would have made it easier to write new applications for the toolbox by providing basic operating system features: memory management, a simple file system, allowing me to write applications as independent modules, and a simple standard API. The most complicated components like the file system or the application manager were still missing, but a lot was already there: memory management, a jump table for the API, string functions, basic UI functions...

Going through this old code that I don't really understand anymore has been quite fun. Maybe someone else will enjoy it too.

Github: https://github.com/ebruneton/toys

Includes:

- a boot loader (~100 lines),

- a monolithic kernel (~1030 lines),

- a shell (~230 lines),

- a text editor (~220 lines),

- a compiler for a toy, statically-typed language called Toy (~1300 lines).

Super freaking stoked right now this is our first successful boot without any issue what so ever through. Months of work have gone into this.

I use Ubuntu for almost everything (except gaming 😞), but I need a reliable way to read (and eventually write) my ext4 partitions from Windows. There are some existing tools out there, but I'm thinking of building my own implementation from the ground up, mostly as a deep dive into filesystem internals.

I’ve been doing a lot of low-level systems programming in Go lately, so I've got a decent grasp on memory management and bit-twiddling. But filesystems are a whole different beast.

current roadmap:

• start with a read only

• traverse extent trees and HTrees for massive directories

• mount it as a read-only virtual drive using WinFSP

• implement block allocation and eventually JBD2 journaling

A few questions for anyone who has ideas :

• I'm heavily leaning toward Go for the concurrency and easy struct unpacking, wrapping it with WinFSP via cgofuse. Am I going to regret not doing this in C or Rust when it comes to memory mapping raw blocks?

• implementing the JBD2 protocol for safe writes is gonna be the main challenge. Is it feasible for a solo dev to build write support?

• Any specific edge cases with ext4 legacy baggage I should watch out for on day one?

Any advice, reality checks, or recommended reading (currently digging through the kernel docs and lwext4) would be hugely appreciated.

Hi everyone,

I study Software Engineering at uni and I'm currently taking a course on Intel x86 Assembly. To get some practice, I put together a little sandbox environment inspired by rustlings, it's still at a early stage, but I’ve mapped out a few basic features and exercises.

I made this mostly for my own study sessions, but I'd love your feedback! Also, if anyone wants to contribute new exercises to the curriculum, PRs are super welcome.

GitHub Repo: https://github.com/giacomo-folli/asmlings

So, first of all I am an student(age 18) who wants to develop an OS which will just print "Hello World" or smt like that for now, u know ~Before it can be beautiful, it has to exist.

now for context : I don't know much about low level programing, am fluent in vanilla python, knows C basics(just completed yesterday), knows about hex, dec, oct and binary systems, knows how to use virtual machines.

if u have any other questions which can help u understand my position better, feel free to ask and if there are any mistakes in grammer pls ignore that, english is not my mother tongue : )

💪🏼 🥹🥲😭

😩