ECMA-335

The ECMA-335 standard specification defines the Common Language Infrastructure (CLI) , which includes a set of conceptual definitions and rules to be followed and engineering mechanisms to be implemented, independent of the target operating system and hardware platforms. The CLI ensures that applications, components, and libraries can be written in multiple high-level languages and can be executed in different target system environments without needing to be rewritten.

We can access the ECMA-335 specification at www.ecma-international.org/publications/standards/Ecma-335.htm. Figure 1-1 shows an excerpt. The download link is www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf, and the XML specification download link is www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.zip.

More objectively, the CLI is an open specification that describes executable code and an execution environment that enables multiple high-level languages to be used on different architectural platforms without being rewritten.

When writing code using a programming language that adheres to the CLI standard specification, the result of the compiled code is a sequence of instructions of the CIL instruction set, as examples show in Listing 1-1 and Listing 1-2.

Open the sample solution RVJ.Core.sln at <install_dir_on_your_local_computer>SourcesAPIsDotNET5.0ProCustomLibsCh01RVJ.Core.

In the first sample project (Buffers_Console_Client), we have in the Program.cs C# file a .NET custom data type named Program derived from System.Object, the .NET root data type for every kind of .NET concrete or abstract class or struct data type, directly or indirectly, as shown in Figure 1-2, Figure 1-3, and Figure 1-4, respectively.

In the C# programming language, because C# treats System.Object as the base class, we do not need to use the System.Object root data type explicitly when we do not have another class as the base data type.

These instructions are not for real hardware or processors. Instead, the CLI standard specification describes a virtual environment that includes some characteristics and functionalities of the elements available in a real computer.

.NET Platform

Microsoft .NET is the official commercial name for the group of technologies and tools designed and implemented based on what is in the ECMA-335 standard specification.

Common Language Runtime, as the name suggests, is an implementation based on the CLI standard specification, and an implementation of the CLR has a set of elements for a fundamental architectural model. Each element has a fundamental set of conceptual definitions and rules to be followed, and engineering mechanisms to be implemented, independently of the target operating system and hardware platforms.

When we are implementing a CLR environment and technologies of a .NET platform, we are creating software elements for a platform that is a nonspecific hardware-based computer (more specifically, a software-only computer, and more commonly known as a virtual computer ). This description includes when planning and implementing custom data types, custom components, custom controls, custom libraries, and specialized tools and frameworks.

For this text, we are using a .NET 5 implementation of the CLR for the sample projects and respective source code.

You can check for the most up-to-date versions of .NET 5 at the official Microsoft website:

https://dotnet.microsoft.com/download/dotnet/5.0.

Independently or together, these abstract aspects focus on management of data types. So, reasonably, that form of environment and its components is known as a managed environment .

For example, when we are developing some application and choose the System.String reference type, we are using one of the fundamental types available through the BCL.

However, the string reference type exists only because the CTS has the string fundamental built-in type defined on it, which is one of the platform-specific fundamental built-in types upon which string operations are built. In fact, the string content (value of) in any instance is made up of a sequence of values of the CTS char platform fundamental built-in type, which is System.Char fundamental data type in the BCL. These platform fundamental built-in types, BCL fundamental types, and any other types derived or based on them follow the rules described by the unified type system.

In the CLI specification, this unified type system is the CTS, which describes rules about conceptual, structural, and behavioral elements that must be followed by the CLI itself and specialized tools (such as compilers and runtime environments).

Remember that this is not a one-to-one mapping between reserved words, data structures, specialized resources, or anything else in the programming languages. That is, what is formalized through the instructions in CIL, what is defined in the CLI specification, and what is implemented by the mechanisms on the platform is what prevails.

When unmanaged code needs to be used from the managed code, the unmanaged code implementation attribute must be applied on the method implementation. In the specific case of the P/Invoke mechanism, the use of the unmanaged code implementation attribute is required.

The pinvokeimpl method attribute is used to indicate that the runtime will switch from a managed state to an unmanaged state when executing the unmanaged code.

Listing 1-3 shows an example of a managed code implementation that uses an unmanaged code implementation of a well-known Windows application programming interface (API) HeapAlloc() function . The method has been applied the unmanaged and native code implementation attributes.

