有感在先：
CodeSta 一家相当有活力的公司，最近和 Microsoft 的 Peter Hallam 进行了一次访谈，里面有一些非常有趣的信息，有趣的不是 Codesta 提的问题，而是 Peter 的回答； Codesta 的问题在两年前就有人提过，问过微软的名人，比如： Anders Hejlsberg ，有趣的是两年后的回答，答案显得更加自信而且听起来比两年前更加清楚，特别是一些战略方面的回答。
我想下面这些是需要你特别注意的：
1. Virtual machine 的问题，为什么需要它，具体它是什么，和 Java 的有什么不同。
2. C# 的设计理论， CLR 又是如何和它进行配合的。
3. CLR 类或 .NET Framework 的设计理念，性能、面向对象、版本、升级的处理策略
4. 如果你非常的喜欢 C#/CLR, 你认为它最 Cool 的地方是什么？
5. 未来可以预见的一年或两年， C#/CLR 的未来会怎样？
6. Why use C# to build your next application or back-end system? －－高效 + 简单 + 我喜欢 !
从中也会嗅出下面一些信息：
1. Microsoft 不会停止有关预装 Java 的上诉，有了 .NET Framework, 有什么理由用 Sun Java 虚拟机，即使一定要还有 Microsoft Java VM 。
2. Microsoft 对 C#/CLR 的未来和进程非常的清晰，并且控制得非常好。
3. 工业支持问题？业界人士有多少人支持，这是微软很难以控制，但又必须努力去改善的。
4. C# 本身，它最大的特性。如果它能作为一种语言而摆脱 made in Microsoft 的负面影响是非常重要的。可以说目前 Microsoft 遮盖了 C# 的许多光辉，未来呢？这似乎不是一个技术的问题。
5. 交互性，没有人比微软人更清楚如何在老的应用和新的应用中互相交互，也许 .NET 是微软唯一一个不是通过快速升级来拉动用户的产品，连接一切而不是征服一起，微软的 2003 温和了许多 J
最后还有些遗憾，因为文章太长，CSDN无法保存，所以我非常的抱歉，并且提供原文的地址：
http://www.codesta.com/knowledge/technical/csharp_clr/index.jsp
小气的神
2003-2-25
www.dotneTTools.org/weblog/weblog.html
=============================================
Talking C#/CLR with Microsoft
by Joseph Molnar
January 6, 2003
** Introduction **
In this article Codesta interviews Peter Hallam, the development lead for the C# compiler. With questions ranging from why Microsoft invested in the creation of the new technologies, to discussing future features, the goal of the article is to get an inside look at Microsoft's newest programming language, C#, and the associated virtual machine, the Common Language Runtime (CLR).
** A Look at Why **
** Codesta: Why did Microsoft create a new language? **
** Peter Hallam: ** 删除xxx个字，太长
** Codesta: Why build a virtual machine if you can guarantee your platform? **
** Peter Hallam: ** Virtual machines allow you to do some things which can be very difficult without them. Things like accurate garbage collection and code access security are dramatically easier to implement on top of a strongly typed virtual machine. Also, implementing RAD environments, which blur the line between design time and runtime, benefit significantly from virtual machine technology.
Microsoft has employed virtual machine technology in our products for a long time. The entire VB product line has been built on a virtual machine which has evolved since its inception.
One thing that Java did was bring garbage collection (automatic memory management) into the mainstream of programming. Before Java, garbage collecting programming systems were limited to a small fraction of the programming community. Java really proved to the programming community at large that garbage collection was mature enough for real world programming.
When COM was being designed (over a decade ago) there was serious discussion on whether it should be garbage collection based. Eventually the decision was made that the programming community wasn't ready for garbage collection.
The main argument against virtual machines has been performance, both memory usage and execution speed. Recent improvements in computing hardware have made virtual machine performance quite reasonable.
With garbage collection firmly entrenched in the mainstream development community, and networked computing driving security concerns, you will see more and more mainstream programming targeting virtual machines.
** Discussing Design Goals **
** Codesta: What were some of the major design goals behind C#? **
** Peter Hallam: ** 再删除无数个字和两端代码
There are a lot of other great features in C# but that's an overview of some of the key design points in the language.
** Codesta: And the CLR, what were some of its design goals? **
** Peter Hallam: ** While sharing some of the goals of C#, such as a unified type system, the CLR was designed to be a high performance platform for executing code. The Microsoft Intermediate Language (MSIL), the CLR's instruction set, was designed to be compiled to the native platform at install time or ‘just-in-time' (i.e. during execution) rather than being interpreted.
One of the primary goals of the CLR was to support multiple languages. This is reflected in the type system, object model and Intermediate Language (IL) which are general enough to support a broad range of languages. For the first time your C++ class can be a super class to a VB class. This has tremendous benefits for teams that include developers of varying backgrounds and skills.
At this moment there are over 20 languages targeting the CLR. Microsoft has C++, C#, VB, J#, and JScript. Outside of Microsoft you will find Cobol, Eiffel, Scheme, and many others.
Security was also quite important, though perhaps I am not the best to describe it. In general, the CLR has a rich security model to allow trusted code to safely interact with untrusted code.
Experience with DLL's and general application installation also played a role in designing the CLR. In particular the CLR was designed to allow easy deployment of applications, and to ensure that existing deployed systems are robust when new versions of existing components are installed. The CLR allows running multiple versions of the same component side by side.
** A Few Deeper Details **
** Codesta: With Microsoft's push for increased security, how was the CLR affected? **
** Peter Hallam: ** Making it easier for our customers to write secure code is one of the core goals of the CLR. Running code on a secure virtual machine allows the barrier between untrusted and trusted computing to exist inside a single process. Trusted components can leverage the services of untrusted components within the same process. The CLR enables you to write secure components in this manner and evolves the programming model forward with respect to security.
Writing secure code is extremely difficult however, and there are no silver bullets. The only way to write secure code is to think hard about security through the entire design and development process. Secure code can be written using most programming environments. The CLR makes it easier for programmers to deliver secure solutions.
** Codesta: C#/CLR has 2 kinds of code, safe and unsafe. What is it trying to provide and how did this affect the virtual machine? **
** Peter Hallam: ** For C# the terms are safe and unsafe. The CLR uses the terms verifiable and unverifiable.
When running verifiable code the CLR can enforce security policies; the CLR can prevent verifiable code from doing things that it doesn't have permission to do. When running potentially malicious code, code that was downloaded from the internet for example, the CLR will only run verifiable code, and will ensure that the untrusted code doesn't access anything that it doesn't have permission to access.
The use of standard C style pointers creates unverifiable code. The CLR supports C style pointers natively. Once you've got a C style pointer you can read or write to any byte of memory in the process, so the runtime cannot enforce security policy. Actually it could but the performance penalty would make it impractical.
Unverifiable code is useful for interoperating with existing non-CLR code (existing C DLLs and COM components). It can also be useful when dealing with existing binary formats found in things like disk files and low level network protocols. This way you don't need to write custom marshalling code in C++ to access legacy components and binary formats.
Any unverifiable code must be fully trusted for the CLR to run it. Unverifiable code is often used to write a secure API on top of an existing legacy component. Many of the .NET Framework libraries are written entirely in C# using unsafe features to access the underlying platform.
The term unsafe has always bothered me. Unsafe code in C# really means more power to access the machine at a lower level without resorting to a lower level language like C. It is certainly possible to write safe secure applications in unsafe C# in the same way that it is possible to write secure applications in C. The difference is that in safe C# the strongly typed nature of the language and the security features of the runtime make it significantly easier to write secure code.
When using unsafe C#, as with standard C code, much more of a burden is placed on the coder to write safe secure code. The tradeoff between safe and unsafe code is really productivity versus power. It is not a tradeoff of safety. The C# language designers wanted to discourage the use of C style pointers and so the best keyword they found was the unfortunately named ‘unsafe' .
** Codesta: In the early days of Java you created an experimental Just-In-Time (JIT) compiler/virtual machine. How would you compare the Java and CLR virtual machines? **
** Peter Hallam: ** The CLR design is much more mature than the JVM. The JVM made some design choices which have proven to be fairly limiting in the real world.
The JVM byte code was originally designed to be interpreted even though most implementations of the JVM now compile to the native machine for better performance. MSIL was designed to be compiled up front so it is more compiler friendly.
The JVM was designed with only one language in mind so it is missing many useful constructs which makes targeting the JVM painful for other languages. This includes the lack of user defined value types, delegates (type safe function pointers), byref types as well as pointer types.
The JVM's class file format and deployment model have a number of shortcomings. The class file format makes some sense if you are deploying a single class at a time, but in the real world that rarely happens. Typically you deploy a library of inter-dependant classes which you've tested together.
In addition, the JVM has no story for executing multiple versions of a class library in the same environment. The CLR's side by side features and deployment model is an enormous win.
Finally, JNI, the JVM's interoperability story, is extremely weak. To interoperate with existing code you must always write a custom marshaling layer in another language like C/C++.
In C# and the CLR most legacy code can be accessed directly from C# code using the built-in platform invoke and COM interop features of the CLR and the unsafe features (C style pointers) in C#. This lowers the bar to interoperating with legacy systems. Often you don't need to go to another language to access underlying platform features when programming in C# or any other language which targets the CLR.
High level constructs provided by strongly typed object oriented languages are great for building complex systems but ultimately it all comes down to bits. Java and the JVM really make it difficult to access the underlying computing platform.
** A Broad Look at the Features **
** Codesta: Microsoft has often criticized for its lack of innovation. What features of C# and the CLR are truly innovative? **
** Peter Hallam: ** The list here is pretty long so I'll stick to a few highlights:
- the unified type system
- the deployment and versioning support
- supporting multiple languages
It is also true that many of the innovations in C# and the CLR are evolutions of technologies and designs which have been around for many years. Garbage collection is a good example. Garbage collection, including the features for getting good performance such as incremental and concurrent garbage collection, has been around for several decades. The garbage collector in the CLR, which was built upon research from the Compuer Science community, is truly world class.
** Codesta: Where did some of the C#/CLR language features get their inspiration from? **
** Peter Hallam: ** C# and the CLR draw heavily from existing computing practice and theory. C# inherits most of its features from the C and C++ family of languages. Garbage collection comes from the dawn of computing (aka before I was born). Many of the component features (properties, delegates and events) come from the VB and COM world. The unified type system sprang from a desire to get the ease of use of fully object oriented type systems from languages like Smalltalk and combine it with the performance benefits of type systems from languages like C and Pascal. The versioning features are pretty much new to C#.
** Codesta: Are there any future features in C# or the CLR you can talk about? **
** Peter Hallam: ** Anders Hejlsberg, the chief designer of C#, announced some of the plans for C# at OOPSLA 2002 in Seattle . These included generics (similar to C++ templates), anonymous methods (unnamed code blocks encapsulated in a delegate) and iterators (a mechanism for traversing collections).
Taking a closer look at generics, we've had some really smart guys in our research department working on a design for both C# and the CLR and they've done some amazing work. By adding generics to the CLR as well as to the language we really hit the sweet spot in all dimensions - execution performance, type soundness, type identity, MSIL size, and native code size.
Here's a quick example of what generics will look like:
<SPAN lang=EN-US style="FONT-SIZE: 9pt; COLOR: black; FO