, SteveRichter wrote

*snip*

I should not say managed code since it does not imply what I am thinking. More just a higher order framework that includes garbage collection and goes a long way in enabling the programmer to get the end result to the user. Like in C# and .NET the programmer is multiple times more productive than with COM and C++.  The OS should have such a framework as its core.

To declare my hand a little bit, I used to run a research group that actually made an OS based entirely in C#. There are a whole myriad of problems that it entails.

Firstly - the real stalling point for OSes (and the reason why writing new ones is hard) is mainly because of the hardware being awkward and needing to constantly do things that C# simply isn't very good at doing (like interrupt routines). This means that you do get to write your OS in C# for the most part, but you end up needing to write large numbers of support routines in x86/x64 anyway, and suddenly you've got lots of extra things that can go wrong - like the calling convention between your ASM routines and your C# routines, or if you screw up the compilation or misalign the stack because your C# compiler isn't quite up to scratch.

Secondly, the OS has nothing beneath it. That means that on entry to your OS, you cannot do anything that might indirectly require a subsystem you haven't initialized yet (like the heap). In fact - the biggest problem time and time again is how to create a subsystem that is dependent on itself (the filesystem has an MFT that contains all of the files, that is itself a file. The virtual memory manager needs memory. The root object type is itself a object type. The heap needs to allocate memory to store heap data etc). Programming it in a managed language tends to make these problems harder, not easier.

The third big problem is that when a new OS goes wrong it is a FPITA to debug. You screw up the VM tables and the processor will just reset. You accidentally allocate two physical pages out to different people because of a race condition? The OS will crash and burn. You screw up your scheduler and you'll be unable to do anything at all.

And the final big problem is that the OS is utterly speed critical in a way that nothing else in the system really is. A 5% drop in speed in your heap allocator is a 5% drop in speed of your whole OS. Allocating an extra object during a timer tick adds up fast into an unusable system.

In my experience (as someone who's written several experimental OS kernels in C# and in C) it's that after a while you realize that you're not programming C# like how you'd program C# in normal programs, because you're constantly writing your C# how you'd write C. You have to return status codes everywhere instead of using exceptions (because exceptions require the heap to be initialized , you have to be cautious about where you allocate memory - so you tend to avoid the new keyword. You spend your whole time in and out of assembler listings to see if your C# program might be emitting instructions that it shouldn't be or if there are optimisations it should be taking that it isn't (like is your function straddling a page boundary?).

Even when you have a heap you end up having to explicitly new and delete everything because no garbage collector exists for free - and shuffling memory around that is referenced by machine registers is a quick way to crash the system.

And when you get further into the OS, you start realizing that the choice of C# is starting to impact on other areas of the system; for example, you can't page out parts of the kernel if it's written in C# in the same way that you can if it's written in C, because C# doesn't have sections (and enumerating attributes and putting them into manual sections is just more work that you don't need right now).

What I'm really trying to get to is that if you are facing the problem of how to write an Operating System and someone says "hey - let's build it in language X" (where X is not raw ANSI C or hand-written assembler) then congratulations, now you have two problems.

It's easier to write an OS in C that feels like C# than to write it in C# that feels like C. And it's impossible to write it in C# that looks like C#.