Last time I discussed the topic of who lives where. And I mentioned that Values live on the Stack, whereas References live on the Managed Heap. All good. But since then, and since digging way deeper into the topic, I realized that this shouldn’t be the MAIN thing you care about. Should you know about it? Sure! But should it be the main thing you care about - no! The main point of consideration should be about the behaviors that they exhibit. And the behavior is determined based on how they are represented. So, let’s talk more about that.

If you’re a newcomer, this is article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t seen any of the past articles - I’d recommend you start from beginning.

As usual, we start with the infographic first:

Let me immediately quote Eric Lippert’s rant on References vs Value types:

Almost every article I see that describes the difference between value types and reference types explains in (frequently incorrect) detail about what “the stack” is and how the major difference between value types and reference types is that value types go on the stack. I’m sure you can find dozens of examples by searching the web.

I find this characterization of a value type based on its implementation details rather than its observable characteristics to be both confusing and unfortunate. Surely the most relevant fact about value types is not the implementation detail of how they are allocated, but rather the by-design semantic meaning of “value type”, namely that they are always copied “by value”. If the relevant thing was their allocation details then we’d have called them “heap types” and “stack types”. But that’s not relevant most of the time. Most of the time the relevant thing is their copying and identity semantics.

Source: Eric Lipperts’ Blog

Given that, indeed, it gets hard to find valuable information, doubly so if you are looking for an image representation, I decided to create one. And here is the enlarged version:

In order to explain the behavior, you need to understand WHY is that behavior happening in the first place. And having an image should help.

Think of both Value and Reference types as Boxes. That’s it. Boxes. And there’s content inside of those boxes. What the exact content is, I’ll explain on the example of trying to store integer “42” inside the box.

In case of “42”, if we stored it inside the variable called “valueVar”, that variable would literally contain the bits that make up 42 (i.e. 000…00101010). I guess that’s simple enough to digest, right?

When it comes to Reference Types, the story is a bit different.

In case of “42”, if you were to store it in the variable called “referenceVar”, you’d effectively be storing the “42” (i.e. 000…00101010) somewhere on the Managed Heap, and the actual 64-bit address where the value could be found would be stored inside “referenceVar”.

valueVar = 42; // valueVar now contains 101010 (i.e. 42 in binary)

referenceVar = 42; // referenceVar now contains 64-bit address where 42 can be found (e.g. 010110101010011...01010)

Why that matters? Well it matters because of the behaviors they exhibit. And these behaviors are fundamentally different and in order to understand them, we need to quickly remind ourselves of how CPUs work.

CPU by itself has no knowledge of Value / Reference types. Hell, not only does it NOT have the knowledge, but it doesn’t care either. When it comes to CPU, all it does is moves the bits back & forth between RAM & registers. That’s it.

So what really happens with Value and Reference types is that, whatever is inside of them, will be copied back & forth. If it’s an actual value - the value itself gets copied. If it’s a reference - well, the memory address gets copied. But ultimately, CPU doesn’t care what it is! It’s just bits!

Let’s take a very simple example of passing both value & reference type to some function and then changing it:

valueVar = 42;

referenceVar = (42); // I added brackets to denote that it's a "reference" to 42 being stored elsewhere

changeVar(variable):
  variable = 88;

Can you blind-guess what happens with each of these? From point of view of CPU, it just copies whatever is inside the variable and it doesn’t care about WHAT it represents.

So, in case of valueVar, the bits that represent 42 get copied to another location on the Stack. And then those bits get updated to bits that represent 88. But did it affect the original “42”? Of course not - you changed the bits of the copy of the value!

In case of referenceVar, though, what gets passed to the function is the ADDRESS. Address where “42” is stored. And once you change it to 88, what you are effectively doing is storing “88” to the address where 42 was initially stored. As you can imagine, this effectively “overwrites” the value. But I think “overwrite” is a really shitty term. You are passing an ADDRESS, a WAYPOINT of a sort, and then saying to store something else to that ADDRESS. Whatever was there will be overwritten by new value. So you are not really “overwriting the variable”, but you are effectively changing the content of whatever is stored at the address that the variable holds. Simple! :)

Subscribe now

But, let’s for the sake of fun, say that you want to update the content of a referenceVar. So you don’t want to update the content at the address that referenceVar holds, but you rather want to update the variable itself. So, how do you do it? Well, turns out that that’s exactly what “ref” keyword in C# does - it passes the address of the referenceVar (i.e. a reference TO THE VARIABLE), so any changes to it would, effectively, overwrite the content of the variable itself.

Finally, let’s talk about Boxing and Unboxing. They are just ways to convert between Value and Reference types. And that’s actually pretty much it. Boxing a value type means - take the value from variable, store it somewhere on the heap, and store the address back to the variable, effectively making it “reference variable”. Unboxing is vice-versa - it takes the value from the heap, and stores its bits into a variable, effectively making it a “value type”.

Here’s a very simple C# code that shows that:

int valueVar = 42; // Value Type

object referenceVar = valueVar; // Boxes the "valueVar" by copying 42 to somewhere on the Heap, and then stores the address in referenceVar

int anotherValueVar = (int) referenceVar; // Does the exact opposite by "unboxing"

For the sheer fun of it, here’s the IL code for the code above:

IL_0000: nop
IL_0001: ldc.i4.s 42
IL_0003: stloc.0
IL_0004: ldloc.0
IL_0005: box [System.Runtime]System.Int32
IL_000a: stloc.1
IL_000b: ldloc.1
IL_000c: unbox.any [System.Runtime]System.Int32
IL_0011: stloc.2
IL_0012: ret

Finally, here’s an amusing piece of code to amuse you:

int fooBar = 42;

Console.WriteLine("Value is: {}", fooBar)

Can you guess why it has to box the fooBar before printing it? :)

Finally, again for the sheer fun of it, I asked ChatGPT to summarize Values and References as if I was a five years old, and here’s what came up as a result:

Okay, let's imagine you have a toy car, and you want to give it to your friend to play with.

Now, there are two ways you can do this:

1. You can give your friend the exact same toy car that you have. In this case, your friend has a copy of the car, but it's still a separate car from yours. This is like a "value type."

2. You can show your friend your toy car and say "Here, play with this car!" In this case, your friend is playing with the same car you have, because you're referring to the car that you already have. This is like a "reference type."

In programming, value types are like a copy of the toy car, while reference types are like the original toy car that you're referring to. When you use a value type, you're creating a new thing that's separate from the original thing. When you use a reference type, you're talking about the same thing that already exists.

Source: ChatGPT

And that’d be all for today. I hope you enjoyed it and if you did - do consider subscribing if you haven’t already :)

Subscribe now

Thanks for reading!

Other articles from the CLR series:

• Assembly's Shameless Metadata Marketing

• Managed vs Unmanaged Code - Part 1

• Managed vs Unmanaged Code - Part 2

• Common Language Infrastructure, Runtime, Type System and other C-s

• Where do Values and References live at?

I finally decided to move away from all the meta-topics and C-stuff. As promised, I’m going to start exploring the .NET memory allocation and common data types.

If you’re a newcomer, this is article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t seen any of the past articles - I’d recommend you start from beginning.

It’s really worth pointing out that if you’re not that familiar with Stacks and Heaps, I’d suggest reading this article to get a sense of it first. Additionally, you might benefit from going through the C++ and Memory Management series, which covers the basic concepts of memory works on a lower level.

As usual, the infographic goes first and then the more detailed text will be below:

For those in a real hurry, I guess it’s enough to remember that, when it comes to .NET and CLR, you really have two main data types - Values and References. Depending on who you ask, they might claim that “primitives” are a third type, but I’d just categorize them under Value Types. Value Types live on the Stack, and Reference Types are located on the Managed Heap. And, for those who want to continue with their day - that’s probably enough info.

For those eager to learn more - stay with me :) As we’ve discussed in the past articles, when it comes to Managed Code, it’s really the runtime engine (CLR) that determines where your data is stored. This is really interesting in comparison to C and C++, where you have the full control over the storage. As in, if you use the keyword “new” or “malloc”, your data will go to the (unmanaged) heap. On the other hand, if you just declare the variable, without “new” (or “malloc”), your data will be stored on the thread’s stack. So technically it’s up to you to decide where you want to place your data; and it’s also up to you to maintain the garbage left on the Heap.

In contrast, Managed Code has to manage the memory for you. And the language engineers seem to have thought that it’s a bit too much of a burden to bother you with, so they made a simple decision - any data type that inherits from System.ValueType (e.g. structs, enums, primitives like integers, floats, etc.) will be stored on the Stack. End of story. And this is probably something that would confuse a C++ engineer — the keyword “new” doesn’t allocate bits from the heap, but rather allocates the memory; on the stack; at least for Value Types.

When it comes to References, the story is different. Anything that is of “Reference” data type will ALWAYS go to the Heap. That includes Classes, Interfaces, Arrays, Strings, etc. Pretty much anything that could grow larger than couple of bytes is likely to go to Heap.

In a nutshell, and this is really amusing, when it comes to .NET and CLR - it’s the Data Type that determines where your data lives. And I think that’s just interesting :)

As usual, the devil really is in the details here. One with a sharp eye might notice and ask about Value Types inside Reference Types. For example - what happens with an Integer defined inside the Class? Does it live on the Stack or the Heap? And as you could imagine - answer is - obviously it lives on the Heap, because it’s part of the Reference Type. But these details and inner-workings is something that we will be discussing in more depth in future articles.

Subscribe now

Before I close this off, I want to make honorable mention of “box” and “unbox”, which are some common concepts that many have heard of, but not everyone is comfortable elaborating. I’m in that group, but I’ll try to give a short intro - boxing variables referes to the process of converting them from Value to Reference type; or, as you could imagine, moving them from Stack to Heap. Unboxing, on the other hand, is kind of an opposite operation - it takes the Value Type from the Heap and stores it on the Stack. But as I’ve learned, there are one too many people pointing out that there’s much more than that, and this is really something that I’ll be exploring and writing about over next articles.

Finally, one last remark - there’s much more to be said about Values and References. One of their properties is where they are stored, but as many have pointed out - this is really more of an implementation detail. Still, I find this to be a valuable information, but in the next article I will dig into what they really are supposed to be.

Thanks for reading!

Other articles from the CLR series:

• Asymmetric Cryptography, Public keys and Strongly-named assemblies

• Assembly's Shameless Metadata Marketing

• Managed vs Unmanaged Code - Part 1

• Managed vs Unmanaged Code - Part 2

• Common Language Infrastructure, Runtime, Type System and other C-s

Well, I think I finally have it nailed down, so let’s talk about it now.

If you are a newcomer, this article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t read any of the past articles - I’d recommend you start from the beginning.

I hope you found that useful? If not - well, at least I really felt relief once I managed to put all of it into an infographic. Woohoo!

Before jumping into the WHAT’s and HOW’s, let me just quickly summarize how we got here in the first place. It all started with the idea of exploring the CLR. Which, to tell you the truth, I was clueless that existed as a concept at all. I knew about C# and .NET, and I was aware it wasn’t compiled to native code, but that was all.

