P/Invoke Free

P/Invoke is an abbreviation for Platform Invoke and refers to the ability to make calls directly to the operating system without using the .NET FCL. In Windows, P/Invoke also allows calls to be made to user or vendor DLL's. P/Invoke is similar to JNI in Java.

Using P/Invoke does not make code unsafe or unmanaged. It does however cause the application to rely on items specific to the operating system. This again makes the application unable to run on Mono, and other future implementations. P/Invoke should be avoided and functions in the FCL should be used instead when possible.

Platform Potential

Because IL is generic, it is not tied to any particular CPU or hardware platform. While IL is currently only supported on Windows, its design is specifically built with other platforms in mind. On Linux, there is already a project called Mono to allow IL code to run on Linux. In the future, other platforms will implement IL execution as well.

Language Neutral

.NET is language neutral. The three most common languages in .NET are C#, Visual Basic, and Delphi. But many others exist for .NET as well, including Fortran, Smalltalk, and others.

But .NET is more than just language neutral. .NET brings all the languages together through its CLR (Common Language Runtime) and CTS (Common Type System). The CLR and CTS allow all the languages to use assemblies produced by other languages as if they were produced by the same language. There is no more awkward translation of parameter types, calling conventions, or naming conventions. Now, C# users can use all code produced by Delphi programmers, Visual Basic users can use all code produced by C# developers, and any combination of languages. No longer are developers segregated by language and forced to interact only through difficult and awkward exports.

Imagine, if all of the sudden the universal translator from Star Trek were made available today enabling Russians to speak directly to Germans, to Dutch, to Spanish, to any language. Each using their own native tongue, yet each hearing in their own native tongue. That is exactly what .NET does for programming languages.

The Future is Faster

Does this mean .NET is slow now and you should suffer until we have even faster CPUs? No!

Let's take a step back and look at how we build applications today. When we compile our source code, the compiler emits assembly code for a specific type of CPU. For Win32, this might be for a 486 CPU. On a 486, the code runs a full potential. However, very few people today are running with 486 computers, and in fact, are using CPUs many versions newer. But since you cannot predict what your users will use, you must compile for the lowest possible factor. This also severely restricts Intel, AMD, and other CPU manufacturers, as backwards compatibility must be maintained for many generations.

With .NET code, your source code is compiled into IL. This IL is then executed on any CPU or operating system with the .NET framework. This IL is not just interpreted though, it is essentially compiled on demand using instruction sets optimized for the platform. This on-demand compiler can be easily updated in the future to support newer CPUs and even incompatible instruction sets. Each individual user then will run their own optimized version of your software, for their hardware. All without needing to ever recompile your code or redistribute your application to users.

Moving from the 16 bit world to the 32 bit world was quite painful for developers. It was not just a simple recompile of the code as many underlying support architectures changed. But with .NET, you can move into the 64 bit world and take advantage of the faster processing power without recompiling, redesigning, or even redistributing your software. That is what I call upgrade insurance!

While C++ can be compiled for many platforms, this requires each build to be built for each and every platform. This is a very maintenance intensive task, and expensive in many cases as well. Cross platform C++ code has a lot more restrictions, and often code does not compile well across platforms, while .NET code is always cross platform. The key factor though is that, in C++, for future platforms, you must recompile as compilers become available, while .NET code needs no changes or recompilation.