[Announce] YulaOS: 32-bit SMP Kernel with Compositing GUI & Self-Hosting Toolchain

[Yula]

Hi everyone,

My name is Vladimir (aka Yula), I am a 15-year-old student, and I would like to share my hobby operating system project: YulaOS.

I have been working on this intensely for the past few weeks (a massive development sprint of sleepless nights), aiming to build a unix-like environment from scratch.

Repository: https://github.com/Yula1234/YulaOS

Key Features

Kernel & Architecture:

• Arch: x86 (32-bit), Multiboot compliant.
• Memory Management: Higher-half kernel, PMM (bitmap), VMM using Red-Black Trees for tracking free virtual memory regions (O(log n) allocation).
• Multiprocessing (SMP): Full SMP support, parsing MADT, APIC/IOAPIC setup, and AP trampoline at 0x1000.
• Scheduler: Preemptive multitasking with basic priority handling.

Drivers:

• Storage: AHCI driver with MSI support (supports read/write).
• Input: PS/2 Keyboard and Mouse.
• Graphics: VBE Linear Framebuffer with SSE-accelerated software rendering.

Userland & GUI:

• Window Manager: Custom compositing WM with support for overlapping windows, transparency, and "dirty rectangles" tracking to minimize redraws.
• Filesystem: YulaFS - a custom Unix-like filesystem with a block cache layer.
• Shell: Features command history, piping (`|`), and process management.

The Custom Toolchain (Work in Progress):
Instead of porting GCC immediately, I challenged myself to write my own toolchain that runs natively on YulaOS. It is not yet fully self-hosting (cannot compile itself yet), but it works for userland programs:

• scc: A Small C Compiler. It performs lexical analysis, parsing (AST), generates IR (Intermediate Representation), and emits ELF object files.
• asmc: A custom assembler for x86 instructions.
• uld: A linker that combines object files into an executable ELF.

Future Plans & Feedback

My immediate goals are to improve `scc` to support more C features so it can eventually compile itself and the kernel.

I would appreciate any feedback on the code structure.

Thanks for looking!

[Alexey1994]

Добрый день.

Есть один вопрос:
1) вы действительно 15 летний студент, или это проблема перевода?

Хоть меня никто не просил, но могу дать некоторые советы:
1) никогда не публикуйте свои собственные работы под GPL, вы не сможете их продать, на поиск работы это тоже никак не влияет, скорее мешает
2) изучайте схемотехнику, электротехнику, современные программисты в этом ничего не смыслят
3) используйте только ассемблер, никаких си, на нём легко научиться писать, программы получаются хорошего качества
4) попробуйте вместо красно-черных деревьев префиксные деревья
5) если вы Владимир, не называйте себя Юля
6) миру нужны изобретатели, ибо автоматизировать мы так и не научились. На сегодняшний день автоматизировано только оболванивание людей всякими психолого-философскими приёмами из СМИ. Чтобы оболваненные люди делали всю работу по автоматизации за почти бесплатно по 8 часов в день 5 раз в неделю. И нужда совсем не означает что за это будут платить. Платить вам будут за видимость работы, лояльность и покорность, а не за результат

[Alexey1994]

My name is Vladimir (aka Yula), I am a 15-year-old student, and I would like to share my hobby operating system project: YulaOS.

I have been working on this intensely for the past few weeks (a massive development sprint of sleepless nights), aiming to build a unix-like environment from scratch.

Я посмотрел бегло код и структуру проекта и всё равно не могу понять как так получилось что в 15 лет нашлись силы и терпение вложиться в столь масштабный проект. Сделано слишком много я считаю, полноценная самодостаточная ОС с программами.

[Octocontrabass]

3) используйте только ассемблер, никаких си, на нём легко научиться писать, программы получаются хорошего качества

This seems like bad advice. (Can you post in English too?)

[Alexey1994]

3) используйте только ассемблер, никаких си, на нём легко научиться писать, программы получаются хорошего качества

This seems like bad advice. (Can you post in English too?)

Of course. My point is this: C doesn't give you complete control over the code, even if you write the compiler yourself. Assembler, on the other hand, doesn't impose any restrictions. If you need AVX optimizations, you just use them. C speeds up development, but the product itself will never be finished, even if new features aren't added. The optimal solution is to develop a prototype in C and manually translate it to assembler.

[Demindiro]

Of course. My point is this: C doesn't give you complete control over the code, even if you write the compiler yourself. Assembler, on the other hand, doesn't impose any restrictions. If you need AVX optimizations, you just use them. C speeds up development, but the product itself will never be finished, even if new features aren't added. The optimal solution is to develop a prototype in C and manually translate it to assembler.

