This project is read-only.

What are the new features in release 103291?

Topics: Compiler
Aug 12, 2013 at 11:41 AM
Just got started with the 103291 release 'cause I saw it come in the recommended list,
Simple as that as the title says "What are the new features in Cosmos 103291?"
Any advantage of using this over the 92560 release or it's basically the same?
Any answers would be appreciated..

~ALLDESP
Aug 12, 2013 at 11:43 AM
improved debugger, using sqlite now. i think work on fat implementation..


Aug 12, 2013 at 12:40 PM
So what's SQLITE? Is it related to SQL? How does it help in developing COSMOS? And after implementing a FAT file system
Could we make executables for our OS also
Would it be possible to port GCC (GNU Compiler Collection) or maybe NASM (NETWIDE assembler) or maybe FASM(FLAT assembler)
Or maybe a simple C compiler like BCC/GCC etc. Cause if we are able to port all this to COSMOS it would be the largest milestone till now.
Aug 12, 2013 at 12:45 PM
sqlite is used for storing debug info. compiler emits that debug information, and the debugger then uses it.
executables will take a while till we get there. first up are rings, memory management and tcp/ip (probably)

Also, running any native tool (gcc, nasm, fasm, bcc/whatever) wont be possible, as cosmos will be a managed environment at all times....



Aug 13, 2013 at 7:19 AM
Why would anyone want to restrict users like that??? Thankfully though at Cosmoses current state, nothing is managed and you are still free to do what ever you want, including writing an ELF loader (I wrote a simple one, and NoobOS has support for loading flat binaries).
Aug 13, 2013 at 7:30 AM
if you want unmanaged code, we cannot do intelligent things like run everthing in same security level and address space and doing protections using the compiler. this gives us potentially huge performance savings.

There are some pretty good unmanaged OS-es around, think of linux, windows, minix, etc..



Aug 13, 2013 at 7:33 AM
if you want unmanaged code, we cannot do intelligent things like run everthing in same security level and address space and doing protections using the compiler. this gives us potentially huge performance savings.

There are some pretty good unmanaged OS-es around, think of linux, windows, minix, etc..



Aug 13, 2013 at 1:10 PM
Edited Aug 13, 2013 at 1:13 PM
That's great GruntXProductions, so you can port all this to A Cosmos OS?
Anyone knows how to Run COSMOS in unmanaged mode, also does COSMOS runs in Real or Protected mode?
I would be eager to know about ELF loaders, Although I have seen the NoobOS project, I could not find the ELF Loader sources,
Anybody knows where it is?
I recently saw a project called MIKEOS which is written in NASM assembler, I recommend you guys
To take a look at it, Since MIKEOS has FAT12 implemented and can execute .bin programs,
it's 16-bit and the 32 bit one requires aeBIOS(extended version of BIOS) so I am scared whether the FAT12 implementation could work........
By the way what is Cosmos (32/64/16 bit) by Default.....
And Just a little question
Where can I get a executable version of IL2CPU? Is it possible to write a code in notepad save it as .cs file and call the IL2CPU compiler by dragging
the code file into the IL2CPU executable like other compilers do? Sorry if it is too silly.......
Thanks for the recommendations mterwood I will see MINIX(never heard about that)
Aug 15, 2013 at 11:03 PM
Well yes. Its a bit tricky though, because Cosmos is an MSIL compiler, not a C# compiler. Your C# code must compile into CLI complaint IL code, which means you can not add any sort of inline assembly or anything like that which would be very useful. As I said in my previous post though, nothing about Cosmos is managed, even though mterwoord seems to want to make it appear to be managed by implementing processor restrictions (Which I do not think helps accomplish anything 'intelligent' and also does nothing towards performance. The only way to make Cosmos truly 'managed' would be to write a separate kernel, that either interprets or executes user code in a managed virtual environment (IE a .net machine that runs in kernel mode)). Cosmos runs in real mode and is 32 bit, NoobOS did not implement a ELF loader, I did. Unfortunately I have not worked with Cosmos in a while, and the source code I have released, does not contain my elf loader, and I was focusing on implementing POSIX syscalls, and making them identical to linux system calls. I believe though I have some code from the crappy ELF loader I wrote, however I ran into several problems properly relocating ELF files, and my attempts to implement paging (All of failed). I do not think IL2CPU works like that (although I may be wrong). I think that the Cosmos devs have everything interlinked, and run ontop of a VS plugin. It would be better though if IL2CPU worked like that, in my opinion that should have been done first, and the VS extension should be last on the developers list...



