OSDev.org

@Hobbes: No way! That can't be true! So I guess that's why every other commercially or non commercially successful OS is written in either C or C++, right? Gee. That's quite a revelation.

Honestly, though: I do wonder why some people like to fight it so much and keep asking about developing in all kinds of weird languages which were simply not made for the task. Why would you try to develop an OS in a language like C#? It really escapes me. C was designed to be, as has been stated before, "A portable assembly language", and is the only language (apart from its derivative, C++) which has been shown (by several real, industry standard kernels) to produce a working kernel on any architecture, or in fact on multiple architectures from the same kernel tree.

I can understand when a highly skilled systems programmer decides to do something for the heck of it, knowing already what he's doing, but what really makes the whole thing more obscure is that only people who are new to kernel concepts ever even suggest using any other language. Why does that pattern follow?

Because they heard that programming an OS is hard, and they want to do it in the language they are most familiar with.

To be honest, if C/C++ weren't my strongest programming language skill, I think I would have considered asking that question myself, back when I started with this stuff.

--

The x86 processor family starts in a state where the only viable language is Assembler. You have to have some Assembler parts in your OS, because no other language will do.

From there, it's only a matter of how much an effort you want to put into it to support a specific language.

There are languages that need no supporting framework at all, C being most prominently among them.

Then there are languages that need very little supporting framework, or can be used in a scaled-down way so they don't need framework, or have such a framework readily available / portable. C++ falls in this category.

And then you are very quickly in an area where the language support framework would be a complete OS in its own right. Java, for example.

Why would you try to develop an OS in a language like C#?

For easier debugging, trusted code, and the MASSIVE efficiency speedups that can be gained by using software isolated processes (which are only available when code is trusted).

Gravaera,
Yes, I was quite astonished too when I first realized it...

Ah. Thanks for the clarifications, JamesM, Solar. Very good points;

--All the best,
gravaera

JamesM wrote:

Why would you try to develop an OS in a language like C#?

For easier debugging, trusted code, and the MASSIVE efficiency speedups that can be gained by using software isolated processes (which are only available when code is trusted).

Also, for ease of portability to other architectures. This can enable interesting things like satellite kernels running on heterogenous processors in a system: http://research.microsoft.com/pubs/81154/helios.pdf

Maybe you could use an JOP based system and program in pure Java.
Also the are many Forth-CPUs out there (For example http://www.opencores.org/project,fcpu) so Forth maybe an option too.

Hobbes wrote:It almost always comes down to C and assembler, doesn't it?

It just depends on how much C/Assembly you want to write to support your language of choice

Hobbes wrote:It almost always comes down to C and assembler, doesn't it?

For most languages, you need a low level layer (usually in C and/or asm) to bootstrap into the HLL. But not all languages don't need that, and you can get away with inline assembly or ASM stubs for the platform-specific bits. C is one of those, but also C++, Pascal and FreeBasic can do that. Basically, you need a language that compiles to native code, and has a functional subset that does not depend on a runtime library.
With C being by far the most used, it's the obvious choice for performing this task over all others.

D is another language that requires no more than a jmp in assembly. But the runtime was so large so you couldn't use most of the language's features since it depended on an undocumented runtime.

You can implement D's runtime in D's freestanding subset. The same goes for FreeBasic, and afaik, Pascal. I can't speak for the other two, but FreeBasic has similar constrains as C (no basic functions vs no libc includes), and you can't use the String and arbitrary sized array types since they use memory management. It is mainly unwieldy because it's not in a Basic programmer's routine to avoid them, while not #including in C is a much more distinct boundary between do and don't. I consider the choice a matter of taste (and sometimes, propaganda. Guilty as charged. )

Combuster wrote:You can implement D's runtime in D's freestanding subset. The same goes for FreeBasic, and afaik, Pascal.

Yes, Pascal works quite nicely with FPC. I have a kernel written in it and it doesn't use any more assembly than usual C kernels. There are the same restrictions as in other languages, of course. For example string operations work only after you have written some "magic" functions.

If you use something that needs runtime support, current compiler versions even tell you even which function is missing instead of just crashing as it used to do earlier.