At this point, we have the following sequence of elements: the CLI standard specification that is composed by and describes the CTS group, the metadata group, the CLS and VES group, and the CLI itself.

Fundamental Types and Hardware Platform

For this discussion, we use Intel IA-32/x64 and Intel 64 fundamental built-in data types (or fundamental built-in types), and we use some defined assembly instructions (implemented and supported) that derive the hardware architecture and the contextual interpretation of the bits on the data type.

The fundamental built-in data types are those defined as integral elements of the platform (in this case, the Intel IA-32/x64 and Intel 64 processor hardware architecture). Therefore, these types are integral elements of the hardware architecture and are not defined by an external library or execution environment.

Although these fundamental built-in data types are supported by a common set of assembly instructions (such as MOV) that perform a common set of operations such move data from one place to another, some assembly instructions support additional interpretation of fundamental built-in data types.

The purpose of this additional interpretation is to allow numeric operations to be performed, and within this context these fundamental built-in data types are viewed and manipulated as numeric data types.

The Intel IA-32/x64 and Intel 64 processors recognize two integer types: signed and unsigned.

Assembly instructions such as ADD and SUB can perform operations on both signed integers and unsigned integers, but some assembly instructions can perform operations only with one type.

The Organization of Fundamental Data Types

Table 1-2 describes the bits in more detail, including information about fundamental hardware requirements and integer types (signed and unsigned).

CTS for Fundamental Types

The CTS supports types that describe values and types that specify contracts (behaviors that the type supports), and the support for these types must be present in an implementation of a CLR. These two types are supported because one of the principles of the CTS is to support object-oriented programming (OOP), procedural, and functional programming languages.

A value is a bit pattern used to represent types such as numbers (for example, integer numbers and float-pointing numbers).

A value type is not an object type, but it is defined using a class definition (declaration and implementation).

Remember that this way of work is defined by CTS and supported by VES in the CLR. From the perspective of the type system and execution environment, it is necessary that an object be declared, defined, and implemented to work within the CLR.

Table 1-3 describes the fundamental built-in types defined by CTS. As the table shows, the root object type is accessible through the object keyword of the CIL. So that programming languages such as C#, C++/CLI projection, F#, VB.NET, and others can access this root object type of the platform, there is a library of fundamental types that is part of the CLI specification. This foundational library is the BCL.

This root object type is the System.Object reference type. When declaring a variable of the object type (CTS model definition) or System.Object (BCL) reference type using any high-level programming language such as C#, C++/CLI projection, F#, VB.NET, and so on, the compiler generates an intermediate code using the object keyword of the CIL. Table 1-4 summarizes and helps you understand and memorize this sequence in a straightforward way.

.NET Module

When we use C++ to write code, the result of the compiled and linked code is a binary file in a specific format. In this case, we are working with PE/COFF (Portable Executable / Common Object File Format), which is used by the Microsoft Windows operating system. When we use C# to write code, or when we use any other programming language or group of extensions that adhere to the CLI specification, the resulting binary file is in the same PE/COFF format. However, that resulting binary file has some data structures changed/included to support the requirements described by CLI specification and aspects of the Microsoft Windows operating system. This is called the CLI PE/COFF module.

Currently, on Microsoft Windows, the CLI PE/COFF module can have .EXE, .DLL, .netmodule, .WinMD, and .UWP extensions created and recognized by the operation system or development tools. In addition, it can have any other extension that can be registered and recognized by the operating system or specialized tools (for software development or not).

In fact, the use of an extension is not required, but it is a good practice and the accepted standard.

If we are using .NET 5 or .NET Core (not the old Windows-only .NET Framework) in a different operating system and on a different hardware platform, the extensions and file formats used are specific to such software and hardware environments. However, the fundamental structural resources defined in CLI as a starting point are the same.

One VES responsibility is to load the CLI PE/COFF modules. Doing so includes verifying some structural rules about the file format and guaranteeing that all information is as expected. The VES uses the metadata information in the CLI PE/COFF modules to verify that the structural aspects are recognized by the rules that it knows as valid, required, or optional. If the structural elements exist and are valid, the next step is to apply the rules based on the nature of the elements and the context of use.

For example, if the element is a managed type, the execution system needs to verify whether it is a value type or a reference type.

