This project is read-only.

You need to export Cosmos to VS 2012 FAST!

Topics: Compiler, Developing Cosmos (Working on Cosmos source code directly)
Sep 1, 2013 at 1:14 PM
Edited Sep 1, 2013 at 1:15 PM
Visual Studio Shell 2010 has been already removed by Microsoft,
In fact No third party sites have VS2010 Shell Integrated,
<< Thank God! I had a copy of VS Integrated Shell >>
What I think :
We should export COSMOS to VS 2012 and then work on Mono Support
Since Mono is cross-platform and is not frequently updated like Visual-Studio
it would be great for Linux Users to Develop OSes in their Favorite Language "C#"
Sep 2, 2013 at 6:08 PM

I'm back from vacation and will be hard at work exporting to 2012, don't worry!

Sep 5, 2013 at 4:21 PM
I just don't understand why Cosmos won't work on 2012 if it works on 2010, The templates I made in VS2010 were compatible with 2012. Did you guys use some complex code that is only compatible with VS2010. I am always a supporter of Mono rather than VS. Although Visual Studio beats Mono in IDE Features and GUI, Mono still has a cross-compiling features which is much more important than GUI and IDE. I think it maybe tough to port Cosmos to Mono but it would be better for cosmos in the future since Linux users would also develop it.
Sep 5, 2013 at 7:36 PM
ALLDESP wrote:
I just don't understand why Cosmos won't work on 2012 if it works on 2010, The templates I made in VS2010 were compatible with 2012. Did you guys use some complex code that is only compatible with VS2010. I am always a supporter of Mono rather than VS. Although Visual Studio beats Mono in IDE Features and GUI, Mono still has a cross-compiling features which is much more important than GUI and IDE. I think it maybe tough to port Cosmos to Mono but it would be better for cosmos in the future since Linux users would also develop it.
What I do not get is the fact that this is even designed for an IDE. Imo, this should be released as some sort of utility that can be invoked from the command line. IDE Plugins should come last, as they are not important...
Sep 5, 2013 at 7:42 PM
yeah, because things like the debugger arent important... it seems to me that you've missed one of the main goals of Cosmos.
Sep 5, 2013 at 7:43 PM
And 2013 RC is almost out.. so hope we get 2012 soon :)
Sep 5, 2013 at 8:15 PM
Edited Sep 5, 2013 at 8:18 PM
ALLDESP wrote:
Did you guys use some complex code that is only compatible with VS2010.
Yes, that is exactly right. It's powerful and lets cosmos be very straightforward for new (or basic) users, but VS integration costs, in that you have to build specifically for a VS version, and you also are likely to have to upgrade or update the code as the VS interfaces and services change from version to version.
I am always a supporter of Mono rather than VS. <snipped>
Snipped all the rest, it really doesn't matter. You like blue, I like red. So what? The project already has a strong investment in various technologies (VS integration), the project already has planned development paths, milestones, goals and design choices made. There's nothing stopping you developing a cosmos integration layer for Monodev or whatever other IDE you think it might be nice to use ... apart from you not actually knowing how to do that, what it involves, or what actually was involved with what has already been done.

Recently on the boards/threads, I have been seeing various themes of posts, and I think they all seem to stem from people misunderstanding the project and it's goals. It might be useful to be more clear about Cosmos being a package which includes Tight IDE integration for fast development, A "cross compiler", and a bootable dot net VM / runtime environment, combined and presented as one thing.

I almost think that it might be more useful to present Cosmos as "take a dot net application make it bootable", instead of "write an OS". All this "develop file systems" and "write own windowing system" and so on come about because people see "write OS" and think of remaking dos or windows, but really the sweet spot is "take your dotnet console server application and make it boot in a VM".

They shouldn't be coding a file system directly into the application, they should be calling dotnet runtime file access methods like normal, and the runtime should handle that. This is not a complaint or criticism of the project, I know this is the intention, it just seems like others don't know that the project isn't quite there yet, and this rabbit hole of wrong direction development has opened up.
Sep 6, 2013 at 3:50 PM
But cross-compiling the Cosmos SDK would be a great achievement, it maybe tough but at the end you will get the result.
And not to forget Microsoft is releasing one VS after another, So we need to work faster, I am studying the Cosmos Source. To what I think the first attempt should be be to cross-compile IL2CPU. Well we need to separate IL2CPU from Cosmos, And then generate a standalone for Linux/Other Linux distros,
So does IL2CPU rely on Cosmos SDK or it is independent i.e. just embedded with Cosmos?
Sep 6, 2013 at 3:52 PM
The VS integration needs IL2CPU.

