The fun and games begin when the runtime walks in
Tags: csharp, dotnet, computerscience
Published: 2020-02-12 05:11:30

Heads up! This blog post is actually a reading log. I'm spending 30 minutes every day (more or less) reading [C# via CLR by Jeffrey Richter](https://www.amazon.com/CLR-via-4th-Developer-Reference/dp/0735667454) and taking notes as I read it. This is tracked as a series on DevTo so you can read all parts of the series in order.

# C# via CLR Reading Log 1: Chapter 1

The common language runtime handles memory management, thread synchronization, and other fundamental tasks for program language implementation. However, it is not particular about which programming language is used. Different programming languages can compile to target the Common Language Runtime (CLR).

Some of the more popular languages that target the CLR are C# and F#, but IronPython and IronRuby are other variants. The CLR gives you the flexibility to pick the right programming language for a particular task while still using the same fundamental semantics exposed by the CLR (memory management, etc)

The process for interfacing an arbitrary programming language with the Common Language Runtime looks something like this:

Programming language file --> Compiler ---> Managed Module -->  CLR

The compiler is responsible for compiling the source code to a managed module -- which is an executable format that the CLR can interpret.

Sidenote: At this point, the book mentions that the CLR takes advantage of the Data Execution Prevention and Address Space Layout Randomization features in Windows. I've heard these terms before and know generally what they are (strategies that exist at the memory management layer for preventing exploits that store malicious code in memory), but don't know the specifics. To-do to read more about this.

Back to the main plot, the "managed module" mentioned above actually consists of four things:

**CLR Header and PE32 header**
The book discusses these in more detail. In short, they are headers that contain metadata about the compiled file. Things like the time it was compiled, whether it can run on 32-bit or 64-bit systems, and more. I'm gonna assume that it's not important to know every property that goes in these headers.

**Metadata**
It's essentially a table that stores the types and attributes defined in the source code that was compiled by the compiler. It includes types and attributes defined in your codebase and in dependencies that you use.

The book referenced that metadata is a superset of older technologies like "COM's Type Libraries and Interface Definition Language files". TBH, I dunno what these are beyond hearing them referenced in technical conversations I've overheard.

Their history aside, metadata tables are useful because they enable many helpful features, like type-checking and supporting garbage collection (the metadata table can be used to resolve which types reference others to determine what data needs to be retained in memory).

The book ends its description of metadata by saying that Chatper 2 is entirely dedicated to metadata tables so I guess I'm in for a treat.

**IL Code**
Intermedia language code is the code that the CLR takes and compiles down to machine code. So the compilation flow for languages targetting the CLR can be summarized as follows.

Programming language (Python, C#, etc) ---> Intermediate language code ---> Machine code

After discussing the managed module architecture, the book introduces a new concept. IL code is not what the CLR works with.  How foolish was I to assume that things could be so simple!

The CLR directly works with assemblies. Assemblies are explicitly described as "an abstract concept that can be difficult to grasp." Well, I don't like the sound of that at all! Thankfully, the book doesn't dive off the deep end here and provides a gentle summary. That's probably why it has so many great reviews!

In brief, it describes assemblies as groupings of one or more managed modules. It also slips in another interesting statement: assemblies are "the smallest unit of reuse, security, and versioning." Sounds intriguing...The book goes on to state that assemblies (along with metadata tables) will be covered in Chapter 2. I guess this is how you keep readers turning pages!

I'm at the end of the 30 minutes now so I'll see you next time when I start reading through the heading titled "Loading the Common Language Runtime."