C compilers can and will emit AVX instructions if you instruct them to, using -mavx option, intrinsics or function attributes.
Intrinsics have the advantage that compilers know about them, allowing more optimizations than with an opaque block of assembly.

An assembly program arguably is never "finished" either as it is:
1. architecture-specific, i.e. non-portable.
2. isn't able to take advantage of new processor features without modification. A program in a HLL could however take advantage of it with a simple recompilation (or by upgrading the interpreter).

But what does "finished" even mean in this context? Consider:

Code: Select all

// echo.c

#include <stdio.h>

int main(int argc, char **argv) {
        const char *pre = "";
        for (int i = 1; i < argc; i++) {
                printf("%s%s", pre, argv[i]);
                pre = " ";
        }
        puts("");
        return 0;
}

This program will never need any modifications on any platform with a C compiler and a C stdlib. It is also highly unlikely it will ever be a performance bottleneck, so optimizations, let alone architecture extensions, are mostly irrelevant.
An equivalent assembly program would have to be rewritten not just for every architecture but every OS too.

[Alexey1994]

intrinsics

Exactly, intrinsics instead of normal instructions

Intrinsics have the advantage that compilers know about them, allowing more optimizations than with an opaque block of assembly.

This means that the code will not always be compiled, not everywhere, and not in 10 years.

An assembly program arguably is never "finished" either as it is:
1. architecture-specific, i.e. non-portable.

It is better to choose one architecture than to support two.

isn't able to take advantage of new processor features without modification. A program in a HLL could however take advantage of it with a simple recompilation (or by upgrading the interpreter).

ror, rol instructions, btr, btc, bts, bsf in C are implemented either through intrinsics, or assembler inserts, or optimizations, and you never know whether the translation you need will work

But what does "finished" even mean in this context? Consider:

for example, the program of the post author:

Code: Select all

// SPDX-License-Identifier: GPL-2.0
// Copyright (C) 2025 Yula1234

#include <yula.h>

#define BUF_SIZE 1024

int main(int argc, char** argv) {
    if (argc < 2) {
        printf("Usage: cat <filename>\n");
        return 1;
    }

    int fd = open(argv[1], 0);
    if (fd < 0) {
        printf("cat: %s: No such file or directory\n", argv[1]);
        return 1;
    }

    char buf[BUF_SIZE];
    int n;

    while ((n = read(fd, buf, BUF_SIZE)) > 0) {
        write(1, buf, n);
    }

    close(fd);
    
    print("\n");
    
    return 0;
}

although I would change it to #define BUF_SIZE 65536 or 4096, but that's not the point. This C program would hardly fit in 512 bytes with all the static library bells and whistles, and in assembler it would easily fit.

[Alexey1994]

Damn it, the author is a clever guy, he wrote a nice-looking code, and I didn't immediately notice that his cat is not concat at all, and he even puts \n at the end. Oh, I shouldn't have looked too closely.

[nullplan]

5) если вы Владимир, не называйте себя Юля

What business is it of yours?

Damn it, the author is a clever guy, he wrote a nice-looking code, and I didn't immediately notice that his cat is not concat at all, and he even puts \n at the end. Oh, I shouldn't have looked too closely.

Is there any point to this riffing? Yes, there is bad C code out there, some of it is even posted to this board. There is also bad assembler out there. I have frequently found assembler to be a write-only language. Changing anything requires so many far-reaching changes that you are better off rewriting the entire part. And that's not very sensible for software development.

[iansjack]

Don't provoke fights or participate in fights started by others. Windows vs linux and programming language battles have been fought many times and resulted in a draw every single time.

[Yula]

Добрый день.

Есть один вопрос:
1) вы действительно 15 летний студент, или это проблема перевода?

Хоть меня никто не просил, но могу дать некоторые советы:
1) никогда не публикуйте свои собственные работы под GPL, вы не сможете их продать, на поиск работы это тоже никак не влияет, скорее мешает
2) изучайте схемотехнику, электротехнику, современные программисты в этом ничего не смыслят
3) используйте только ассемблер, никаких си, на нём легко научиться писать, программы получаются хорошего качества
4) попробуйте вместо красно-черных деревьев префиксные деревья
5) если вы Владимир, не называйте себя Юля
6) миру нужны изобретатели, ибо автоматизировать мы так и не научились. На сегодняшний день автоматизировано только оболванивание людей всякими психолого-философскими приёмами из СМИ. Чтобы оболваненные люди делали всю работу по автоматизации за почти бесплатно по 8 часов в день 5 раз в неделю. И нужда совсем не означает что за это будут платить. Платить вам будут за видимость работы, лояльность и покорность, а не за результат

