En los artículos anteriores hemos hablado de conceptos como CTS, CLI (CLS), IL o JIT, los cuales pueden resultar bastante confusos. A continuación daremos una aclaración del significado de cada uno de ellos, y explicaremos su función dentro de la plataforma .NET, para lo cual se hará una explicación más a fondo de su funcionamiento.

Hemos comentado en artículos anteriores que cuando compilas un código fuente a un binario de .NET, éste binario no contiene código máquina de la arquitectura en la que se compiló, sino que se genera un código para una máquina virtual, al estilo del bytecode de Java.

Además se comentó que era posible utilizar un objeto escrito en un lenguaje .NET desde otro lenguaje .NET. La explicación a ésto es un poco más compleja: cuando tú compilas un código, se genera un Assembly o ensamblaje, que es la unidad mínima de compilación en .NET (que además es autosuficiente y autodescriptiva), el cual puede contenerse en un fihcero .exe o .dll, dependiendo del tipo de código que contenga y de la función a realizar. Dicho assembly está formado por un código que entenderá la máquina virtual, llamado IL o Interpreted Language, y es lo que denominaremos CLI o Common Language Interface, que, junto con el uso exclusivo de los tipos definidos en el CTS o Common Type System, permitirán que cualquier compilador .NET pueda entender dicho assembly al generar otros programas o librerías.

Hasta este momento hemos conseguido unificar el lenguaje pseudo-ensamblador que usarán los compiladores .NET, de forma que será posible la interacción entre distintos lenguajes. Pero, ¿cómo se resuelve el problema de que distintas arquitecturas y sistemas operativos puedan ejecutar un mismo código máquina?. Pues la respuesta es parecida a la que da Java. Java implementa una máquina virtual que interpreta el bytecode. .NET hace una precompilación del IL para proceder a su ejecución. A esta técnica se le denomina JIT Compilation o Just In Time Compilation. ¿Ventajas? Pues como la compilación resulta que se reduce practicamente una traducción entre lenguajes máquina, ésta requiere muy poco tiempo, por lo que el resultado final es que es más eficiente que la interpretación del código (de todas formas Mono también dispone de un intérprete de IL, llamado mint)

Como comentario final al artículo, decir que me resultó realmente extraño que Microsoft diseñara una plataforma que fuera capaz de de correr en diferentes arquitecturas y más aún, en diferentes sistemas operativos. La explicación es que Microsoft no buscaba la portabilidad, sino que buscaba la integración de distintos lenguajes de programación (C#, C++.NET, VisualBasic.NET, etc), consiguiendo como «daño colateral» dicha portabilidad.

Pues eso ha sido todo por el momento. Nos vemos en los próximos artículos.