Because there is a HUGE working code base in C.

I think you need to ask a slightly different question to be more accurate.

Why didn't Microsoft rewrite Windows 7 in C#

There is a very simple answer to that one. Windows comprises an estimated 50 million lines of code. Rewriting 50 million lines of code just to change languages is a ton of work for very little / no profit.

Basically because it is not ideal for an Operating System. C# is, by definition, a high-level language that is built on many layers of features and (usually) the .NET framework. Memory management is abstracted away from the developer and for such a critical application that is under incredible scrutiny for efficiency and performance, this is not an ideal environment for Op Sys development. The list goes on, but that's a big part of it.

They're probably still researching an OS built in something like C# ( Microsoft Singularity ^[1])

Singularity is a research project focused on the construction of dependable systems through innovation in the areas of systems, languages, and tools. We are building a research operating system prototype (called Singularity), extending programming languages, and developing new techniques and tools for specifying and verifying program behavior.

There is an interrupt dispatcher written in C but once it finishes, it gets dispatched to compiled C#.

Because rewriting 60 million lines (no, I'm not exaggerating) of perfectly good C/C++ code just to prove a point would be insane? I would think that's the main reason.

One reason is that Windows Vista was not written in C#. Or XP, or 2000, or NT4...

Windows may be one of the biggest code bases in the world, and maintains decent backwards compatibility. Rewriting it in a new language isn't likely.

There was some other issues back in the longhorn days ^[1]... They quote some guy named Joel Spolsky, so take this with a gain of salt... ;)

Do you use C# to create device drivers? I bet you don't, nor does anyone else? So, why would Win7 device drivers be written in C#?

Do you often scrap existing code and rewrite it, just for marketing purposes? Neither does Microsoft.

This is a pretty silly question, if you think about it.

I think a big part of the reason is performance. A lot of people really don't need large amounts of performance, checking email, browsing the web are all pretty simple and don't need a lot of performance.

However those who actually do need the performance (think Pixar or other companies that do rendering, scientific communities, etc), having the overhead of all this managed code would make computing in these areas extremely difficult because every CPU cycle counts.

I don't think OS level engineers consider a managed language acceptable, the common excuse is probably performance.

Of course, when C first came out, many didn't believe you could successfully code an OS in anything but assembly.

I think the biggest reason is that C# gives away the source.. IL is pretty easily converted back into high level code, and recompiled. This would effectively make Windows Open source.

To add to all the answers here, how about libraries. There are tons of classes in .NET which simply wrap the Win32 API.

Such as Directory.GetFiles(), check it out with reflector, mainly the InternalGetFileDirecotryNames() internal method, it just turns around and calls the Win32 API.

The answer to your question is more than just, "it's hard" or "it takes lots of time". It is also about resources, not to mention having a large code base that's WRITTEN, TESTED, and PAID FOR. To be rewritten, which WILL introduce bugs guaranteed.

Could Microsoft reimplement Windows with a .NET core instead of a Native Core? Absolutely, there is no question it is possible. It would just time to get it right. I don't think anyone would want to wait that long. Parts of the OS will be implemented in Managed Code and perhaps one day the Kernal too, but to just dump out millions of line of working code, isn't going to happen.

Also, if we remove native support in the OS, then apps like Office, IE, Firefox, iTunes, and Visual Studio, will no longer work! There are parts if not the entire product written in C++.

p.s. If the Office team has publicly refused to rewrite Office in .NET, how can you expect the Windows team (the platform Office runs on top of) to rewrite their product?

See the source code in C/C++ of windows XP on Usenet (Win32) and you will understand...

As others have mentioned: Singularity is a research project and won't see production. However, there's also Midori ^[1], which is said to be based off the Singularity research project. While most things regarding Midori are pure speculation, it's not unlikely that it will make its way into a future release of Windows. However, don't expect Windows 8 or even 9 to be based on Midori, since the switch to a managed OS would break nearly every application in existence (although .NET based applications might be easily portable). It's more likely that the change to Midori would be gradual, where Midori would run along Windows, or even on Windows as a process.

