MSILVosSpec.docx

1、MSILVosSpecCommon Language RuntimeTechnical Overview of the Common Language RuntimeVersion 1.4 Beta 1 Copyright 2000 Microsoft Corporation. All rights reserved.Last updated: 10/15/18 6:20 PMContacts: jsmiller, lisasuTable of Contents1 Overview of the Common Language Runtime 71.1 Problems Addressed 8

2、1.2 Relationship to Type Safety 91.3 Relationship to Managed Metadata-driven Execution 101.3.1 Managed Code 101.3.2 Managed Data 111.4 Relationship to Unmanaged COM 121.5 Introduction to the Common Language Specification (CLS) 121.6 Summary 142 Type System 162.1 Relationship to Object-Oriented Progr

3、amming 172.2 Values and Types 182.2.1 Value Types and Reference Types 182.2.2 Built-In Types 182.2.3 Classes, Interfaces and Objects 192.2.4 Boxing and Unboxing of Values 202.2.5 Identity and Equality of Values 202.2.5.1 Identity 212.2.5.2 Equality 212.3 Locations 222.3.1 Assignment Compatible Locat

4、ions 222.3.2 Coercion 222.3.3 Casting 222.4 Type Members 242.4.1 Fields, Array Elements, and Values 242.4.2 Methods 242.4.3 Static Fields and Static Methods 252.4.4 Virtual Methods 252.5 Naming 262.5.1 Valid Names 262.5.2 Assemblies and Scoping 262.5.3 Visibility, Accessibility, and Security 282.5.3

5、.1 Visibility of Types 292.5.3.2 Accessibility of Members 292.5.3.3 Security Permissions 302.5.3.4 Nested Types 302.6 Contracts 322.6.1 Signatures 332.6.1.1 Type Signatures 332.6.1.2 Location Signatures 332.6.1.3 Local Signatures 342.6.1.4 Parameter Signatures 352.6.1.5 Method Signatures 352.7 Assig

6、nment Compatibility 372.8 Type Safety and Verification 382.9 Type Definers 392.9.1 Array Types 392.9.2 Pointer Types 402.9.3 Interface Type Definition 412.9.4 Class Type Definition 422.9.5 Object Type Definitions 432.9.5.1 Scope and Visibility 432.9.5.2 Concreteness 432.9.5.3 Type Members 442.9.5.4

7、Supporting Interface Contracts 442.9.5.5 Supporting Class Contracts 452.9.5.6 Constructors 452.9.5.7 Finalizers 462.9.6 Value Type Definition 462.9.7 Type Inheritance 472.9.8 Object Type Inheritance 472.9.9 Value Type Inheritance 472.9.10 Interface Type Inheritance 472.10 Member Inheritance 492.10.1

8、 Field Inheritance 492.10.2 Method Inheritance 492.10.3 Property and Event Inheritance 492.10.4 Hiding, Overriding, and Layout 492.11 Member Definitions 522.11.1 Method Definitions 522.11.2 Field Definitions 522.11.3 Property Definitions 532.11.4 Event Definitions 542.11.5 Nested Type Definitions 54

9、3 CLR Metadata 563.1 Components and Assemblies 573.2 Accessing Metadata 583.2.1 Metadata Tokens 583.2.2 Member Signatures in Metadata 593.3 Unmanaged COM and Unmanaged Code 603.4 Method Implementation Metadata 613.5 Class Layout 623.6 Assemblies: Name Scopes for Types 633.7 Metadata Extensibility 65

10、3.8 Globals, Imports, and Exports 673.9 Scoped Statics 684 Common Language Specification 704.1 Marking Items as CLS-Compliant 704.2 Identifiers 714.3 Overloading 714.4 Operator Overloading 734.4.1 Unary Operators 734.4.2 Binary Operators 734.4.3 Conversion Operators 754.5 Naming Patterns 754.6 Colle

11、cted CLS Rules 765 The Virtual Execution System (VES) 805.1 Microsoft Intermediate Language (MSIL) 815.2 Loading Managed Code 835.3 Conversion of MSIL into Native Code 845.4 Verification of Implementation Code 855.5 Services Based on Stack Format 855.6 Security Services 875.7 Profiling and Debugging

12、 Services 885.8 Delegates 905.9 Proxies, Contexts, and Remoting 906 Index 93Overview of the Common Language RuntimeThis document serves as a high-level technical introduction to the architecture of the Common Language Runtime (CLR), part of the .NET Framework. Where appropriate, this document provid

