The Microsoft Side of Things
Microsoft has treated the .NET Development process in a way that no one could have ever anticipated, and it seems to be treating them well in return. Besides breaking quite a few “family traditions” of the Microsoft Camp, .NET is a step in the right direction no matter what angle you look at it:
- No Backwards Compatibility – Not Really
Microsoft’s insistence on backwards compatibility won it a host of developers and a big headache back in the 90s – but with .NET it’s a whole ‘nother story. .NET 2.0 isn’t strictly compatible with .NET 1.0 or 1.1 applications – that is, Microsoft isn’t worried about bringing older applications crashing. After all, since the .NET platform is a virtual machine of sorts, why bother?
Instead of allowing .NET 1.x applications to “run guaranteed” on the .NET 2.0 platform Microsoft simply provided a way to run both simultaneously without a problem. You simply install both engines, and the application can pick and choose the combination that suits it best: keeping the headache and bloat factors down to a minimum but nevertheless ensuring that developers don’t need to sit for hours figuring out just why their applications don’t run on the new platform. You just don’t need to anymore.
- Friendly Licenses – Really Friendly
Using the licensing system first used in/by Microsoft Research (TM), the .NET Framework comes under a very friendly license that lets you do almost anything. Know as “Shared Source,” it’s Microsoft’s version of the BSD License: you don’t own the engine, but you can do whatever you want with it… And pass the license along. Or something like that.
- It Exists for Itself
Microsoft does the research, codes the platform, and then gives you the tools to do what you need. Besides being free, it exists for itself. What that means is, Microsoft doesn’t use .NET as a way to gain money (not directly at any rate), but rather urges and innovates in .NET just for .NET to gain market usage – since .NET is guaranteed to run flawlessly on Windows and the server-side implementations still need IIS, and the users just want a steady flow of innovation and improvement for a framework that just works, it’s a win-win situation for everyone.
But .NET isn’t just different, it’s also the same. Everyone has heard Bill Gates’ version of “I have a dream:” Information at the Fingertips. That was Microsoft’s goal ever since Windows 2.0, and although Vista failed to achieve that, .NET still can. The .NET Framework is at heart a framework that gives the developers direct access to the very tools they need to make applications that do exactly what they want, without needing to mess with the other code too much.
But if .NET is what Microsoft always wanted.. What happened to Longhorn?!
That’s a good question that unfortunately doesn’t have a good enough answer. In the original alpha builds, Windows Codename Longhorn was a pure .NET-driven operating system, complete from head to toe.
We can only guess what happened and why Microsoft decided to leave .NET and write Vista’s backend and 99.9% of the UI in unmanaged C++, but it’s probably something along the lines of “too much pinvoke.”
To put it simply, .NET 2.0 simply isn’t ready for a project on the enormous scale: an operating system. It isn’t flexible enough, but even more importantly: it isn’t mature enough. It’s stable, but it’s missing too many functions that are required for an operating system to work the way it should. Too many low-level calls simply aren’t there, and if you’re going to use pinvoke 90% of the time, you might as well just fall back to C++.
Although that doesn’t satisfactorily put the question to rest, and Microsoft could have built the .NET Framework up around them as they went along, it doesn’t really matter. Anyone using .NET will be writing applications to run on top of an operating system, not instead of one — and for that it’s plenty good enough.