Lambda the Ultimate

Point 8: RealProxy is a .NET class that provides pretty much the same functionality as Java's dynamic proxies. It provides an "invisible" way to convert function calls into messages.

Point 9: NGEN.EXE translates an assembly (== code package) into native code and installs it into the local machine's native code cache. This is a way to pre-compile the code instead of waiting for JIT to do it.

With regard to point 8: component frameworks such as CORBA and COM (DCOM) provided a means to extend intra-process programming techniques and conventions beyond process boundary (even across the network.) This was accomplished by providing (amongst other things) an infrastructure for converting standard stack-based method invocations into message-based protocols (where the messages could be sent over the wire.)

These frameworks exhorted a price for the conveniences they provided. Basically, you had to program for them. That is, a C++ program written for COM or CORBA looks (and works) differently than a standard C++ application. There was a lot of overhead: writing an IDL, lots of API calls for setting up the system, etc.

Java with RMI showed how easily this type of thing could be done when the environment provides the appropriate facilities, built on a thorough reflection API (see items 2 and 3 in Don's list.) .NET uses the same model and extends it in several notable aspects:

1. The remoting API is open and documented. This means that .NET remoting can (and probably will) be extended to support additional wire protocols.
2. Using this API, .NET comes with several built-in remoting services, e.g. TCP and SOAP.
3. Speaking of SOAP, .NET automates much of the process of building and using web services. It provides remoting services that work with the various SOAP protocols such as WSDL and UDDI.

With regard to point 9: .NET allows the byte code to be JIT-ed, compiled to native on install, or at build time. Pre-compiling can obviously improve performance but I don't share Don's enthusiasm over this technology:

• Most apps spend most of their time in very restricted sections of their code. These sections will be JIT-ed only once and then executed many time throughout the app’s lifecycle.
• .NET's overhead compared to C++ (even with COM) is not limited to the JIT overhead. For good and bad C++ lets you work much closer to the metal, thus providing much finer control over performance related issues (e.g. custom memory allocators for STL vs. .NET GC.)
• It's all about the algorithms anyway ;)