Keep in mind though, that most likely, running IL2CPU on mono would work, but requires massive plugging..
You say we should split IL2CPU from Cosmos. We want to, but splitting means more work to keep them in sync, and we are really tight on developers already..



2013/9/6 ALLDESP <[email removed]>

From: ALLDESP

But cross-compiling the Cosmos SDK would be a great achievement, it maybe tough but at the end you will get the result.
And not to forget Microsoft is releasing one VS after another, So we need to work faster, I am studying the Cosmos Source. To what I think the first attempt should be be to cross-compile IL2CPU. Well we need to separate IL2CPU from Cosmos, And then generate a standalone for Linux/Other Linux distros,
So does IL2CPU rely on Cosmos SDK or it is independent i.e. just embedded with Cosmos?

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


Sep 7, 2013 at 2:06 AM
They shouldn't be coding a file system directly into the application, they should be calling dotnet runtime file access methods like normal, and the runtime should handle that. This is not a complaint or criticism of the project, I know this is the intention, it just seems like others don't know that the project isn't quite there yet, and this rabbit hole of wrong direction development has opened up.
Heres were I ask the important question, why the hell not??
Sep 7, 2013 at 5:00 AM
Wait! How would it be if we could :
1) Make a Mono C# Project.
2) Separate the Cosmos.IL2CPU class from the source.
3) Make another Mono C# Project
4) Add the Cosmos.IL2CPU, Generate a Library,
5) Reference it to our project, and then call IL2CPU normally
6) Make a Mono Cross Template
Note that features like PXE,LAN and other IDE features, may not be available. But its good for a headstart.
Also I was thinking to add a ASM.Emit function (taken from Viper) in which we could write pure x86 ASM code i.e. IL2CPU won't parse that. It would write it as is.
I was wondering whether I could see the x86 ASM code generated by IL2CPU.
Sep 7, 2013 at 5:06 AM

There isn't really such a thing as a "mono" project. You can use MSBuild with Mono as well.

Sep 7, 2013 at 6:28 AM

Major point of cosmos is to not allow assembler code in user code. Not even in drivers. Everything should be in msil-based languages...

Op 7 sep. 2013 06:00 schreef "ALLDESP" <[email removed]> het volgende:

From: ALLDESP

Wait! How would it be if we could :
1) Make a Mono C# Project.
2) Separate the Cosmos.IL2CPU class from the source.
3) Make another Mono C# Project
4) Add the Cosmos.IL2CPU, Generate a Library,
5) Reference it to our project, and then call IL2CPU normally
6) Make a Mono Cross Template
Note that features like PXE,LAN and other IDE features, may not be available. But its good for a headstart.
Also I was thinking to add a ASM.Emit function (taken from Viper) in which we could write pure x86 ASM code i.e. IL2CPU won't parse that. It would write it as is.
I was wondering whether I could see the x86 ASM code generated by IL2CPU.

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

Sep 7, 2013 at 7:45 AM
Edited Sep 7, 2013 at 7:58 AM
GruntXProductions wrote:
Heres were I ask the important question, why the hell not??
I had to finish the post quick and go out, so it became sort of a clipped ending. I'm sure it was long enough already, but now this one will be long too.

The fact that you are asking, and with "the hell", suggests a misunderstanding of how these things really are designed and work. The important question to me is, why don't you know already why not to write all your code in a great big monolithic console application using non standard classes when standard ones exist.

I am not saying you cannot do it, but you should not be doing it. You can cook microwave dinners in the oven but you do better putting them in the microwave the way they are intended to be cooked. If you want to use an oven, you do better getting oven-cook food. The right tools for the job. The right layer for the type of code.

When you write application code, you call library functions for your target platform. You don't write a List class, you use the built in ones. Your application is providing value, and creating your own List class instead of using the built in one has no value, and risks defects (bugs).
Just as with the list class, you don't write a file or directory class, you call the library ones. The equiv of file.open and so on. You let the your code pass of the technical details of how to do that down the chain, thru libraries to the language's runtime, and let them pass the details of how that actually happens down the chain to the underlying OS services.
In dos that might have been all the way down to the loaded file systems on MS interrupt handlers, and it might have passed the request finally to a DOS then BIOS call, to the actual hardware disk, or it might have even passed it to a Netware or MS workgroup TSR network file system handler for further processing.