What's perhaps more interesting than Midori to replace the desktop Windows are the rumors that Midori will power Windows Mobile 8, something much more feasible than desktop Windows.

Re-writing any large project written in 'C' or 'C++' (well any language really) would be a long journey which most companies would not risk. Bringing back the OS to the same feature set as previous versions would more than likely take more time than delivering several versions of the existing product.

A more practical approach is to identify a migration path that can occur over time while minimizing impact of existing features (and hopefully adding value at same time).

What language is the CLR written in......I rest my case.

C# is a high level language, a great powerful language for creating applications, not operating systems. It runs in a layer (IL) on top of the runtime framework and the runtime framework 'currently' runs over an OS (typically Windows). I am not aware of a .Net runtime framework running on bare metal.

That's the same scenario with Java. There are some small projects of Java Based Operating Systems, but not too serious. And Java has runtime environment for bare metal (again, not too serious). There are even some sort of Java-ready hardware too, but again a very long way to make it commercialized.

To me that is the main issue, of course there are more to it, such as device drivers and so on.

What would be the point? There isn't much that you can't do in C# that you can in C/C++ using Windows SDK. It would be about 1000 times easier to write a .NET layer over the missing functionality than to rewrite Windows in C#.

I think a great deal of the real reason has to do with divisions within Microsoft. Windows is produced by one division. C#, .NET, and so on, are produced by another division (developer tools).

To make a long (and frankly, ugly) story short, everything I've seen or heard indicates that the Windows division has little (if any) interest in using C# or .NET at all. From the sounds of things, nearly the only things from the developer's tools division that the Windows division uses at all are the basic command-line compiler and linker -- and even that's pretty grudging, and done primarily because they have no real choice.

A little bit of a late comment but for googlers like myself..

You have the COSMOS ^[1] project os that is -

"implemented completely in CIL compliant languages"

It ain't pretty but it is a POC that is going somewhere..

Speed / Performance. As fast as the .net JIT VM can be, it's still too slow / heavy to run an OS in.

I've read somewhere on Microsoft Research that they are researching on how to implement a Win32 "Runtime" on a managed operating system. They talked about a managed driver programming interface, too. Too bad i can't find it anymore. I think it might not be impossible, but of course it will always have parts of its codebase written in assembler and C++/C. I'm also sure if the runtime is really the at the foundation of the operating system, the performance overhead would become smaller.

The runtime's performance and stability, while much improved in the later versions, still isn't to the point where you can build an OS on it and claim 5 9's of uptime, which Windows Server needs to do. You could in theory build the Shell on C#, but there are still a bunch of trade-offs there.

Garbage collection.

You want a real-time system without needing to pause randomly, sometimes for even more than 1 second. Imagine browsing, listening to music, and watching stock charts, and then BAM, garbage collection.

You can't use an interrupt handler that has random interrupts to clean up memory. See DPC for a small explanation ^[1].

It's entirely possible to load required runtimes with native API and throw a .NET application at it.. Figuring out exactly what runtimes to load would be the hardest part..

Simon

I think the sole reason why Microsoft didn't write Windows 7 in C# is because .Net is just a set of user libraries that utilize native Windows API. (Repeat of Yassir).

Think it of like this - would you write an operating system in VB6? VB6 is an interpreted language - so it requires an OS with the VB6 runtime, which wouldn't make any sense if you were trying to make an OS that ran in an OS.

I would imagine Windows 7 was written in C, some C++ and Assembly. Something that has this large of a codebase has to have sprinkles of other languages in it for optimization.

C# was new when Vista was under development, MS got lot of experience C++ programmers and code base of Windows Vista ready for performance and feature improvement.

Changing programming language for OS from C++ to C# is not that costly for Microsoft they did it before and I am sure they will do it in future, its just matter of time.

Because C#'s code is recognized by Windows itself, not by your computer's hardware (BIOS and/or CPU). You would need to have another version of Windows installed to be able to run an OS off of a high-level language like C#.

Assembly and C are two of the lowest level languages that any computer will understand because they relate directly to the BIOS/CPU. C# is a wrapper around lower-level languages and the Windows API.