Visual c# Development

[gedd]

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

I disagree:

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

Argument was, not you.

JIT , Just in time , convert function at first call, so how to call function without decoding.

Let's talk about it around a cup of java (coffee)

[ru2aqare]

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

From a pure "learn the language" viewpoint, I would vote for C#. However, in the context of osdev, C++ wins hands down. The reason is that you can start coding your OS in C++ with almost no extra libraries, tools etc. To start coding your OS in C#, you have to have additional tools, implement (or use an existing implementation of) the CLR, etc. There are many more C++ tutorials floating around.

[kop99]

I think it's better to use C or C++ for OS Dev.
C# is nice language for application but not for OS dev.

[Steve the Pirate]

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

There's nothing 'visual' about OS development - well, you can do it in Visual Studio, but you're not going to be going anywhere near the click and drag tools - only code.

C++ would be far easier than C# for OS dev, but still requires runtime stuff to get most functions (like global objects, new and delete, etc.). And then you don't have any libraries like STL or anything - so you have to write them from scratch if you want them...

[NickG]

Yea
Like, if you where to Develop an OS in c/c++
That would be much easier, but...
c# Would be the application builder for the OS
Like a simple little paint program
and make the OS Run A fat32 File system, that would be good
For c# Applications
Or an address book
that would be good.

[rootnode]

Well, developing an OS in 100% pure C# is still possible.
Our approach is to write the Kernel in C#, compile it to native code, and then JIT other processes.
So the only things not running in managed code are the kernel and the compiler/VM.

Getting the kernel to boot and finishing the compiler is the part that takes most of our time, but once finished it'll be easier to develop drivers, apps and other stuff.

[Colonel Kernel]

Argument was, not you.

JIT , Just in time , convert function at first call, so how to call function without decoding.

I think you misunderstood what I meant by this:

Even the CLR never interprets IL

By "interpret" I didn't mean just "decode", I meant "decode and execute each IL instruction in software" as opposed to compilation, which is "decode each IL instruction and re-encode it as a native machine instruction for execution later". Does it make sense now?

[gedd]

Boring of this discussion, it's like talking to a wall.
I'm right not you... no me ... no me

CLR is like a Virtual Machine, JIT is a part of it (for performance reason).
If you have no JIT what the CLR doing ?
And before calling JIT what's the CLR doing ?
And when you load assembly what's CLR do ?
Have you some idea of what is a metadata token ?
And it's utility ?

Try MS documentation, MSMVP books
Better, try to read (by code) an assembly and display IL code, like disassembler.
Before reach this goal you'll understand

[Colonel Kernel]

Boring of this discussion, it's like talking to a wall.

I failed the Turing test.

I'm right not you... no me ... no me

We're both right (mostly), we're just talking about different things.

CLR is like a Virtual Machine, JIT is a part of it (for performance reason).

Correct.

If you have no JIT what the CLR doing ?

It might be running in a binary pre-compiled with ngen.

And before calling JIT what's the CLR doing ?

I can tell you one thing it's not doing: interpreting the IL.

To summarize my points:

1. The CLR uses JIT compilation.
2. Unlike certain JVMs, the CLR does not include an interpreter.
3. Running JIT-compiled IL is a lot faster than interpreting IL. I think you agree with me on this but seem to be stuck on what "interpreting" means.
4. JIT-compiled code will not necessarily run faster than pre-compiled code. This was my original point. There are interesting research results about this here. To summarize: Whole-program optimization is not feasible for JIT because JIT has to run quickly.
5. You don't need the CLR to run C# code. Check out Cosmos and the Singularity project at MSR for examples.

[gedd]

Ok you are a god and you are able to develop an OS with visual C#, give me a copy when it's done.
If i have a problem to developp my HTML os , can i ask you for help ?

PS : when ngen convert an assembly, it must convert all assembly dependency .... and when it's done don't use CLR --> off topic

[Colonel Kernel]

Ok you are a god and you are able to develop an OS with visual C#, give me a copy when it's done.

If I was a god I'd have infinite time... That would be nice!

OSDev in C# has been done by others anyway (Singularity, Cosmos), so we all know it is possible... Maybe not with Visual C#, although it has a nice editor.

Check out ru2aqare's post: He has implemented a C# compiler that produces code with no dependency on the CLR.

I'm not saying it's easy... it's not. I'm also not making a particular claim about whether or not I can do it... I'm too busy working as a .NET developer full-time to try it myself anyway. I'm just trying to answer the OP's question, and clear up all the confusion around interpretation versus JIT versus native code.

PS : when ngen convert an assembly, it must convert all assembly dependency .... and when it's done don't use CLR --> off topic

Converting an assembly to native code using ngen does not remove its dependency on the CLR. The code in the native binary produced by ngen still relies on the garbage collector, for example. The CLR is implemented as a bunch of unmanaged COM DLLs that every assembly depends on, whether ngen'd or not. But yes, this is getting off-topic since it is not about C# per se.

[Steve the Pirate]

If i have a problem to developp my HTML os , can i ask you for help ?

That's actually a pretty cool idea - somebody should write a compiler that converts a special type of HTML (well, XML really, but it might be fun to try and make something that validates as HTML) into C - like

Code: Select all

<int name="version" value="2"/>
<printf args="version">Welcome to HTML-OS Version %i</printf>

becomes

Code: Select all

int version = 2;
printf("Welcome to HTML-OS Version %i", version);

and so on, just to shut up those pundits who say that it can't be done

Well, it's really a pretty terrible idea, but still...

[-m32]

If i have a problem to developp my HTML os , can i ask you for help ?

It was tough, but here's a screenshot of version 1 of HTMLOS!

[gedd]

Does it support Silverlight 3 ?

[redoktober]

my god!
could you please, please tell me how you went about making this?