Browse DevX
Sign up for e-mail newsletters from DevX


Down to the Metal: Managed Code Under the Hood (Part I)

No matter which high-level languages you use to create .NET applications, they all compile to Intermediate Language (IL). In this series, you’ll dig down inside the .NET framework and find out how IL works. Learn to write IL directly to create .NET assemblies without the need for a high-level language or sophisticated IDEs.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

here are many reasons for using Intermediate Language Assembler (the short form is ILAsm) rather than a high-level language like C# or VB.NET. For example, you can do things with ILAsm that are not supported by the high-level language you choose or fix bugs in an assembly without having the source (if it's not signed of course). Or perhaps you're just a freak like I am, who always wants to know how things really work under the hood. Before getting into IL itself, it's important that you know a bit about the technologies that lie behind the .NET execution engine. I'll explain the basics briefly; for a more detailed explanation see the related resources.

To get the most benefit from this article, you should have a good understanding of .NET programming in general. No matter what language you use to write .NET applications, the contents of this article apply to any .NET assembly. You will need the Microsoft .NET SDK and a plain text editor (Notepad will do fine) to create the samples. CLI—Common Language Infrastructure
CLI is a specification that defines how executable code (Common Intermediate Language or CIL in this case) is run in an execution environment (.NET's Virtual Execution System, or VES). The CLI consists of four parts:

  • Common Type System (CTS)
  • Metadata
  • Common Language Specification (CLS)
  • Virtual Execution System
Here's a brief description of each of these four essential parts. Common Type System: This is the center of the CLI. It describes what types are available for all CLI compliant high-level languages—the types that can be used by a compiler and the CLI itself. A very important role of the CTS is to guarantee type safety. Type safety basically states three axioms that must apply to every type in the CLI:

  • References are what they say they are. Every reference to an object has to include sufficient type information to ensure that it is what it appears to be. References are not allowed to point to character data in one code line and then be interpreted as integer data on another code line. Every reference is typed and also contains information about the possible conversions for that type. Type safety makes it impossible to produce bugs or security issues by misinterpreting referenced data.
  • Identities are who they say they are. This rule prevents malicious use of an object by spoofing the compiler to use another type or security domain. The object can be accessed only by functions and fields that are identified by its type information. But be careful, it's still possible to design a class in such a way that it compromises security.
  • Only appropriate operations can be invoked. Accessible functions and fields are defined by the type of the reference pointing to the object. This already takes into account the visibility that stems from access modifiers, for example, private fields are only visible in the class itself and not outside.
Metadata is used to store information about types in a way such that any CLI compliant tool (compilers, debuggers, or even the execution system) can read this data, regardless of which programming language was used to create it. Metadata is primarily used for declarative programming. For example, you could store information such as debugger visibility in the type metadata rather than deriving a special interface for that purpose. Metadata is both more convenient and easier for programmers to use. The execution environment can use metadata to support different execution models, for better control of optimization rules, and to provide automated support for built in services. Metadata can be also very useful for application deployment, particularly when supporting different possible target environments. Common Language Specification
This is a kind of contract between the CLI and the language designers. Imagine if there were no common specification: Every high-level language would have to be shipped with a different .NET Base Class Library. But with the CLS all languages capable of compiling code for the CLI agree on a set of functions and types that form a common base of services.

Virtual Execution System
The VES enforces the CTS and executes managed code—you can say that managed data is nothing more than data that the CLI automatically loads and unloads via a mechanism that's called garbage collection. Managed code is code that can access this data. Similarly, because the data is managed by the CLI it can't be accessed from code that isn't CLI aware. However, managed code can also access unmanaged data because there is no special mechanism protecting it from being accessed by anything. The CLI also takes care of exception handling, and storing and retrieving security information in managed code.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date