Visual c# Development

[NickG]

Ok, So i am wondering if you can develop an OS In the language visual c#(Microsoft programming) And make it bootable

I would like to know so i can dev. A C# OS

PS: Did i put this post in the wrong topic?

[neon]

Hello,

Any language can be used so long as it can produce binaries that your system can support and can produce system level code. So yes, it is possible (and has been done before. i.e., Singularity). Although in the case of a language like C#, it is alot more harder to get it working and may be impossible by itself (it would probably need a layer of C or C++ along with assembly language of course.)

[NickG]

Yea, I think there is a C# Virtual kernel called comet i think that is what it is called, unless it is Cosmos

PS:It is cosmos i looked it up, but i am too lazy to change it

[imate900]

You'd need to implement a full CLR for C# using C/C++/Assembly before jumping to C# code.

[Colonel Kernel]

You'd need to implement a full CLR for C# using C/C++/Assembly before jumping to C# code.

Not true. The CLR includes a lot of stuff like JIT that is not strictly necessary for running C# code. All you need is a run-time library, a garbage collector, and a way to compile C# to native code. It's still a lot of work, but it's not nearly equivalent to implementing a "full CLR".

[gedd]

The CLR includes a lot of stuff like JIT that is not strictly necessary for running C# code

Right but recommended for performance reason.

Compiling C# code (and any language from .net platform, J#, iron python, VB.net, F#, etc) will give you Metadata and Bytecode (IL) wrapped in a PE/Coff executable file (dll or exe).
Things that must be done to "execute" it, is decode metadata and bytecode, loading CLS common lib (in mscorlib.dll or yours), and interpret it in a virtual machine.In fact it's more complicated but i "forgive" details intentionaly

The virtual machine must be in native code on your os. So you mus t develop an os in a language that produce native code before ....

Cosmos os is not really a .net os, the SDK on dev platform translate IL to native before produce executable so the os never execute IL code

C# and CLR specification are public, PE/Coff format too, so enjoy ...

[Colonel Kernel]

Right but recommended for performance reason.

Why? I don't think JIT is necessarily faster than native code. An ahead-of-time compiler is free to spend a lot more time optimizing the code than JIT.

Compiling C# code (and any language from .net platform, J#, iron python, VB.net, F#, etc) will give you Metadata and Bytecode (IL) wrapped in a PE/Coff executable file (dll or exe).

Only if that's what your compiler does. There is nothing about the C# language that prevents you from developing a compiler that compiles C# directly to native code.

Things that must be done to "execute" it, is decode metadata and bytecode, loading CLS common lib (in mscorlib.dll or yours), and interpret it in a virtual machine.

Metadata is not required at run-time unless you use reflection. Decoding the bytecode is not necessary if you compile directly to native code. mscorlib.dll is not necessary if you implement your own run-time library. Even the CLR never interprets IL -- it is always JIT compiled first.

C#-the-language and .NET-the-framework are not the same thing.

[gedd]

gedd wrote:
Right but recommended for performance reason.

Why? I don't think JIT is necessarily faster than native code. An ahead-of-time compiler is free to spend a lot more time optimizing the code than JIT.

JIT convert IL to native code.

Compiling C# code (and any language from .net platform, J#, iron python, VB.net, F#, etc) will give you Metadata and Bytecode (IL) wrapped in a PE/Coff executable file (dll or exe).

Only if that's what your compiler does. There is nothing about the C# language that prevents you from developing a compiler that compiles C# directly to native code.

Actualy C# is use in .net platform to compile byte code only.

Metadata is not required at run-time unless you use reflection

False false and false, try to read ISO doc about CLR before talking about

Decoding the bytecode is not necessary if you compile directly to native code.

see upper

mscorlib.dll is not necessary if you implement your own run-time library

mscorelib is the CTS needed by CLR, it's an assembly ( you know what it is)


if

Even the CLR never interprets IL -- it is always JIT compiled first.

Stupid ! CLR is used to execute assemblies so bytecode and JIT then

C#-the-language and .NET-the-framework are not the same thing.

Really ? great discovery but i am aware on it
.Net is my job, i'm a specialist

Now can develop your native code C# compiler it will usefull to develop your os when it will be finished

[ru2aqare]

Only if that's what your compiler does. There is nothing about the C# language that prevents you from developing a compiler that compiles C# directly to native code.

Actually I have created a proof-of-concept C# to C compiler. It accepts a subset of valid C# and generates C code, which is compiled using msvc or gcc. Sources not yet available, sorry; at some later point when it is no longer POC, but an usable implementation.

Metadata is not required at run-time unless you use reflection

False false and false, try to read ISO doc about CLR before talking about

My compiler propagates type information at compile time, so there is very little metadata stored. However, some is still required (for example, type casts). Reflection is not supported, and currently I don't plan on doing so.

Decoding the bytecode is not necessary if you compile directly to native code.

see upper

My compiler agrees with Colonel Kernels point. There is no bytecode (or IL) involved.

mscorlib.dll is not necessary if you implement your own run-time library

mscorelib is the CTS needed by CLR, it's an assembly ( you know what it is)

I don't need mscorlib, I have (a very limited, I admit) subset of the base class library along with an implementation of the VES.

if

Even the CLR never interprets IL -- it is always JIT compiled first.

Stupid ! CLR is used to execute assemblies so bytecode and JIT then

Sorry, I have to agree with Colonel Kernel here. The Microsoft implementation of the CLR doesn't interpret IL (as old Java versions used to interpret Java bytecode instead of using JIT techniques).

Now can develop your native code C# compiler it will usefull to develop your os when it will be finished

Actually, I'm doing just that. </sarcasm>

[NickG]

Woops, i shoulnt of put this topic up, It's gonna turn into something bad again

*Yells* Dont Fight please, its because of things like this that got *ALL* of my topics locked

[JackScott]

NickG, they are all using valid reasoning to point out flaws in each others arguments. Which is perfectly acceptable on a technical forum. In addition, so far they have not resorted to personal insults or anything of the kind.

Unlike some other arguments (Emacs vs. Vi, Linux vs. Windows, Tea vs. Coffee, Cats vs. Dogs), this argument is likely to result in a better understanding of the concepts for all the participants, and for the people reading the topic as well. I, for one, am finding it quite interesting.

Now that I've said this, watch the topic slide downhill and mock me...

[NickG]

Alright, which would be easier, c# or c++??
And no im not inviting a flamefest, im just asking some people Which would be an easier programming language for an OS
(I bet that people will say c++)

[VolTeK]

hmm didnt i post something here

no no no, no vs anything, all it does is put it into arguments like, "my programming language is harder than yours" kind of arguments, especially when you comment that C++ is easier, some people will diagree and the whole thing will start from there.

oh and jackscott, i think all of those vs ideas have been used already on here, i think they were all locked also

[neon]

Alright, which would be easier, c# or c++??

Although I do not know the language, I have heard alot of times that C# is easier to learn and work with. But for OS development, C++ of course as it was based on C which in turn was originally designed to be a systems language.

[Colonel Kernel]

In addition, so far they have not resorted to personal insults or anything of the kind.

I disagree:

Stupid ! CLR is used to execute assemblies so bytecode and JIT then

But I don't let it bother me.

Alright, which would be easier, c# or c++??

Using existing tools? I'd say C++, hands down. You'd have a lot less work to do since you wouldn't need a GC or run-time library. Just don't try writing your own C++ compiler unless you want to have nightmares for the rest of your life...

<offtopic>I'm 1337! It says so in my post count! </offtopic>