13、es pointers to more detailed information contained in other documents. At the center of the runtime is a single type system, the Common Type System (CTS), which is shared by compilers, tools, and the runtime itself. It is the model that defines the rules the runtime follows when declaring, using, an

14、d managing types. The CTS establishes a framework that enables cross-language integration, type safety, and high performance code execution. This document describes the architecture of CLR by describing the CTS and its implementation by the runtime. The following four areas are covered in this docum

15、ent: The Common Type System. The Common Type System (CTS) provides a rich type system that supports the types and operations found in many programming languages. The Common Type System is intended to support the complete implementation of a wide range of programming languages. Metadata. The CLR uses

16、 metadata to describe and reference the types defined by the Common Type System. Metadata can be stored (“persisted”) in a way that is independent of any particular programming language. Thus, metadata provides a common interchange mechanism for use between tools that manipulate programs (compilers,

17、 debuggers, etc.) as well as between these tools and the Virtual Execution System. The Common Language Specification. While not strictly part of the CTS, the Common Language Specification is an agreement between language designers and framework (class library) designers. It specifies a subset of the

18、 CTS Type System and a set of usage conventions. Languages provide their users the greatest ability to access frameworks by implementing at least those parts of the CTS that are part of the CLS. Similarly, frameworks can be most widely used if their publicly exposed aspects (classes, interfaces, met

19、hods, fields, etc.) use only types that are part of the CLS and adhere to the CLS conventions.The Virtual Execution System. The Virtual Execution System (VES) implements and enforces the CTS model. The VES is responsible for loading and running programs written for the CLR. It provides the services

20、needed to execute managed code and data, using the metadata to connect separately generated modules together at runtime (late binding). Together, these aspects of the CLR form a unifying framework for designing, developing, deploying, and executing distributed components and applications. The approp

21、riate subset of the Common Type System is available from each programming language that targets the CLR. Language-based tools communicate with each other and with the Virtual Execution System using metadata to define and reference the types used to construct the application. The Virtual Execution Sy

22、stem uses the metadata to create instances of the types as needed and to provide data type information to other parts of the infrastructure (such as remoting services, assembly downloading, security, etc.).Problems AddressedThe Common Type System addresses a number of issues that have complicated th

23、e creation and deployment of distributed applications:Similar and but subtly incompatible types - Dates, Times, Integers, SQL nullable type, etc.Limited code reuse - Cannot import a type from a different language and treat it the same as types defined directly in the language.Non-uniform object mode

24、ls Differing ways of dealing with events, dynamic behaviors, persistence, properties, exceptions, etc.The CTS abstracts and simplifies the details of the language/tool that must be known before a service can be built. By providing a common framework, it allows the runtime and associated services to

25、automate much of the work that is performed manually today. The common framework repairs the following weaknesses in todays infrastructure:No common execution model - No uniform way to inspect the state of an executing program. Crucial for code access security, enables declarative runtime services,

26、and simplifies tools like profilers. Brittle binding mechanisms All the things that lead to “DLL hell” and the general versioning problems that arise from software evolution.In short, too little is known about a program after it is compiled. The CLR addresses this problem by providing:a Common Type,

27、 a means of persisting information about types along with the components that use them (metadata), a specification of the subset of types that have broad reach across programming languages, and a means of building instances given type descriptions (the Virtual Execution System).Relationship to Type

28、SafetyType safety is usually discussed in terms of what it does, e.g. guaranteeing encapsulation between different objects, or in terms of what it prevents, e.g. memory corruption by writing where one shouldnt. However, from the point of view of the Common Type System, type safety is about guarantee

29、ing:References are what they say they are - Every reference is typed and the thing referenced, the definition, also has a type, and they are compatible in a strict sense.Identities are who they say they are - There is no way to corrupt or spoof an object, and by implication a user or security domain

30、. The access to an object is through accessible functions and fields. An object can still be poorly designed. The key is that a local analysis of the object and the things it uses, as opposed to a global analysis of all uses of an object, is sufficient to understand the vulnerabilitiesOnly appropria

31、te operations can be invoked The reference type defines the accessible functions and fields. This includes limiting visibility based on where the reference is, e.g. protected fields only visible in subclassesThe Common Type System promotes type safety e.g. everything is typed. Type safety can be opt

32、ionally enforced. The hard problem is determining if an implementation conforms to a typesafe declaration. Since the declarations are carried along as metadata with the compiled form of the program, a compiler from Microsoft Intermediate Language (MSIL) to native code (see Type Safety and Verification) can type-check the implementations. When coupled with code signing, the issue is then when to t