Pass cosmos to Gen3

[selkij]

The current state of Cosmos is as follows:

• unstable memory manager (and memory leaks)
• slow canvas
• broken network protocols
• VBE only works on VirtualBox
• code can be confusing

Here are the current components/projects that need improvements:

• IL2CPU
• Canvas
• Memory Manager
• TCP, UDP, FTP, and maybe more
• INTs, unhelpful error message when we don't have a debugger and the DivisionByZeroException's ISR doesn't fire (probably because of IL2CPU)
• Project cleanup
• Better general exception handling
• AfterRun() is useless because only force shutdown is available
• A "ring system" is used but a kernel should only have ring 0

Additions to Cosmos that people may want:

• UTF-8 encoding
• Multithread (with the needed components like APIC)
• Limine boot protocol instead of Multiboot2 (that leads us to x64)
• UEFI
• USB xHCI
• More customization like they can disable a component and make their own with a given object (without having to make a plug which is time and resource-consuming)
• More optimized IL2CPU or move to NativeAOT
• Port to ARM
• Easier access to XSharp in code
• A Driver object to make driver coding easier
• Possibility to customize limine.cfg
• Stop focusing on Visual Studio, people like me also use other IDEs like Rider

And so multithreading is even blocked by the memory manager, I suggest passing to gen3 to start from zero for a better result, to discuss below.

[terminal-cs]

About the VBE, if you enable it from the properties menu it uses VBE from multiboot which works everywhere, but it's annoying to manage. Also, if you enable it from project properties, it cannot be disabled at runtime, and the screen cannot be resized.

[RaphProductions]

SipaaKernel is VBE-based and its working on VMware,VBox

[terminal-cs]

If there's ever a good effort to re-do cosmos as a whole, i recommend to re-do IL2CPU, or, at least re-do the plugs system, as the way it works causes most of the memory leaks, and the memory leaked cannot be freed, even with Heap.Collect(). A coredev told me just by the way the current plug implementation is made causes the plugs so code fixes won't work to fix it.

[selkij]

Yep but maybe if a re-do of IL2CPU would have to be done, we could pass it to x64 and so use limine protocol for cosmos instead of multiboot2

[quajak]

How do plugs cause memory leaks?

[selkij]

more view aspects with a coredev would be great like @quajak @zarlo @MishaTy
(I call everyone to be sure)

[zarlo]

I think that IL2CPU needs to be replaced with Native AOT, and Cosmos completely rewritten.

a downside with Native AOT we have to implement more or less the whole standard library

[terminal-cs]

I think that IL2CPU needs to be replaced with Native AOT, and Cosmos completely rewritten.

a downside with Native AOT we have to implement more or less the whole standard library

Isn't that already being done in cosmos?

[jwoff78]

I've compiled runtimelabs/nativeaot for mono on my system, some stuff is rather straight forward after that, if you can implement there library it will take a lot of the hassle out the libraries rest under \runtimelab-feature-NativeAOT\src\coreclr\nativeaot

[zarlo]

I think that IL2CPU needs to be replaced with Native AOT, and Cosmos completely rewritten.

a downside with Native AOT we have to implement more or less the whole standard library

Isn't that already being done in cosmos?

no we only have to do it for things that call native code

like with lists we dont have a plug for that as its not needed we just use the code from .nets standard library but with arrays (what lists use under the hood) we had to make a plug as that uses native code

[quajak]

All of the issues can be solved in the current system with in most cases not that much work including the issues with IL2CPU with regards to exception handling. The real issue with the state of the project is that IL2CPU and Cosmos require more work to improve than people are currently putting into it. This might be partially due to the size, complexity and quality of the code but a rewrite is not necessarily going to increase the number of contributors.

The only reason to rewrite Cosmos from the ground up is due to the limitations to IL2CPU and if we were to rewrite Cosmos from the ground up it should be based on .Net AOT since they have way more resources and a more advanced system. To get around rewriting the entire standard library, patching AOT to load in the existing standard library and using a plug based system like currently should work but I havnt looked into the details.

Personally, I don't think I will have time to support such an effort in any meaningful fashion but if others want to go ahead with it, please do. I will continue making progress on the current version, whenever possible.

[AsertCreator]

how we need to make cosmos libraries: as close to net bcl, or as far from net bcl? if we make it close, we need to rewrite it entirely to use cosmos routines, but also, it would be easier for developers to port their apps to cosmos. but if we make it far, cosmos would be much lighter and cleaner, but app porting would be very hard

[AsertCreator]

btw, we need to rewrite cosmos's documentation and finally realize where documentation will be

[AsertCreator]

btw2, should we preserve cosmos's modules/sections/technologies names? CGS and CAI sound great. CGS needs a complete rewrite and CAI needs a intel hda/realtek support

[AsertCreator]

i think cosmos needs to have a userspace, paging and uefi support (sound like a cosmos will not be a os development kit). cosmos does currently have some sort of ring system, but it doesnt switch actual x86 privilege rings. paging would be great, as we can swap pages to disk, implement copy-on-write or move data around ram more efficiently. uefi support would give us acpi, framebuffer, x64, arm, pci, usb support almost out-of-box

[selkij]

Yep and using limine boot protocol instead of multiboot2

[AsertCreator]

is limine bootable using multiboot2? limine bp is pretty cool, but i think cosmos still should be bootable using grub, even if it will be a limine in a middle. it is possible using grub's chainload module, which loads an efi app

[AsertCreator]

i came up with an idea. we can make il2cpu to generate assembly files for every class separately, then compile them and link them all. using this scheme, we can inject c/c++ code into cosmos, and use it from cosmos using extern and some attribute

[AsertCreator]

at what point we should stop gen2 development and start gen3 development?

[zarlo]

gen 3 started like 2 years ago

[selkij]

gen 3 started like 2 years ago

Well it has been paused as I've seen there wasn't any changes made since I discovered cosmos

[AsertCreator]

it was last updated 5 years ago, as i remember

[selkij]

If we all agree on passing to gen3, a coredev can create a branch and a PR for that.

[RaphProductions]

switch cosmos to .NET 7?

[zarlo]

we will only be supporting LTS versions of .net so next .net update will be .net 8

[BlitzWolf007]

If we rewrite Cosmos to gen 3 we should make it 64 bit and UEFI based.

[selkij]

yeah that's what we said

[BlitzWolf007]

oh I didnt see that sorry

[selkij]

https://trello.com/b/CGi2Wi0N/cosmosgen3

[AsertCreator]

maybe we could deprecate xsharp? in cosmos and il2cpu we need it only for inlining assembly. we could make some attribute for il2cpu that will tell that this function is assembly. xsharp examples are empty. xsharp is not used so much

[AsertCreator]

i mean, that xsharp is not used, but for inlining assembly and generating output. we can merge xsharp and il2cpu together, if xsharp is basically useless

[zarlo]

xsharp can be used as a standalone language

[AsertCreator]

nobody uses xsharp as standalone language.

[zarlo]

cosmos does there the debugger uses just x#

[BlitzWolf007]

Well, a cosmos application uses x#, but no other non-cosmos app. Would it really be that hard to scrap il2cpu all together? (im just asking not trying to minimize the efforts of the past devs to create Cosmos, XSharp, IL2CPU etc)