Hello, first of all, let's follow the OSDev rules and communicate in English. Next, I will answer some of your questions, yes, I really am 15 years old.

1. I carefully chose the license, and since I do not plan to monetize this project in any way, the license was chosen based on the ideal criteria for open source.
2. So far, my knowledge is limited to what I have read in the specifications of specific processors, controllers, and other hardware that needed to be read to write this operating system.
3. In fact, you are unlikely to be right about this, because I know how to write and read in assembler, you can even see that on my repository in github there is a programs folder in which there is such a file as asmc.c, this is my personal assembler for my operating system written in C. As for writing an operating system in assembler, no one disputes that it will not be many times, but it will be faster enough than a project written in C, however, support and a banal understanding of your own code, as well as the ability to build minimal useful abstractions, will immediately disappear, moreover, wherever really high speed is needed, or just low-level hardware control, I use assembler inserts in my code, which you can also see by looking at the repository on github, in particular src/drivers/vga.c.
4. So far I have not heard anything and have never encountered such a data structure, let's see, so far I have not encountered any problems with my current allocator in terms of speed or fragmentation.
5. Perhaps you did not read the nickname correctly, he is not Julia, but Yula, there is such a toy, most likely you know.
6. I don't quite understand what this is about...

Anyway, thanks for the feedback!

[Yula]

Damn it, the author is a clever guy, he wrote a nice-looking code, and I didn't immediately notice that his cat is not concat at all, and he even puts \n at the end. Oh, I shouldn't have looked too closely.

Yes, in general, you should not pay attention to such small programs written in C lying in the programs folder, they are generally created only for operating system tests, system calls and other things, this is not relevant software of course

[Yula]

Overall, I don't claim that my OS is a groundbreaking innovation. My goal is simply to demonstrate that there are people interested in low-level programming, and that age is not a barrier.

I also hope we can avoid nitpicking over minor details regarding the userspace tools. For instance, pointing out that my cat command doesn't actually concatenate files and adds an extra newline is unnecessary. I didn't aim for complexity or strict compliance for the software in the programs folder. While the C compiler and Assembler required serious effort, the rest of the utilities exist purely for testing purposes. I wrote cat in a couple of minutes just to verify that pipes were working correctly when I first implemented them in the kernel.

I have a clear vision of where the project is heading and what needs fixing. The kernel is past its infancy; it has become a fairly large project. With 30,000 lines of code, I realize this is the critical point where I need to focus on refining the architecture and addressing technical nuances. I am well aware of current flaws, such as the shell running in kernel space instead of userspace, or the lack of certain abstractions and conveniences for userspace programs. However, these are solvable issues, and I am working on the project almost every day.

Thank you all for your feedback.

[Yula]

I would like to address Alexey's points regarding Assembly in the kernel in more detail.

I agree that Assembly is excellent where it is truly necessary, such as for hardware interaction and other low-level tasks. However, I believe writing a full-featured kernel entirely in Assembly is a maintenance nightmare.

This is not because Assembly is difficult, nor because I lack understanding. As I mentioned before, I wrote my own assembler with a sufficient ISA set, and I have a strong grasp of x86 Assembly. The issue lies elsewhere.

For instance, consider code maintainability. It is simply unfeasible for a single developer to write a kernel of this scale in Assembly and still navigate the codebase efficiently. This isn't a lack of skill; rather, I consider it an inefficient decision to force Assembly into places where it is absolutely unnecessary.

I compile my kernel with various GCC optimization flags. If you examine the disassembled output, it is evident that the compiler optimizes C code quite effectively. While it might slightly lag behind hand-written Assembly in raw speed, the code remains readable, easier to document, and allows for effective debugging with modern tools.

Regarding portability, which others have already mentioned: although I don't have immediate plans to port the kernel to other architectures (like ARM), having a massive amount of Assembly would make this physically impossible without messy #ifdefs during compilation. In general, I strive to minimize the amount of Assembly code in my kernel, prioritizing abstractions and future portability.

In short, Assembly is a powerful tool, but it should not be abused to the project's detriment.

[Yula]

To give you the full picture of the project's scale: I started writing YulaOS from scratch on December 18, 2025.
Everything you see in the repository (~30k LOC, the kernel, the custom toolchain, the GUI) is the result of a sleepless marathon over the last 27 days (often working 20+ hours a day without sleep). This was a massive "winter break sprint" for me.