As luck would have it, my manager started talking about CLR and SQL Server, and how the two could be integrated (which, if you didn’t know, is this amazing thing that allows you to run your .NET code back-to-back with SQL Server’s Query Engine). This triggered me to go and learn what CLR is at all. And that’s how this whole series about “Deep dive into CLR” started.

Now here’s the funny thing - there doesn’t seem to be a clear info on anything about the CLR anywhere on Internet. Well, at least not clear enough for somebody whose just trying to learn about it. All the online docs make perfect sense if you know WHAT it is, but if you’re a newcomer - good luck :) So I kept reading about CLR (there’s this great book called “CLR via C#” by Jeffrey Richter) but I also kept finding references to CLR being implementation of CLI.

Thing is - I had no clue what the CLI is. And to make it even funnier - there’s also CIL, which stands for Common Intermediate Language. People might occasionally call it IL or MSIL - Intermediate Language and Microsoft’s Intermediate Language. Perfect for newcomers!

To cut the long story short - I kept searching for a diagram, or anything that would show me the connection between CLR, CLI, CIL, CTS, CLS, etc. But I found nothing. Nil. Void. Which eventually led me to the idea of creating one:

Now this honestly makes me happy because I can finally have a mental image of what is what and what is a subset of what, which is something I’ve been trying to figure out for a while. Let’s start from top and progress towards the bottom.

Common Language Infrastructure (CLI) is an openly available standard, commonly referred to as ECMA-335 standard. You can find it here. It’s a 500+ page long PDF which describes absolutely every possible thing you could imagine. And somebody told me that “first 100 pages should be a necessary read for every .NET developer”.

CLI describes the platform. The unique environment that makes it possible to execute multiple languages on. And yes, that means - C#, VB.NET, F#, Managed C++ (commonly called C++/CLI) and even Python (through IronPython), PHP (through PeachPie) and others. So CLI is a top-level idea which, among other things, defines the following:

1. The language, commonly called Common Intermediate Language (CIL), but occasionally referred to as Microsoft’s Intermediate Language (MSIL). I wrote extensively about it in this article.

2. Type System, commonly called Common Type System (CTS), which basically argues how you make some meaning out of your bits. It distinguishes two types of data - value types and references, and builds further from there. Any language that wants to conform to CLI has to take into account the CTS definitions.

3. VM itself, called Virtual Execution System (VES), which actually executes the Intermediate Language. Interestingly enough, CLR (Common Language Runtime) is just one implementation of VES.

4. And finally - Metadata, which is that thing that everybody loves, right? The data about the data; or the description of data. Meta data. It’s actually really cool and CLI defines TONS of parameters needed in order to give your data an actual meaning which VES further uses to execute your bytecode. It also, among other things, dictates how the CLI code can be injected into EXE files, making them executable just like it was a native code.

Reasonable question to ask would be — WHY? Why would anyone do this in the first place? And I find the actual definition from ECMA-335 PDF to be a perfect answer here:

The CTS is about integration between languages: using another language’s objects as if they were one’s own.

The objective of the CLI is to make it easier to write components and applications in any language. It does this by defining a standard set of types, by making all components fully selfdescribing, and by providing a high performance common execution environment. This ensures that all CLI-compliant system services and components will be accessible to all CLI-aware languages and tools. In addition, this simplifies deployment of components and applications that use them, all in a way that allows compilers and other tools to leverage the high performance execution environment. The CTS covers, at a high level, the concepts and interactions that make all of this possible.

I think that puts the intent just perfectly - make it possible to have multiple languages, that don’t even have to share the syntax, but which do conform to the same rules - rules of CLI. This way you can, say, write majority of code in C#, but write some specific expressions in F# and just reuse them back in C#. Given that it all compiles to same language, the problem simply boils down to the syntax itself :)

And that’d be about it for this article :) And to tell you the truth - this really takes a huge burden of my back as I’ve been really struggling to put all of this into a perspective. The fact that I finally did do it really makes me happy. And I hope you found it useful! :)

If you enjoyed this article - be mindful that I try to post twice a week. So if you haven’t subscribed already, now’d be a good time to do so:

Subscribe now

I’d also appreciate if you share it with your colleagues:

Share

Thanks for reading!

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

• Asymmetric Cryptography, Public keys and Strongly-named assemblies

• Assembly's Shameless Metadata Marketing

• Managed vs Unmanaged Code - Part 1

• Managed vs Unmanaged Code - Part 2

Last time I opened up a story on Managed and Unmanaged code and I mentioned that I believed it was a nice intro before jumping into Stacks and Heaps. I also mentioned that along the way I realized that what I thought was “Managed Code” was not in check with what it really was. This article is supposed to be the ultimate explanation and clarification on WHAT it really is.

If you are a newcomer, this article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t read any of the past articles - I’d recommend you start from the beginning.

As per usual, we go with infographic first and then we’ll discuss the inner details afterwards:

Okay, cool. I hope you found that useful :)

Here’s the deal - as I mentioned in previous article - I was under impression that “Managed Code” and “Managed Languages” refer to languages that have Garbage Collection. Then I learned it’s more than that - it refers to languages that have a “manager” that manages the stuff for you. But WHAT kind of stuff? And WHO is this manager? Too many questions started popping up to the point that I thought about giving up this whole idea altogether and skipping right to memory management itself.

Thankfully, I persisted. And I eventually learned that the term “Managed Code” got coined by Microsoft. And not just that, but I eventually started putting together the whole puzzle with Common Language Infrastructure (CLI), Common Intermediate Language (CIL), Common Language Runtime (CLR), Common Language Specification (CLS), Virtual Execution System (VES), etc. I won’t bother you much with it as there will be a separate dedicated article that will cover all of these. But I’ll just give you the essence that might be useful for the topic.

“Managed Code” refers to the code that compiles to something called “Intermediate Language”, which is just a fancy way of saying “a code that is not native machine code”. That’s what Intermediate Language is - a middle-man. And it’s officially called Common Intermediate Language (CIL; not to be confused with CLI).

To give you an example - C# code compiles to Intermediate Language. So does VB.NET. So does a version of C++ that is usually called C++/CLI or Managed C++. And I wrote a lot about Intermediate Language in previous articles, so do make sure to check them out if you’ve never seen how it looks like.

Subscribe now

But how does the code move from Intermediate Language to Native CPU instructions? This is yet another thing defined by Common Language Infrastructure - runtime engine. CLI defines a thing called Virtual Execution System (VES) which describes how you go from Intermediate Language to Native architecture where your program is executing. And this is where it becomes funny - CLR (Common Language Runtime) is JUST ONE of the concrete implementations of VES. But there are others as well! There’s Mono, there’s .net nanoFramework, and I guess there are others as well. But CLR is rather popular one because it’s what usually executes your .NET code :)

So let’s try and answer the “What is Managed Code?” question again - Managed Code is any code that conforms to Common Language Infrastructure standard and that compiles to Intermediate Language. After that, the runtime engine (e.g. CLR) takes over and ensures that your code converts into actual CPU instructions, which is a process known as JIT Compilation (Just-in-Time Compilation). But more about that in future!

By now I’m sure that you’ve figured that calling Java, or any other languge a “Managed one” is wrong? Unless you have a compiler that turns Java into Common Intermediate Language, then it’s not “Managed”. Simple as that, I guess? :)

And that pretty much concludes today’s story. I’m going to dedicate a separate article to the whole “CLI, CIL, CLR, CTS, CLS, VES, etc.” chaos, but until then, I hope this thing here gives you a bit of clarity :) Until then, if you haven’t subscribed already, now’s probably a good time to do so:

Subscribe now

I’d also appreciate if you share this article with your network:

Share

Thanks for reading!

Other articles from the CLR series:

• What is a .NET assembly?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

• Asymmetric Cryptography, Public keys and Strongly-named assemblies

• Assembly's Shameless Metadata Marketing

• Managed vs Unmanaged Code - Part 1

If you are a newcomer, this article is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t read any of the past articles - I’d recommend you start from the beginning.

I hope you enjoyed the infographic. But I have to disappoint you now - it’s incorrect :) Well, to be more precise - mostly incorrect. Ouch.

Here’s the deal - I used to think that Managed vs Unmanaged refers to the fact whether the language has Garbage Collector or not. Which kind of made sense and I’m sure at least some of you share these same beliefs.

Then I started investigating and looking around and I figured that it actually refers to MORE than the Garbage Collection. It refers to languages that have a “Manager” that takes care of your shit. Oh, did I say “shit”? I meant - resources. Logistics, as some would say. And in a way, it was true. Managed Languages DO have some kind of manager that manages stuff for you.

Subscribe now

Next, I started thinking about the proper analogy. Because one thing I love about my bitesized articles is that I always try coming up with a simple analogy that would engrave the concept in your brain. What came to mind was “singers”. They could be “freelancers” and manage all of their gigs on their own, or they could hire a manager to take care of their crap while they focus on their art. And the analogy made sense because you could point blank ask “so, what’s better?” and the answer would be the most disliked answer ever produced - “it depends”. And it really DOES depend. Being a freelance artist gives you a freedom, possibly more money, more control, etc. But it comes with some costs, right? You have to manage way more crap than someone with a dedicated manager. You could really bounce back & forth and I’m sure you could generate tons of pros & cons for both.

The analogy and this whole graphic made a lot of sense. But something didn’t really click. So, C# is managed language, VB.net is managed language, Java is managed language, Python, Ruby and PHP would likely fit under the “managed languages” umbrella as well. On the other hand - C and C++ are unmanaged languages. They give you a full access to memory and whatnot. Well, yeah, just like freelance artists - they allow you to do whatever the heck you want. It all fits. Almost.

Then I started producing some questions that I couldn’t really find a proper answer to - “is Rust a managed language”? “What about Go?”. The answers weren’t really clear to be honest.

I came around a Quora post that claims that “Unmanaged Languages” compile to Native code, whereas Managed ones compile to Bytecode. That makes sense. So that means that Rust and Go are also Unmanaged, right? Almost.

Rust, I guess you could say fits the “Unmanaged” category. It compiles to machine friendly bits, it doesn’t have garbage collection, you are allowed to do whatever the heck you want … it all fits. Perfect. But Go fucked me up :) Go, even though I never really used it, claims that it manages your resources for you. In a way. And it has Garbage Collector. But it also compiles to native code. What the actual fuck? What the fuck are you, Go? Are you Managed or Unmanaged for hell’s sake?

The fact that I couldn’t answer this question really meant one thing - I didn’t have a complete picture of what this all means. And like I said at the beginning - it was eating me alive. What’s more, I just couldn’t proceed with Bitesized Articles before I answered this question. I HAD TO answer this question.

I eventually came to learn that “Managed Code” was a term that was coined by no one else but my current employer - Microsoft :) The earliest reference I could find dates back to April 2003. Yes, that’s 20 years ago! And it was a reference that “explains” the idea behind the term, so I guess the term itself was coined even earlier. I’m guessing that it originated with the whole CLR and CLI thing, but I yet have to check this out.