The same basic idea applies here, you are writing an "application", a console application. The idea is you write it using the standard dot net base class libraries, and then further the other libraries of the framework, such as the bits providing Linq, networking, console, asp.net / MVC, Windows Forms,and so on.

Those bits of library call down to the cosmos runtime / VM .. that is a replacement for the MS Dot Net Runtime or the Mono runtime. The vm provides things like memory management / GC, dynamic loading of modules, compiling / jitting, threading support, process and app domain management (loading, start/stop, security) and so on. Since that would be written as part of the project, interested parties could experiment with replacing those elements to try out new stuff, such as your own garbage collector. Or totally different security models and IPC, such as in Singularity. Process and app domain management would be the place to handle running other code, although since the environment is a managed one, loading and running elf or dos MZ stuff would not really be how to go ahead, rather, loading other dotnet assemblies and having their code execute would be the goal.

The runtime has to take your calls to "open file", and actually make that happen, and that is by calling down again, to the OS layer. On DotNet that is done calling windows OS services. On mono running on linux, they call out to the linux OS services etc. The underlying OS worries about hardware drivers, file systems, video drivers, and provides access in it's own standard way, which the runtime is written to use.

Cosmos implement the OS layer by using a combination of plugs and then more (c# and x#) code to write the OS layer, and have the cosmos runtime/vm call that code (instead of say issuing a MS File system interrupt).

You should want to implement your (or any other file system) at THAT level, just like any other operating system does. You could probably write the actual code, already.

Then when you compile, the app code you wrote, and the runtime code libraries, and the OS code with your drivers are all compiled to IL assemblies , then fed thru the cross compiler giving you your assembler output.

I think tho that cosmos still suffers from the lack of interface support, and then a side issue is plugs have not been implemented for some things. Generally they are not hard to fix but not a priority currently (unless they use interfaces). But someone sitting down wanting to just write a quick "guess" app and boot it up will not understand the "plug" level. It's intended that they don't have to, cos it'll be done and just work, at some point. If interfaces support is implemented, lots and lots of already existing dot net library code all starts to work fine and dandy, and the missing "core" plugs that are not plugged at the moment would quickly be plugged properly. Quite often they rely on code using interfaces so there's no point, better off waiting.

So IF all the libraries were implemented and plugged (I doubt anyone will ever do winforms, although the mono one might be a start point), you could sit down, start a new (non cosmos) project .. it could be a console guess app, an asp.net web server app, or whatever else. You would write it and have it build and run, as normal, in VS, under windows or whatever. It would work. You would then pretty much be able to build it using cosmos instead of dotnet or mono, and instead of running as a console window or asp.net app in windows, it would build, then boot itself up and be running in a VM, without any other OS .. and more importantly without any change to the code you wrote and built against the standard libraries.

The actual "application" project bit of cosmos isn't the interesting bit, that should be a normal dotnet app of some kind ... using whatever libraries from core, and other sources, that you feel like. Maybe there's a good ncurses library for c# console mode windowing. Write the app using it, make it run as normal, then retarget the exact code against cosmos not dotnet 4.5 or mono or whatever.
The interesting bit is being able to alter the runtime. The interesting bit is being able to code the OS layer (drivers and services) in managed C# with all the benefits that gives you. The interesting bit is taking your dotnet application (be it console, server, whatever) and having it run in a VM and not having to pay a license for an underlying OS you aren't using, and having that OS consume only the (vm hardware) resources your application actually needs to function.

Instead though what people are doing is writing a little console guess app to start, then coding into that app some way to access hardware directly, and then directly a file system or whatever, and then directly video access, then building some classes to call those things, and then running the whole thing in a main application thread loop ... It's like taking a dot net console project and trying to code the whole of a dos emulator into that one project ("program"). It's just not how things are done. Can you do it? Maybe. Is it painful and uphill and throwing away the design and lessons of all the years of development so far, and all of the benefits of being in dot net managed platform in the first place? Yep. Is it often a waste of time, in that fixing or completing the underlying layers to work as planned and intended will still need to be done, and will not likely benefit at all from these offshoots? Yep.

Memory management / garbage collection is implemented in a "never release" way, because that's all that is needed at the moment, with the level of work still to do. The right thing to do is wait until the underlying stuff needed for these is there (interfaces again? debugging support?), and implement one or more MMs / GCs, and so the runtime will work "as normal" with all existing code. The very worst path I can imagine is to try and write c-like memory management routines, and then change all sorts of dot net code to start calling get and free and what not .. it would be like the old days, only with a runtime library that you'd have to rewrite to use it all! Or you would be writing into your own app a new runtime library / class structure that obeyed those free/get calls, and well, you might just as well go use Turbo Pascal OWL or Delphi VCL or C and Curses if that is what you want.

Also doing these things are likely to be a burden to the developers who ARE working on the intended path ... eg when random people keep coming along to ask about these offshoot wrong directions? Even more annoying to the developers might be that people going down this path keep coming back and saying "change your project to make what I feel like doing, to help me go down this other path" when that other path is the wrong way. Asking (and sharing/popularizing code that causes other people to ask) the devs to help, advise, support and even to take on extra unneeded work, all based on going off on some other path, on a project that has very low contributing devs in any case....

TL;DR ? ... cos it's not how to do it properly, it's how to badly hack around things that are not yet complete, it encourages others who don't yet know, to head down the wrong path too, and it causes drain on the dev time that is available.
Sep 7, 2013 at 7:49 AM
Edited Sep 7, 2013 at 7:49 AM
ALLDESP wrote:
Wait! How would it be if we could :
You could, no one wants to. It's not the direction intended, it's not something people would want to have to support or even really be involved in, at this time, or in that manner.
Sep 7, 2013 at 10:11 AM
Flatlined785 wrote:
The interesting bit is being able to alter the runtime. The interesting bit is being able to code the OS layer (drivers and services) in managed C# with all the benefits that gives you. The interesting bit is taking your dotnet application (be it console, server, whatever) and having it run in a VM and not having to pay a license for an underlying OS you aren't using, and having that OS consume only the (vm hardware) resources your application actually needs to function.<
That's something which is completely unnoticed in Cosmos, As most people say Drivers can only be written in C/C++ and no other language, But I see, how did we managed to implement VGAScreen, Keyboard, Video Drivers, FS Sound Drivers all in managed C#.
  • I agree to the point that Flatlined785 wrote :
    Cosmos is something that takes a C# Console Application and Makes it Bootable,
    But.................................................
    Doing that is itself a great job!
  • For the future of Cosmos I think of using CLR/CLI for calling up certain Dlls, right now IL2CPU only generates x86 code from MSIL, I know at this stage we should not think of Low-Level stuff, but it could attract the majority of the advanced developer community....
  • I was thinking that why did you guys use FAT12, in fact FAT12 is much more tougher to use than FAT16 or FAT32 cause you have that extra nibble to deal with.
Sep 7, 2013 at 2:37 PM
There are lots of things we can do. We used to support Mono, and some day we will again. But right now its 2-3 of us doing all the work and dozens of others telling us what we should do, when we barely have resources to do what we are doing now.

So until others start coding, please stop telling us what we should do when we can barely do what we do now. Its like telling a man in a wheelchair - "hey you should walk!"
Sep 7, 2013 at 2:51 PM
I am working on the Source!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Sep 9, 2013 at 7:23 AM
Then maybe you can help out on getting userkit working on vs2012?



2013/9/7 ALLDESP <[email removed]>

From: ALLDESP

I am working on the Source!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

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


Sep 9, 2013 at 12:45 PM
I could and I will but the thing is I have VS2010/2012 Express. I wouldn't be able to test the code. But yeah I would post the code or maybe give it to any of the developers to test it......
Sep 9, 2013 at 12:50 PM
No point in modifying code without testing..



2013/9/9 ALLDESP <[email removed]>

From: ALLDESP

I could and I will but the thing is I have VS2010/2012 Express. I wouldn't be able to test the code. But yeah I would post the code or maybe give it to any of the developers to test it......

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


Nov 6, 2013 at 9:09 PM
In case it is of interest to anyone on this thread, see latest check-in. VS2013 is now (at least in-part) supported. (Only tested against Ultimate; Express editions are almost certainly not supported).

Regards,
Ed