Board.KolibriOS.org

Hi all. For a long time there was an idea that it would be good to start a 64-bit KolibriOS, that would be compatible with the current 32bit version (like modern MenuetOS is backward compatible with Menuet32 apps). And I want to try to start the development. I think that in Kolibri64 we should not repeat the mistakes and downsides of current KolibriOS such as:
- threads are stored in a static array => no more than N threads
- window system: static array of windows, one thread - one window (even if thread doesn't need window), buttons in kernel (really weird, why not comboboxes or editboxes:) )
- no file descriptors => inefficient work with files
- no standard i/o streams => cannot make normal console, command command pipes (like cmd1 | cmd2 | .... | cmdN)
- no SMP support, computational inefficiency, cannot use more than one cpu core (and significant part of current code relies on this fact)
- apps are loaded at 0x0 so NULL is correct address
- overall weird kernel API design (syscalls like draw a dot, line, rect, read a dot, also I dont think that midi stuff and cd tray open/close in kernel is a good idea)

In this thread I will post my thoughts and results, and we can discuss various aspects of the Kolibri64 kernel design

So, as for the kernel, I think I should start with an example that would be able to boot into 64-bit mode and have a debug board with a custom font. Next, I think it is necessary to work on memory managers, interrupt handling and SMP.

Also I found two OSes written in x86-64 assembly Cyjon (https://github.com/CorruptedByCPU/Cyjon) and BareMetal (https://github.com/ReturnInfinity/BareMetal), whose code would be useful to see

What will be the architecture of the kernel? Monolith, modular or microkernel? Who will be involved in its development?

Alex2003 wrote: ↑Tue Jan 30, 2024 12:09 am What will be the architecture of the kernel? Monolith, modular or microkernel? Who will be involved in its development?

I think monolith, but minimalistic, without GUI. Current kernel includes basic GUI like buttons. What if I want to create my own button with cool visual style? Or button with image. In this case I can't just use kernel buttons, I will need to implement button in userspace - duplicate functionality. In the other hand, if we implement buttons in the kernel, we should also implement other basic controls like editboxes, textareas, checkboxes as in WinAPI. But as I said I think GUI in kernel makes development much harder. More code in kernelspace - more crashes (including floating, unreproduceable ones).

On development: to start with, I plan to implement some basic things like initializing 64bit stuff and write at least memory manager.

rgimad wrote: ↑Tue Jan 30, 2024 11:18 pm What if I want to create my own button with cool visual style? Or button with image. In this case I can't just use kernel buttons,

You can, you just create invisible button and draw image using separate functions...

Less code in kernelspace sounds great tough, the question is where to draw the line..

Regarding "initializing 64 bit stuff", why not use pure64?
https://github.com/ReturnInfinity/Pure64