Tell me again why we need both .NET and Windows? Why can't Windows morph into the CLR?

Question

The same way DOS morphed into Windows?

We seem to have ended up supporting and developing for three platforms from Microsoft, and I'm not sure where the boundaries are supposed to lie.

Why can't the benefits of the CLR (such as type safety, memory protection, etc.) be built into Windows itself?

Or into the browser? Why an entirely other virtual machine? (How may levels of virtual machine indirection are we dealing with now? We just added Silverlight - and before that Flash - running inside the Browser running inside maybe a VM install...)

I can see raw Windows for servers, but why couldn't there be a CLR for workstations talking directly to the hardware (or at least not the whole Windows legacy ball and chain)?

(ooppp - I've got two questions here. Let's make this - why can't .net be built into Windows? I understand about backward compatibility - but the safety of what's in .NET could be at least optionally in Windows itself, couldn't it? It would just be yet another of many sets of APIs?)

Factoid - I recall that one of the competitor architectures selling against MS-DOS on the IBM PC was UCSD-pascal runtime - a VM.

Answer 1

because it would break backwards compatibility? and mainstream chips architecture doesn't line up with VM architecture? They made hardware for a Java VM a while ago, but nobody cared.

Answer 2

Because Microsoft has got a huge legacy they cannot just simply drop. Companies has invested lots of money for the Windows and Win32 software they cannot dismiss.

Answer 3

Well, for one the CLR isn't an operating system. That's a pretty big reason why not ... I mean even the research OS, Singularity, is not just the CLR. I think you should read up on some books about the Windows kernel and general operating system stuff.

Answer 4

And let's not forget that DOS didn't morph into Windows, at least not the Windows we know and love today. DOS was the operating system, Windows 3.1 a GUI shell resting atop said operating system.

When Windows 95 came out, it is true that there was no more boxed product labeled "Microsoft DOS," but Windows 95, architecturally, was DOS 7.0 with a GUI shell resting atop.

This continued through Win98 and WinME (aka Win9X).

The Windows we know today (XP, Vista, 2003, 2008) has its core from the Windows NT project, a totally separate beast. (Although NT was designed to be compatible with 3.1, and later, 9x binaries, and used a near-identical but expanded API.)

DOS no more morphed into the Windows we are familiar with than the original Linux core morphed into KDE.

The two APIs will need to continue to coexist as long as there are products built natively against Windows which are still in a support cycle. Considering that the Windows API still exists in Windows Server 2008 and Windows 7, that means at least 2017. Truthfully, it will probably be longer, because while managed code is a wonderful thing, it is not always the most appropriate/best answer.

Plus ... As a programmer, you ought to know better than anyone: It's never as easy to do something as it might appear from the outside!

Answer 5

Microsoft are still a few Windows releases away from that.
But they would start with something like Singularity I think.

Answer 6

Windows is multi-million lines of code, most of it in C. This represents an enormous decades-long investment. It is constantly being maintained (fixed) for today's users. It would be completely impossible to stop the world while they rewrite every line in C# for ten years, then debug and optimise for another ten, without totally wrecking their business.

Some of the existing code could in theory be compiled to run on the CLR, but it would gain no benefit from doing so. Compiling a large subset of C to the CLR is possible (using the C++/CLI compiler) but it does not automatically enable garbage collection, for example. You have to redesign from the ground up to get that.

Answer 7

CLR or some VM maybe used (VM's are being used) to run an OS on top of it . But then the question is, what should one use to build the VM? Probably C/C++ or some other similar language and (most) probably Assembly in some cases to speed up things.

That would mean the VM will still have the problems that Windows (or any OS) faces now. As pointed out by others, some part of the OS and related applications may be ported (or as you said morphed) to be over the VM, but getting the entire OS on top of a VM dosen't serve much purpose. The reason being, the VM will be the real OS then, implementing garbage collection and other protective measures for the Morphed OS.

Those are my two cents. :)

Answer 8

The biggest issue I see is that the CLR runs on a VM, and the VM is useful as a layer of abstraction. Some .NET apps can be run on Linux (see the Mono project, I think they are up to .NET 2 compatibility now), so that would all be gone. In C/C++ or languages that directly talk to the hardware, you have to recompile your code into different binaries for every OS and hardware architecture. The point of having the VM there is to abstract that, so that you can write the code, build it, and use the exact same binary anywhere. If you look at it from a Java perspective, they have done a much better job of using their VM as a "write once run anywhere" model. The same java classes will run on Windows, Mac, and Linux without rebuild (by the programmer anyway, technically the VM is doing that work).

I think the #1 point here is that .NET/CLR is NOT Windows specific, and IMO Microsoft would only help the .NET suite of languages if it put a little more effort toward cross-OS compatibility.