Managed Code refers to the code that compiles to Common Intermediate Language (CIL), often referred to as Microsoft’s Intermediate Language (MSIL) or just Intermediate Language (IL). And yes, it’s that damn thing that I keep ranting about from the beginning of this series. Managed Code is a code that compiles to Intermediate Language and gets executed by Common Language Runtime (CLR). That’s it. That’s the whole point. Nothing to do with Garbage Collection or whatever. No. It’s all about Common Language Runtime (CLR) and Intermediate Language. And yes, that explains the meaning behind “Managed C++” - it’s C++ that compiles into Intermediate Language and can be executed by CLR.

What this further means is that the graphic from above is barely wrong :) It’s wrong because it missed the point of “Managed”. And that’s why I named this one “part 1”. In “Part 2” I will do the proper honors and explain this exactly as it is.

Until then, if you enjoyed this, you might also want to subscribe :)

Subscribe now

I’d also appreciate if you share this with your colleagues:

Share

Thanks a lot for reading!

Other articles from the CLR series:

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is a .NET assembly?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

• Asymmetric Cryptography, Public keys and Strongly-named assemblies

• Assembly's Shameless Metadata Marketing

It’s a new day and new opportunity to learn something interesting about .NET and CLR :)

For those just joining this train, This is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you haven’t seen any of the past articles - I’d recommend you start from the beginning.

NOTE: This article is a bit longer and might get cut off by your email client. I suggest opening it either in Substack app or in your web browser.

Today I want to talk about something that is deemed to be boring. Well hell, I myself avoided reading about it because I thought it’s boring as crap. And to tell you the truth - I was, in fact, right. It is boring as crap. Metadata. Metadata tables. Anything that has “meta” in it is usually something that you deal with only if you’re forced to, right? :) Nobody likes meta (no pun intended).

To tell you the truth - I never really planned on writing this article. Seriously. Because I didn’t care about it and I’m sure you don’t care either. But something changed. And what changed is that, all of a sudden, it all clicked in my head. FUCK. Holy FUCK. That Metadata thing … That metadata thing is actually REALLY COOL! Like FUCKING AWESOME. It’s like Assembly itself WANTS you to inspect it. Look into it. Explore it! Plus, it tells you ALL about its behavior, its constraints, its memory requirements … you name it and there’s likely a metadata about it! It’s a GOLD MINE if you want to learn stuff about DLL or EXE in front of you!

Before we jump into the details, let’s start with Infographic first and then I’ll share more:

A’ight, I hope that was a bit more amusing than a dry thought of Metadata? :)

Now before we embark on the journey of this post, I really want to emphasize that ILDASM.exe (Intermediate Language Disassembler) is really a tool that you want to have handy. It’s surely lying somewhere in your .NET folder so just go and search for it (btw, I use a tool called “Everything” which is this blazing fast indexer that just rocks):

Next, I want to look into MSCorLib.dll, which, from my very modest search, seems to stand for Microsoft Common Object Runtime Library (there’s some history behind WHY is that, and the WHY seems to be that before it was named .NET, it was meant as improvement of COM). MSCorLib.dll is a core runtime library for .NET and what I want to do is see what it’s Manifest can tell me about it:

That’s quite a biggie right there :) And what I actually find amusing is that, in certain scenarios, your DLL’s metadata overhead could be way bigger than the actual code that it contains :) DLL’s and EXEs are really chatty!

Subscribe now

So, in a nutshell, what are Metadata Tables? Well, just like with any meta data, their purpose is to DESCRIBE the Assembly (DLL or EXE; I guess I’m becoming boring by repeating this all the time?). And to tell you the truth, it’s not just meant for you, but it’s actually meant for CLR (Common Language Runtime - the runtime engine of .NET). It tells CLR which objects are inside, which are required to be imported, how much memory is needed, etc.

If you really stop and think about it - I guess there’s simply no other way to have an architecture-agnostic binaries without Metadata. Like, you either compile the binaries for specific architecture (e.g. Windows and x64) or you have some way of communicating HOW to go from “intermediate language” to a native CPU opcodes. And the latter is communicated by Metadata. I never checked it but I’d guess Java and it’s JVM works the same way.

So what I’m going to do now is paste some random excerpts of Metadata from the gigantic file I’ve shown you above. Then I’m going to discuss each of.

So what we see here are two TypeDefs, shorthand for Type Definition. As you could imagine, this means that these are these two types that exist inside this assembly - EmptyArray and FXAssembly.

Inside each of those TypeDefs, we see Fields and Methods, which I guess goes without saying that it represents the fields and methods inside those types.

“Flags” represent the info for JIT and CLR on how to interpret these Types and Methods. For example, “[Private]” flag above the “.cctor” method means that Constructor (.cctor is a shorthand for constructor) is Private.

There is a total of 2992 types defined inside this assembly and the last one is the one shown below:

Aside from TypeDefs, what we also see if we keep scrolling this gigantic piece of DLL, is the following:

Bunch of ModuleRefs (16 in total). As you could imagine, these are external assemblies that are needed in order for this assembly to function properly.

Then we have this:

Bunch of attributes about the assembly itself. Some of these you could actually override (e.g. Company Name, Version, etc.).

Then we have FIVE additional files that are inside this assembly:

If you remember the article on Assembly Manifest, I mentioned that you might have more than one file packed inside Assembly. In this case, there are five .nlp files which, to tell you the truth, I have no clue what they are :)

Finally, last one interesting to me was this one:

All the Strings that show up in your code will be stored under “User Strings” metadata table (btw, “L” stands for “Long” meaning that each character takes 2-bytes).

From my research, there appears to be around 40+ Metadata Tables, but sadly, the only resource where I could find this list was a “CLR via C#” book :/ I’m sure there’s a full list somewhere as part of CIL specification, but I haven’t found it yet. Once I do, I will update this article.

And there you have it :) I think knowing what your assembly holds is really valuable as you can do all kinds of cool stuff with it (e.g. analyze the dependency tree or ensure that code isn’t doing anything it’s not supposed to be doing).

This also marks the end of me talking about assemblies only (so far I dedicated past three articles on it; you can find them below). Next article will shift focus towards memory management, Stacks and Heaps and differences between Managed and Unmanaged languages.

Until then, if you haven’t already, I’d appreciate if you subscribe. I tend to publish these deep-dives at least twice a week and I make sure they are fun to read:

Subscribe now

You may also help this article reach wider audience by sharing it with your network (which I’d also appreciate!):

Share

Thanks for reading and see you next time!

Other articles from the CLR series:

• Asymmetric Cryptography, Public keys and Strongly-named assemblies

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is a .NET assembly?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

This is a continuation of my Deep-dive into CLR (i.e. .NET’s runtime) series. If you missed the previous article on Weakly and Strongly-named assemblies, I’d recommend checking that one first. If you haven’t seen any of the past articles - I’d recommend you start from beginning. Finally, if you’re here just for asymmetric cryptography - enjoy :)

Last time I mentioned that Strongly-named assemblies are ones that are digitally signed by the owner. I also promised to share more details on what that means at all. And this is what I want to do now :)

As usual - infographic goes first and more details below:

I hope that wasn’t too much to digest? If it is - please let me know and I’ll do more graphics to break this down even further.

The thing with asymmetric cryptography is that it might look spooky and confusing at first. And it most certainly felt so for me when I encountered it for the first time, some 5-6 years ago. But just like everything else - it’s REALLY simple. And I’ll make sure to explain it properly.

Let’s first start with symmetric cryptography. In symmetric crypto, what you have is ONE key (think of it as a password if you want) that can both LOCK and UNLOCK the data. It’s literally like a physical key - you can put the data into a box, lock it and whoever wants to unlock that box would need to have the exact same key. This also means that if your key gets stolen you’d have to change the whole lock. Some of the popular symmetric crypto algorithms are AES, DES, 3DES, etc. (do note that DES is now deemed insecure).

Generally speaking, symmetric cryptography and symmetric ciphers are great and really fast, but the problem is the distribution of the key. In order to use encrypted communication, you would first have to exchange the key with the party you are trying to talk to, but how do you do that over an insecure network, like Internet? Hint: you don’t.

This is something that Asymmetric Cryptography aims to solve. Instead of having ONE key that you’d have to exchange, somebody came up with an awesome idea - why not have TWO keys? They’d work in pairs (i.e. one wouldn’t make sense without the other) but one would have to be kept Private and another one should be publicly shared (e.g. you can put it in your email signature). They were named Private and Public keys respectively.

So the way it works is really simple. Think of it as having a lock that can be locked with ANY of the two (either private or public key) but in order to be unlocked - the OTHER key has to be used; using the same key to unlock wouldn’t work. And if you think that’s impossible - I have some good news for you - it most certainly is!

Let’s say you have two parties that want to communicate - Joe and Maria. Furthermore, they want to ensure that their communication is secure. How do they do that?

Simple! If Joe wants to talk to Maria, he’d just ask her for her public key. Given that the whole purpose of it is to be public, Maria can freely send it to anyone, including Joe. Now that Joe has Maria’s public key, he uses it to encrypt the message that he wants to send. And here’s the interesting thing — once you lock the message with Public key, the only way to unlock it is by using, you guessed it - the Private Key! So Joe is free to send the encrypted message over Internet because nobody except Maria will be able to decrypt it! It’s just beautiful! And if Maria were to contact the Joe, she’d take his Public key, encrypt the message and send it over insecure network.

Now the real beauty of this all happens once you reverse the process. Imagine you have a piece of information that can be unlocked with somebody’s Public key. What does that tell you? It tells you that whoever encrypted it - has the Private key :) Meaning that the only person who could have created and encrypted that is the owner of the Private Key. So this effectively means that by encrypting anything with your Private key is a very simple way of claiming ownership and identity.

For example, if I wanted to claim that email was sent by myself, and if I were to give you a way to confirm that, what I’d do is write an email, encrypt it with my private key and publish it on internet. Anyone can now take my public key, decrypt the email and confirm that, indeed, it was made by myself, because no one else has my Private key.

This exact process is how Digital Signatures work. What you do is you create something (e.g. a DLL file), and then you encrypt piece of it (usually the hash value of the file’s content) and store it alongside the DLL. You also want to pack your public key so that anyone can confirm the ownership, but it’d be totally valid as well to ask them to find your public key on a reputable source (e.g. your Website) and use that to confirm the ownership.

Consumers of your DLL can then calculate the hash value of that same file, and then use your public key to decrypt your signature and compare the two. If the current hash version matches the one that you digitally signed - file is genuine. If there’s a mismatch - file is not genuine.

And that’s really about it :) As I said - it’s really simple and I think it’s just beautiful; honestly. And hopefully it wraps up the story on why Strong-named assemblies contain the public key alongside them.

Anyway, in future articles I’ll slowly move my focus from assemblies towards Stacks and Heaps in .NET and CLR, with a special focus on Boxing & Unboxing. And if you havent’t subscribed already, now might be a good time to do so :)

Subscribe now

