What the "EE" means in SOS?

Question

I found "EE" is a magic word for me.

Inside CLR, there is a "EEClass", which is created by CLR class loader. And I don't know why it is called EEClass.

Now, come to the SOS world, there are more EE here, like EEHeap, EEStack [-EE], Name2EE.... Do they stand for the same meaning here ?

Answer 1

The CLR started life long before it was adopted to run .NET code. Started as the Universal Runtime in Project 42, a highfaluting project that failed but whose parts survived in subsequent projects, like .NET. Continued into NGWS (Next Generation Windows Services) before it evolved as the execution engine for .NET. 42 was the building number that the group worked in on the Microsoft campus.

Several acronyms survived, quite visible in the SSCLI20 source code and names you see back in the debugger and header files. A smattering of them:

• URT, Universal Runtime. Ancient, it just remains in the native error codes you get from managed code, they have facility code 19, FACILITY_URT in the WinError.h header file. Which makes any such error code value 0x8013xxxx.

• COM+ or COMPlus. Also ancient, COM+ was the evolution of COM, notable for losing the middle-ware war to Java and the name of the group in Microsoft that had primary Project 42 responsibility. Still visible in the names of exceptions, including the native exception code for any .NET exception: 0xe0434f4d. 434f4d are the ASCII codes for "COM". The CLR itself actually uses very little COM code, just to produce the stack trace from the pdb and the custom hosting, debugger and profiler interfaces.

• COR, Common Object Runtime. The acronym that starts appearing after the Project 42 bits. Survives in all the names of the SDK header files, like Cor.h, CorError.h, CorDebug.h and several hosting api names, like CorBindToRuntimeEx. Renamed to "CLR" in the .NET 4 versions btw.

• EE, Execution Engine. Appears in the names of parts of the CLR that were adapted specifically for running .NET code. As you found out.

• SOS, Son of Strike. A debugger extension that uses the DAC (Data Access Component) to hook into and reveal internal CLR data structures. Strike was the name of a debugger extension used to get .NET version 1.0 going, back when it had the internal project name Lightning. Lighting Strike, you get it. Evolved as a general debugging tool, thus becoming the son of Strike. DAC is visible from the mscordacwks.dll runtime support DLL and the error message you get when you try to load a minidump that was created with a different CLR revision.

The internal project names are also prominently visible in .NET Framework source code. .NET 1.0 was Lightning, .NET 1.1 was Everett, .NET 2.0 was Whidbey, WPF was Avalon, WCF was Indigo.

A similar kind of highfaluting project that involves the CLR is taking place right now. Super-secret, its code name is Midori. Little is known about it, other than it aims to implement an entire operating system based on managed code. A follow-up on the otherwise well published Singularity prototype.