uniOS - x86-64 hobby OS with native GUI desktop, looking for feedback

[unionyxx]

Hi everyone,

I’ve been working on uniOS, a hobby x86-64 operating system written mostly in C++20.

I’m posting it here because it has reached a point where it boots into its own GUI desktop instead of just being a kernel demo. The desktop currently has a window manager, dock, menubar, terminal, Files, Preferences, About, and a few other small programs.

It is not Linux-based. The project has its own boot path, kernel, userspace, filesystem layer, and GUI stack. A lot is still unfinished/rough, but it is finally usable enough to show and get feedback on.


Screenshot of the current uniOS desktop.

Project page:
https://unionyxx.github.io/uniOS/

Source:
https://github.com/unionyxx/uniOS

Current things I’d like feedback on:
- whether the README/project page makes it clear how the system is structured
- what would make it easier for other OSDev people to build or test
- which parts of the architecture look questionable
- what would be most useful to work on next

If anyone is willing to try it, I’d especially appreciate reports on boot issues, graphics/input problems, or confusing setup steps.

Thanks!

[savoita]

This is pretty impressive! How much code generation was used to create this? It's a lot of progress for only 5 months.

[unionyxx]

This is pretty impressive! How much code generation was used to create this? It's a lot of progress for only 5 months.

Thanks!

For the kernel/boot/filesystem side, basically none of it was generated and pasted in. I used AI mostly for website/README work, mockup ideas, and sometimes for boring UI/userspace scaffolding.

For low-level code I don’t trust generated output much. It can look plausible while still being wrong in ways that only show up later as triple faults, broken memory assumptions, or random crashes. So anything in the boot path, kernel, paging, syscalls, VFS, etc. was written, tested, and debugged by me.

The 5 months is also not 5 months of casual weekend work - I’ve been spending a lot of time on it

[nullplan]

For low-level code I don’t trust generated output much. It can look plausible while still being wrong in ways that only show up later as triple faults, broken memory assumptions, or random crashes. So anything in the boot path, kernel, paging, syscalls, VFS, etc. was written, tested, and debugged by me.

Very sensible. I approve!

[jrifuoue]

Very cool project!

[unionyxx]

Quick update on the project:

Multi-core is now actually working! INIT-SIPI-SIPI with lost-IPI retries, per-core PerCpu/GS setup and LAPIC timers; plus three separate deadlock/race fixes in the scheduler and TLB-shootdown paths. Userspace and the compositor now run stably across cores - validated by 2- and 4-core smoke suites plus a soak test in QEMU. Metal validation next.

I also wrote a detailed, up-to-date wiki on the website covering all the internals (boot sequence, memory layout, VFS, GUI stack, build steps, etc.):
https://unionyxx.github.io/uniOS/wiki/