Thanks for reading!

Other articles from the CLR series:

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is a .NET assembly?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

It’s Saturday and what a better way to spend 3 mins of your weekend than by refreshing your knowledge on DB’s Transaction Isolation Levels, right? RIGHT? 🤓

I know, I know, who cares about that? It’s a boring and hard-to-grasp topic. And you have your fancy ORM that does it for you anyway … Which all makes sense until you learn that there are some weird scenarios like “Lost Updates” and “Dirty Reads”. Ouch!

“Well, no problem”, you say, “I’ll just tighten my Transaction Isolation Level. I don’t even need to understand how that works, because the higher the better”. And that’s true - higher isolation level is better; until you see the performance hit :)

Here’s what I want to do - I want to give you a frame in which to think about DB Transaction Isolation levels, but through lens of something that you can easily remember. Through the lens of Building a Snowman :)

As usual, we go with infographic first and then with more detailed text.

I hope that was amusing enough :) Because, Isolation levels are actually really cool concepts to grasp. They do have their own set of intricacies, but, for starters, you should at least be aware on what they are.

Before I give you more context, I just want to let you know of the results of my 15-sec google search on Default Isolation levels in each DB:

1. MySQL - REPEATABLE READ

2. PostgreSQL - READ COMMITTED

3. SQL Server - READ COMMITTED

4. Oracle - READ COMMITTED

I want to emphasize that I literally did a 5-sec search for each and this is what came as a result. As usual, your mileage on your production database may vary, so do make sure to check it out.

So what is this all about? Well, it’s really simple - Transaction Isolation Levels are all about what happens when multiple users are trying to read & write data from the same row. That’s concurrency. It tries to answer the question of “what will happen and how do I resolve the conflicts”. You can also think of it as two users trying to edit the same Excel row at the same time. That’d be concurrency as well.

Subscribe now

And here’s what happens under each level:

1. Under READ UNCOMMITTED, everything is fully transparent and everybody sees everything. If one user starts a transaction and starts editing the data, all other users will see all their changes even though they weren’t committed. This is great in cases where you know that concurrency is highly unlikely to happen (e.g. you have single writer and multiple readers or whatever).
   
   The problem would arise if user reads something that another user decides to roll back. We call this scenario a “dirty read” and depending on the context, consequences could range from “meh” to “well, we’re in deep shit now”.

2. Under READ COMMITTED, database ensures that you see only the data that has been committed to DB. This is actually pretty good for most scenarios, except, and this is amusing - except if you wanted to ensure that you don’t see different data within a same transaction.
   
   It’s a hard to grasp scenario so I’ll give you an example - long-running analytics query; or a machine learning thingy, whatever. Under READ COMMITTED, you would see some data that has been written to DB. All good. But imagine if your transaction was a long-running one (e.g. it lasts for several minutes). What could happen is that somebody modifies the data AGAIN, and if you re-read this you’d see a different value. This problem of possibly seeing DIFFERENT data under two SELECT statements in a single transaction is something that is not ideal for all scenarios. And that’s what gets solved with REPEATABLE READ.

3. Under REPEATABLE READ your transaction is guaranteed to see the EXACT SAME data all the time, for as long as transaction takes. Even if data changes in the meantime, you are still guaranteed that, in a single long-running transaction, you keep seeing the exact same values.
   
   Frankly speaking, this is probably OK for 99% of the scenarios. Those 1% of cases would be if you want to ensure that no new data is added or removed while your transaction is running (e.g. think if your query depends on the exact number of rows). For such cases, you want to go with Seralizable Level.

4. Under SERIALIZABLE level, DB ensures that concurrent transactions are executed serially (i.e. one after another). Think of it as physically locking the database while you are doing stuff in it. It’s super-slow because there’s no concurrency, but it’s effective if you need to ensure data is exactly the same.

And that would be it, really :) As you can see - it’s not that hard, right? READ COMMITTED would serve most of the use-cases, but if you need to level-up the game - you can always upgrade to REPEATABLE read.

Finally, based on your use-case, you could also consider DOWNGRADING the isolation level. For example, if you are 100% sure that two transactions would never touch the same row, or that they’d operate on different columns - you can always consider easing the isolation and effectively improving the performance :)

Hope you enjoyed this article! If you did, I’d appreciate if you share it with others as well :)

Share

You can also subscribe if you haven’t already :) I publish at least twice a week, but usually way more often:

Subscribe now

Thanks for reading!

You know what’s interesting? I initially created THREE infographics on this topic, and that’s because I figured there’s a lot to unfuddle here. But as luck would have it, I didn’t have that much time to wrap them up, so I let them air-dry for couple of days.

Well, during this morning’s shower (yes, most of these are ‘created’ during the shower-time), the thought hit me — why the heck would anyone want to read THREE graphics on Strongly-named assemblies? It can and should be compressed in a single one, and if anyone wants to explore more than that - they’ll be equipped with knowledge to do so.

So yeah, lo and behold, I bring you - ONE image :) And as usual - the graphic goes first and then more details will follow:

Alright, cool! I hope that gave you an idea?

You know, in my opinion, Strongly-named is just a mouthful for a very simple concept - a file that is (digitally) signed. And yeah, Weakly-named is not an official name, but I “stole” it from CLR via C# (amazing book, btw!).

So wbat’s the whole deal? Well the deal is really simple - anyone could make a malicious assembly, fill it up with bunch of malware, name it System.dll and find a way to store it in a shared location on your system where .NET runtime would pick it up. Well, anyone could have been able to do this IF there was no way to verify whether the DLL is legit. And luckily - there is such way. And that way is something which has been fairly known for a while now - Digital Signing.

Let’s for a moment assume that you are Microsoft and you want to ship a new version of System.dll. I want to emphasize that, even though I currently am employed by Microsoft, my day to day job has NOTHING to do with .NET framework development. I work in Azure SQL MI. This scenario is 100% made up in my head in order to showcase a theoretical process:

1. First things first —> I’d update the code with whatever I wanted to do in System.dll and I’d build a new version of it. At this point I have a “weakly-named” assembly - it’s just a DLL without any info on the identity and ownership that could be validated.

2. Next, I’d take all the bytes that make up my DLL and run them through SHA256 hashing algorithm. You can think of it as hash = SHA256(file_content).

3. Now that I have a fixed-size hash (hashes ALWAYS produce fixed-sized output, no matter how big the input is), next thing I do is take a Private Key that only couple of Key keepers in Microsoft have access to. It’s named “private” for a reason - access to it is severly restricted. What I do is I encrypt the file’s hash with this private key. Think of it as doing ENCRYPT(file_content_hash, private_key).

4. The output of previous operation is what is called a DIGITAL SIGNATURE - it’s a hash of my file’s content, encrypted with the key that only I know about. Next, I add this digital signature to the assembly as well.

5. Finally, I add Microsoft’s PUBLIC KEY alongside this signature as well. Public Key is public for a reason - anybody can have it!

6. At this point, I embedded the digital signature and public key, and alongside other info in this file (name of assembly, version, culture, etc.) this makes the assembly STRONGLY-Named, meaning - anybody can verify that this was really created by Microsoft.

But logical question to ask is - but HOW can anybody verify it? And the answer is simple - by using Public Key.

The thing is, if you don’t know how Private/Public key crypto works, this all sounds like bunch of complicated crap. Let me assure you that it’s REALLY SIMPLE and I’ll spend the whole next article explaining this topic.

For now, think of it this way - you have Private and Public key. Former you must keep super-secret, and latter you can print on your wall if you want. But here’s the trick - whatever you ENCODE with Private Key, can only be DECODED with Public Key! You CAN NOT decode with Private Key. It works in one-way only!

Same is true for Public Key - if you encode something with Public Key, the only way to decrypt it is by using the matching Private Key :) It’s beauty of the math at it’s finest.

Subscribe now

So what this all means is that, if you want to verify genuiness of the System.dll, you’d take the file’s bytes, run them through SHA256 hashing algorithm and then take the digital signature (which, if you remember, is a Digital Signature that was encoded with Microsoft’s Private Key), decode it with the public key that is embedded in the assembly, and compare the two. If the hashes are IDENTICAL - then file is genuine and hasn’t been tampered with. If there is a mismatch - file has been tempered with!

In terms of pseudo-code, that would be:

# On Microsoft side

SIGNATURE = ENCRYPT(SHA256(FILE_CONTENT), PRIVATE_KEY)
EMBED(SIGNATURE in DLL)
EMBED(PUBLIC_KEY in DLL)

# On Client side

FILE_HASH = SHA256(FILE_CONTENT)
ORIGINAL_HASH = DECODE(SIGNATURE, PUBLIC_KEY)

IF FILE_HASH == ORIGINAL_HASH : file is Genuine

But how do you know if public key is genuine, right? Well that’s where Certificate Authorities come into play. They are middle-man’s, trusted by everyone, whose only job is to stay safe and make guarantees about who owns which public key. But that’s a story for the next time. For now just take my word that there is a simple way to validate if Public Key belongs to Microsoft, and that is done by asking the “Trusted Authority”.

Long story made short - combo of these four (Assembly Name, Version, Culture, Public Key) is what uniquely identifies assembly and makes it a Strong-named one. Strong-named as in - it can be UNIQUELY identified. Remove the public key from equation and you have a weakly named assembly.

Last but not least - GAC. As you likely now, Global Assembly Cache (GAC) is a place where you store DLLs that you want to share. And that’s where all .NET’s DLLs reside. You can, of course, add your own assemblies there, but there’s a hard requirement that any assembly going into GAC must be strongly-named. This makes sense because GAC has the HIGHEST priority when CLR starts searching for assembly to load. If assembly is in GAC - everything else will be ignored and this is by design.

And that’s about it for today :) Next time I’m going to talk a bit about Cryptography and Private/Public keys and how they work. After that I’m likely moving either towards Assembly Metadata Tables (incredibly cool topic btw!) or towards the Stacks and Heaps in .NET. Until then, if you haven’t already, do consider subscribing as there’s lot more cool stuff to come!

Thanks for reading!

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is a .NET assembly?

• What is Assembly's Manifest?

Last time I covered what assemblies are, and today I want to focus on one of the most important pieces that every assembly has - the Manifest file. And before you brush it off with “blah, who the heck cares about ‘Manifests’”, trust me - they can tell you A LOT. You may not need them right now, but not knowing what’s inside will severely limit what you are able to do with CLR. So, take my word and READ through this article.

As usual, we go with infographic first and then with the more detailed explanation:

I hope that was easy to digest?

First and foremost - Manifests are NOT unique to .NET. Not at all. You can find them in C++, Java, Rust, Ships and Airplanes carrying cargo, etc. They are EVERYWHERE. Hell, there’s even an Agile Manifesto.

Manifest is a summary of what’s “inside”. What is being “carried”. It can be a ship, a train, a JAR or a DLL, and Manifest’s job is to give a quick summary over it. In terms of CLR, think of it as “just reading the Manifest” instead of going through each line of code stored inside.

Subscribe now

Speaking of .NET Assemblies in particular, Manifest is required to contain the following information:

• Identity of the Assembly — what is the name of it, who created it, which version is it, etc. Additionally, if it’s a strong-named one (and we cover what this is in the next article!), there will be a way to confirm the identity of it.

• Content inside the Assembly — remember the previous article where I said that assembly can contain one or more files? Well, Manifest tells you WHAT are the files packed inside.

• External references — if you wrote a program that uses Console.Writeline, you’d be relying on existence of System.Console namespace, which is part of System.Console.dll assembly. This would be your external reference.

Now instead of bullshitting too much and given the fact that you could find all this info online anyway, let me give you some actual meat. I’ll use our friend ILDASM.exe (Intermediate Language Dissasembler) to peak into Manifest of System.Console.dll:

There’s a lot of content in there, and instead of pasting the images, I will paste parts of the text and then describe what each of them is:

.module extern kernel32.dll
.module extern user32.dll

These two are the native libraries (i.e. non-CLR DLL’s) that assembly requires. They are part of Windows API so feel free to google them if you want to get deeper understanding.

.assembly extern System.Runtime
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 7:0:0:0
}
.assembly extern System.Runtime.InteropServices
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 7:0:0:0
}
.assembly extern System.Threading
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 7:0:0:0
}
.assembly extern System.Memory
{
  .publickeytoken = (CC 7B 13 FF CD 2D DD 51 )                         // .{...-.Q
  .ver 7:0:0:0
}
.assembly extern System.Text.Encoding.Extensions
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 7:0:0:0
}

These are all the EXTERNAL REFERENCES — assemblies that this assembly requires to be loaded in order to function properly. What you see along with names are the public key tokens and versions for each. Version is probably obvious (i.e. it’s the version of assembly that is required), but if you are not familiar with Public Keys - don’t worry, it will be more clear in the next article. In short - it’s part of something called “Strong-named assemblies” and this Public Key token is a sort of fingerprint that identifies them.

.assembly System.Console
{
  .custom instance void [System.Runtime]System.Runtime.CompilerServices.ExtensionAttribute::.ctor() = ( 01 00 00 00 ) 
  .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32) = ( 01 00 08 00 00 00 00 00 ) 
  .custom instance void [System.Runtime]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::.ctor() = ( 01 00 01 00 54 02 16 57 72 61 70 4E 6F 6E 45 78   // ....T..WrapNonEx
                                                                                                                   63 65 70 74 69 6F 6E 54 68 72 6F 77 73 01 )       // ceptionThrows.

  // --- The following custom attribute is added automatically, do not uncomment -------
  //  .custom instance void [System.Runtime]System.Diagnostics.DebuggableAttribute::.ctor(valuetype [System.Runtime]System.Diagnostics.DebuggableAttribute/DebuggingModes) = ( 01 00 02 00 00 00 00 00 ) 

  .custom instance void [System.Runtime]System.Runtime.CompilerServices.DisableRuntimeMarshallingAttribute::.ctor() = ( 01 00 00 00 ) 
  .custom instance void [System.Runtime]System.Runtime.Versioning.TargetFrameworkAttribute::.ctor(string) = ( 01 00 18 2E 4E 45 54 43 6F 72 65 41 70 70 2C 56   // ....NETCoreApp,V
                                                                                                              65 72 73 69 6F 6E 3D 76 37 2E 30 01 00 54 0E 14   // ersion=v7.0..T..
                                                                                                              46 72 61 6D 65 77 6F 72 6B 44 69 73 70 6C 61 79   // FrameworkDisplay
                                                                                                              4E 61 6D 65 08 2E 4E 45 54 20 37 2E 30 )          // Name..NET 7.0
  .custom instance void [System.Runtime]System.Reflection.AssemblyMetadataAttribute::.ctor(string,
                                                                                           string) = ( 01 00 15 2E 4E 45 54 46 72 61 6D 65 77 6F 72 6B   // ....NETFramework

 //
 // etc.
 //

  .publickey = (00 24 00 00 04 80 00 00 94 00 00 00 06 02 00 00   // .$..............
                00 24 00 00 52 53 41 31 00 04 00 00 01 00 01 00   // .$..RSA1........
                07 D1 FA 57 C4 AE D9 F0 A3 2E 84 AA 0F AE FD 0D   // ...W............
                E9 E8 FD 6A EC 8F 87 FB 03 76 6C 83 4C 99 92 1E   // ...j.....vl.L...
                B2 3B E7 9A D9 D5 DC C1 DD 9A D2 36 13 21 02 90   // .;.........6.!..
                0B 72 3C F9 80 95 7F C4 E1 77 10 8F C6 07 77 4F   // .r<......w....wO
                29 E8 32 0E 92 EA 05 EC E4 E8 21 C0 A5 EF E8 F1   // ).2.......!.....
                64 5C 4C 0C 93 C1 AB 99 28 5D 62 2C AA 65 2C 1D   // d\L.....(]b,.e,.
                FA D6 3D 74 5D 6F 2D E5 F1 7E 5E AF 0F C4 96 3D   // ..=t]o-..~^....=
                26 1C 8A 12 43 65 18 20 6D C0 93 34 4D 5A D2 93 ) // &...Ce. m..4MZ..
  .hash algorithm 0x00008004
  .ver 7:0:0:0
}

These are the Attributes of our assembly (System.Console.dll) which represent various Metadata ranging from which Company published them (Microsoft) all the way to some Attributes that I have no faintest idea what they are. You can always google each one of them to see what’s their purpose. Some of these attributes are also visible when you click on Properties of the DLL:

Also, “publickey” part is, like I said above, part of something called Strong-named assemblies, and Public Key is something you can use to confirm the identity. Again, no worries if you’re not familiar, it will become much more clear in the next article!

.mresource public FxResources.System.Console.SR.resources
{
  // Offset: 0x00000000 Length: 0x00001ABF
}
.mresource public ILLink.Substitutions.xml
{
  // Offset: 0x00001AC3 Length: 0x000001F4
}

These two appear to be two resources that have been embedded inside the Assembly as well, but I have no clue what they are used for. What you see for each are exact coordinates of where they start and where they end.

.module System.Console.dll
// MVID: {BA4D167A-DE2E-4B21-827E-BAF8C9B71D53}
.custom instance void System.Runtime.CompilerServices.RefSafetyRulesAttribute::.ctor(int32) = ( 01 00 0B 00 00 00 00 00 ) 
.custom instance void System.Runtime.CompilerServices.NullablePublicOnlyAttribute::.ctor(bool) = ( 01 00 00 00 00 ) 
.custom instance void [System.Runtime]System.Runtime.CompilerServices.SkipLocalsInitAttribute::.ctor() = ( 01 00 00 00 ) 
.imagebase 0x00400000
.file alignment 0x00001000
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x0000000c    //  IL_LIBRARY
// Image base: 0x0000020072620000

.module defines which modules exist in this Manifest, .imagebase I presume is the offset where the CLR code starts, .file alignment I have no faintest idea what it does, .stackreserve is the size of the Stack that your assembly will get (this can be controlled with /STACK linker option) and for the rest I was just too lazy to look up what it is.

So what you’ve seen so far is a complete deep-dive into contents of an actual Manifest - Manifest of a System.Console.dll, which is an assembly that contains Console.Writeline command.

For reference sake, here’s an assembly of a C# app that contains a single Console.Writeline(“Hello world”):

All in all, I hope that Manifests are a bit more clear now. Their main purpose is to communicate who they are, what’s inside and what they need. There’s another interesting piece of info that is being stored in Assemblies, called Metadata Tables. They go into even more depth, and define pretty much every single parameter, class, method and variable that exists inside CLR. But that will be a topic for another time!

Next time I will be talking about Strong-named Assemblies. Until then, if you haven’t already, now’d be a good time to subscribe :)

Subscribe now

Thanks for reading!

Other articles in this series:

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is a .NET assembly?

• Weakly and Strongly-named Assemblies

Before you mention it - you are right. This is a bit of a non-standard article. From time to time I like sharing some interesting facts that I spend a lot of time thinking about. And this is one of those :)

Let me share the infographic first and then I’ll add some more context:

First and foremost - these are NOT some random tips that I picked up from internet. Nope. These are LITERALLY my first-hand experiences and I’ll elaborate on each one.

Before I do, I have to mention that almost a year ago, I wrote an article titled How I learned to read (and read 30 books in a year). In a nutshell, I went from not reading a single book in my life to being an avid reader, and that article shares a lot of my personal details.

This one is more or less the summary of it :)

Subscribe now

So, let’s discuss each of the points:

1. Read more than one book at a time - this one was a literal game changer for me. Honestly. I remember being stuck for months reading Crime & Punishment, not wanting to start anything new before I finished that one and yet even by thinking of it was making me want to rip my eyes off.
   
   The thing is that you really need to read whatever you feel like reading at the moment. Just like your moods will vary, so should the book that you are reading.
   
   My advice is to have at least two to three books, ideally of completely different genre, and just pick the one you feel like reading the most.

2. Skim through books to get a sense of what’s inside - this is actually true for anything; especially when learning stuff. Khan Academy openly tells you to ALWAYS skim through lesson first, then do a quick read and then do a focused one. Same should be true for books.
   
   Feel free to jump back & forth. Check what’s coming. Go back to what you missed. You are not obliged to read in a linear fashion!

3. Give it 15-20 minutes to get you engaged - and you might think that this is too short, but the thing is - we usually don’t start reading because we know we won’t have much time, while on the other hand we refuse to spend 15-20mins because it sounds too short, so what we end up is a freaking limbo sauce where we keep questioning but never deciding to take a course of action.
   
   My advice - give book some short time to get you curious and if it fails to deliver it - forget it and move on.

4. Drop the book you’re not enjoying - this is probably one of the best advices I ever read. You DO NOT have to finish every book; doubly so the ones you are bored with.
   
   I mean, you are likely skimming through this article, right? Imagine if you had to read every single blog post from cover to cover? That’d leave you with zero time to actually explore and find stuff that you DO enjoy!

5. Find genre that fits you - this is probably one of the most important advices. Explore and read variety of stuff until you find something that interests you. And once you do find it - feel free to exhaust the hell out of it!
   
   One advice I heard some time ago was “find a writer that you like and read everything from them. And once you read everything, see what they liked and go and read that”.

6. Take it slow - seriously. It’s ok to skip a day. Or a week. Reading should be fun and not a forced activity. Hell, there are days where I spend 3 minutes reading and that’s it. And yet there are days where I can’t stop thinking about that damn thing I read within 3 minutes so I spend hours exploring. Just go with the flow.

7. Take notes while reading - and this is something that I struggled with. I clearly remember trying to read Game of Thrones and getting completely destroyed by sheer amount of characters and connections between them. But what I used to think is that having to write stuff down makes you dumb and that it’s not the “right way” to read.
   
   Forget all the bullshit - take notes. Open excel. Draw charts if needed. There are tons of sites that actually give you great summaries of characters appearing in the book. Use them!

