Share type system and intermediate language
The type in the CLI is constructed by the fields and methods at the minimum, but how these fields and methods itself defines? The CLI standard defines an intermediate language-independent intermediate language that is used to describe programs, which defines a general-purpose type system to provide basic data types for this intermediate language. These two things together form an abstract computing model. The standard uses some rules to modify this abstract model, which describes how abstract models can translate into machine instruction streams and memory references; these conversion processes are very efficient, identify and accurately describe the semantics of many different programming languages. The intermediate language, intermediate language type, and conversion rules constitute a generally meaningful, language-independent method for describing the program.
The intermediate language defined in the CLI specification is called a universal intermediate language (CIL). It contains a rich operation code collection that is unrelated to any existing computer hardware structure for driving an easy-to-understand abstract stacking machine. Similarly, the General Type System (CTS) defines a basic collection of types that contain standard transmutable interoperability. In order to fully realize the benefits of this language-independent world, the advanced compiler needs to understand the collection of CIL instruction sets and the data type it matches. If there is no such agreement, then different languages must choose different mapping methods; for example, how big is the length of the int type in C #? What is the relationship with the Integer type in Visual Basic? Is it the same as the LONG type in C ? These options will become quite simple by matching the instruction sets and these types, of course, the choice of which instructions and types that should be used is determined by the compiler, but a good specification means that these selections Becomes quite direct and simple. By using this method, the results code can interoperate with the code and framework written in other languages, resulting in more efficient reuse. Chapter 3 describes the CLI type system in detail, and Chapter 5 describes CIL, and how it is converted to cost instructions.
Type-based portable packaged unit: assembly
CLI uses its type system and abstract computing model to achieve this ideal: people can use them to create applications with software components written by different people at different times, with them to create applications. In the CLI, a separate component can be packaged in a unit called the fitting, and the fitting can be loaded in need to dynamically load in the execution engine, which can be loaded from the local disk, or can be loaded from the network, or even in the program. Control, dynamic creation.
The assembly defines the semantics of the component model for CLI. The type cannot be externally located outside the assembly. Conversely, the assembly is the only mechanism to load the type into the CLI. The assembly is also made up of one or more modules (the module is the package sub-unit of the resident information), and a large block name is metadata of the assembly of the assembly. Although the assembly can also be composed of multiple modules, it is generally only one module in general.
In order to ensure that the assembly does not be tampered with when it is compiled and loaded, each assembly is signed through a secret key and a hash table of the entire assembly, and this signature can be placed in the list of installed. This signature is trusted by the engine and can ensure that the assembly does not be tampered with, and the dangerous assembly will not be loaded. If the hash table included from the assembly is not matched from the hash table generated by the assembly, it will refuse to load the parts when running, and an exception is thrown before the potential dangerous code will do anything.
In many ways, the fittings are the meaning of the CLI, just like shared libraries or DLLs. Same as the operating system: they are all methods of binding and identifying code belonging to the same part. Thanks to the reliable bi-binding method established in the CLI, each component can be loaded, translated and executed in the case of independent of its neighbors, even if they are interdependent, Interfering with each other. This is critical, because the platform, applications, libraries, and hardware changes over time. Component-based solutions should continue to work properly when these components changes. We will discuss fittings in Chapters 3 and 4. Component Isolation: Application Domain and Remote Call
To make the assembly work together and protect the assembly to load the capacity of each component in a malicious code or bug hazard in other components, as important as the ability of the code organization in the component. Operating systems often get independence by establishing a way to protect address spaces and providing communication mechanisms that connect to protect address spaces and other address spaces; address space provides protection boundaries, while communication mechanisms provide channels for collaboration. There is similar isolation in the CLI to perform code concept, which consists of application domains and support for remote calls.
The assembly is always loaded in the context of an application domain, so the type is limited by their application domain, for example, the static variable defined in the program set allocates space and storage in the application domain. If the same assembly is loaded in three different domains, three different copies are assigned to the data of this assembly type. In essence, the application domain is "Lightweight address space", which is the same restrictions performed by passing data, CLI execution, and operating system between different address spaces between individual applications. It is desirable to communicate across the domain boundary, you must use a special communication channel and operate according to a specific rule.
Technologies, known as remote calls can be used to communicate between applications running on different physical computers (computer that may run different operating systems, with different processors). As always, the remote call mechanism is often used to separate components in the domains located in the same process in the same machine. I want to participate in the remote call or must be serialized so that they can pass between domains or must be inherited from the System.MarshalByrefObject type so they can communicate with the proxy objects that are bumbled. In Chapter 4, the application domain, remote call, and detailed details are loaded.
Named rules for flexible version of the loading service
Because all types and types of code exist in the assembly, there must be a set of definition descriptions how to find and use the assembly when the execution engine requires the type of assembly. The name of the assembly consists of a standard collection of an element, including the foundation name of the assembly, a version number, a regional culture (for globalization service), and a representative publisher's public key to the publisher of this assembly . The combination name guarantees the adaptation of the software that is elegantly created by each assembly. When compiling, each assembly will contain a reference to the combination name of other assemblies that it depends on compile, and remember the version information of each of these assemblies. In this way, when loading, the program rally requires a particular (or semantic consistent) version of the assembly it rely on. The binding policy used to meet these needs can be changed by setting settings, but the binding strategy is impossible to ignore.
You can usually find an assembly in one of the following two places: in a global assembly cache (GAC), a cache for the entire machine, or a URL-based lookup path. GAC is a valid database for assemblies on each machine, each of which is uniquely identified by its four part names. The GAC can be a directory of a file system, but it is not, the CLI run must be able to store different versions of the same assembly in the GAC and can track these different versions. The lookup path is basically a collection of a URL (usually a directory of the file system). When you need to load an assembly, you will search for these paths. Chapter 4 explains the loading process in detail, and how the load is implemented. JIT compilation and type safety
The execution model described in the CLI means that the work of compiling advanced types should be converted to the work separation of these types of descriptions to code and memory structure based on a particular processor. This separation has brought a lot of important advantages to the calculation model, for example, after new operating systems and processors, it is easy to adjust the code to adapt, and can independently define versions of components from each different source. This separation also brings new challenges. For example, because all types are described by CIL and CTS, all types must be translated into machine code and memory structures before they can be used; essentially, the entire application must always be reopened before running. Compile, this may be a very expensive approach.
In order to divide the CIL into the cost of converting CIL into machine instructions (ie, the time spent on load, including the required memory), the type of load based on the CLI-based application is very unique, until the software is running requires them Will be loaded, once the type is loaded, its method will be translated until the software is executed. This extension load and code generation are called instant (JIT) compilation. The CLI is not necessarily required for the last time JIT compilation, but delays in loading and compiling will always occur in some point of the lifecycle of an application to convert CIL into machine code. One thing that can be imagined is that the software installer can perform compilation. Chapter 5 will explain how to implement the implementation of the CLI specification JIT compilation.
The most important reason why JIT compilation to establish JIT compilation in the CLI execution model is not obvious. The conversion of the abstract component to the running machine code is performed under the control of the engine's own loader and the compiler, which is the reason for the execution engine holds control, and efficient running code, even in C . The code and a codeworthy code written in the code are called back, and the execution engine can work well. Traditional compilation, link, and loading process, still exists in the CLI, just as we see, the elements on each toolchain must use a large number of complex technologies (for example, caching) because the delay is used High runtime price. These higher costs are worth endure because the delay also enables full control of behavior of the running components. Since the execution of the CLI is based on the gradual loading of the type, all types are defined using the platform-independent intermediate language, the CLI execution engine is constantly compiling and adding new behaviors during its operation. Because the CIL is designed to be check, and type, compiled as a machine code is performed under the control of the privileged execution engine, so you can check the type security before allowing a new type of time. The security policy can also be checked and applied when the CIL is converted into a machine code, which means that the security check can be inserted directly into the code, executed in the name of the system when the method is executed. Briefly, the CLI can strengthen reliable managed execution by compiling components when delayed loading, checking, and until runtime.
Manage
Type loading is a key to the tool chain that causes the CLI to run at runtime. Take a look at the part of the load process, the CLI needs to be compiled, assembled, link, verifies the format of the executable file and the metadata of the program, the calibration type security, eventually or even the resources of the runtime, such as memory and processor cycles, It is controlled under the control of the component. The task associated with all these phases causes the CLI to include the name binding, memory distribution, compilation, and patch, separation, synchronization, and symbol resolution. Because it always wants to delay the implementation of these elements to the last time, the execution engine can enjoy a highly reliable control of the load and execution strategy, memory organization, generating code, and code and underlying platform, operating system interactivity. Delayed compilation, link, and loading provide better portability to leapfross the target platform and across version. By delaying the decision, the delay address, and the offset calculation, the selection of the processor instruction, the conversion of the delay call, of course, there is also a self-service of the latency link to the platform, the assembly can become more Previously compatible. It is very viable by defining a good metadata and strategy driven.
The execution engine of the translation metadata is a trusted system code, so enhancements are also enhanced by post-loading, security and stability. Each assembly contains a collection of licensing permissions related to it defines what operations that allow this assembly to perform. When this assembly is attempts to perform a sensitive action (such as trying to read or write a file, or trying to use the network), the CLI will view the call stack to check it to determine if all code in the current range has a right. Permissions - If the code on the stack does not have the right permissions, the operation will be rejected, an exception will be thrown (an exception is another mechanism that can be interactive between components; the CLI design is not only supported in the execution engine Abnormal semantics within a broad range, also integrate an abnormal signal from the underlying platform). Chapter 6 and Chapter 7 will detail the managed execution.
Use metadata to achieve data-driven scalability
The CLI component is described. A CLI component contains definitions of each member of its internal, and these definition information is guaranteed in runtime to help virtual implementation of a factor that is highly adaptable. Each type, each method, each field, each single parameter on each single method call must be sufficient, and this description information must be stored inside the assembly. Because the CLI delays the last time of the various link operations to the required execution, it is desirable to achieve great flexibility by using metadata to operate components and creation of new components. The code established above the CLI can use the same type of skills used with the CLI, which is simply a fortune for tool software and runtime services.
In order to obtain type information, the CLI programmer can use the reflection service provided by the execution engine. Reflection provides the ability to check the compile time when runtime. For example, for a managed assembly, developers can get type of structural information, including its constructors, fields, methods, attributes, events, interfaces, and inheritance relationships. It may be more important, developers can add their metadata to the component's description information using a function named custom property.
By reflexing can not only get compile time information, but also an example in which the operation is operated. Developers can use reflections to enter the inside of the type, obtain their structural information, and based on internal information of this structural information operation type. For the method, it is the same; the developer can dynamically call the way to run. The programming capabilities of this metadata drive style, and how to achieve it, we will come into contact with Chapter 3 and talk in detail in Chapter 8. CLI shared source code implementation: ROTER
In the summer of 2001, a group developer of Reid Man announced a small development plan of Microsoft: A free software product, including modifications, re-published source code. This name called SharedSource CLI (SSCLI, people also calling its code name, "rotor") product, including a CLI execution engine that implements all features, a C # compiler, basic programming library, and many related development tool. This product is quietly developed around the business .NET framework, representing an important aspect of Microsoft's developer tool strategy, in fact, SSCLI wants three purposes: testing the portability of CLI specification, helping people to learn and understand Microsoft's commercial CLR products, as well as long-term promotion colleges' interest in CLI. Most importantly, SSCLI should comply with ECMA standards so that people who wish to understand and implement this standard can use SSCLI as a guide.
Although SSCLI is the subject of this book, it is actually the core of this book. SSCLI helps us clarify how CLI is so interested in work, and why. This product itself contains a huge number of code, so it can provide important help for researchers and trials working in the development tool or system design, the same as teachers with computer science. This book tried to assist in analyzing and explaining the rules of basic code to provide these people with a high-level guide for these people. The CLI standard will become increasingly important, and the best way to fully understand it is to browse, create, observe, and analyze an instance of a run.
Rotor demonstrates a method of creating a transplantable, programming language-independent CLI specification, of course, it is not a unique way. When writing this book, there is a similar implementation of other CLI specifications, including the two of Microsoft (commercial .NET framework and "streamlined framework" version of the version), and third-party manufacturers The two open source implementations, a from Ximian (name mono), another from the Dotgnu project (called portable.net - portable .NET). Rotor itself provides a wide range of additional development tools and features that exceed standards. To illustrate those content in this product, Figure 1-3 uses a picture to illustrate the Microsoft commercial product (.NET CLR), CLI and C # standards, and the difference between ROTER.
As shown, SSCLI is a supercoming of the CLI standard, while Microsoft's commercial products are a supercoming of SSCLI.
Rotor is a collection of huge number of codes developed by many people, so it is a complex and
The variables on the stylist (Stylistically Variable ???), in the size of the software, it can be compared to those of the largest famous open source products, such as Xfree86, Mozilla, and OpenOffice. Like these products, if you want to learn about these huge amounts of code, it may be expected. This book will help you complete this task easier, let us start from this product's own brief process. SSCLI is developed using C and C #, and a small number of assembly combination coding development, which is developed by a three-stage process. First, a C compiler based on a specific platform is used to develop a platform adapter layer (PAL), which is a library for the differences of each API of the operating system in a single abstract program collection. Thereafter, a series of developments necessary to create SSCLI (including C # compilers) are created and link on the PAL library. Finally, use these tools and Pal libraries to develop other parts of our products.
Table 1-1 lists some subdirectors that are useful when browsing the SSCLi source code, the SSCLI source is located in the book CD of this book (you can also download from http://msdn.microsoft.com/net/sscli)
Table 1-1. Important subdirectories in the product, as well as the contents of the catalogs.
Subdirectory content
/ Build includes creation of a good executable and library file
/ CLR / SRC Many home directory containing core content subdirectory
/ BCL basic class library, write with C #
/ csharp A C # compiler, written with C #
/ Classlibnative C Writing Development Base
/ debug realizes hosting commissioning
/ DLLS / MSCORSN strong name encryption code
/ Fjit SSCLI's JIT compiler
/ Fusion positioning version file code
/ ILASM a CIL assembler
/ ILDASM a CIL reverseiber
/ INC shared contains files
/ MD metadata tool
/ Toolbox / Caspol Caspol Source Code
/ Tools Many home directory of tools
/ CLIX SSCLI hosted startup
/ GAC GACUTIL Cache Tool Source Code
/ Peverify Peverify CIL Check Tools
/ SOS SOS debug external library
/ strongname serial number code signature tool / VM CLI execution engine
/ DOCS documentation
/ FX / SRC attached home directory
/ net / system / net network function library
/ regex / system / text regular expression library
/ jscript A complete JScript compiler that can be compiled into a CIL code, using C # writing (a managed managed code compiler!)
/ managedlibraries / recning Remote call support for basic class libraries in the BCL directory
/ PAL PAL implementation on multiple specific operating systems
/ PALRT supports the low-level API running in SSCLI, but not for a particular operating system
/ Samples uses CLI examples
/ TESTS extension test and test infrastructure
/ Tools used to create tools for SSCLI products
These subdirectories can be divided into four concepts, as shown below:
N CLI execution engine
n Packaging and extend the component framework of the execution engine
n Portable (PAL) for porting from one operating system to another operating system
n Tools, tests, compilers, documents, and tools for work with managed code.
Let us study these parts in turn, where to find them to find their implementation methods.
CLI execution engine
The execution engine is the core of the CLI. It includes component models, as well as runtime services, such as exception handling, automatic heap and stack management. In many aspects, it is a big wizard (???); it is the code referred to when we talk about "running" and "virtual execution environment". JIT compile, memory management, assembly, and class load, type resolution, metadata parsing, stack traversal, and other basic mechanisms are implemented here. In the SSCLI / CLR / SRC directory and four subdirectories VM, FJIT, MD, and Fusion, you can find code that contains most execution engine functions.
As shown in Figure 1-4, the execution engine consists of a series of loadable dynamic libraries instead of a single executable. CLIX Program Enact Actuator (or any program that wants to use execution engine service) loads the primary shared library, SSCOREE, to create a CLI instance in the process, then provide a startup assembly that needs to be executed for this instance. Therefore, in the execution engine is no main function, it is hosted by other programs in the form of packaging. Execution Engine rely on a large number of other shared libraries, including some unacceptable libraries, as they need to be replaced, such as Crypto code must be loaded and created in MSCORSN, and some will play in many different places The role of the library, such as PAL, can find it in the Rotor_PAL directory and the Rotor_PALRT directory. Finally, those who do not often need are also packaged in the separately loaded libraries, such as MSCORDBC, this library implements the debugger function support. Development library in CLI
The CLI shared frame not only contains standards, underlying functions, such as metadata, universal intermediate languages, and universal type systems, including advanced,-oriented class libraries. Table 1-2 Summarize these libraries by listed all aspects of use
Table 1-2. The advanced elements included in the CLI standard library.
Category function
Production library text formatting, regular expression, collection, time, date, document and network IO, configuration, diagnosis, globalization, independent storage, XML
Execute the engine library separated domain, asynchronous calls, stack traversal, stack tracking, garbage collection, handle, environment, thread, abnormal, monitoring synchronous, security, check, reflection, serialization, interoperability with machine code
Type-related library simple type, value type, commission, string, array
Extended numerical library decimal value, double precision and single precision floating point, mathematical calculation
Programming language support compiler service, custom metadata properties, resource recycling
These libraries provide an interface to use the underlying operating system function, but is used by a manner that adapt to the CLI's service and specification, so that the programmer's productivity is improved through their consistency and high quality. .
These APIs also serve other less important aspects: They promote component integration through exposure programming services and rules, and promote the hygiene of components through programming services and rules. Reduce components developers must complete the thinkeeping work to the smallest service, or to minimize the need to manage the complicated components, so that the inheritance between the components is smoother and safe (and reduces the need to write Code). The less the component is not dependent on other components, the less working for other components, the more likely it is, the more you easily read, and robust. We realize that component-based software truly meaning is required to create components to rely on a managed execution in an environment in which these principles are core designed.
Some people may put the CLI library as another trendy version of the C operation time library. In fact, the CLI library does not tries to provide all the functions for all programmers; but the core components that almost every programmer will be used. Because the base library in the SSCLI / CLR / SRC / BCL directory is a portion where any CLI implementation must have, they form the basis for the implementation of portable applications. At SSCLI / FX, SSCLI / CLR / SRC / Classlibnative, and additional libraries in the SSCli / ManageDlibralies directory, or optional standard libraries or is part of SSCLI. Currently, all the libraries in SSCLI can be found in Microsoft's business .NET framework. If you browse each library, you will find that in addition to the SSCLI / DOCS directory, there is a separate downloadable file (also included in the book CD of this book) in addition to the documentation of the Rotor product and its function. There include documents of class libraries. This document comes from the document used in Microsoft's .NET Framework SDK, but it has been modified and transformed into a simple HTML file.
Platform adapter layer
PAL is a very interesting software, although people are not very concerned about it, it is very useful. Of course, any adapter or drive layer containing a large number of code has a significant feature, which is that the primary purpose of PAL is to be separated from the details of various operating systems in many operating system platforms. The choice in SSCLI is very clear: because it is started from a particular Win32 code, the PAL is designed to express a subset of the Win32 API (can be found in SSCLI / PAL / ROTOR_PAL.H). This implementation will definitely not complete because it only needs to provide those calls that CLI actually use. Don't try to use PAL as a universal Win32 simulation layer because it is incomplete.
Of course, the work of porting Rotor to a new platform should start from PAL because tools for creating Rotor depends on their operating systems and resources based on their operating systems and resources. You can view the SSCLI / PAL / UNIX directory to find out what content. Here, there is a large number of important tasks that must be completed: provide universal abnormal processing mechanism, universal thread, shared handle management, IO, synchronization, commissioning, etc. A specific host process, such as a web server or database, is likely to require their own similar runtime. PAL semantics need to consider these issues. Because these situations, and PAL define how to use the operating system resources, it is very important to understand a variety of PAL's implementations for many people.
In addition to PAL, the SSCLI / PALRT / SRC directory contains a Win32 API implementation library, SSCLI requires this library, but the execution of this library does not depend on the operating system. This library also includes a small amount of PAL's API. It is indeed a variety of hodgepodges, but interesting is, which contains the Decimal algorithm, some simple implementation, array processing, memory management, and various other useful functions of Microsoft COM component models.
The most interesting method of PAL must be the execution engine control. SSCLI design requirements can collaborate in the original process and machine code. This means that you need to capture many operating system calls to provide opportunities for execution engines to maintain unusual information required to use runtime systems, such as garbage collection or security systems. This is a key to the PAL layer. The SSCLI implementation is created in abstract ways expressed in PAL. If there is no PAL, it does not maintain independent, security and control. For example, threads and abnormalities are implemented in the PAL, both of which are critical for execution engines at runtime because it uses an exception frame to track managed modules, using a thread stack to store a diffusion structure including its own service state. The details in this regard will be discussed in detail in Chapter 6, while the PAL's own design will be the subject of Chapter 9. Tools, compilers, tests, documents and other useful things
A considerable part of the code is composed of a frame structure for creating, testing, and using its CLI. The PAL layer we just discussed is like this code. Various additional development tools, useful things, and test procedures can be found in all parts of this product. These tools belong to management development and create a wide range of products.
In terms of management, many tools in Rotor products will be familiar with any programmers who have experienced using Microsoft .NET framework because these two implementations of their basic functions, such as linkers, assembler, and Anti-vocabulary. SSCLI / CLR / SRC, SSCLI / CLR / SRC / TOOLS, AND SSCLI / CLR / SRC / Toolbox directory include subdirectory of these features, and tools for developing and running hosted codes using SSCLI, such as CLIX.exe . The programmer should look at the document in the SSCLi / DOCS directory to find out if a feature is shared by the Rotor version tool and its copy of its .NET framework, not all features are shared.
The creation system used to self-generate ROTOR is located in the SSCLI / Tools directory. These tools are created on the PAL to track dependencies, drive creating processes, assemblies, and execution files, once created, installed libraries and executables will be placed in the SSCLI / Build directory. Relying on Rotor is puzzling because it is a very huge project, so these tools are important. You can view the SSCLI / DOCS / BuildTools directory to learn how to use them, and how developers interact with them when modifying the code.
Once SSCLI is created, you can use the test program in the SSCLI / TESTS directory to test it. In particular, the PAL test program in the SSCLI / TESTS / PALSUITE directory can be used to check the new PAL implementation, or check it to a change in the existing PAL, in the SSCLI / TESTS / BVT directory Developers create a check test (BVT) that can be used to check the work completed in the execution engine. There are also tests for other areas such as basic class libraries, such as the basic class library. Most tests, including BVTS, using test tools in the SSCLI / TESTS / HARNESS directory, and the document is located in SSCLI / DOCS / TESTING_OVERVIEW.HTML.
Rotor-related documentation and technical information is located in the SSCLI / DOCS directory, which contains information for the selection of specific implementations for browsing the source code, modifying the code, and understanding the CLI structure and creates SSCLI. This directory also includes a detailed description of a PAL that will be very useful for people who need to transplant Rotor to a new platform. Take some time to browse this directory is worth it.
Book scope
The focus of this book is to implement how the CLI component model and its underlying execution engine are implemented in SSCLI. It is also simple to describe the need to place such a mechanism on the operating system, as well as the general transplant. The discussion of the compiler, language and framework, as well as the use of CLIs using the non-container, but these content can be found in many books of the Net framework and the CLI. The size and scope of the book, as well as the fact that the author wants to see the book published, and determines the content of this book. It also needs to be declared: Most of the C examples of the SSCLi source code in this book are cleared, replaced with pseudo code in the process. The purpose of this is to remove the ugly macro definition, error handling, and assertion that will confuse the true code so that the code is more readable. If you plan to add and modify SSCLi source code, you should be aware that variables that must be retained, as well as the same programming style and error handling methods as SSCLI developers. Appendix D briefly describes these aspects.
Summary
The CLI is the first virtual execution environment that can be shared from head design and can be shared by many different programming languages. Platform provider, frame creation, and programmers don't have to be forced to pay attention to all language features, but only use the advantages of creating components, such as exception, garbage collection, reflection, code access security, data driver Scalability. With CLI, you can easily merge already existing code into components-based programming, resulting in growing interoperability and shared frames.
CLI is used to pack, describe, and deploy components. None of the operating system and implementation language. This is important because this format forms the basis of the structure of the CLI data drive. The data drive mechanism improves programmers' productivity because it makes different procedures, libraries, and tools to interact seamlessly and develop over time. A data-driven component model is like today's technology is the future guarantee.
The virtual instruction set and type system depicts the virtual execution model of the CLI, showing the tempting of the Holy Cup: Software can operate anywhere, and the CLI design is of course foreseen that a variety of different implementations and different versions can be on many platforms. Cap stock world. However, in this world, using CLI's outstanding support for interoperability, each implementation may expose unique frameworks, services, functions, and tools, or increase the language characteristics of the base capacity. This will result in a similar C language development, in this development, rarely an important application is independently created at the standard runtime. Instead, the application will be wise to combine the standard functions of the platform-related libraries, and combining the base of specially designed using specially designed across platforms. Many important CLI programs will combine the platform-related components and combine third-party components that specifically designed specifically in cross-platform to form a standard component.
People develop CLI language-independent characteristics, data-driven structure, and its virtual execution model to create an efficient collaboration between components without sacrificing security and encapsulation. The metadata stretching chain creates a behavior that can be aware of the components, where security errors can inject secure errors into their code. Each phase in the CLI execution model includes works from the previous stage to receive data, converts, and enhances it, and then passes it to the next phase. This book describes the complete chain of these phases, and their implementation engine, starting from the initial start sequence until the last managed resource is released.
