Two interesting notes from current reading:
1. You can write code that runs IL commands directly if you’re current language doesn’t support a specific command.
2. ILDasm.exe and ILAsm.exe. Clearly ILAsm.exe is an intermediate language assembler, so you could write pure IL and compile it straight from there. ILDasm.exe is a lot more interesting.
Recently I ported the PHP API for theprintful.com to .NET. I’m going to use the binaries generated from that project to see what ILDasm.exe actually does.
Rather nicely, ILDasm.exe has a GUI component (go figure). We can visually inspect different different packages, their classes, as well as all of their members:
Right now I can’t see any immediate usage of ILDAsm, but it’s nice to know it’s there.
I did wonder if I could write an unsafe method in C# that would inject IL for me, then compile it into my project to surface otherwise unused IL behavior. Seems like it could also be an attack vector if that’s the case.
Already off to a good start! I started reading the tome this morning on the train to work. I’m tracking all my personal notes through Evernote, so I may share those down the road a bit.
There are things I’m already aware that the CLR does, but they’ll be included if I read about them and I think they’re interesting. For example, I already knew that all exes/dlls get a Windows PE header (if you’re unfamiliar, check out Corkami’s PE101 – it’s crazy good), but I think it’s interesting none the less. I also found out that there’s a separate PE32+ format for 64-bit platforms.
Metadata is actually compiled into every CLR module, which I was unaware of. This means all type information is baked directly into the module itself. Suddenly the previous black magic underlying .NET Reflector with all of it’s advanced module information and assembly cross-referencing seems obvious. That metadata is also why Visual Studio’s IntelliSense feature is so good. Everything drives off of the module metadata, meaning look ups are super-fast and reflect the actual state of the assembled module.
On that note, this metadata only gets included for managed modules. By default, C++ gets compiled down to native modules, so if you’re writing C++ you lose these metadata benefits. However, you can specify an optional compile-time switch, “/clr”, which will turn said modules into managed code. Very neat.
There’s also a very handy tool called CLRVer.exe that’s included with Visual Studio. To run it, open the Visual Studio Command Prompt. It will list installed versions of the CLR. If you supply “-all” as the first parameter, it will show all programs running under the CLR along with what version they’re using. There are separate versions of the VS command prompt, one for x86 and one for x64. It will only report on assemblies running under that particular address space. It will also exclude any process running under other usernames unless ran as admin (at least that’s the behavior I observed).
In the coming weeks I’ll be specifically writing about major lessons from CLR via C# by Jeffrey Richter.
I know how the Java Virtual Machine works, but I’m still in the dark when it comes to the CLR. I actually ported NanoVM from the AVR to the Zilog ZNEO in college.
Since I’m writing a lot of C# every day (and often high-performance C#) it’s a knowledge gap that I absolutely must fill. I’m pretty excited to dig into serious content.