8. It’s OK to re-read the same book - and not only is it OK but it’s actually a great thing. Books are PACKED with details and there’s simply NO WAY to gather all of them in one go.
   
   There are some books I read three times so far and I’m absolutely planning to read them 10 more times for sure :)

And that’d be about it! I’d be more than happy to hear your experiences!

P.S. Next article will be continuation of the Deep-dive into CLR series and will discuss Assembly’s Manifest file and what it is.

Until then!

Today I’d like to talk about one of the basic ingredients of CLR (and .NET) - the Assemblies. As usual, the infographic goes first, followed by more detailed explanaten below.

I hope that was understandable :)

As you can see - at it’s most fundamental level, assemblies are a way of packaging and distributing code. I say “at most fundamental level” because there’s a lot more going on there, but we’ll cover that when the time comes. For now, you can think of them as archives that pack one or more files inside; it’s like a .tar, in a way.

One thing you can find inside the assembly, aside from the actual code itself, is Assembly Manifest. And if you stop and think about it, you soon realize that if you have one giant blob of ones and zeroes, and those ones and zeros belong to different files - how do you know what is what? And how do you even know if the assembly is safe to use? Or who created it? Or what the version is? Too many question that beg for an answer. And the answer is simple - Manifest.

I’ll expand lot more on Manifest and what’s inside as part of the next article, but for now just keep in mind that it’s like an Identity Card for your assembly. It provides info on WHO created it, WHICH version of the assembly is it, WHAT are the external dependencies that assembly has and what are the files that are INSIDE the assembly. That’s about it in a nutshell.

Let me show you how to look into your assemblies. Because talking is cool, but seeing it in action makes all the difference in the world. First and foremost, locate your ILDASM.exe (the MS IL Dissasembler). It comes with .NET installation so you should have it somewhere around.

Let’s look into the assembly that gets produced as a result of this simple code:

using System;

namespace CsharpDllLibrary1
{
    public class Class1
    {
        private readonly Int32 x;

        public Class1(int x) 
        { 
            this.x = x;
        }

        public int GetOne()
        {
            return 1;
        }        
    }
}

ildasm.exe CsharpDllLibrary1.dll

That’s cool, right? As you can see - there’s a Manifest, and then there’s my library namespace with a single class inside. Cool!

If you open the Manifest, you’ll see something like this:

That's a lot to digest if you’ve never encountered it. But what you see in the Manifest is basically the Table of Contents (i.e. what’s inside) plus the Identity Information (which is missing btw but more about it later on).

And if we sneak peak into GetOne() method, you will see something like this:

So in a nutshell, what’s inside the assembly is Manifest, CLR code and optional resources (which I’ll leave for some other time). I’d actually encourage you to locate ILDASM.exe on your computer, find a DLL (or EXE) that was built using some .NET language, and explore what’s inside. You will learn the most by actually doing it.

Another thing that’s interesting to mention is - how does Windows know whether the EXE or DLL contains native code? And the answer lies in - based on the header information. To be valid, EXEs and DLLs have to conform to the Portable Executable (PE) format (and I’ll write more about it as well!) and what CLR does is that it stores info inside that header that the code that follows should be run through the CLR. But again, don’t sweat over it, I’ll cover this in a separate article.

Finally, in the graphic above, I made honorable mention of Global Assembly Cache (GAC). That’s a very fancy name for a folder that holds commonly shared DLLs (e.g. .NET framework’s DLLs). GAC is one of the folders where CLR runtime looks for assemblies if they can’t be located in your program’s local folder. But there’s a trick to it - for assembly to be elligible to be inside GAC folder, it has to be Strong-named. Strong-named is yet another fancy word for a very simple thing - digitally signed file, whose identity you can verify.

If you’re not familiar with digital signing of content, well, it’s really a cool way of claiming ownership of stuff using Private/Public keys. Owner of assembly “signs” the file (think of it as placing a seal on it) with their Private key, and they provide a (public) key which can only break the seal signed with owner’s private key. It can be a bit mind-boggling but for now just think of it as a very simple & efficient way to confirm ownership of the assembly.

And that would be all I had to share for today! If you enjoyed this content, do consider subscribing. In the next few articles I will talk more about Manifest and Strong-named assemblies before moving on to discuss the Memory Management features of CLR.

Subscribe now

Thanks for reading!

Other articles in this series:

• What is Common Language Runtime (CLR) and why should I learn about it?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

If you’re an old subscriber, you likely know that I’ve published 17 infographics on C++ and Memory Management. This actually took me some 40+ (or maybe even 50+) hours to complete but I really had tremendous fun while doing it :)

If you are a newcomer, well, I created bunch of infographics and they look similar to this one:

What I want to do now is create one mega-article that will link all the articles (and infographics) that I’ve published in this series. Each one contains a high-quality image and an extended description. You can also find a print-quality PDF here.

As far as I'm concerned, you are free to use them in any way you want - download, print, copy, distribute, … do whatever you like as long as you keep my credentials on the bottom :)

Table of contents:

(Note: I suggest bookmarking this page)

• C++ and Data Types

• Where are my program’s bits?

• Stacks, Heaps and other funny places

• What is a Stack, really?

• Why is Stack (much) faster than the heap?

• Stack attack

• The magic of keyword “new”

• Heaps and Stacks - explained like you're five

• Why does Memory Leak?

• Pointers & References - our school day boogeymans

• How Windows allocates memory

• Memory allocation through Heap API

• Virtual Adressing and Why every process sees the same memory space

• Virtual Memory API and all the cool stuff you can do with it

• Memory Allocation Functions - a primer

• RAII and Smart Pointers - smarter way to work with your memory

P.S. Check out other series that I’ve covered:

• (Windows) Containers, for People in a Hurry

• SQL Server’s Storage Engine Internals

• Deep-dive into DB Indexes

• Deep-dive into CLR (in progress)

I’ve been talking about it for a while now. Given that the last article on C++ and memory allocation went out yesterday, it’s time to start a new chapter and new deep-dive series.

Before I do, I’d like to take a moment and reflect on one thing. And this is something that has been hanging over my head for a while now. If you are just casually scrolling through Bitesized articles, you’d probably think something along the lines of “wow, this guy makes context switches like it’s nothing!”. In a way, you’d be right - I started writing about SQL Server’s Storage Engine Internals, then switched to Containers, then spent some months on DB Indexes, before finally moving to C++ and Memory Allocation. Wanna know how that works and feels?

It sucks. And it scares the shit out of me. Honestly. It is exciting, for sure, because I get to explore cool new things that I’m really interested in, but trust me - it’s scary! Starting ANYTHING new is always scary.

But here’s the gist - I learned that after two or three articles it becomes a breeze and then it just starts flowing. Really. So I just need to survive to break the ice of the new topic and then I’m sure it will get easier :)

Anyway, I just wanted to share those thoughts with you. Back to the original topic - CLR. As usual, the infographic first and then we go with some more detailed explanation!

I hope you found that useful :)

Let’s start from the beginning - do you need to know about CLR in order to use C# (or any other .NET based language)? No.

So why SHOULD YOU spend time on it? In my opinion - for the same reason you decide to learn anything - once you understand the internals, you get a whole new perspective on how to write more performant and reliable code.

Back to the topic, though. So, what’s the Common Language Runtime (CLR )? Well, it’s the Runtime Engine for .NET. Just like JVM is for Java. It makes your .NET code actually DO stuff. But there’s a lot more to it.

All your .NET code compiles into something that is, these days, referred to as Microsoft’s Intermediate Language (MSIL). Here’s a very simple app:

namespace SampleCSharpApp2
{
    internal class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, World!");
        }
    }
}

And here’s the MSIL code that was generated for it (hint: .NET bundles an app called ILDASM.exe - an IL Dissasembler; search for it in your .NET directory):

.class private auto ansi beforefieldinit Program
       extends [System.Runtime]System.Object
{
  .custom instance void [System.Runtime]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )
  .method private hidebysig static void  '<Main>$'(string[] args) cil managed
  {
    .entrypoint
    // Code size       12 (0xc)
    .maxstack  8
    IL_0000:  ldstr      "Hello, World!"
    IL_0005:  call       void [System.Console]System.Console::WriteLine(string)
    IL_000a:  nop
    IL_000b:  ret
  } // end of method Program::'<Main>$'

  .method public hidebysig specialname rtspecialname
          instance void  .ctor() cil managed
  {
    // Code size       8 (0x8)
    .maxstack  8
    IL_0000:  ldarg.0
    IL_0001:  call       instance void [System.Runtime]System.Object::.ctor()
    IL_0006:  nop
    IL_0007:  ret
  } // end of method Program::.ctor

} // end of class Program

If you’ve never encountered it before - that’s OK. It might take a moment or two to get adjusted to it. What you are looking at is disassembled MSIL code :) It looks like assembly, but it’s way more readable and understandable. Well, for contrast, here’s an actual assembly code for the same thing:

You have to agree that MSIL is a “bit” more understandable, right?

Anyway, we’ll talk lot more about MSIL in the upcoming articles. And if you haven’t subscribed already, now’s a good time to do so:

Subscribe now

The whole point of MSIL and CLR is that you can run it on any architecture and any platform. And that’s made possible by the fact that MSIL is being interpreted by CLR, which takes those instructions, compiles them to native-code for the target platform (e.g. if you are executing the code above on Linux, it’d be compiled to Linux’s native code) and executes them. This process of compiling just before executing is called JIT Compilation (Just In Time Compilation). It has some pros & cons but we’ll also spend some time discussing that in future articles. What’s important to remember for now is that CLR compiles the code to machine-readable language, whereas Java interprets the code and emulates it through Java’s VM. Again, don’t worry too much about it for now - it’ll become more clear as we progress.

What’s uniquely cool about MSIL is that, strictly speaking, you are NOT limited to C#, F#, VB, etc. As long as you write a program that takes ANY source code (e.g. Python, PHP, C++, etc.) and converts it to MSIL - you can have it run on CLR. And people actually did just that:

• IronPython compiles Python to CLR

• PeachPie compiles PHP to CLR

• Managed C++ compiles C++ into MSIL

• Windows’ PowerShell was built on top of CLR

• etc.

I hope you got the idea so far :) MSIL is awesome and we’ll definitely talk much more about it in upcoming articles.

And this is where I’ll stop for today. I hope that this article gave you an idea of what’s coming. And trust me - a LOT MORE interesting stuff is about to come throughout the following weeks! Next time I will be talking about Assemblies, the fundamental unit of deployment for CLR.

Until then!

P.S. If you enjoyed this article, do consider sharing it:

Share

Thanks for reading!

Other articles in this series:

• What is a .NET assembly?

• What is Assembly's Manifest?

• Weakly and Strongly-named Assemblies

We’re nearing the end of these C++ Memory Allocation series and there are two more things that I want to talk about — RAII and Smart pointers, which is the topic of today, and Alternative Memory Allocation libraries which will be the topic of the next article.

As usual, first we go with the bitesized infographic and then the more detailed info will follow. Enjoy!

Cool! I hope you found that useful?

