My project, in general, is at an early development stage. However, there is one relatively complex component, a boot loader, that is "ready", i.e. I'm trying to make it stable so no new features are added to it unless really needed. When it comes to programming, this project is not a project but the project for me. I'm not going to start it from scratch or abandon it, but I try my best and see how far I get. Also, I'm perfectly happy what the project is at the moment so there is no "I'd be happy if..." or similar.

2nd Revision of Cardinal (after original Cardinal and then Cardinal;). Cardinal# builds upon design stuff learned from the previous write, opting to go for ahead-of-time compiled C# to replace the elf module loading scheme in Cardinal;

Just got the AoT compiler working a bit better, the entire object model is still missing though, that's going to be my next step. Just felt like showing off

_________________"If the truth is a cruel mistress, than a lie must be a nice girl"Working on CardinalFind me at #Cardinal-OS on freenode!

I finding it nice. I was courriuos what i see technologically. A GUI or just wired trick to make the window? The simplistical approach touching my imagination.

It is not a real GUI and calling it as a "wired trick" is a very good description. However, it is quite flexible in general because the boot loader service provides UTF-8 text output to text mode, VGA mode or VBE modes. The memory footprint for all this functionality is very small and I never read data from the framebuffer. Fonts are 7x14 pixels, and this detail alone complicated the VGA mode support.

The simplistic look is a combination of "technical limitations" and stylistic vision.

Antti: How boot service provide UTF? It two level boot loader or UEFI?

There are many steps (e.g. master boot record, volume boot record) but the main logic is in the "actual" boot loader. In short, the boot loader is "a small OS" but there is no full Unicode support, obviously. It is not a modern OS because it does not control hardware. It reads databases and init files from disk and starts an "architecture specific" executable. All these are placed in "high memory" if possible. Init files are "/system/in_ia16.at", "/system/in_ia32.at", and "/system/in_x64.at". They run in real mode, protected mode (ring 3), or long mode (ring 3), respectively. All the time firmware (BIOS) is still in control.

There are boot services, like e.g. console output, keyboard input, serial ports, and block I/O. Also, basic things like the memory map (sorted and "processed") are provided. After init executables are ready, they call an "exit" function and then the boot loader removes itself and returns to ring 0 and init executables are "on their own". The whole layer is written (at least that was the intention) so that the UEFI boot loader will provide the same interface. That is not available yet and will not be in the near future.

At some point I can create a questions & answers topic. This topic is for screenshots!

After implementing a VFS, devfs, a ustar driver and ELF loading(+ a few syscalls like read, write etc) I was able to create a tiny init program, a shell, and... a paint program. There were a ton of bugs(most of them in exec) but I managed to remove enough to be able to run this. Programs still can't receive arguments or environment variables and copying from and to user is vulnerable to NULL pointers, but hey, it works!

This is after I stopped using VGA text mode, and implemented my own kernel console rendering, currently using VESA in the bootloader. It's a first step to porting to UEFI. It also seems to run faster than VGA text mode in VirtualBox.

Who is online

Users browsing this forum: No registered users and 11 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum