.NET o no .NET, esa es la cuestión : interop, Visual Studio

Viendo el código fuente de .NET con Visual Studio 2012

Rafael Ontivero — Sat, 15 Sep 2012 11:19:14 GMT

Quien tenga una versión anterior de Visual Studio seguro que sabe que se puede navegar por las tripas de .NET y ver cómo Microsoft ha implementado todo el tema. Pues bien, más o menos a mediados de agosto del corriente (2012) se anunció la disponibilidad del código fuente de .NET 4.5, lo que nos permite meternos en las tripas del Framework y, lo que es mucho más interesante, mirar cómo funciona todo lo nuevo relacionado con Windows 8.

El artículo citado da un somero repaso a las novedades no específicas de la biblioteca, entre las que se pueden destacar el añadido de métodos asíncronos en conjunción con las clases de tareas, y que ahora el jitter es capaz de optimizar el código para los procesadores multinúcleo. También se mejora el rendimiento de casi todo (como siempre dicen, lo que a veces no es cierto), y se potencia el acceso de .NET a nueva parte nativa de Windows 8 (o RT o Metro o como quieras llamarlo), que es código nativo escrito en C++ y C++/CX, permitiendo a este lenguaje acceder, también, a código escrito en otros lenguajes .NET gracias a su parte CX (que como ya he dicho varias veces, es nativa).

Como en otras versiones, el código fuente está disponible para descarga directa, o para ser visto desde nuestro propio código, y también como símbolos de depuración.

La captura de abajo nos muestra una aplicación Metro por defecto, detenida en un punto de interrupción, tal y como se ve en mi Visual Studio 2012 sin cambiar la configuración por defecto:

Fijaos en que la ventana de Call Stack estgá prácticamente vacía, y si hacemos Step Into simplemente saltamos a la siguiente línea de nuestro código fuente.

Vamos a habilitar la posibilidad de meternos dentro del código de Microsoft.

Nos vamos a TOOLS -> PROPERTIES, abrimos la pestaña lateral de Debugging, y cambiamos las siguientes opciones:

· Marcar Enable Just My Code

· Marcar Enable .NET Framework source stepping

· Desmarcar Step over porperties and operators (Managed only)

· Marcar Enable source server support

· Desmarcar Require source files to exactly match the original version.

Dejadlo todo más o menos como en la imagen:

Ahora, en la pestaña de Symbols, hay que añadir una nueva dirección de descarga de los mismos: http://referencesource.microsoft.com/symbols. Como en la capura.

Finalmente, cuando le deis a OK el IDE se quedará bajando ficheros. Hay que esperar a que termine, y dependiendo de lo rápida que sea tu conexión, tendrás que esperar bastante tiempo.

Con esta configuración, cada vez que se necesite algo, el IDE irá a los servidores de Microsoft, por lo que la carga y depuración de vuestro programa podría ser muy lenta a veces… por lo que se pueden bajar todos los símbolos de una tacada e instalarlos de forma local, apuntando la URL anterior a done los hayamos instalado. Podéis bajarlos de aquí.

La siguiente captura muestra algo de las tripas de Metro:

Vale. Ahora el tío de la rebaja. ¿Habéis intentado profundizar en el código fuente, en métodos como el Activate() de la primera captura? No entra, ¿verdad? No muestra código fuente, sino que simplemente salta sobre la llamada.

Un gallinfante a quien adivine por qué es.

Vale: es código nativo. Es decir, la parte Metro del .NET Framework no es código manejado, sino nativo. Es decir, está escrita en C++/CX, en donde la parte CX actúa como Sugar Syntax de todo el perifostio COM y COM+ que finalmente es .NET

Y todavía me atrevería a añadir algo más. Metro esconde en la manga algunos trucos de desarrollo que a MS no le interesa que se sepan, y ya visteis lo fácil que es hacer ingeniería inversa de una aplicación .NET. Si toda esa parte hubiera estado hecha con .NET, sería facilísimo meterle mano.

¡Y qué cojones, donde esté C++ que se quite cualquier lenguajucho de mala muerte! ;-)

¿Qué es C++ y qué es C++/CLI?

Rafael Ontivero — Mon, 15 Jun 2009 18:26:01 GMT

Introducción

Suele aparecer con cierta frecuencia en los foros de ayuda cierta confusión entre C++ y C++/CLI. Hay quien pregunta algo de C++ siendo C++/CLI y viceversa, o quien intenta aplicar algo de C++/CLI a C++ (y también al revés), o simplemente se ve completamente ofuscado con el tema. En esta entrada vamos a intentar poner un poco de orden en todo esto.

C++ no es C++/CLI

C++ es el lenguaje de toda la vida, inventando por Stroustrup y que, pese al deseo de muchos, está más vivo que nunca y sigue creciendo en funcionalidades y potencia, como es el hecho de que el próximo estándar va a añadir cosas muy interesantes que veremos por aquí. Si no pasa nada, antes de fin de año estará aprobado, se llamará C++09 y sustituirá a C++03 (No, no os penséis que hay 6 versiones entre uno y otro, no, es que el estándar se llama con el año en que se aprobó –si, ya sé que no es lo óptimo pero es así).

En C++ tenemos punteros, referencias, clases, herencia, polimorfismo y todo lo clásico del lenguaje, y los últimos compiladores de Microsoft lo implementan muy bien. Es decir, con Visual C++ (la versión que sea), se puede seguir programando como hasta ahora, con MFC, con Win32 o con cualquier otra biblioteca existente (QT, wxWidgets, y un largo etcétera).

Luego tenemos la plataforma .NET, en la que C++ no puede entrar directamente ya que hay cosas que .NET no soporta, entre las que caben destacar los punteros y la herencia múltiple. No vamos a entrar en detalles de por qué eso no funciona, sino que vamos a aceptarlo como dogma (quizás en algún momento futuro me dé por explicarlo, aunque tampoco es un tema difícil en exceso).

Por lo tanto Microsoft creó un nuevo lenguaje que llamó C++/CLI[1], es decir, el C++ del CLI. Si bien en su momento fue diseñado para que fuera un lenguaje de primera clase (otra forma de decir que debía soportar todo el conjunto de .NET), con la llegada de la versión 3 del Framework C++/CLI se quedó como una herramienta avanzada de interoperabilidad entre .NET y Win32 (luego veremos más sobre esto).

Existen dos formas para acercarnos a las diferencias entre C++ y C++/CLI, o más bien se trata de dos maneras de explicar los mismos conceptos. Yo al menos no tengo clara cuál es la versión formal, si bien me aboco por la primera. Veamos en detalle estas das aproximaciones.

PRIMERA APROXIMACIÓN: C++ es un subconjunto de C++CLI

C++/CLI incluye a C++. Es decir, todo lo que se puede hacer en C++ también se puede hacer en C++/CLI, y más. Si nosotros cogemos un código fuente escrito en C++ y lo compilamos como C++/CLI obtendremos un programa completamente funcional igual que lo era compilado en C++. No vale intentar llamar a una DLL nativa como si fuera nuestro programa, ni a un fichero objeto ya compilado (no me refiero a un objeto, sino a un fichero .obj), debemos partir del código fuente, todo el código fuente.

De este modo, hemos convertido un programa C++ en otro C++/CLI que necesita el .NET Framework para funcionar pero que simplemente continua siendo, exactamente, el mismo que antes y con el mismo código fuente.

Y entonces podemos añadir código que use cosas del .NET, con ciertas limitaciones que veremos luego, pero lo que sí podemos es utilizar los nuevos conceptos de .NET, como referencias manejadas, liberación automática de memoria, genéricos y demás zarandajas.

Por lo tanto, está claro que C++ es un subconjunto de C++/CLI desde este punto de vista.

SEGUNDA APROXIMACIÓN: Son lenguajes diferentes que funcionan lado a lado

Aquí C++ tiene una parte de su sintaxis compartida con C++/CLI de igual modo que el primero la tiene con C. No obstante, son dos lenguajes completamente diferentes que no sólo pueden interactuar entre sí (como C y C++), sino que incluso pueden escribirse en un mismo código fuente, de manera que unas sentencias estarán en C++ y otras en C++/CLI.

A primera vista puede parecer extraño, pero lo cierto es que se trata de una aproximación también correcta (y lo demostraremos).

Si bien podemos compilar un programa existente como .NET, ese código no usa nada de .NET, y el código que creemos para usar .NET no se puede utilizar con el antiguo, no al menos de forma directa: no podemos tener una referencia manejada a un objeto nativo, ni un puntero nativo a una referencia manejada, no podemos obtener la dirección de un objeto manejado, y muchas otras limitaciones más.

Sin embargo, sí que hay otras cosas que podemos compartir de forma indistinta: muchos de los tipos nativos, podemos alojar un puntero nativo en una clase manejada (al revés también, pero con ciertas complicaciones adicionales), y podemos interactuar con código nativo de forma mucho más sencilla que con otros lenguajes.

RESUMIENDO, que es gerundio

Antes de entrar en otras profundidades, conviene hacer un breve resumen de lo que estamos tratando.

Hemos visto que Microsoft tiene dos lenguajes C++: el tradicional y el .NET, llamado C++/CLI. Con el primero ellos podemos construir programas tradicionales (MFC, QT, Win32, etc.). Con el segundo desarrollamos aplicaciones para .NET.

Por otro lado, podemos mezclarlos, o usarlos de forma combinada para crear aplicaciones mixtas que usen partes en Win32 o nativas y partes en .NET o manejadas.

No obstante, son lenguajes diferentes que comparten bastante sintaxis.

Rizando el rizo

Supongamos el siguiente programa, creado a partir del asistente para "Consola CLR", que es como MS llama a un programa C++/CLI en modo consola.

#include "stdafx.h"

#include <stdio.h>

using namespace System;

int main(array<System::String ^> ^args)
{
    printf("Hello World");
    Console::WriteLine("Hello World");
    return 0;
}

Si nos fijamos atentamente, es una mezcla de código nativo (la inclusión de stdio.h y la línea que contiene printf) y código puramente .NET, y si lo ejecutamos veremos cómo se imprimen ambas líneas por la consola.

Por otro lado, podemos elegir entre tres modos de generar un programa en C++/CLI: la opción por defecto es "/clr", aparte de "/clr:pure" y "/clr:safe". ¿En qué afectan a nuestro modelo? En bastantes cosas. La imagen siguiente nos localiza, dentro de las opciones del proyecto, el lugar en dónde cambiarlo:

La primera de ellas es que la opción "/clr:safe" no nos permite compilar código mixto; es decir, si intentamos compilar el programa de arriba con esa opción obtendremos una muy larga lista de errores en relación a la inclusión de stdio.h y del printf. Si quitamos esas dos líneas y compilamos con dicha opción nuestro programa, se ejecutará sin problemas, y si lo miramos por ejemplo con el .NET Reflector veremos que es idéntico (o casi) a cualquier otro programa equivalente escrito en, por ejemplo, C#.

"/clr:pure" nos dice que nuestro programa, aparte de acceder a código manejado, también puede tener código nativo compilado como código manejado. Y finalmente la opción por defecto nos permite, aparte de lo anterior, acceder a módulos completamente compilados como código nativo y a compilar la parte nativa como tal.

Por ejemplo, si compilamos nuestro ejemplo con cualquiera de las dos opciones reseñadas, obtenemos el siguiente código generado por el .NET Reflector:

int main(int argc, char modopt(IsSignUnspecifiedByte^)** argv)
{
    ::printf(&::?A0x67b7b245.unnamed-global-0);
    Console::WriteLine("Hello World");
    return 0;
}

Vemos cómo hacemos una llamada a la función printf, que es nativa, con una cadena también nativa y luego hacemos una llamada a WriteLine con una nueva cadena, esta vez todo código manejado.

Una primera aproximación nos dice que C++ es un subconjunto de C++/CLI ya que la llamada a printf se realiza desde código manejado, y el parámetro es la dirección de un miembro de una estructura global, o eso parece). Estamos en la primera aproximación.

Segunda vuelta al rizo

Veamos ahora el siguiente código:

#include "stdafx.h"
#include <stdio.h>

using namespace System;

void printk(const char *p)
{
    while(*p)
    putchar(*p++);
}

int main(int argc,char **argv)
{
    printk("Hello World");
    Console::WriteLine("Hello World");
    return 0;
}

Hemos cambiado poco, pero lo suficiente para ver ciertas diferencias en el código compilado resultante. Hemos añadido una función nativa que recibe un puntero a una cadena y la pone en consola.

¿Qué se imagina el lector que pasará al compilar esto tanto con "/clr" como con "/clr:pure" (recordemos que "/clr:safe" no puede contener código nativo de ningún tipo)? ¿Qué pasará con la función printk?

