This is a followup question from [the now deleted] thread:
http://web.archive.org/web/20100812071342/http://stackoverflow.com/questions/783238/why-windows-7-isnt-written-in-c
What kind of problems might one expect to encounter by choosing C# over the tried-and-true strategy of using C? What kind of problems in this domain might be better solved by a high-level language like C# compared to C?
For Singularity, they used an extended version of C# called Sing# (based on an earlier research project called Spec#)
Here's some relevant snippets from http://arstechnica.com/information-technology/2011/06/window... ...
* ... Longhorn would integrate .NET into the core Windows platform. .NET FX, as it was known in the company (with "FX" standing for "framework") would give way to WinFX, a Windows Framework based on the same technology. Among other things, this would include a brand new way for writing user interfaces, codenamed Avalon, that would be thoroughly modern, vector-based, and hardware-accelerated. Windows itself would be written to use WinFX for its user-visible programs—Explorer, calculator, and so on—and, going forward, .NET would be the way to write Windows applications. Win32 would still exist for backwards compatibility, but it would be frozen and left static.
* Longhorn would have been the end of the old ways of writing Windows programs, and the dawn of a new era of modern Windows development, one that was not hamstrung by design decisions made ten or fifteen years prior.
* As we all know now, Longhorn never shipped as such. The project grew enormous, unmanageable, and broken. Around the same time, Windows XP, on which Longhorn was based, was being ravaged by hackers. Microsoft poured its resources into making Windows XP and Windows Server 2003 tolerably secure—an effort that culminated in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1—then, for the most part, started development of its next operating system, the one eventually to ship as Windows Vista, all over again.
* One of the biggest losers in this developmental reboot was .NET. Windows Vista, though radical in some ways, abandoned the entire "WinFX" concept. Avalon did ship—it's now known as Windows Presentation Foundation (WPF)—but as an add-on to the operating system, not a core part.
They probably failed because they were competing against themselves and were just too big and compartmentalized.
I'm a fan of .NET and it would have been pretty awesome to see it take such a large role in the OS itself.
A modern OS is a huge amount of work. It's so vast, your choice of language isn't going to make or break you. Moving a mountain with a tablespoon should proceed three times faster than with a teaspoon. You're still looking at an eternity if you're the only guy.
For this reason, your best bet is to narrow in. Decide what it is you want to write an OS for. Do you want to explore novel user experiences? C# is probably fine for that. You don't need to write the whole OS there, just the "shell" and the window manager. You can do that now, and not spend any time dealing with drivers. Do you want to experiment with microkernel or exokernel architecture? You'll be breaking new ground. Is C# OK for that? What you're really asking is, what are the limitations of C# that you'll run into? The GC pause is one, another is dealing with raw bytes and making it perform. If make the CLR self-hosting, you're going to find performance problems like crazy. If you make fixing that your mission, you could be a hero like the PyPy guys, and everything gets better, or you might just be throwing away a lot of work.
I happen to think a lot of interesting problems would benefit from a high-level approach. Security is a declarative process. You want to say what you want secured and not how. Only one system I know of has ever used Prolog for this (MeeGo, IIRC?) but it was probably a perfect fit. There are lots of opportunities for this kind of thing in OSes and they're never really exploited. If your whole kernel is C and you want to add a declarative security module, well, you'll be writing C. You can surely accomplish the same tasks in C as C#, but if it's a pain in the ass you'll either wind up with a weaker or more limited version in C, or you'll spend more time writing and polishing it. But the world is ripe for a few people to take the unpopular tradeoff and see how well it works out, rather than taking their predecessor's word for it.
To sum up, they're not suitable for the whole job from start to finish. However, if you tried it, you'd make some interesting stuff, and learn a lot, maybe even make things better for other people. Take a crack at it. Worst thing that could happen is you fail. :)
On the other hand, IIRC early machines at least used custom hardware with direct support for many runtime features and implementation details, e.g. GC and tagged pointers.
I think what makes us non-Lispers romanticize the Lisp machine isn't that it ran Lisp per se or even a high level language. It's the Aston Martin flavor of a machine built to be one comprehensive whole by people who understood all the layers and wanted a coherent machine in toto. We still crave these things, and there's something vaguely upsetting about knowing that (for instance) one's Smalltalk image is running within a Unix environment and not natively, even though in practice it's better this way.
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.
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.
Yes, the Linux kernel is, but not all of the userland, which is what makes Elementary OS, "Elementary OS." ElementaryOS outside of the kernel is primarily Vala[1].
One of the comments by the ElementaryOS developers the other month on HN about their usage of Vala and its performance:
> aroman 51 days ago | link
Vala is, all in all, fantastic. The way I describe it to people is "it feels like C# but runs at C speed", and that's pretty much accurate. The only issues we have are binding bugs and Vala bugs, both of which are harder and harder to find these days. And when you do find one, the development community is very active and you can find the help you need.
For concurrency, I have personally written async vala code (which has some excellent support, including closures), but there is full thread support via GObject. The thread safety stuff is the same as the underlying library, and lots of work goes into GLib/GTK+ to make them thread safe where appropriate.
In Rust, the type system encompasses things like who owns a pointer, so you can keep memory management simple, while choosing performance-oriented paths when needed.
The CLR itself is actually fine with a lot of such things (nothing stops you from stack allocating a string "by hand"), it just doesn't help you out. IL is pretty expressive and can translate C in a fairly straightforward fashion. So "C#" by itself has some drawbacks, but they could be patched over with some interop libraries or language extensions.
What they've achieved is really quite impressive. http://cosmos.codeplex.com/
When you write your compiler you will probably end up leaving out some C# features such as reflection, because they are too intertwined with .NET. This is common with other languages when people have tried to write a compiler that emits machine code and it does not usually cause a problem because the problem of interfacing with hardware does not demand the same features from a language as building a modern web app does.
Do your research before starting this because you will likely find a lot of projects that have already built bits and pieces that you can reuse.
I can't think of a single long term advantage of using a language that high level to build system software. Sure it makes a cute research project but that's about it.
As for application level stuff, a big chunk of windows 8 is c#, mainly in the metro space as is windows phone.
That you didn't mention Singularity or Cosmos tells me that you haven't cared enough about this to even do a cursory Google search on the subject.
Anyway, Google those above OSes, browse through their white papers and you'll have your answer (as given above). You might also check out JavaOS, Inferno, JNode, etc which have similar goals.
To get you started with less effort:
https://en.wikipedia.org/wiki/Singularity_(operating_system)
If you don't want to appeal to the general market, but more for a specialized market (like in enterprise or whatever), then you should probably optimize it for AMD's Mantle API, too, and take full advantage of the performance for both the CPU and GPU that you get from that. Also don't even bother with 32-bit.