I’d like to share some additional thoughts on RAII (Resource Allocation Is Initialization) first. I was actually reading the “Tour of C++" by the C++’s father himself - Bjarne Stroustrup and I clearly remember him saying “so people kept forgetting to deallocate memory, opening up various memory leaks, so I came up with this acronym - RAII, which was supposed to put an end to it”.

Honestly speaking, I tried really hard to understand the logic behind the name and, sadly, I just kept failing; miserably so. It just doesn’t make ANY sense to me. I was happy to learn that others find it “weird”, so to speak, as well, and people apparently came up with a better acronym - Stack Bound Resource Management (SBRM). Now this one is troubling to me as well, but at least it communicates the idea a bit better. So let’s focus on that.

Subscribe now

What both RAII and SBRM advocate is that any memory allocation (e.g. constructing any object or allocating raw bits of memory) should be wrapped inside a SINGLE object. And this object should have Destructor defined which should cleanup any initializations that were made. Here’s a simple example:

class DataPackage
{
private:
	int* data;

public:
	DataPackage()
	{
		data = new int(12345);
	}

	~DataPackage()
	{
		delete data;
	}
};

void useData()
{
	DataPackage* data = new DataPackage();

	// Do something useful with data ..

	// And feel free to forget to remove it ...
	// Once the function ends and "data" goes 
	// out of scope, destructor will be called 
	// and dynamic memory will be cleaned up.
}

What we do above is we do dynamic allocation of an INT, but we do it inside an object. And we can really forget about it because once the pointer to DataPackage goes out of scope, the destructor will be called and the memory will be cleaned up.

Compare that to this:

void leakyData()
{
	int* data = new int(12345);

	// Do something useful with data ..

	// Unless you delete it explicitly, you leak 32 bits
	// every time you call leakyData() ;/
}

That makes sense? I hope it does. And I guess that “Stack Bound Resource Management” makes more sense as well now. All your locally allocated variables are put on Stack (hence the name) and once they go out of scope, Destructor is automatically called (assuming there IS one, obviously). So it really boils down to (ab)using this nifty feature of Stack vars being cleaned up automatically. It’s like a free garbage collector!

I was also happy to learn that Rust actually enforces RAII to be used, which is one of the principles that language is built on :)

Speaking of stuff that relies on RAII, not mentioning Smart Pointers would be a disservice to reader :) I was actually thinking of naming the article “There’s nothing inherently Smart about Smart Pointers”, but eventually decided against it. Smart Pointers are smart because they rely on simple things — Stacks that call Destructors once the object goes out of scope :)

If you want to learn details, I thinks this article that mentions them back in 2002 can give you a solid context, whereas this StackOverflow answer goes in a really nice and yet approachable depth.

Given that I understand you are likely in a hurry, I’ll try to be short and sweet. Smart Pointers rely on Destructors and that’s fine. What’s different about them is how are they supposed to be used. Unique Pointer is just like your regular pointer - it encapsulates a single resource. Shared Pointer is more of a thing that you might want to copy to multiple places, while letting the Shared Pointer keep the count. Once the count drops to zero - destructor removes the original resource. And finally, Weak Pointer is similar to Shared Pointer, except that it doesn’t count :) And that’s actually all there is to it.

Here are some really simple examples to give you a clue:

auto data = std::make_unique<int>(12345);

auto shared_data = std::make_shared<int>(12345);

// This won't work - unique_ptr can NOT be copied and C++ reports an error.
passDataByValue(data);

// This will work, and shared_data's ref. count will increase by 1 here
passDataByValue(shared_data);

Here’s a live example:

Notice the “_Uses” being set to 1 here. Now see what happens once we pass it by value:

As you can see, _Uses is now 2. What this means is that once we go out of scope of passDataByValue(), destructor of Shared Pointer will be called, but given that _Uses is > 1 - the original object won’t be removed. It is only after the SECOND function is done that the object will be cleaned up.

And that’s about it for today! :) If you found it useful, I’d appreciate if you share it with your network:

Share

Next time I’m going to talk about alternative libraries for Memory Allocation. Until then!

Other articles from the C++ Memory Management series:

• Pointers & References - our school day boogeymans

• Heaps and Stacks - explained like you're five

• Why does Memory Leak?

• Pointers & References - our school day boogeymans

Somebody once said that the perfect way to spend Sunday is by doing a recap of what you learned in BitesizedEngineering series on C++ Memory Allocation :)

As usual, the bitesized graphic first and then more details for those eager to understand more details:

I hope that was useful :)

So, in a nutshell, what we have is:

• malloc() — which I’d guess stands for “Memory Allocation” is a C function for allocating the memory. Given that C++ was meant as an extension of C (hence the “++” meaning an increment of C), malloc() exists in C++ but people generally recommend avoiding it. Here’s a nice StackOverflow thread if you want details.

• “new” expression — which I occasionally call “keyword new” for reasons known to myself only, is basically a C++ way for allocating memory. I’ll discuss more details about it below.

• HeapAlloc() — is part of Windows’ API and as such should be used ONLY if you’re targeting Windows only. For any other case you should really stick to “new”.

• VirtualAlloc() — is also part of Windows’ API and represents the lowest-level API that you can interact with. It enables some amazing stuff, but also comes with a cost. We’ll discuss it below as well.

void* memory = malloc(1024);

char* memory = new char[1024];

void* memory = HeapAlloc(GetCurrentProcess(), 
    HEAP_GENERATE_EXCEPTIONS | HEAP_ZERO_MEMORY, 1024);

// You get back 4096 bytes (i.e. 1 page)
void* memory = VirtualAlloc(nullptr, 1024, MEM_COMMIT, PAGE_READWRITE);

As you can see above, “new” is the only one that works with actual Data Types. All others work with raw bytes. What’s more, HeapAlloc() and VirtualAlloc() require some additional properties, which, frankly, are the exact reason why you’d likely be using them in the first place - to tweak the memory allocation behavior :)

Subscribe now

Now let’s answer the “so, what should I use?” question. And the common answer seems to be - unless you know WHAT and WHY you are doing it, you should likely stick to expression “new”.

One of the main benefits of the “new” vs everything else is that it guarantees type-safety. As in - with “new” you ensure that you get only as much bytes as you need for DATA TYPE that you want to create (remember when we discussed that C++ is all about Data Types?). On the other hand, with malloc(), HeapAlloc() and VirtualAlloc() you get back a void* — which is a confusing way to inform you that you get a pointer, pointing to some memory address, but it’s up to you to figure out how big that SOMETHING is (hence the “void” part).

Another “issue” with malloc(), HeapAlloc() and VirtualAlloc() is that you get back a NULL if there’s no free memory to allocate. “new” will generate exception, which is a preferred OOP way to handle exceptional scenarios. You can override this behavior with Heap and VirtualAlloc(), but still, it’s something to keep in mind.

Yet another thing to keep in mind is that “new” will invoke a Constructor (and Destructor), whereas other APIs won’t do that. I guess this communicates that “new” is much more than a Memory Allocator, right? It’s really ALL what C++ is about - Data Types. And this aligns really nicely for those coming from pretty much any managed language, where you think of “new” as a way to construct an object :)

Finally, one cool question that one might ask is — so, if “new” is all about Data Types, and specifying data types, how do you allocate large chunks of memory then? And the answer is quite simple - you can use the operator new and allocate bigger chunks internally (by invoking malloc() / HeapAlloc() / VirtualAlloc() under the hood).

Fun fact btw: in Windows, “new” actually uses malloc() under the hood, and malloc() calls HeapAlloc() which in turn calls VirtualAlloc(). You can read more about it here.

And that’d be about it for today :) Next week, as I announced before, I’m going to start sharing some insights on how CLR works (i.e. a .NET’s Runtime Engine), but in parallel I’ll be working on some articles on how memory paging works, and what are User and Kernel modes in Windows (and how do they affect the memory). Until then, if you liked this, I’d appreciate if you share it! :)

Share

Thanks for reading!

Other articles from the C++ Memory Management series:

• Pointers & References - our school day boogeymans

• How Windows allocates memory

• Memory allocation through Heap API

• Virtual Memory API and all the cool stuff you can do with it

As usual, the infographic goes first and then some additional thoughts. Enjoy!

I hope you found that useful! If not - reach out my complaints mailbox, eh :)

So here’s the deal - Virtual Memory API represents the lowest-level API your process can interact with in order to allocate memory. But here’s a kicker - at that level, you can’t really ask for BYTES. I mean, technically you CAN, but what you will get back are PAGES. E.g. if you ask for 10 bytes - you will get 4096 bytes back (i.e. a single page). If you ask for 10.000 bytes you will get 3 pages back, etc.

Here’s an example:

PMEMORY_BASIC_INFORMATION mbi = new MEMORY_BASIC_INFORMATION();

// Ask for 10 bytes
LPVOID memory = VirtualAlloc(nullptr, 10, MEM_COMMIT, PAGE_READWRITE);

VirtualQuery(memory, mbi, sizeof(*mbi));

// mbi.RegionSize will report 4096 bytes

As you can imagine, given that HeapAlloc() and others call VirtualAlloc(), that means that they have to do some book-keeping in order to deal with pages properly. But that’s a different story for another time.

Subscribe now

Anyway here are some cool things that VirtualAlloc() allows you to do:

