Chapter 1:
1. Component technology mainly emphasizes an agreement between independent development and deployment procedures (Contract, how to do it, how to do it). COM is M $ for the first time trying to standardize these. Before COM appeared, it was agreed as a simple function entry, so COM had a big step from the previous world, it is a major progress that dynamically loads the code and the type system in a fairly consistent manner together.
2. COM is a programming model, which is also supported platform technology, but it lacks a stable platform technology, so COM technology faces the end.
3. For agreed descriptions, the COM support format for M $ definition and support is not one, but two: Interface definition, IDL, and Type library (TLB) files. But unable to determine these two formats who are "authority" or "standard", this is the main problem one.
4. Also, COM lacks scalability. MIT Group began researching a new programming model based on the programming idea called "AOP (facing aspect)" in the early 1990s. Later EJB is this evolution. Unfortunately, the MTS team did not depend on any COM convention format. With the launch of VB, the research results of the MTS team announced death.
5. COM component conventions are based on type description. This agreement is physical (Physical), based on binary, so the calling method between the assembly is very strict. The final assembly is finally only the protocol of the stack structure in the memory, which does not describe the content of the semantic. In this case, version control is also very large. Accurate requirements are too high to produce efficient code, but there is an unacceptable unreliability.
6. In order to deal with the problem caused by COM, the COM team and the MTS team decided to develop a new component platform, naming: Com3 à Cor (Component Object Runtime) à URT (Universal Runtime) à CLR (Common Language Runtime) ).
7. The only common point of COM and CLR: The agreement between components is based on type.
8. The agreement between components in CLR: Use "metadata". Metadata is a machine-readable, and forms a specification. And you can use the "Custom Attribute" to easily extend the metadata (actually in "Applied M $ .NET Framework Programming" - "Applied" - A book, Richter suggests this understanding as a string The serialized binary data written, needs to be retrograde it again).
9. The CLR convention itself is a logical structure that is described as a type. The CLR does not look at the form of performance in memory, and the content in the fact that the content is first loaded until the runtime is running, and then the actual address / offset of the member is calculated. (My understanding is that this agreement is "read", not "judging", it is like direct C & P text rather than holding "cardboard book" again OCR, OCR requires that the text is high. In fact, this understanding is also very powerful. Due to such a "load latency", such parsing must be judged when the actual deployment can be judged that in order to solve this, let the components do not contain machine code, use the common intermediate language (CommON Intermediate Language) to do this (also IL, MSIL). 10. Since the generation of local code is postponed to the actual operating phase, the IA-32 / Pentium architecture is developed to the IA-64 / ITANIUM architecture, and the CLR seems extraordinary (for such, for example, "optimization for machine (instruction set)" An example can be explained in the "Applied" book).