Veámoslo, pero esta vez con el ILDasm:

Da igual que lo compilemos con cualquiera de las dos opciones, de nuevo una función nativa ha sido compilada como manejada, estamos, otra vez, en el primer caso (y recordemos que .NET, junto a C#, permite punteros, algo no muy tenido en cuenta a veces).

El tercer rizo (y punto final)

Bueno, ya sólo nos queda un nuevo ejemplo de código:

#include "stdafx.h"
#include <stdio.h>

using namespace System;

#pragma unmanaged
void printk(const char *p)
{
    while(*p)
    putchar(*p++);
}
#pragma managed

int main(int argc,char **argv)
{
    printk("Hello World");
    Console::WriteLine("Hello World");
    return 0;
}

Hemos colocado nuestra función nativa bajo las directivas del preprocesador indicadas. Si ahora intentamos compilar este programa con la opción "/clr:pure", nos saltará un error diciéndonos que no podemos compilar la función printk como nativa bajo este modelo.

No obstante, si lo hacemos con "/clr", obtendremos el siguiente código para la función printk:

¡Ondia! No está, no hay nada… Realmente está ahí, pero al ser código nativo, ni el ILDasm ni el Reflector son capaces de verlo. Ahora nos hemos acercado un poco más a la segunda aproximación, en la que estamos viendo cómo C++ va por un lado y C++/CLI por el otro.

Sí, ya sé que es una forma un poco retorcida de verlo, pero sigamos…

Podríamos haberlo complicado un poco, compilando dos módulos independientes, uno con las opciones para C++/CLI y otro sin ellas, y haber hecho la llamada del manejado al nativo, pero ¡eso es exactamente lo que ocurría cuando hacíamos la llamada a printf!

O a cualquier otra función de Win32 o de una biblioteca de C++ nativa. Por tanto, la segunda aproximación también es completamente cierta. Alguien podría objetar que “eso pertenece a una DLL”, pero podemos compilar nuestro código con enlace estático al runtime de C y tendríamos el mismo caso: ejecutando código nativo y manejado desde un mismo ejecutable.

[1] Olvidémonos por completo de las managed extensions, haremos como si no existieran ni hubieran existido nunca jamás de los jamases J.

La estructura intraducible, I (de Interop y otras yerbas)

Rafael Ontivero — Fri, 19 Dec 2008 19:23:45 GMT

A veces resulta curioso cómo algo tan sencillo como mapear una estructura de C en .NET se puede convertir en un algo muy cercano a una pesadilla dependiendo del lenguaje que hayamos elegido para realizarlo. Partamos de la siguiente estructura de C:

typedef struct
{
    BYTE byOut[4]; // Outputs [0..3]
    BYTE byAux; // Aux output
} usbOutput;

A simple vista es algo muy elemental: un array de cuatro bytes y uno más después. Esto en una máquina Intel en realidad termina ocupando 8 bytes, 4 para el primer elemento y otros cuatro para el segundo si no se cambia la alineación.

La traducción a C# requiere de ciertos trucos un tanto oscuros y no muy bien documentados:

[StructLayoutAttribute(LayoutKind.Sequential)]
public struct usbOutput
{
    [MarshalAsAttribute(UnmanagedType.ByValArray, SizeConst = 4)]
    public byte[] byOut;
    public byte byAux;
}

Todo el secreto está en la declaración de los atributos que preceden al array. Básicamente le estamos diciendo al runtime que lo que viene a continuación es un array embebido directamente y no un array normal; es decir, que en lugar de guardar un puntero en la estructura y coloque el array en otro lugar, lo que está haciendo es colocar el array de cuatro elementos directamente en la estructura.

El autor no sabe si esa construcción funciona o no porque no lo ha probado, pero supone que debe hacerlo ya que si no difícilmente se iba a poder trabajar con Win32 desde C#.

Pero resulta que uno está haciendo el ensamblado en C++/CLI para aprovechar las facilidades del código mixto, por lo que piensa que la traducción directa servirá:

[StructLayout(LayoutKind::Sequential)]
public value struct usbOutput
{
    [MarshalAsAttribute(UnmanagedType.ByValArray, SizeConst = 4)]
    Array<byte>^ byOut;
    byte byAux;
};

Pero tras las primeras pruebas descubre que no, que .NET te ignora olímpicamente y el array byOut se queda como un puntero en la estructura, con el consiguiente desbarajuste cuando dicha estructura es bloqueada (mediante un pin_ptr) y pasada a la función nativa. Con la experiencia del autor, en general o bien se te cuelga el IDE o bien el aplicativo empieza a hacer cosas bastante extrañas…

Tras recorrerse Internet completo, de hecho el autor llegó hasta aquí, no descubre nada que le sea útil excepto una construcción de Nishant Sivakumar que no le funciona bien. Pero como el autor de esta entrada tiene el libro de Nish, busca el original y descubre que la versión encontrada en Internet no funciona, pero la del libro sí lo hace, pero funciona sólo en C++/CLI, ya que si se llama a byIn desde C#, el compilador falla debido a que la sobrecarga de operadores es mucho más versátil en C++ y C++/CLI que en C# y éste no sabe cómo actuar.

La solución de Nish se puede encontrar en la página 185 de su libro titulado C++/CLI in Action, que recomiendo encarecidamente a todo aquel que quiera aprender este lenguaje.

Mi solución parte de la de Nish con una ligera modificación, que es la de sustituir la sobrecarga del operador de acceso indexado, [], por el indexador por defecto.

La solución

La potencia expresiva de C++ es prácticamente infinita, ya que si existe alguna construcción en cualquier otro lenguaje que no exista en C++, resulta poco menos que seguro que se pueda simular y casi integrar en el lenguaje a través una biblioteca que simule el tipo o el constructo necesario, y eso es lo que aquí hemos hecho.

Necesitamos algo que nos permita insertar una secuencia repetida de un mismo elemento y que tenga semántica de array… Pues nada, elemental, querido Watson:

template<typename T,int size>
[StructLayout(LayoutKind::Sequential,Size=sizeof(T)*size)]
public value class FixedSizeArray
{
    T FixedElementField;
    public:
    property T default[int]
    {
        T get(int i)
        {
            return *(&FixedElementField+i);
        }
        void set(int i,T t)
        {
            *(&FixedElementField+i)=t;
        }
    }
};

Creamos un nuevo tipo que recibe un tipo llamado T y un entero que va a indicar el tamaño estático del array. Luego le decimos a .NET que nuestra clase es una estructura secuencial y que su tamaño es de tantas veces como elementos a repetir en relación al tipo base.

Y declaramos el tipo en cuestión, que hemos llamado FixedSizeArray y que contiene un elemento del tipo T. Asimismo posee un indexador por defecto que recibirá un entero que será el índice del elemento a leer o escribir. Lo único que le falta al ejemplo es controlar el tamaño del índice, pero como en el caso del autor es algo interno a él mismo, lo obvia.

La línea más curiosa de todas es el acceso al elemento interno:

*(&FixedElementField+i)

Expresándolo paso a paso, en primer lugar obtenemos la dirección de memoria de FixedElementField a través del operador &. A esa dirección añadimos el índice como si de un puntero de C++ se tratara, y luego desreferenciamos para obtener (o asignar) el valor.

A primera vista no debería funcionar, pero sí que lo hace ya que debemos tener conocimiento de cómo C++ y C++/CLI (y en general casi cualquier lenguaje orientado a objetos funciona). Cuando uno crea un objeto de una clase, sólo está creando el bloque de datos del mismo, ya que la clase ha sido traducida a una lista de funciones más o menos globales que residen en el segmento de código, y cuando se invoca un método cualquiera, realmente estamos haciendo una llamada de función global pasando en primer lugar un puntero a la dirección donde están los datos…

El uso de esta construcción es bien sencilla:

[StructLayout(LayoutKind::Sequential)]
public value struct usbOutput
{
    FixedSizeArray<byte,4>byOut;
    byte byAux;
};

Simplemente indicamos un objeto del tipo FixedSizeArray del tipo y tamaños adecuado. Y el acceso desde, por ejemplo, C#, todavía lo es más:

usbInput input=new usbInput();
input. byOut[2]=55;
Console.WriteLine(input. byOut[2]);
GetInputs(ref input);
//etc.

La única limitación de esta construcción es que sólo permite simular arrays de una dimensión. En una próxima entrada pondré cómo hacerlo para elementos de varias.