I am aware of the Shared Source Common Language Infrastructure and also the MethodImplOptions Enumeration. I am interested to learn more about how the .NET runtime is implemented.
For example, in his answer to the following question; Hans Passant talks about how Math.Pow() is implemented in C++ in: clr/src/vm/ecall.cpp: How is Math.Pow() implemented in .NET Framework?. My question is: how do you know to look in that file in the first place? Is it because you know the code so well or is there a reference somewhere? i.e. a reference that says that Math.Pow() is implemented in: ecall.cpp
Well, you could poke around in the sources of the SSCLI. But I guess that is not what you were after 🙂
You can however narrow down the false positives of a plain
findstr /s /i "pow" *.*.You’d start by decompiling (or disassembling, if you feel like it) the
System.Mathclass. You would find it inmscorlib.dll, which MSDN would tell you in case you didn’t know.If you do, you’ll see that the method doesn’t actually have a body defined there, but merely the signature. It has the
MethodImplAttributeassigned, though. Which bears the value ofMethodImplOptions.InternalCall. Again, looking at MSDN tells you, that this method isThis should give you one important hint: it is probably implemented in C or more like C++, since that is the language that is used to implement the CLR itself.
Knowing that, you do a search over all the C++ source files of the SSCLI.
findstr /s /i "pow" *.cppThat narrows down the hits considerably, but still is a lot of stuff. Know it is really time to experiment, like make the search case sensitive, and look for whole words only (to exclude stuff like “power”).
findstr /s /r "\<Pow\>" *.cppDoing this will, for this example, return only two hits:
The output pretty much gives it away then:
Powseems to be somehow related toCOMDouble::Pow, which is show also.Frankly, I don’t remember how I really came up with the knowledge that
InterallCall/ instrinct functions (or there lookup tables, if you will) can be found inclr\src\vm\ecall.cpp, but the above is what I would have done, if I need to again.To add to Hans’ comment to your question about having studied the SSCLI, I would say that in general it is always educational, heck even “entertaining” if you’re geek enough, to read and explore other codebases. Especially, when they are related to the technology domain you are currently working in. I guess many people have been spelunking in the BCL and other .NET libraries, either using decompiling or the public available sources, which even have comment. But the CLR itself is also quite interesting, even with the SSCLI being somewhat outdated by know. Another interesting thing, IMHO, are the CRT (C/C++ runtime library) sources that are installed with Visual Studio (e.g.
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt).