Out of curiosity, why x86? Is it the preponderance of resources? The weird instruction format? The complexity of the boot sequence? Are you specifically trying to mimic DOS?

> A support for the ARM architecture (aarch) is coming soon too.

Wow! How do you support a DOS-like OS across multiple architectures when DOS itself is tightly tied to interactions among the program, the system code, and the architecture?

I have not looked at this project, but my guess would be: x86 is a widely available platform that, because of its history and relentless compatibility, contains a lot of legacy interfaces that make implement a very simple, thin-layer and “DOS-like OS” without the need to parse device trees, set up MMUs, deal with complex busses like PCI(e) and so on.

It is much harder to bootstrap a simple OS in ARM, and it won’t stay very simple unless you accept significantly more limitations than you would under x86. (For example, you can’t do very much with the MMU off on ARM, and you also don’t have convenient BIOS interfaces that allow you to, say, read a sector, or wait for a keypress, with just a few lines of assembly).

The x86 arch is used because this system iteration derives from the first one, which relies on BIOS interrupts and inline assembly in Turbo C. I am not trying to mimic (MS-)DOS exclusively, but both systems are highly inspired by it.

IMO multiple archs could be supported as Rust compiler allows the target arch specification, so one would build a specific target before the build itself.