Whats left of my ELF loader (I do not think it works in my recent build, the whole inner working of the kernel I was attempting to developing has changed, streams, file access, ect)

https://infinitykernel.codeplex.com/SourceControl/latest#InfinityKernel/InfinityKernel/Kernel/Core/ELF32.cs

ELF loader in action: http://www.youtube.com/watch?v=7wIYCx0M2ns

I also wrote a simple PE loader for my generic DOS clone OS that I wrote using Cosmos, that works too.

https://gdos.codeplex.com/SourceControl/latest#GDOS/EXE/PE-EXE.cs
http://www.youtube.com/watch?v=Tyur9klsPEw

And remember, just because that can load PE files, does not mean it can run windows programs. Obviously the NT kernel, and APIs would be needed to run a windows program.

Also sorry for all the weird uneeded indents that exist in some files on there, I wrote alot of that code in linux, and windows so the line ending are different in some files (Which apparently Codeplex does not like, as everything looks fine in Monodevelop, or Visual Studio)
Aug 16, 2013 at 7:02 AM
Grunt: having a managed environment can definitely be applied by using an AOT compiler like cosmos does. Mono has options to run .NET code compiled to native images. This also is still a .NET-compliant environment then. It's the environment, not just the final runtime environment that counts here.

Having a managed environment (AOT-ed, JIT-ed, or Interpreted doesn't matter) allows us to do things differently. In traditional operating systems, one needs to do systemcalls from usermode to kernelmode. each context switch (1 call means at least 2 switches) can 1 msec on a 2Ghz Pentium 4 machine. In cosmos (not where we are now, but future) we can do this with simple method calls (under the hood). this is a HUGE performance gain. There are plenty by using a managed operating system. Doing this using an interpreter or jit means we cannot take all the time we need for compilation, and will slow us down tremendously..



2013/8/16 GruntXProductions <[email removed]>

From: GruntXProductions

Well yes. Its a bit tricky though, because Cosmos is an MSIL compiler, not a C# compiler. Your C# code must compile into CLI complaint IL code, which means you can not add any sort of inline assembly or anything like that which would be very useful. As I said in my previous post though, nothing about Cosmos is managed, even though mterwoord seems to want to make it appear to be managed by implementing processor restrictions (Which I do not think helps accomplish anything 'intelligent' and also does nothing towards performance. The only way to make Cosmos truly 'managed' would be to write a separate kernel, that either interprets or executes user code in a managed virtual environment (IE a .net machine that runs in kernel mode)). Cosmos runs in real mode and is 32 bit, NoobOS did not implement a ELF loader, I did. Unfortunately I have not worked with Cosmos in a while, and the source code I have released, does not contain my elf loader, and I was focusing on implementing POSIX syscalls, and making them identical to linux system calls. I believe though I have some code from the crappy ELF loader I wrote, however I ran into several problems properly relocating ELF files, and my attempts to implement paging (All of failed). I do not think IL2CPU works like that (although I may be wrong). I think that the Cosmos devs have everything interlinked, and run ontop of a VS plugin. It would be better though if IL2CPU worked like that, in my opinion that should have been done first, and the VS extension should be last on the developers list...



Whats left of my ELF loader (I do not think it works in my recent build, the whole inner working of the kernel I was attempting to developing has changed, streams, file access, ect)

https://infinitykernel.codeplex.com/SourceControl/latest#InfinityKernel/InfinityKernel/Kernel/Core/ELF32.cs

ELF loader in action: http://www.youtube.com/watch?v=7wIYCx0M2ns

I also wrote a simple PE loader for my generic DOS clone OS that I wrote using Cosmos, that works too.

https://gdos.codeplex.com/SourceControl/latest#GDOS/EXE/PE-EXE.cs
http://www.youtube.com/watch?v=Tyur9klsPEw

And remember, just because that can load PE files, does not mean it can run windows programs. Obviously the NT kernel, and APIs would be needed to run a windows program.

Also sorry for all the weird uneeded indents that exist in some files on there, I wrote alot of that code in linux, and windows so the line ending are different in some files (Which apparently Codeplex does not like, as everything looks fine in Monodevelop, or Visual Studio)

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Aug 16, 2013 at 8:39 AM
"Having a managed environment (AOT-ed, JIT-ed, or Interpreted doesn't matter) allows us to do things differently. In traditional operating systems, one needs to do systemcalls from usermode to kernelmode. each context switch (1 call means at least 2 switches) can 1 msec on a 2Ghz Pentium 4 machine. In cosmos (not where we are now, but future) we can do this with simple method calls (under the hood). this is a HUGE performance gain." And how on earth do you plan to have these 'under the hood' methods? You do realize that alot of stuff (Drivers, writing to video memory, ect) have to be done in kernel mode, right? Unless you plan on making everything run in kernel mode (Which to me, is unsecure, even in a perfect .NET environment. Im sure it could be easily exploited) your 'under the hood' methods are still going to have to rely on something running in Kernel mode to some perform tasks. And if the operating system is already in kernel mode then, why not just let the programmer do what ever they want..... I am not sure what your plans are for Cosmos, but I can assure you, that the people using Cosmos are just using it as a native compiler to develop their own kernel (Unix clone, DOS clone, or something else) in their favorite language, and would rather have freedom to develop what ever type of kernel they want, instead of being restricted to one design. That is why I think that you guys should keep IL2CPU, and what ever sort of 'managed' kernel you plan on developing separate, so people can use IL2CPU for their own projects......
Aug 16, 2013 at 10:40 AM
Thanks guys for those long posts, Now I have a bit of idea about what Cosmos Actually is.
Now I am going to Take a Look at the Loooooooooonnnnnnnng.... Source of COSMOS, Anybody knows MOSA(Manged OS Alliance) Project,
It's like Cosmos (uses C#)
Does Cosmos has a inbuilt sound driver cause a saw this guy playing a note like:
A#
B#
X#
(Using all those note/tones or whatever)
http://www.youtube.com/watch?v=sDtyvT8p3Og&feature=c4-overview-vl&list=PLA3A26E5193527C24
Aug 16, 2013 at 11:49 AM
Grunt, everything currently runs in ring0 mode, and everything will keep running in ring0. it has the risk of being unsecure due to bugs, but nothing new here: you expect hardware to have no bugs, but they have bugs as well.. You basically trust the system.

at some point, you will be able to use il2cpu standalone, but all current devs are interested in cosmos, so nobody invests time on making support for separation.

Why not allowing full access to hardware to process developers? security: only our kernel and compiler define what happens, not the end user dev. (drivers don't directly do OUTB/INB statements, but retrieve some object, which is compiled to performant code...



2013/8/16 ALLDESP <[email removed]>

From: ALLDESP

Thanks guys for those long posts, Now I have a bit of idea about what Cosmos Actually is.
Now I am going to Take a Look at the Loooooooooonnnnnnnng.... Source of COSMOS, Anybody knows MOSA(Manged OS Alliance) Project,
It's like Cosmos (uses C#)
Does Cosmos has a inbuilt sound driver cause a saw this guy playing a note like:
A#
B#
X#
(Using all those note/tones or whatever)
http://www.youtube.com/watch?v=sDtyvT8p3Og&feature=c4-overview-vl&list=PLA3A26E5193527C24

Read the full discussion online.

To add a post to this discussion, reply to this email ([email removed])

To start a new discussion for this project, email [email removed]

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Aug 22, 2013 at 10:58 AM
So it means IL2CPU standalone is possible?
I am at least interested in IL2CPU which does the awesome part of the work
So any ideas on how to compile the standalone I guess it will use the
COSMOS.IL2CPU class.
Wait! Can I create a Console Application, Reference IL2CPU Class and then make
a command line argument for File Input and then compile it using the Compile Command
in the library? Would that be possible?
Aug 23, 2013 at 9:47 AM
And Grunt I'm greatly surprised by your GLNFS File Explorer you built, <the one that reads .vmdk files> showed in the video, Did you use the VM Ware API for that or made it from scratch?