Windows DNA and .NET
Did the phrase that I used earlier to describe .NET- "the new environment for creating and running robust, scalable, distributed applications"-sound familiar? If so, there's a reason: .NET is basically the offspring of an earlier attempt to satisfy these lofty goals. That platform was called Windows DNA. However, .NET is much more than Windows DNA was meant to be. Windows DNA was a solutions platform that focused on solving business problems through the use of Microsoft server products. The term "glue" was sometimes used with Windows DNA, as in, "DNA defines the glue used to piece together robust, scalable, distributed systems." However, aside from being a technical specification, Windows DNA didn't have any tangible pieces. This is just one of several major differences between Windows DNA and .NET. Microsoft .NET is not just a set of specifications. It also includes several tangible products, such as compilers, class libraries, and even whole end-user applications.
The Common Language Runtime
The CLR is the very core of .NET. As the name suggests, it is a run-time environment in which applications written in different languages can all play and get along nicely-otherwise known as cross-language interoperability. How does the CLR provide this cozy environment for cross-language interoperability? The Common Language Specification (CLS) is a set of rules that a language compiler must adhere to in order to create .NET applications that run in the CLR. Anyone, even you or me, who wants to write a .NET-compliant compiler needs simply to adhere to these rules and, voila!, the applications generated from our compilers will run right alongside any other .NET application and have the same interoperability.
An important concept related to the CLR is managed code. Managed code is just code that is running under the auspices of the CLR and is therefore being managed by the CLR. Think of it like this: In today's Microsoft Windows environments, we have disparate processes running. The only rule that applications are required to follow is that they behave well in the Windows environment. These applications are created by using one of a multitude of completely dissimilar compilers. In other words, the applications have to obey only the most general of rules to run under Windows.
The Windows environment has few global rules regarding how the applications must behave in terms of communicating with one another, allocating memory, or even enlisting the Windows operating system to do work on their behalf. However, in a managed code environment, a number of rules are in place to ensure that all applications behave in a globally uniform manner, regardless of the language they were written in. The uniform behavior of .NET applications is the essence of .NET and can't be overstated. Luckily for you and me, these global rules primarily affect the compiler writers.