1. Reserve memory -- which is a really nifty process completely made possible by the fact that OS uses Virtual Addressing instead of physical one. By "reserving" range of memory, you are effectively telling your system that the range of pages you are asking for SHOULD NOT be given to anyone else (i.e. any "new" and "HeapAllocs()" won't get those addresses). This operation does NOTHING to Physical RAM, and it's 100% logical (i.e. all of this happens on the OS' memory manager level) and as such is pretty cheap to do.
   
   Here’s an example:

   

   As you can see - I asked for total of 1GB and 10 Megs, but what’s really committed is just 10 Megs.

2. Protect Memory -- which if you are thinking in OOP terms would be similar to defining a constant or a private property. You can really set some cool properties on memory pages (e.g. make memory read-only, or completely disable any access) and, for example, ensure that no malicious code can actually do anything nasty. Check out official docs for list of all Memory Protection constatns.

3. Lock Memory -- which pretty much means to tell OS not to move your bits from RAM to Hard Disk. And this is really cool because getting your bits back from Hard Drive actually bears some cost and hurts efficiency, so asking for your bits to always stay in physical RAM ensures maximum performance. On the other hand this makes your program pretty greedy so you really have to strike a balance here.

You can check the official docs for list of all interesting things you could do.

And that’d be about it for today :) Next time we're going to talk about comparison of various allocation functions.

I also want to emphasize that, as announced before, I started creating graphics on the CLR topic so that's coming out next week as well!

Until then, if you enjoyed this article or learned anything new - I’d appreciate if you share it with your network!

Share

Thanks for reading!

Other articles from the C++ Memory Management series:

• Virtual Adressing and Why every process sees the same memory space

• Memory allocation through Heap API

• How Windows allocates memory

• Pointers & References - our school day boogeymans

As we do usually, first the bitesized infographic and then the more detailed explanation below!

Enjoy!

A’ight, I hope you found that useful. If not - well, at least I know I gave my best.

The truth is that I lied to you before. I lied when I said that memory addresses that you get back from OS are RAM addresses. They are not. And some of you probably figured that I’m a liar and you stopped reading. That’s OK. Thing is - I think this was a WHITE LIE. A lie that told with a greater purpose. Purpose of making it simpler to digest the content at the moment. But now I’m giving you the full picture (and I swear that was the only lie I told!).

Thing is - you never ever get to see the actual physical RAM addresses. Never. Ever. Hell, I actually went way and beyond to figure out if there’s even a way to do so! No matter how privileged your process is, you ALWAYS see Virtual Address space. The actual conversion from Virtual to Physical happens in the OS’ Kernel itself!

But why is that? Well I guess I explained it in the infographic below, but I’ll repeat for those with fuse-short attention span:

1. Process can ask for more memory than there is Physical RAM — this isn’t such a big of a problem in these days of massive servers with hundreds of gigabytes of RAM. At least not a big enough of a problem to bother you. But to get an actual picture, I want to take you back to 32-bit Windows era. The era when Windows supported maximum of 4 gigs of RAM (simply due to number of bits available for addressing!).
   
   During the 4 gigs and 32bits era, Windows would usually split your RAM into two halves - User Space and System Space. And it’d split it in 50:50 ratio. So your program, along with all other programs out there gets 2 gigs of RAM and Windows uses other 2 gigs for, you know, Kernel, Drivers and all other things going under the hood.
   
   Question then becomes — how the heck do you start a Chrome browser with 2 gigs of RAM, right? Not to mention Chrome and, god forbid, a Calculator. The answer is simple - you don’t. Or at least - you couldn’t. And that sucked because some people really wanted to use Chrome.
   
   So how do you solve this unsolvable problem? Well, you lie. Just like I lied a bit when I told you that addresses reference physical RAM addresses, so does Windows lie a little bit and allows you to ask for more memory than it actually has. And this white lie of Windows is called - Virtual Addressing.
   

   

   
   Windows will allow you to allocate, say 5 gigs of RAM in order to fire up two Chrome tabs (e.g. for GMail and LinkedIn) and it will happily provide you with memory space. But here’s the deal - some of those bits will end up on your hard drive (a process called “Paging Out”; more about it in future articles). So you keep working with these Virtual Addresses, thinking you have 5 gigs at disposal, but what happens in the background is that Operating System keeps juggling those bits back & forth between actual RAM and your Hard Drive. Cool stuff!

2. You can have contigous ranges of addresses — objectively speaking, there is NO way you’d ever get a contigous range of addresses from RAM, simply due to fragmentation that happens over time. So if you were working with ACTUAL physical addresses - that would be a no-go. Forget about integer arrays where next element is 4 bytes away from current one. Ain’t gonna work.
   
   But when you use made-up addresses, you can do whatever the heck you want! So you ask for 2 gigs of RAM, and you get a 2 gigs contigous block back. In the background it’s 99% NOT contigous and some of it is likely sitting in your hard drive, but that’s somebody else’s problem!

3. Stricter process isolation — just imagine a scenario where each process could write to any PHYSICAL memory address. You don’t have to be a security expert to see that a malicious process would try and scan the whole RAM immediately, right? I mean, sure, you could task your OS to track what belongs to whom, but once you end up in shared memory waters, shit becomes serious. And why bother?
   
   If you provide each process with a virtual address space starting at 0x000 and going all the way to 0xFFF…FFFF, all you need to do is ensure to track the mappings of the process itself. Easy peasy (in a way!).

Finally, and I know I haven’t introduced it officially yet (and I’ll do that in next articles!) but there are TWO modes of operation for each process in Windows. One is “User Mode” and another is “Kernel Mode”. User Mode is where all your user-started processes execute, whereas Kernel Mode is where all your drivers and Windows operate. Obviously, that’s oversimplification, but let’s assume it to be like that for now.

Subscribe now

Difference between these two (again, an over-simplification!) is that each Process running in User Mode sees only it’s own Virtual Address space. Whichever memory location you ask for from inside the User process, Windows would see if you allocated that area and if you did - you’d get it back. If not - well, segmentation fault. Oh, and by the way - there’s NO way for user process to even ask for Virtual Addresses in Kernel space!

On the other hand, processes running in System Mode (Kernel Mode, whatever), actually see a SINGLE & UNIFORM Virtual Address space. They could ask for ANY address which, when mapped, could either be of a process running in user mode or could be of bits that were allocated by another process running in System Mode. Point being - anything running in System Mode can see and modify ANYTHING in the RAM!

And that’d be about it for today :) I hope you found that useful, and if you did - I’d appreciate if you share it with your network!

Share

Next time I will be talking about Virtual Memory functions and VirtualAlloc(). Until then!

Other articles from the C++ Memory Management series:

• Memory allocation through Heap API

• How Windows allocates memory

• Pointers & References - our school day boogeymans

• Why does Memory Leak?

First things first - I promised more articles this week but I barely managed to deliver two so far. I apologize. The thing is, if you care, that I had three conference talks to give (Wednesday, Thursday and Friday) and I simply presumed that I will manage to publish the articles in the night-hours. Well, what I didn’t count on was my son’s teething going crazy, virtually leaving us with no sleep at all :) So yep, I barely pulled this one and I’ll try pushing through one more on Sunday!

But that’s not what I wanted to talk about though. What I want to discuss today is Windows’ Heap API. That magical thing that pretty much ANY language runtime eventually has to interact with. Be it C’s “malloc()”, C++’s “new”, Rust or .NET - they all interact with Windows via this API. So, let’s discuss it.

As usual, the bitesized graphic first and the more detailed explanation will follow below.

I hope that infographic gave you a clue? :)

One thing that you should be aware of is that the moment your process starts, you get 1MB of Stack and 1MB of Heap memory. What that further means is that if you can fit your Heap requirements in that 1MB, you should, theoretically, end up being way more performant than if you kept asking for more memory.

What’s cool to know is that you can override this behavior by providing the /LINK directive to linker. If you know that your process will require, say, 5MBs to operate at it’s finest, then you should be good to go and ask for 5MB from the start.

What I find even more interesting is the sole reason of why would anyone use HeapAlloc instead of “new” or “malloc()”. And frankly, you probably shouldn’t, because default implementations are good enough for most cases.

HOWEVER, and this is really cool, by using Windows’ native API for memory allocation you get access to some Windows-specific functionalities which simply can not be provided by generic implementations like “new” and “malloc()”. And two coolest things that you can do are:

1. Create private Heaps, and

2. Pass some low-level flags (e.g. in order to disable serialization)

You might be wondering why in the world would anyone want to have more than one heap, right? Isn’t one enough?

Subscribe now

One is enough. But having private ones really unlocks some cool things that I already mentioned in the graphic:

1. You can create Memory Pools (i.e. heaps of fixed size) and allocate memory from there. Furthermore, you can overload the operator new and place only specific objects on that private Heap, giving you a full control over WHERE they are and ensuring that you can remove them in one go by simply calling HeapDestroy().

2. Another cool thing you can do is have one Heap per thread. And if you are certain your heaps won’t need to share memory, there’s no need to have them wait for memory allocations (you are probably aware that “new” and “malloc()” are thread-safe and serialized, right?). By creating private Heaps and using the HEAP_NO_SERIALIZE flag you can ensure that each thread gets its bits immediately and without overlaps with others.

3. And finally, by allocating memory upfront, you can prevent memory fragmentation from happening. One typical example would be if you had a dynamically growing linked-list. The more time it passes between elements being added, the higher the chances are of those memory chunks ending up on different memory pages.

Obviously, there’s a downside to all of this - now you have to add additional tracking and management for creating and destroying the heaps. But still, it all depends on the use-case.

And that would be about it for today. If you want to learn more about Heap API, I encourage you to check the official docs.

Next time I’m going to talk a bit more about Memory API and VirtualAlloc, which is what gets called by HeapAlloc. Until then, if you enjoyed this article, I’d appreciate if you share it with your friends & colleagues :)

Share

Thanks for reading!

Mixa

Other articles from the C++ Memory Management series:

• How Windows allocates memory

• Pointers & References - our school day boogeymans

• Why does Memory Leak?

• Heaps and Stacks - explained like you're five

This article will pretty much try to answer the question I had a while ago - “what really happens (in Windows) when you type keyword ‘new’” (e.g. new CandyBar()).

As usual, the bite-sized graphic first and additional details below it.

(click on image to expand)

As you see, both C++ and C (and I’d presume Rust and any other language runtime) eventually end up calling the Heap API (strictly speaking, “keyword new” calls “operator new” which in turn calls “malloc()” which eventually ends up calling “HeapAlloc”). Heap API is the main interface that Windows provides in order to allocate SINGLE BYTES.

Why do I say “Single Bytes”? Because once you go past the Heap API (i.e. once you go one level below) you end up in in VirtualAlloc (i.e. Memory API) which works in PAGES. What that means is that on this level you can only allocate MEMORY PAGES, which are ~4KBs in size.

If you’re not really familiar with Heap and Memory API, that’s totally fine. I will be digging deeper into them in the next articles!

Subscribe now

Now why is all of this important, interesting or relevant at all? Why in the god’s name would you ever interact with HeapAlloc or VirtualAlloc instead of using ol’ good keyword new? And the truth is - if you’re asking this question, you likely won’t need to do it. But here’s the thing - C++ is built to run on ANY platform and that means that “new” has to be universal enough to be compileable for any underlying OS. Which further means that it has to be more on the generic side, which eventually means that it can’t provide support for some OS specific things and tweaks.

On the other hand, given the fact that HeapAlloc and VirtualAlloc are Windows-specific APIs, they support pretty much anything that you can ask Windows to do, some of those things being:

1. Heap API allows you to create private Heaps and ask HeapAlloc to allocate bits from those places

2. You can disable thread-safety and serialized access by specifying the HEAP_NO_SERIALIZE flag

3. Memory API’s VirtualAlloc allows you even greater control - you can ask to RESERVE memory without committing it, you can do some tweaks on address ranges where memory is being reserved, etc.

Generally speaking, possibilities are endless and you can pretty much fine-tune HOW you allocate the memory and make it fit your use-case. However, do remain mindful of the fact that with great power comes great responsibility.

Finally, in case you are wondering HOW you can actually see this in action - it’s quite simple. Fire up the Visual Studio, write some simple code that uses the “new” keyword (e.g. int* foo = new int(10);) set a breakpoint at that line, go to Disassembly window and just follow what happens:

And that’s about it. Go try and experiment with it!

Next time I’m going to talk more about Heap API and HeapAlloc. Until then, do let me know if you found this article useful. You’d also help me if you spread the word by sharing it with your friends and colleagues:

Share

Thanks for reading!

Other articles from the C++ Memory Management series:

• Pointers & References - our school day boogeymans

• Why does Memory Leak?

• Heaps and Stacks - explained like you're five

• What happens when you type the "new" keyword?