Hacker News Reader

Comment by CyberFonic | Hacker News Reader

To write an OS you need to generate native executable for the hardware that you are running on. The mainstream implementations of C# require CIL + CLR. i.e. you need a virtual machine + libraries and framework. Not exactly "bare metal" environment.

But C# is more advanced language than C, so that might be beneficial in some areas. As a minimum you would need a C# to native compiler and facilities to include assembly language code in some low level areas.

To get a better idea of what it takes to implement an OS, take a look at the Linux kernel source code. Or if that is too daunting, you could look at Minix 3 sources.

View on HN

C# generates native code just like many other languages. In fact with a few minor tweaks MS has written an OS in C# called Singularity.

I looked it up on Wikipedia. You may have overlooked the fact that MS abandoned this project and that it used assembler, C and C++ to build the foundations. So the exercise has shown that it is possible, albeit with a considerable amount of non-C# code. But I think they also learnt that it isn't a particularly effective. There isn't enough information on Midori, the "commercial" successor to Singularity to make any assessment.

C# by default doesn't generate native code. C# generate CIL (Common Intermediate Language), which only gets turned into native code at runtime by the JIT (Just in time compiler).

That being said, it is also possible to generate a native image (using ngen) to transform CIL into native code for a specific machine. But that approach is the exception more than it is the norm.

The process you outlined language -> bytecode -> native code is exactly how FreeBSD works when compiled by clang.

That approach is also the norm on iOS for both Obj-C and C#.

I am pretty sure ngen doesn't create native code in the sense that it doesn't create a windows executable. All it does is the same as the JIT but does it up front (for the target platform). In other words it still generates something the runs inside the CLR.

You're right, it's basically skipping the JIT step for better performance for managed apps at the cost of higher initial load time (e.g. more to read from disk).

It does generate native code. What else do you think is what runs at runtime? .NET never has been interpreted (apart from Micro) so you either have the JIT or ngen and both result in the bytecode translated to native code prior to running. That it still calls into the CLR for things like object allocation, garbage collection, etc. doesn't change anything. You can do the same from C++ if you want.

There is a reason they call it managed code. It isn't native windows code.

Reply on news.ycombinator.com