"Essential. Net" Reading notes-Chapter 1

Notes
Chapter 1:

1. Component technology focuses primarily on agreements between independent development and deployment programs (contract, which means doing what is best). COM is the first attempt by m$ to normalize these conventions. Before COM appeared, the Convention simply represented a simple function portal, so COM took a big step forward from the previous world, and it was a significant advance, integrating dynamically loaded code and type systems in a fairly consistent way.

2. com is a programming model and a supported platform technology, but it lacks a solid platform technology, so COM technology faces the end.

3. For the contract description, the m$ definition and supported COM support format is not one, but two: the Interface definition language (Interface definition Language,idl) and the type library,tlb file. However, it is not possible to determine who the two formats are "authoritative" or "standard", which is one of the major issues.

4. There is also a lack of scalability in COM. The MIT team began to study a new programming model in the early 90, based on what is now called AOP (aspect-oriented programming) programming ideas. This evolved from the EJB that came later. Unfortunately, the MTS group does not rely on any one of the COM Convention formats. With the introduction of VB, the research results of the MTS group were declared dead.

5. COM component conventions are based on the type description. This Convention is physical (physical), and is based on binary, so the invocation between components is very stringent. The final component's convention is ultimately a protocol that forms the stack structure in memory, and there is no content to describe the semantics at all. In this case, versioning is also a very big problem. Precise requirements are too high to produce efficient code, but there is an unacceptable level of unreliability.

6. To address the issues raised by COM conventions and their definitions, the COM group and the MTS Group decided to develop a new component platform named: Com3àcor (Component Object Runtime) Àurt (Universal Runtime) à CLR (Common Language Runtime).

7. The only common denominator between COM and the CLR is that the conventions between components are based on type.

8. Conventions between components in the CLR: using metadata (metadata). The metadata is machine readable (machine-readable), and is a specification. And you can use custom attributes to easily extend metadata (in fact, in the applied m$. NET Framework Programming, later called "Applied" – Richter suggests that this be interpreted as a sequence of serialized binary data that needs to be deserialized when it is needed.

9. The CLR convention itself is described as a logical structure of a type. The CLR does not look at the representation in memory, in fact the content in memory is not loaded for the first time until run time, and then the actual address/offset of the member is calculated. (My understanding is: This kind of agreement is "read out", not be "judged out", it is like direct c&p text rather than holding "paper on the blackboard" and then OCR out, OCR requires the accuracy of the text is very high. In fact, this understanding is also quite far-fetched l). Because of such "load latency", such parsing must be judged by actual deployment, in order to resolve this, the CLR makes the component almost without machine code, using the Common Intermediate language (Common intermediate Language) to do this (also known as Il,msil).

10. Since the generation of local code has been postponed to the actual operational stage, the CLR has made a significant difference for the Ia-32/pentium architecture to the Ia-64/itanium architecture (the rest, such as the optimization of "machine (instruction Set)" can be added to the "applied" A book is explained).