If the element is an assembly reference type, one responsibility of this type is to describe various characteristics of the managed module (structural and behavioral), such as the relationships it has with other managed modules and what managed types are in it (and in any other managed module).

.NET Assemblies

People often wonder what a .NET assembly is exactly. Put simply, and as defined and described by the CLI, an assembly is a logical unit for management and deployment of resources designed to work together. In an implementation of CLR, assemblies can be static or dynamic.

Using the ILDASM Tool

With the code compiled and the binary generated, we now can use the Intermediate Language Disassembler (ILDASM) tool. (ISLASM , in contrast, stands for Intermediate Language Assembler.) On the same command prompt that we used to compile the code, write the following command:

ildasm RVJ.ProDotNETCustomLibs.dll

With the module RVJ.ProDotNETCustomLibs.dll loaded by the ILDasm.exe tool, we see the screen shown in Figure 1-5.

Now double-click in the manifest. A new window will open with information about the assembly manifest, as shown in Figure 1-6.

Implementing the entrypoint Method

We have created a single-file static assembly, with only the assembly manifest. If we want to create an .EXE, we need to change the source code. Using the same RVJ.ProDotNETCustomLibs.il, update the source code to include a managed method that is the entry point:

.assembly extern System.Runtime {

  .ver 5:0:0:0

}

.assembly RVJ.ProDotNETCustomLibs.Buffers {

.ver 1:0:0:0

}

.method static public void MyEntryPointMethod() cil managed {

.entrypoint

    ret

}

As you can see, the name of the .entrypoint method does not need to be main.

To build this code, use the following command:

ilasm /Output=RVJ.ProDotNETCustomLibs.exe RVJ.ProDotNETCustomLibs.il

After the code compiles without error and with the binary generated, we can use the ILDasm.exe tool to load the module RVJ.ProDotNETCustomLibs.exe, and then we have more than just the assembly manifest, as shown in Figure 1-7.

As shown in Figure 1-8, we have created a single-file static assembly, with the assembly manifest and one method (in this case, the entry-point method). When RVJ.DotNETProCustomLibs.exe runs, it runs like any other .NET managed executable.

Listing 1-5 shows an example of managed instructions from one of the sample projects that comes with the companion content of this book. The .module directive indicates the name of the binary module (in this case, RVJ.ProDotNETCustomLibs.exe). The .assembly directive describes which assemblies make this a logical unit of management and deployment of resources designed to work together. The .assembly RVJ.ProDotNETCustomLibs.Buffers (without the extern keyword) describes that this assembly is in the current module. The use of .assembly extern directive describes to the assembly the types that your .assembly or .module are referencing. For example, .assembly extern System.Runtime indicates that the assembly RVJ.ProDotNETCustomLibs.Buffers is using one or more types of the assembly mscorlib. The highlighted CIL instructions are the same that you can read in the RVJ.ProDotNETCustomLibs.dll or RVJ.ProDotNETCustomLibs.exe modules. Chapter 2 discusses these and other instructions in more detail (with even fuller detail following in subsequent chapters).

.assembly extern System.Runtime {

  .ver 5:0:0:0

}

.assembly RVJ.ProDotNETCustomLibs.Buffers

{

  .ver 1:0:0:0

}

.module RVJ.ProDotNETCustomLibs.exe

.imagebase 0x00400000

.file alignment 0x00000200

.stackreserve 0x00100000

.subsystem 0x0003       // WINDOWS_CUI

.corflags 0x00000001    // ILONLY

.method public static void  MyEntryPointMethod() cil managed {

  .entrypoint

  // Code size       1 (0x1)

  .maxstack  8

  IL_0000:  ret

} // end of method 'Global Functions'::MyEntryPointMethod

Listing 1-5

Fundamental Keywords Used by Static Assemblies or Dynamic Assemblies

As you can see, the VES handles a lot of work. Even still, though, there are more interesting functionalities within this mechanism.

Chapter 2 discusses these resources and goes into more detail about the CTS and VES. Specifically, you’ll read more about fundamental built-in types and about how the execution environment deals with these types and structural elements of the platform. Initially, we use code written directly in CIL to provide more information about the use of the types and so that you better understand how to work with modules and assemblies. We then use some code in C++ to highlight some internal aspects of the execution environment and some special types. From that point, we embark on our journey through foundational BCL using the MSIL and C# programming languages.