.NET o no .NET, esa es la cuestión : Win32

Llamando al API de WinRT desde aplicaciones de escritorio normales en C#

Rafael Ontivero — Sat, 02 Feb 2013 14:09:00 GMT

NOTA IMPORTANTE:

Esta entrada está obsoleta porque lo que describo más abajo no funciona tal y como está contado. Es un mea culpa en toda propiedad por no haber probado antes lo que escribía, pero es que la entrada original es bastante creíble.

Eso me llevó a crear un nuevo artículo, esta vez verificado, que se puede leer aquí:

Llamando al API de WinRT desde aplicaciones de escritorio normales en C#

******************************************************

El otro día twiteé un enlace que tenía apuntado por ahí y que no había leído hasta el momento del twitt, como me pasa con una docena más, que tengo en la lista de encontrar tiempo y tranquilidad para leerlos en detalle.

Y como creo que debería estar en castellano, os voy a contar de qué va la cosa.

Todos sabemos que ahora hay dos Windows 8. El tradicional de toda la vida y el RT. A ver, son el mismo, pero a la vez diferentes. El RT es la versión para tabletas, que en teoría permite desarrollar usando sólo un subconjunto de Win32 y de .NET, pese a que por debajo sigue estando el Windows de toda la vida.

La otra versión es la normal, la del escritorio pleno y funcional a la que estamos acostumbrados, que a su vez usa el API tradicional, ya sea el nativo Win32 o el de .NET.

Y si bien está prohibido usar el API completo en las aplicaciones RT, lo contrario no es así ya que en el escritorio tenemos plena libertad para utilizar cualquier cosa, incluyendo el API de Windows RT. Lo que ocurre es que el soporte directo para ello está ausente en las versiones de Visual Studio.

Pero se puede hacer editando el texto plano del fichero de nuestro proyecto: <proyecto>.csproj. Ahí dentro debemos añadir las líneas

</propertygroup>

Y a partir de ahí, una vez recargado el mismo, podremos usar el API de Windows RT con sólo añadir las referencias adecuadas según se vayan necesitando. El mayor problema es que tenemos que saber cuáles son y añadirlas a mano.

C++/CX (III). Objetos COM

Rafael Ontivero — Fri, 18 May 2012 14:14:09 GMT

Decíamos ayer y antes de ayer que para crear aplicaciones Metro en Windows 8 podíamos usar, o bien el .NET Framework 4.5 con C# y VB.NET o bien hacerlo con el tradicional C++. Ya conocemos que Microsoft se ha dado cuenta de que la cosa manejada no deja de ser un poco juguete comparada con la nativa, y que hay muchísimas empresas que siguen, no solo con C++, sino incluso con MFC.

Independientemente de eso, lo cierto es que el API para Metro no es más que una variación de Win32, empaquetada y ofrecida mediante objetos COM nativos. La idea es cambiar Win32 y prohibirla para Metro, ofreciendo su equivalente mediante la biblioteca WRL que no es más que un encapsulado exportado mediante COM.

Aquí parece como si Microsoft matara dos pájaros de un tiro, ya que .NET utiliza COM internamente, o lo más parecido y cercano a ello. Por lo tanto, lo exportado mediante la WRL es tomado, por un lado por .NET y por el otro por C++ con su extensión CX.

Tenemos que decir que C++/CX es código nativo. Sin recolector de basura. Sin máquina virtual. Compilado para un procesador específico. No es más que nuestro código escrito en C++ que utiliza objetos COM envueltos en una serie de clases al estilo de .NET. De hecho, la sintaxis de C++/CX es la misma que la de C++/CLI, por lo que en un principio puede llevar a confusión.

De todos modos, para aquellos que hayan leído el Rationale de Sutter (versión en español de Octavio Hernández y del que suscribe aquí), sabrán que es la única otra sintaxis posible y, o bien escribimos en C++/CLI para el .NET clásico (léase Windows Forms) o bien lo hacemos en C++/CX para Metro. Y si bien podemos hacer ambas cosas para Windows 8, las aplicaciones C++/CLI serán las tradicionales, y las C++/CX las Metro.

Con esto queremos decir que, usando C++/CX, tenemos acceso a toda la parafernalia nativa de C++ como la STL, Boost, C++11… y encima desarrollar para Metro. O dicho de otro modo: cualquier código que tengamos que no haga uso de ventanas ni de Win32 de forma directa no servirá para las aplicaciones Metro.

***

La parte CX se activa con la opción /ZW del compilador, y lo que hace es mapear los objetos COM en clases normales y corrientes. Allí donde antes teníamos que enfangarnos con IInspectable, y usar toda la parafernalia COM, ahora simplemente tenemos que usar una ref class normal y corriente con sus constructores, destructores, propiedades, delegados y métodos que recibirán los tipos de datos más estándar y que devolverán también valores estándar.

O en otras palabras: las clases que nos ofrece el API de Metro (por llamarlo de alguna manera, ya que es el API de WRL) son envoltorios a objetos COM WRL. Y de igual forma que los programadores de Windows han construido la WRL, nosotros también podremos tener objetos del mismo tipo, hechos por nosotros y ofrecidos a terceros.

Supongamos que tenemos una clase cualquiera con un método llamado Compute que toma dos enteros y devuelve un valor de estado. Para nosotros, que usamos dicha clase, tan sólo tenemos que llamar al método y esperar el resultado.

Pero internamente, lo que está haciendo el sugar syntax de la parte CX del compilador, es algo así:

//Parte del “consumidor” de la case
inline int Computer::Compute(int first, int second) {
    int result;
    HRESULT hr = ___impl_Compute(this, first, second, &result);
    if (hr != 0) ___impl_throw_for_hr(hr);
    return result;
}

Y luego, el método __impl_Compute, que está en el lado del componente (si fuera una clase WRL estaría dentro de la WRL), sería algo así:

HRESULT __stdcall ___impl_Compute(Computer* cmp,

int first, int second, int* result) {

try { *result = cmp->Compute(first, second); }

catch(Platform::Exception^ e) { return e->HResult; }

return S_OK;

}

De este modo vemos cómo podemos acceder a un método sin toda la parafernalia ni las ofuscaciones de COM. Y no queremos entrar en detalles sobre por qué COM es tan así, mayormente porque no tenemos ni repajolera idea.

No obstante, si así lo queremos por detalles de la implementación o simplemente por ser guays, tenemos acceso a la parte interna de WRL de la siguiente manera:

//Assuming 32-bit pointers

Computer^ computer = ref new Computer;

int* vtable_array = (int*)computer;

int* icomputer_vtable = (int*)vtable_array[0];

int* compute_will_be_fptr = (int*)icomputer_vtable[6];

typedef HRESULT (__stdcall *compute_fptr_t)(Computer*,

int, int, int*);

compute_fptr_t compute_fptr = (compute_fptr_t)compute_will_be_fptr;

//…use compute_fptr freely :-)

No voy a comentar nada de aquí porque simplemente me parece algo demasiado barroco y supongo que sólo será útil si te encuentras con algún bug en la parte CX del compilador… También podemos acceder a la interfaz COM pura a través del método RoActivateInstance, pero lo dejamos para los hardcore.

***

Finalmente hay una opción del compilador no documentada para que éste nos muestre una estructura detallada del componente WinRT que especifiquemos:

/d1reportSingleClassLayout<CLASSNAME>

Y de nuevo dejamos la opción para los aventureros, que yo ya me he cansado de escribir por hoy.

¿WinRT un subsistema? No, no lo es

Rafael Ontivero — Wed, 02 Nov 2011 16:41:00 GMT

Bueno, al final no ha costado mucho encontrarlo. Básicamente, el resultado de esta investigación es:

O con otras palabras: WinRT y Metro se ejecutan, como todo lo demás, sobre Win32, con las ventajas y los inconvenientes que eso pueda tener. No me malinterpretéis: no hay nada malo que la arquitectura sea diferente a la indicada en el gráfico de arriba, lo que está mal es que Microsoft nos mienta tan descaradamente. Simplemente eso.

Si lo han hecho así, por algo será y sus motivos tendrán, y es entonces cuando, ya definitivamente, yo tenía razón: Windows ya no es Windows NT, y su grandiosa arquitectura por bloques se ha perdido en el camino. Y esto sí que es malo, bastante malo, porque estamos volviendo a un batiburrillo de código como es, por cierto, el OS X (quizás algún día hable de ello).

Vosotros mismos podéis comprobarlo sin problema alguno y de forma muy rápida. Tenéis que construir dos aplicaciones, una WinRT en C++/CX y otra clásica de Win32. No hay más que utilizar las plantillas por defecto sin ningún cambio.

Eso sí, hay que hacerlo a partir de la versión Developer de 64 bits de Windows 8, e instalar una versión de la MSDN, porque la Express creo que no es capaz de generar programas Win32 puros.

He llamado “TestWin32” a mi aplicación tradicional, que genera una ventana de Windows normal y corriente utilizando directamente el API de Win32. A la Metro la he llamado “TestSplitApplication”. Una vez generadas, tenemos que compilarlas. Visual Studio se os quedará más o menos así:

Si ahora nos vamos a la carpeta en donde está almacenado el proyecto (que podemos hacer desde el mismo IDE posicionándonos en el nombre de la solución en el Explorador y elegimos Open Folder in Windows Explorer), carpeta Debug, encontraremos el ejecutable del programa nativo (TestWin32.exe) y dentro de la carpeta TestSplitApplication, el de la aplicación Metro.

(Por cierto, en uno de esos lapsus teclae tan habituales en mi, le he dado el nombre de “TestSplitApplicarion” en lugar del correcto.)

Ahora debemos conseguir el Dependency Walker, aunque existen otras herramientas de línea de comandos que nos permiten hacer lo mismo dentro del SDK, lo interesante es utilizar esta porque lo veremos todo de un golpe. El mayor problema es que se trata de una utilidad que hace tiempo que no se incluye en ningún SDK, por lo que hay que conseguirla de forma externa.

Una vez obtenida la versión de 32 bits, porque nuestros proyectos son de dicho tipo, la ejecutamos sobre cada uno de los dos programas. Este es el resultado:

¿Lo veis? Ambos programas importan las mismas DLL, las de Win32 como KERNEL32.DLL y USER32.DLL.

Es decir que ambos son aplicaciones Win32 nativas.

***

Si nos diera por abrir, por ejemplo, uno de los dos KERNEL32.DLL, veríamos que ambas DLL son la misma con las mismas dependencias y exportaciones. Por lo tanto, ambas aplicaciones dependen del mismo subsistema.

Reitero que es una tontería, pero no lo es cuando intentan engañarte.

Lo que sí parece han hecho ha sido romper KERNEL32.DLL en otros ficheros más pequeños que contemplan subconjuntos de lo que en versiones anteriores había en él. Quizás de esta forma reduzcan la huella de memoria evitando cargar sub ficheros cuando estos no se vayan a utilizar.

***

Esto nos lleva a un tercer problema: parecer ser que una aplicación Metro no puede ejecutar funciones de Win32, y una de Win32 tampoco de WinRT.

¡¡Pero si es el mismo subsistema!!

Pues bien, estamos ante una limitación artificialmente impuesta por Microsoft sin ningún motivo técnico aparente… con lo guapo que sería hacer aplicaciones Win32 con C++/CX…

Se me ocurren un par de trucos para poder forzar esto, pero no creo que valga la pena hacerlo en una versión tan temprana como esta. Quizás cuando salga la definitiva, si tengo ganas y si nadie más se me adelanta, lo intente.

C++/CX (I). Windows 8 y el nuevo subsistema WinRT

Rafael Ontivero — Mon, 31 Oct 2011 14:34:00 GMT

Observad con detalle la imagen de arriba. Fijaos en que está dividida en dos grandes bloques. A poco que os haya preocupado la arquitectura lógica de Windows, os daréis cuenta de que hay nueva chica en la oficina: WinRT.

Ya hablé de algo así aquí, pero en relación con la arquitectura de Apple comparada con la de Windows, y de los últimos cambios que Microsoft ha ido haciendo para adecuar su plataforma NT para que sea funcional y útil para el usuario medio, dejando un poco de lado la arquitectura tradicional.

Pues bien, parece ser que me tengo que comer mis palabras con patatas (no, no esas patatas, Z). Volviendo al gráfico anterior, WinRT es un nuevo subsistema igual que lo es Win32. Para aquellos que no tengan claro qué es, os cuento un poco la arquitectura teórica de Windows NT.

El sistema operativo cuenta con un kernel (sí, como el de Linux, pero con muchas más cosas dentro de él y mucho más dinámico), que en teoría se asienta sobre una capa HAL que abstrae a dicho núcleo de la arquitectura física. En su momento hubo HAL para ARM y para otras plataformas. En la actualidad sólo la hay para x86, tanto en versión de 32 como de 64 bits.

O eso creía tras haber hecho un somero análisis de las tripas de Windows 7. Pues bien, si Microsoft añade soporte para ARM (y recordemos que van a salir procesadores de este tipo de 64 bits), dicha capa debe ser o bien reimplementada o bien ya existía y simplemente estaba inactiva. O lo que me parece más lógico: recompilar todo el sistema operativo para que se ejecute en dicha arquitectura, cambiando lo que haya que cambiar, dado que eso de traducir cualquier otro procesador a x86, sobre todo desde un ARM, suena a fantasía animada de ayer y de hoy.

Por otro lado, Windows se mueve mediante subsistemas. Uno de ellos es Win32. Otro lo fue OS/2 y también Posix (sí, en un pasado lejano, Windows NT era capaz de ejecutar comandos de unix con las primitivas de desarrollo que tiene la parte estándar Posix de Unix). Es decir, un subsistema suministra cierta abstracción sobre el núcleo, proporcionando un API mucho más rico y potente. Y de paso lo aísla para que las aplicaciones sean incapaces de tumbarlo.

En otras palabras, Win32 se ejecuta en el anillo 3 y el núcleo en el cero, y es Win32 el que, cuando una aplicación pide algún recursos del sistema (por ejemplo un puerto serie), el que se encarga de mover la petición y de realizar tareas intermedias, evitando así que un mal uso por parte de una aplicación genere una pantalla azul.

Digamos que una aplicación en el anillo 3 jamás podrá tumbar al sistema ejecutándose en el anillo 0, o al menos esa es la teoría. A veces un parámetro mal pasado puede terminar en una caída completa, pero no es lo habitual, y cada vez menos.

Pues bien, aparte de Win32, ahora tenemos un nuevo subsistema llamado WinRT. O eso dice, al menos la teoría y así nos lo presenta Microsoft en sus gráficos y en la escasísima información de la que disponemos.

Una de mis próximas tareas es la de intentar averiguar si esto es así o no lo es. No es la primera vez que Microsoft miente descaradamente, como cuando dijo de XAML no iba a necesitar de Win32 y que desaparecían los bucles de mensajes y que se ejecutaría sobre DirectX… Hasta donde sé, todavía eso no es del todo cierto.

También nos dijo que .NET iba a ser un subsistema, y realmente se ha quedado como una capa sobre Win32…

Por lo tanto, estad atentos al blog. Además, el dibujo original de Microsoft deja mucho que desear respecto a la claridad, presentando Internet Explorer y .NET como subsistemas independientes de Win32, lo que es, a todas luces, completamente falso:

***

Volviendo al gráfico de arriba, podemos ver algunos detalles que creo no son del todo ciertos, pero nos dan una idea de la arquitectura del nuevo WinRT (sobre la que se basa la interfaz METRO que llevará, junto al escritorio tradicional, Windows 8).

(Una de las cosas por las que dudo que WinRT sea un subsistema completo es el hecho de que Windows 8 consuma menos memoria que el 7 y de que se pueda producir ese intercambio tan rápido entre los dos escritorios, lo que me hace pensar que, de nuevo, se trata de algo sobre Win32).

En WinRT hay dos interfaces de desarrollo principales: XAML y HTML. Es decir, podemos hacer aplicaciones clásicas basadas en el primer modelo y modernas en el segundo.

A simple vista puede parecer que en ambas se utiliza una misma variación del XML, pero no es así. En el caso de HTML/CSS nuestra aplicación no será otra cosa más que una página web ejecutándose dentro de una sesión más o menos oculta de Internet Explorer. Tendremos acceso a esas dos tecnologías (incluyendo HTML5) y JavaScript como lenguaje de desarrollo.

En el caso de XAML, estamos ante la última evolución de las interfaces de usuario dinámicas en las que la interfaz está completamente (o lo más posible) separada del código en sí, lo que permite una soltura nunca vista hasta ahora. O al menos esa es la teoría y casi os diría que la práctica.

XAML es muy potente. Demasiado, casi diría. Se trata de una especie de colección de contenedores jerárquicos que pueden actuar como tales o como elementos finales, y pueden mutar de un tipo a otro con una facilidad pasmosa. De hecho, cambiar el aspecto visual de una aplicación XAML puede llegar a ser cosa de unas pocas –muy pocas- líneas de código, con el añadido de que quien haya desarrollado con .NET y la versión anterior, está casi listo para esta nueva (que por cierto no es mi caso, pese a ver en su momento las ventajas evidentes del nuevo modelo).

Por lo tanto, los programadores de .NET que hayan abandonado Windows Forms por la nueva forma, lo tendrán bastante fácil. Los dinosaurios como yo mismo tendremos ciertas dificultades en adaptarnos… o no.

¿Recordáis C++/CLI, el C++ del .NET? Pues bien, la única pega para que dicha extensión de C++ pudiera utilizar XAML es que no se soportan las clases parciales como en C o en VB.NET. Por desgracia, eso sigue siendo así, y la interfaz clásica continua estando vedada para los programadores de C++ en .NET, quedando limitados a Windows Forms y a un IDE que no es que se muestre muy estable manejando el lenguaje…

***

Bueno, ahora, por fin, entra C++/CX. ¿Qué es? Nada más y nada menos que una nueva extensión a C++, con una sintaxis muy similar a C++/CLI pero con un propósito muy diferente: el de soportar METRO y XAML. Y no, no es .NET. Es nativo.

Supongo que Microsoft se planteó ante una disyuntiva muy pero que muy gorda: el rendimiento de .NET es suficiente para un PC, pero no lo es para una plataforma móvil como una tableta. No estoy diciendo que sea malo, estoy diciendo que eso de tener una máquina virtual consumiendo memoria y recursos, un jitter ejecutándose detrás de todo, y un post-compilador pasando MSIL a código nativo no es de recibo para un Tablet.

Delante de todos está el fracaso de Android. Por favor, absteneros fundamentalistas y otros pájaros de similar calaña: Android es un fracaso. Puede que aguante unos cuantos años, pero terminará por caer estrepitosamente, tanto por problemas técnicos (demasiado consumo de memoria, demasiada lentitud, demasiadas capas una encima de otra, demasiadas caídas) como por comerciales (demasiada fragmentación, demasiado abandono de terminales a medio hacer), etc..

Por lo tanto, para competir en igualdad de condiciones, tenemos que darle caña a iOS. Se debe hacer algo similar, y ese algo es WinRT y C++/CX. No hay máquina virtual .NET, ni nada oculto (o eso quiero creer), tan solo un motor de ejecución, una interfaz y el propio sistema operativo. O en otras palabras: objetive-c, cocoa y lo que quiera que haya en el núcleo de iOS (parece ser que un BSD recortadito).

Otro problema es la arquitectura. Ya se ha demostrado que x86 es demasiado pesado y demasiado hambriento de energía como para ser útil en el mercado móvil, por lo que hay que subirse al carro de ARM, que son micros mucho menos complejos y por tanto consumen mucho menos y andan más sueltos.

Por lo tanto se necesita algo diferente, algo mucho más liviano. Y eso, de nuevo, es WinRT. Por lo tanto, la combinación ganadora es C++/CX, XAML y, cómo no, C# y VB.NET corriendo sobre una variación de .NET llamada .NET 4.5 WinRT (y que funcionará más lento y consumirá más batería que una aplicación realizada con C++/CX).

Pero el núcleo, el centro de todo, es C++ y WinRT. Luego está .NET, encima igual que en Win32. Como debe ser. Y de nuevo absténgase fundamentalistas. Si lo han hecho por algo será. Quien cae del árbol a tiempo todavía puede recuperarse.

***

C++/CX no es .NET. Es nativo. Y la parte CX no es más que un envoltorio cómo para los interfaces COM, ese animal mitológico con el que los programadores de C++ nos tenemos que enfrentar de tiempo en tiempo y que nos pone los pelos de punta.

Es decir, la parte CX sólo se utiliza para interactuar con XAML y los componentes que se hayan creado a tal efecto. Luego, nuestro código será C++ normal y corriente, con la STL, los streams (que personalmente pienso que no son muy útiles), Boost o lo que queramos usar y esté disponible. Desarrollo determinista por completo, sin recolector de basura (a no ser que nos hagamos uno), sin elementos ocultos excepto el envolvente COM que han llamado CX y que nos servirá para interactuar con los componentes.

Otra ventaja de C++/CX sobre .NET es que, si quieres hacer un juego sobre DirectX, tendrás que usarlo ya que ni C# ni VB.NET están soportados, de nuevo como debe ser.

Ah, y con soporte para clases parciales, lo que… bueno, mejor lo dejamos para más adelante.

MAC Rationale vs Windows Rationale en el desarrollo

Rafael Ontivero — Sat, 19 Mar 2011 14:42:00 GMT

Todavía estoy leyendo temas generales sobre el desarrollo en MAC, de hecho aún no he pasado de los manuales que describen las tecnologías y los diferentes bloques en que se divide el desarrollo en MAC.

No obstante me ha surgido una curiosa reflexión que quiero compartir con vosotros. Todavía no estoy muy seguro de que sea completamente cierta, porque todavía no he profundizado en los conceptos MAC y lo que he leído tiene más que ver con la publicidad del desarrollo en esta plataforma que otra cosa, pero creo que tiene muchos visos de ser real como la vida misma.

Y lo más curioso de todo es que tiene mucho que ver con el desarrollo Windows, y más cercanamente al de las tecnologías .NET. Cuanto más leo sobre Cocoa, QuickTime (que no sólo es un programa sino una tecnología), etc., más me parece estar leyendo sobre .NET, o más bien sobre la forma en la que se publicita .NET.

Se habla de grandes grupos de tecnologías orientadas a objetos, con grandes rendimientos y grandes facilidades ofrecidas a los desarrolladores. Calcado uno de otro. Ahora habrá que ver la pura realidad.

Del lado .NET ya lo tengo claro: mucho ruido y pocas nueces, al menos para desarrollo de sistemas. Quiero creer que del lado MAC no será igual, pero cualquiera sabe. Ya os iré diciendo.

***

Pero no, no es sobre eso sobre lo que os quería hablar. Veamos por un lado la arquitectura lógica expresada por los manuales de MAC, que creo es más real que la dicha por los de Windows.

Debajo del todo un ordenador de Apple hay un Kernel BSD que no es otra cosa que una variante de UNIX igual que es Linux. Y luego hay un sistema POSIX de toda la vida que de nuevo tiene que ver con el mundo UNIX (que viene a ser como una serie de servicios que simplifican el acceso al núcleo del sistema igual que una consola de comandos en Windows permite trabajar con ficheros sin tener que tocarlo).

Aunque Apple lo ha llamado Darwin, no deja de ser lo que es, y de hecho Apple publica todo el código fuente de ello. Al ser un estándar debe estar separado. Realmente está separado.

Encima de eso hay una serie de capas, Cocoa, Carbon, QuickTime. Más o menos. Pero lo que es cierto es que esos subsistemas están completamente separados del núcleo o más bien encima de él.

En Windows creo que no es así. En su momento, en las versiones NT originales sí que lo era (o al menos así se publicitaba). Recordemos la capa HAL que podía ser para un montón de procesadores y luego el sistema NT Executive nativo, que corría sobre dicha capa. Pero ahora, después de la unificación con la plataforma 9x en lo que fue Windows XP dudo mucho que siga siéndolo.

Porque ahora no hay soporte para ARM, ni para SuperH, ni para PPC. Sólo Intel x86 y dando gracias. Me juego un gallifante a que ahora está todo mezclado y revuelto (y de ahí los problemas de Microsoft para volver a añadir soporte para ARM). Porque si no fuera así no se entendería cómo puede funcionar el sistema de vídeo sobre Win32 accediendo al driver que está en el núcleo (sí, ya sé, anillos, gateways y todo eso, pero no voy por ahí)…

Bueno, quizás en esto me equivoque, pero si alguien me explicara cómo el hecho de reproducir un vídeo dentro de un navegador pueda generar una BSOD estando los sistemas separados, que me lo diga. Porque me ha pasado. Y no una, sino varias veces. Putas ATI.

De todos modos luego veremos alguna razón más de ello y quizás uno de los puntos más fuertes de por qué Microsoft está un poco contra la espada y la pared.

***

Apple ya lo ha hecho al menos dos veces y lo va a hacer una más. En x64 no va a haber Carbon, que es como se le llama al subsistema que soporta programar en C y C++ de forma nativa. En x64 sólo vamos a tener Cocoa (Objetive-C y Objetive-C++) y POSIX (que yo sepa). En su momento, con el cambio de PPC a x86 repitió jugada, haciendo borrón y cuenta nueva y forzando a muchas empresas de software a reescribir sus programas. Como cosa curiosa os diré que Apple encargó a Adobe la creación de su iPhoto, iVideo y demás programas de esa plataforma y Adobe los mandó a freír espárragos porque estaban como locos rehaciendo sus propios programas. Creo que hubo otro cambio rompedor más en los MAC pero ahora no recuerdo qué.

Bueno, el meollo del asunto está en que a veces es conveniente hacer borrón y cuenta nueva. Hasta donde sé, el API de MAC OS X y el de iOS es un API moderno, orientado a objetos y bastante potente. Ya os diré si realmente es cierto cuando me enfangue las manos con ello.

***

Ahora volvamos a Windows. Aquellos que hayan leído sobre el tema, sabrán lo que son los subsistemas. Para los que no, una pequeña introducción.

Win32 es un subsistema. POSIX es un subsistema (o lo era hasta que lo quitaron). De hecho, en las primeras versiones de NT había hasta un subsistema OS/2.

Un subsistema es una API completa que sirve para que las aplicaciones escritas para tal subsistema se ejecuten en él, sean independientes del núcleo y no puedan afectarlo en ninguna manera. Ved la siguiente imagen de la Wikipedia y fijaros arriba a la derecha.

http://en.wikipedia.org/wiki/File:Windows_2000_architecture.svg

Básicamente esa debería ser la arquitectura de Windows. Fijaros también en lo que hemos hablado antes sobre el HAL y el Executive.

¿Realmente Windows es así? Creo que no. Teóricamente si cogéis un programa 100% compatible POSIX y lo ejecutáis en Windows 2000, debería funcionar. ¿Lo hace? Pues no. En su momento lo probé y no funcionaba. Tampoco lo hacía uno de OS/2 cuando ese subsistema estaba, todavía, presente. No es que no funcionaran bien o hicieran alguna cosa rara, es que la mayoría de veces simplemente no cargaban.

¿Ha visto alguno de vosotros un Windows NT ejecutado en un ARM o en un SuperH? Yo no y no creo que funcionen. ¿Vais viendo ya por dónde voy?

Con esto no quiero decir que nunca hayan llegado a funcionar, lo que quiero decir es que yo al menos no lo conseguí en su momento. En un MAC moderno podemos ejecutar prácticamente cualquier comando típico UNIX, desde un “ls” hasta un “ps” pasando por un “dd” o lo que queramos. Aparte de los que la propia Apple ha añadido, que hay unos cuantos.

De nuevo no me malinterpretéis, en ningún momento estoy diciendo que un MAC sea mejor que un Windows por eso. Simplemente estoy diciendo que en un MAC sí que están separadas y presentes las distintas piezas, o al menos así lo creo. De nuevo el tiempo me lo dirá, y yo a vosotros.

***

Y ahora entramos de lleno en .NET. ¿Por qué .NET no es un subsistema y sin embargo está construido sobre Win32, que no es precisamente un API limpia y ordenadita sino más bien todo lo contrario? ¿Por qué no aprovecha Microsoft la arquitectura de los subsistemas para hacer a .NET miembro de derecho propio dentro de Windows y no un mero envoltorio que cada vez se va pareciendo más a lo que envuelve, sobre todo en el tema de la guarrería?

Si ya .NET es algo grande en el aspecto del rendimiento y funcionalidad (comparado con su contrapartida Java y a veces con el propio Win32), ¿qué rendimiento no tendría si fuera un subsistema independiente?

¿O es que toda la estructura arquitectónica de Windows es una mentira como un castillo y no puede haber otros subsistemas cooperando sobre el ejecutivo?

Me gustaría que alguien me aclarara todo esto, porque sinceramente no lo entiendo. Yo tengo mi teoría, que no voy a exponer aquí no sea que se me acuse de lo que creo no soy, y menos ahora que tengo mi calentón de fanboy…

GetWindowText() en ropa interior

Rafael Ontivero — Tue, 18 Jan 2011 20:44:46 GMT

Justo he empezado a leer The old new thing de Raymond Chen, que es un libro entresacado a partir de las entradas más interesantes del blog del autor. Y me está gustando tanto que lo estoy leyendo como si fuera una novela de aventuras, sección tras sección. En él hay un curioso capítulo que trata de las interioridades de la función de Win32 GetWindowText() que no he podido reprimirme en parafrasearlo aquí.

Para aquel que no lo sepa, dicha función devuelve en uno de sus parámetros el título de la ventana o el texto contenido en un control, dependiendo sobre qué tipo de ventana se ejecute.

Lo curioso es ver cómo funciona. Si la llamamos sobre una ventana de nuestro propio proceso, la función genera el mensaje WM_GETTEXT para que seamos nosotros mismos los que devolvamos el texto que queramos. Evidentemente si no capturamos el mensaje, será Windows quien devuelva el valor por defecto, que será el mismo que si se realiza la llamada a una ventana de otro proceso. En este caso, la función devolverá la cadena que Windows ha almacenado interiormente y que contendrá lo dicho.

Curioso, ¿no? De hecho en el libro de Raymod viene un ejemplo para hacer que una ventana devuelva un texto diferente según se llame desde el mismo proceso o fuera de él.

¿Por qué funciona esto así?

Según Chen es muy sencillo, y viene de la herencia de Windows 1.0 y versiones posteriores en las que la multitarea era cooperativa.

Imaginemos que vamos a mostrar la lista de programas en ejecución. Para ello, el programa enumerará todas las ventanas principales de Windows y les pedirá su nombre a través de GetWindowText(). Ahora supongamos que uno de esos procesos está colgado por algún motivo. Si la función genera un WM_GETTEXT sobre dicho proceso tonto, Windows al completo se quedaría bloqueado porque al no procesar el mensaje, la función nunca retornaría y un supuesto programa “matador” de procesos que no responden también se colgaría…

Por lo tanto, los diseñadores de Windows decidieron que una llamada a GetWindowText() debería comportarse tal y como se ha descrito más arriba. Es decir, si un proceso usa la función sobre sí mismo, es indicativo de que el bucle de mensajes está funcionando bien y por tanto podrá responder a un WM_GETTEXT. Pero si se hace desde otro proceso, nadie garantiza que el bucle de mensajes del llamado esté funcionando bien, por lo que entonces Windows toma el valor almacenado internamente, que generalmente es el nombre de la clase de ventana o el título de la misma.

De este modo, al menos desde Windows 95, un proceso tonto no tumba al sistema cuando intentemos matarlo desde el Administrador de Tareas o desde cualquier otro programa enumerador.

Hemos leído: Windows Internals 5ª Edición

Rafael Ontivero — Wed, 03 Mar 2010 12:38:00 GMT

No sé si es que la memoria me falla, o que tiempos antiguos fueron mejores o que simplemente he mezclado dos libros, pero lo cierto es que este libro me ha reportado más desilusiones que ilusiones. Recuerdo haber leído ediciones anteriores (la cuarta seguro que no), aunque en mi biblioteca física –la de los libros en papel, vamos-, sólo veo el de Helen Custer, que fue, si de nuevo las meninges no me engañan, el primero o la precuela de la serie. Pero lo que no recuerdo es que fuera tan políticamente correcto, y eso es lo que me ha defraudado de este.

Porque en el libro no viene nada que no esté documentado en el DDK, el SDK u otra documentación emitida por Microsoft, lo único es que, aquí, está todo reunido de una forma más o menos coherente, organizada y en papel.

Es evidente que intentar explicar en un libro –aunque sea de más de 1200 páginas- el funcionamiento de un sistema operativo que tiene más de cincuenta millones de líneas de código es tarea imposible.

Lo que no esperaba es que fuera tan políticamente correcto, tan formalmente estudiado para no resultar inadecuado, ya que seguro muchas de las cosas que se cuentan en él no son tal y como se han presentado, o se han omitido. Y estoy seguro de ello, porque en algunas secciones hay huecos y cosas que no están del todo explicadas. Si bien se pueden deber al desconocimiento de los autores, o al recorte de páginas, el texto podría haber sido más fluido. Hay secciones enteras que no son más que un mero recitamiento en plan loro de lo aprendido, en lugar de resultar un continuo coherente. Y de hecho, hay partes que no las he leído por aburridas, pesadas y por apuntar a ser un mero listado de características tal y como se pueden encontrar en una documentación oficial.

Y como muestra de lo omitido, un botón: ¿Se fragmenta el registro de Windows?, escrito en este mismo blog. Pues bien, hay muchas secciones así, que te dejan con la palabra en la boca, como si sólo te hubieran contado lo que han querido…

No obstante esas pegas, que pueden enteramente deberse a mi mismo y a que no aceptaría la invitación a un club que me aceptara como socio (parafraseando del mala manera al insigne Groucho), el libro debe ser una gozada para muchos administradores y algunos programadores, ya que te explica muchas cosas que de otro modo quedarían al aire o como interpretación de un curso de sistemas operativos 101.

Así mismo, en aquellos casos en los que pienses que el problema no está en tu código o tu script, puedes bucear dentro de las estructuras internas de Windows (allá donde el libro las explica, que no es en muchos sitios, la verdad) para descubrir dónde te has equivocado tras muchas horas de investigar donde no era.

Y poco más que contar, si quieres ver qué trae el libro por dentro, pues te das un voltio por Amazon y miras el índice.

Conversión ANSI a Unicode y viceversa

Rafael Ontivero — Wed, 03 Feb 2010 11:51:00 GMT

Seguro que no es la primera vez que te pasa que te dejan una serie de rutinas (generalmente en formato DLL) que reciben cadenas en formato ANSI y tu aplicación está escrita en Unicode, y cuando preguntas si tienen versión Unicode te responden que no y que no la van a tener… Y como no quiero perder mi empleo, voy a parar aquí.

Pues bien, existe una forma muy sencilla de pasar cadenas entre ambos formatos sin tener que liarnos con las funciones de conversión de Win32, que no son precisamente fáciles de manejar. Y como esto va a modo de receta, no entro en más detalles.

Lo primero es incluir atlconv.h en aquella unidad de compilación en donde vayamos a hacer conversiones.

Lo segundo es colocar la macro USES_CONVERSION; dentro del método en el que vamos a realizar las conversiones.

Lo tercero es declarar un puntero ANSI o Unicode dependiendo de si queremos pasar de un lado a otro.

Y finalmente usar la macro adecuada. Veámoslo con un ejemplo:

#include <atlconv.h>

Void FuncionQueNecesitaPasarDeANSIaUnicode(void)
{
    USES_CONVERSION; //ANSI 2 UNICODE macros

    char szCad[MAX_PATH];
    LPWSTR szCadUnicode;
    FuncionQueNecesitaANSIporqueNoTieneUNICODE(szCad);
    szCadUnicode=A2W((LPCSTR)szCad);

    CString printCad;
    printCad.Format(_T("ATPC: %s"),szCadUnicode);
    AddLogString(printCad);
}

Hay una espuerta de macros con el formato

[C]<origen>2[C]<destino>[EX]();

Origen y destino pueden ser A para ANSI, W para Unicode, T para cuando estamos generando código agnóstico en cuanto al formato de cadena, y OLE para cadenas OLE. C se usa para cuando es una cadena constante.

De este modo, A2W convertirá de ANSI a Unicode, y W2A al revés. Aquí la referencia completa.

Todo lo que quisiste saber sobre las DLL y no te atreviste a preguntar (II)

Rafael Ontivero — Fri, 29 Jan 2010 11:28:00 GMT

Como podéis ver no se me ha olvidado el tema, simplemente es que he estado demasiado gandulete como para escribir sobre esto, pero una pregunta en el foro web de C++ me ha hecho que me ponga a ello. En teoría esta debería ser la tercera parte en lugar de la segunda, aunque la verdad no es que realmente tenga mucha importancia. Por lo tanto, esta entrada que estás leyendo sigue a esta otra.

Aquí voy a contar los tres modos que hay de usar una DLL desde C y C++, aunque solo voy a explicar dos de ellos porque el tercero digamos que viene de las primeras versiones de Windows y ni siquiera sé si los compiladores modernos la soportan.

Pero antes, una introducción.

¿Qué necesito para usar una DLL de terceros?

Cuando vamos a usar una DLL, ya sea nuestra o de terceros, se nos deben suministrar al menos tres archivos. El primero, que no nos haría falta para el segundo método, es un fichero cabecera conteniendo los prototipos de las exportaciones de la DLL, es decir, las firmas de las funciones y la declaración de los tipos contenidos.

En general, el formato de cada prototipo debe seguir de cerca el siguiente formato:

__declspec(dllexport) __stdcall int HazAlgo(int algo);

extern “C” __declspec(dllexport) int HazAlgo(int algo);

La primera firma declara una función con formato de llamada estándar (el __stdcall) que pertenece a una DLL y que resulta exportado, es decir, que podemos usar. La segunda declara lo mismo pero con el protocolo de llamada de C, que también podríamos haber puesto como __cdecl. Del protocolo de llamada ya hablé en la entrada anterior, y en general todos los compiladores de C y C++ deberían entender ambas declaraciones, y si no lo hacen seguro que tienen expresiones similares.

El segundo fichero es lo que se conoce como biblioteca de importación, que es un archivo con la extensión .lib, con la diferencia de que, en este caso, en lugar de contener las propias funciones como en una biblioteca normal, lo que contiene son las firmas de las funciones exportadas y cómo están relacionadas con la propia DLL.

En el mundo Windows existen dos formatos de ficheros .lib: el COFF, que es el que usa Microsoft y compiladores compatibles y el OMF, que es el que usan otros compiladores como el C++Builder. Generalmente todos los compiladores suelen venir con una herramienta de conversión de formato.

Y finalmente necesitamos la DLL y todas sus dependencias si las hubiera.

En general muchas veces no es necesario recompilar el código de nuestra aplicación cada vez que se modifique la DLL si no hemos cambiado nada de la parte pública. Creo que incluso si se añaden funciones a la DLL tampoco es necesario recompilar siempre y cuando no se cambie ninguna declaración de las existentes y enlazadas.

Primer método: el fácil

El método más sencillo para usar una DLL en nuestro código en C o C++ es añadir la biblioteca de importación (el fichero .lib) a las demás bibliotecas en nuestro proyecto, lo que se suele hacer en las opciones del enlazador.

Luego incluimos el fichero cabecera en donde nos haga falta y ya está todo hecho: tan sólo debemos llamar a las funciones de la DLL como si fueran funciones normales y corrientes.

Debemos tener en cuenta que si la DLL contiene clases o tipos no estándar, quizás el enlazador sea incapaz de encontrar los nombres porque cada compilador de C++ ofusca el nombre de las funciones de una manera diferente, y en ese caso sólo nos queda la opción de o bien pedir una DLL compatible con nuestro compilador o bien hacer un strip del fichero LIB, ver cómo se llaman en realidad las funciones, y hacernos nosotros mismos el fichero cabecera. No os lo recomiendo.

El último paso es dejar la DLL en una ruta que nuestro programa sea capaz de encontrar, como el directorio donde se está ejecutando o en algún camino disponible en el PATH.

Segundo método: carga dinámica

No lo he dicho antes, pero cuando se usa el primer método, las DLL se cargan de forma automática a la vez que nuestra aplicación, y siguen en memoria hasta que salimos.

Existe una forma de carga manual un poco más laboriosa, pero que nos permite cosas como la carga dinámica de temas, de extensiones, de plugins o de diferentes versiones de una misma DLL.

Supongamos que tenemos una DLL con las cadenas para cada idioma. Cuando arranquemos nuestra aplicación miramos qué idioma está en la configuración y cargamos manualmente la DLL adecuada. Es lo que hace automáticamente el sistema MUI de Windows y la internacionalización en .NET y otros lenguajes. Pues de igual forma que se hace automáticamente, se puede hacer manualmente.

Para este método sólo necesitamos la DLL en cuestión y la lista de prototipos de funciones. Lo primero es hacernos un puntero a función de cada una de las funciones de la DLL:

int (__stdcall *pHazAlgo)(int);

Luego llamamos a la función de Win32 LoadLibrary() pasándole la cadena en donde está la DLL que queramos cargar. La función nos devolverá un HINSTANCE, que si todo ha ido bien será diferente de NULL. Entonces, para cada una de las funciones de la DLL, la cargamos sobre nuestro puntero mediante GetProcAddress() pasándole el HINSTANCE y la cadena con el nombre de la función en la DLL:

pHazAlgo=GetProcAddress(hLib,”HazAlgo”);

Ahora tendremos un puntero a función (que realmente es un doble puntero, porque ese puntero apunta a una tabla dentro de la DLL que a su vez apunta a la función real). Con ese puntero podemos llamar a la función sin problemas:

int respuesta=pHazAlgo(3);

Quizás tengas que hacer algún tipo de moldeo en la llamada a GetProcAddress().

Cuando queramos descargar de memoria esta DLL, llamamos a FreeLibrary() y será descargada. Nuestros punteros seguirán asignados, pero apuntarán a ningún sitio, por lo que si volvemos a necesitar la DLL (u otra versión de la misma) deberemos repetir el proceso.

Tercer método: ordinales y ficheros DEF

Este es el que no voy a explicar porque es muy antiguo y ni siquiera sé si sigue siendo válido. Antiguamente las funciones dentro de las DLL se guardaban numeradas. Es decir, en lugar de guardar una cadena con el nombre y un puntero a la relación relativa dentro del fichero en los metadatos de la DLL, se guardaba un array de punteros que apuntaba a cada una de las funciones.

Luego se tenía un fichero DEF que ponía el nombre de la función y el ordinal que tenía dentro de la DLL (la posición dentro de ese array), de forma que cuando se compilaba un programa para una DLL de este tipo (usando el fichero DEF en lugar del LIB), se dejaba un array de punteros a funciones que el cargador pareaba con el de la DLL…

Ya os podéis imaginar la que se podía armar si por cualquier motivo ese orden era cambiado por el compilador. El que faltara un ordinal simplemente lanzaba un error, pero el que se cambiara uno por otro podía terminar tumbando no solo nuestra aplicación, sino Windows al completo, ya que en aquella época las DLL sólo se cargaban una vez y eran usadas y compartidas por todas las aplicaciones que la requerían, sistema operativo incluido.

Esto se hacía así porque con la velocidad de los procesadores de aquellos años, el tiempo para buscar la cadena con la función en los metadatos y parearla con el puntero correspondiente consumía una gran cantidad de tiempo, sobre todo si había muchas funciones dentro de una DLL, y en la forma de ordinales tan sólo había que copiar punteros en bucle.

Obtener el propio número de versión desde MFC y Win32 (y II)

Rafael Ontivero — Tue, 26 Jan 2010 12:30:41 GMT

Hace poco expliqué cómo obtener el número de versión del propio ejecutable desde C++ Builder utilizando la VCL (su biblioteca de clases) y dejé como pendiente el obtenerla desde Win32 o MFC. Como lo he necesitado, he modificado el código y lo presento aquí:

TCHAR appName[MAX_PATH];
GetModuleFileName(AfxGetApp()->m_hInstance,appName,MAX_PATH-1);
DWORD handle;
DWORD size = GetFileVersionInfoSize(appName, &handle);
if(size!=0)
{
    TCHAR *buffer = new TCHAR[size + 1];
    GetFileVersionInfo(appName, 0, size, buffer);
    VS_FIXEDFILEINFO *pFixedInfo;
    UINT uVersionLen;
    if (VerQueryValue(buffer, _T("\\"), (void**) & pFixedInfo, (UINT*) & uVersionLen) != 0)
    {
        CString version;
        version.Format(_T("%d.%d.%d.%d"),HIWORD(pFixedInfo->dwFileVersionMS),LOWORD(pFixedInfo->dwFileVersionMS),HIWORD(pFixedInfo->dwFileVersionLS),LOWORD(pFixedInfo->dwFileVersionLS));
        CString title;
        GetWindowText(title);
        CString newTitle;
        newTitle.Format(_T("%s - V%s"),title,version);
        SetWindowText(newTitle);
    }
    delete[] buffer;
}

Si os fijáis, el código es muy similar al del otro post, tan sólo cambia la forma de usar las cadenas, en una mezcla de MFC y Win32.

Para obtener la ruta del propio ejecutable, tenemos que hacer una llamada a la función de Win32 GetModuleName() que, a través del HINSTANCE de la aplicación, rellenará una cadena con la ruta, devolviendo el tamaño ocupado. No deben preocuparnos los desbordamientos de buffer si pasamos el tamaño correcto de la cadena: la función truncará hasta el máximo.

Los pasos siguientes son iguales, y lo que cambia, de nuevo, es el manejo de las cadenas y cómo las añadimos al título de la ventana.

Para que este código funcione en Win32 puro, tan sólo hay que usar las cadenas de C (y sprintf() y accesorias) o bien usar las cadenas de la biblioteca de C++, que es lo que recomendaría.

¿Se fragmenta el registro de Windows?

Rafael Ontivero — Wed, 06 Jan 2010 13:22:00 GMT

La respuesta corta es que sí. La larga es que no mucho. Veamos.

Acabo de terminar de leer la parte del libro de Windows Internals que se refiere al registro de Windows, y básicamente me ha quedado un mal sabor de boca, cosa que a veces suele pasar con este tipo de libros políticamente aprobados, y es que no deja nada claro si el registro se fragmenta o no.

En disco, el registro no es más que una serie de ficheros repartidos a lo largo de varios lugares, ficheros que se corresponden con las diferentes ramas del mismo. La mayor ventaja de Vista y siguientes frente a XP es que ahora existe un juego de llamadas a función que realizarán operaciones transaccionales sobre el mismo. Es decir, igual que en las bases de datos –y el registro no deja de ser una-, iniciamos una transacción, realizamos una serie de acciones y si las completamos bien, cerramos dicha transacción, y si no, la abortamos. Para los programas instaladores esta característica es cojonuda, y a veces también para los programas de usuario. Con sólo imaginarnos dejar el registro a medio actualizar a causa de un corte de corriente…

Lo que sí queda claro es que en memoria la fragmentación es mínima. Es decir, casi da igual el grado de fragmentación que haya en los archivos (los hive, como los llaman), cuando estos son cargados a memoria mediante virtualización de la misma, la posible fragmentación queda reducida al mínimo. Además, los valores más comúnmente accedidos quedan cacheados. También se mantienen listas y cachés de escritura, para minimizar la sobrecarga en el sistema, lo que a veces, ante un corte imprevisto de corriente, hace que no se graben dichas modificaciones, aunque Windows garantiza la no corrupción de los hives mediante un sistema de mapeados y de escrituras en ficheros dobles y triples (más o menos lo mismo que hago yo con los firmwares cuando los datos no deben corromperse ante un corte de luz –en mi caso se trata de memorias flash y eeproms, pero la situación es la misma). La descarga a disco se hace cada cinco segundos, aunque podemos forzar nosotros una mediante la llamada a la función RegFlushKey() que, pese a lo que diga la documentación, hace un volcado de todo lo pendiente, no solo de la Key abierta.

Pero en disco la cosa no está tan clara, y los autores tampoco lo dicen expresamente, pero parece ser que sí, que el registro se puede fragmentar.

El registro se guarda en disco en bloques de 4KB. Es decir, aunque necesitemos 1 byte, el hive crecerá en 4KB. Eso no quiere decir que hayamos desperdiciado el resto, que no va a ocurrir, ya que luego dicho bloque se irá rellenando conforme se vayan añadiendo claves.

Ese es el primer nivel de indirección. Encima existe un nuevo nivel lógico, en el que el registro se distribuye en forma de listas sobre dichos bloques, y que realmente conforman la estructura que nosotros vemos. Digamos que este nivel consiste en una especie de mezcla de árbol y lista enlazada que se va distribuyendo a lo largo de los bloques en disco.

La combinación de ambas estructuras permite la fragmentación de forma muy fácil: tan solo hay que ir creando árboles y luego eliminando nodos y árboles anteriores. De hecho, en poco tiempo podríamos tener un buen nivel de fragmentación, sobre todo cuando hemos instalado y desinstalado un montón de programas.

No obstante, Windows lucha contra esta fragmentación mediante la compactación de los espacios libres. Es decir, cuando en un bloque físico hay huecos, estos serán compactados para dejar el mayor espacio libre contiguo, para –creo entender- volver a ser reutilizado.

No obstante, el bloque no será liberado de disco hasta que no esté completamente vacío, y sólo cuando esté al final del fichero. Es aquí donde puede venir la fragmentación, ya que podríamos tener muchos bloques vacíos por en medio y una jodida clave al final que nos impidiera la limpieza de un buen espacio en disco, ya que el algoritmo de desfragmentación no coloca los huecos al final, sino que simplemente los maximiza.

Y aquí es donde entra la estadística. Estadísticamente hablando, siempre habrá algo de fragmentación porque habrá huecos intermedios, que serán rellenados conforme se vayan necesitando, y en el peor de los casos el registro no decrecerá en tamaño, pero tampoco crecerá hasta que todos los huecos estén rellenos.

Lo que más me jode de todo esto es que en el libro no está muy claramente contado, sino que el tema de la fragmentación se recorre de puntillas, como si fuera un pecado. Tan sólo se comentan, de pasada, dos funciones que podrían permitirnos compactarlo y quizás decrecerlo: RegSaveKey() y RegReplaceKey(), que dice son usadas por Windows Backup.

Podríamos intentar jugar con dichas funciones para ver si conseguimos compactar nuestro registro pero, siéndoos sincero, no tengo ganas de trastear con algo que podría dejar mi ordenador completamente inservible sólo por ganar unos cuantos megas de disco…

BingOS o cómo no reventar de impaciencia

Rafael Ontivero — Mon, 28 Dec 2009 11:01:13 GMT

Ya es oficial. Ya no tengo que morderme los nudillos, ni ponerme esparadrapos en la boca, ni pisarme a mi mismo para evitar soltarlo: Microsoft ha lanzado un nuevo sistema operativo especialmente diseñado para los ultraligeros y toda su familia anexa, por lo que tampoco descarto ver lectores de libros-e con esta tecnología en sus tripas.

Como está basado en Windows CE, el núcleo será igual de estable, y al ser una versión “destripada”, todavía más. Por ejemplo, yo una vez conseguí una imagen de CE de 4MB conteniendo la GUI completa (también IE) e ignorando muchas cosas accesorias.

La ventaja evidente es que muchos de los programas existentes para CE (léase Windows Mobile) funcionarán sin modificar…

Pero la cosa no termina ahí, sino que, como nos tiene habituados, MS sacará varias versiones, incluso una “Starter” que sólo podrá navegar por determinados sitios, así como otra con sólo la posibilidad de navegación.

Parece ser que la idea es darle una buena coz a Google, y aunque MS sea un dinosaurio lento y torpón, si se decide a poner en marcha la máquina, saca ventaja a quien sea. El anuncio más o menos oficial, aquí: http://www.ethek.com/bingos-el-nuevo-sistema-operativo-de-microsoft/.

Obtener tu propia versión

Rafael Ontivero — Thu, 03 Dec 2009 10:22:10 GMT

Muchos habréis observado que en las propiedades de un ejecutable o una DLL suelen aparecer, en la pestaña Detalles de las propiedades, una serie de nombres y de datos sobre la versión de dicho fichero.

Eso se consigue embebiendo en el ejecutable un recurso de versión, que en Win32 se llama RCVERSION y que consta de una serie de cadenas y valores predefinidos que podemos rellenar a nuestro gusto.

En las imágenes de abajo podemos ver un ejemplo añadido a un ejecutable, tanto desde C++ Builder como desde Visual C++.

Si os fijáis, ambas tienen más o menos los mismos elementos, pero en el caso del C++Builder existe la opción de incrementar el número de Build automáticamente. Hasta donde yo sé, eso no lo permite Visual C++ (quizás se haga en conjunción con un CVS o cuando haya uno compatible), y básicamente consiste en incrementar automáticamente el último numerito cada vez que compilemos algo. A lo largo de diferentes versiones del producto, este incremento se producía cuando se hacía un Build, un Make o incluso nunca (debido a un bug). En la versión 2010 se hace cada vez que compilemos algo.

Bueno, una vez que hemos especificado nuestro recurso de versión, es tiempo de que podamos leerlo desde el propio ejecutable para poderlo poner, por ejemplo, en la pantalla de “Acerca”, en la de “Splash” o donde queramos. Si os dais cuenta, esos números suelen aparecer en muchas aplicaciones.

El código es muy sencillo:

DWORD handle;
DWORD size = GetFileVersionInfoSize(Application->ExeName.w_str(), &handle);
wchar_t *buffer = new wchar_t[size + 1];
GetFileVersionInfo(Application->ExeName.w_str(), 0, size, buffer);
VS_FIXEDFILEINFO *pFixedInfo;
UINT uVersionLen;
if (VerQueryValue(buffer, L"\\", (void**) & pFixedInfo, (UINT*) & uVersionLen) != 0)
{
    String version = L" " + String(HIWORD(pFixedInfo->dwFileVersionMS)) + L"." + String(LOWORD(pFixedInfo->dwFileVersionMS)) + L"." + String
    (HIWORD(pFixedInfo->dwFileVersionLS)) + L"." + String(LOWORD(pFixedInfo->dwFileVersionLS));
    m_caption = Caption + version + L" - ";
    Caption = m_caption + m_document->FileName;
}
delete[] buffer;

El ejemplo que he puesto es para C++ Builder Unicode, pero resulta trivial convertirlo a C ó C++ estándar. Tan sólo hay que cambiar el tipo de las cadenas por las adecuadas.

Primero se hace una llamada a GetFileVersionInfoSize() pasando la ruta de nuestro ejecutable y un DWORD que de nada sirve. Con el tamaño del recurso, llamamos a GetFileVersionInfo() volviendo a pasar la ruta del ejecutable y un buffer con el tamaño adecuado.

Después creamos un puntero a una estructura del tipo VS_FIXEDFILEINFO y la pasamos a la función VerQueryValue(), que también recibe el buffer original, qué parte del recurso queremos sacar (“\\”, es decir, la versión raíz –los recursos de versión se pueden embeber unos dentro de otros) y algún que otro valor más.

Si esta función encuentra lo que le decimos, entonces podemos usar el puntero de la estructura y formatear una cadena con los cuatro números de versión.

Lo que hagamos con esa cadena es cosa nuestra. En este caso la añadimos al título de la ventana actual y lo guardamos en una variable miembro que usaremos cada vez que cambiemos de documento.

Y no nos olvidemos de liberar la cadena asignada.

Cómo salta Windows entre anillos (Modo Kernel y modo Usuario)

Rafael Ontivero — Sat, 21 Nov 2009 13:37:03 GMT

Esta semana estamos de fiesta, y es que una de mis pasiones en el desarrollo siempre ha sido verle las tripas a Windows, y a ello vamos. Antes de nada, lo que voy a contar aquí es un resumen del punto System Service Dispatching del capítulo 3 de Windows Internals 5ª edición, pero es un resumen un poco especial porque voy a añadir cosas de mi cosecha, como siempre hago, ya que no es cosa de ir parafraseando lo que voy aprendiendo/recordando.

En entradas anteriores, y algunas veces en los foros, he comentado sobre saltos entre anillo 0 y anillo 3, y aquí voy a explicar de pasada lo que significa. Un microprocesador moderno (y no tan moderno), cuenta con un juego de instrucciones en cierta medida especiales, instrucciones que son necesarias para configurar el hardware y el propio funcionamiento del software. Hablamos aquí de las interrupciones y toda su parafernalia asociada, del control de la memoria virtual, del acceso directo a hardware (es decir, escribir o leer en una dirección de memoria o en un puerto en el que no hay tal, sino alguna electrónica que debe reaccionar en base a dicha lectura o escritura), etc.

Esas instrucciones son peligrosas de usar, y en general no deben estar disponibles para los programas normales, ya que entonces un error podría llevar a la caída total del sistema o incluso a la rotura de algún elemento electrónico.

Es decir, que podríamos dividir el juego de instrucciones de un microprocesador en dos grandes grupos: aquellas que no son necesarias para que un programa funcione normalmente y las que, si se usan de forma incorrecta, pueden terminar armando un buen pirifostio.

Pues básicamente eso son los anillos 0 y 3. En el 0 están las instrucciones peligrosas, en el 3 las que cualquier programa puede usar, y si un programa normal utiliza una del cero, generará una excepción (¿De qué me sonará esto?) que será capturada por el sistema operativo y manejada a su antojo. Aunque realmente no es del todo así, para nuestro propósito es suficiente.

(Si os dais cuenta, he hablado del 0 y del 3, pero también hay un 1 y un 2, que Windows no utiliza. Digamos que la separación de las instrucciones en estos distintos niveles permiten una serie de facilidades a la hora de construir software de sistemas, ya sean sistemas operativos o aplicaciones que vayan a correr en un microprocesador con estas características, lo que ocurre es que Windows aprovecha estos niveles únicamente de una sola forma, que llama modo usuario y modo kernel).

Pues bien, el kelmer, uis, perdón, el kernel, la mayoría de los drivers, y el motor gráfico (que fue ampliamente criticado en su momento pero que permitió que NT 4.0 pudiera ser usado en ordenadores no tan potentes) se ejecutan en el anillo 0, y los demás subsistemas (incluido Win32) en el 3. De esta forma un programador chapucero (o un compilador) sólo podrá tumbar su programa y nada más. Recordemos los días de Windows 3.x y DOS en los cuales tumbar por completo el sistema era tan fácil como ejecutar dos instrucciones de ensamblador seguidas: cli y luego sti, o al revés, ya no me acuerdo.

Una aplicación llama a una función, que debe terminar siendo ejecutada dentro del kernel (por ejemplo, abrir y leer de un fichero, cosa que necesita que los drivers de disco hagan trabajo de bajo nivel sobre la controladora y sobre el propio disco). Pongamos que nuestro programa llama a WriteFile(), y nos da igual que sea una aplicación .NET llamando a sus clases, ya que terminará en esa función. Esa función, que está en Kernel32.dll y pertenece al subsistema Win32, llamará a NtWriteFile(), que está en Ntdll.dll y no pertenece a ningún subsistema, sino que está disponible para cualquiera de ellos. Esta función llamará entonces a KiSystemService(), que está en Ntoskrnl.exe y se ejecuta en el anillo 0 en lugar del 3. Finalmente, esta última función hará lo que tenga que hacer llamando a otras funciones del kernel y de los drivers hasta que al final devolverá el resultado hacia atrás hasta nuestra aplicación.

Fácil, ¿no? Pues no, porque si nuestra aplicación hubiera llamado a WriteFile() con algún parámetro mal que fuera crítico (y se me ocurre pasar un valor aleatorio diferente de cero al handle del fichero sobre el que queremos escribir), lo más seguro es que termináramos en una pantalla azul (como más o menos ocurría en Windows 3.x y a veces en Windows 9x). Además, es muy posible que durante el procesamiento de la función, se salte varias veces entre el modo kernel y el user por necesidades del guión.

Pero todavía hay más, ya que no hemos tenido en cuenta que el controlador de tiempos y de procesos puede cortar en cualquier momento esa llamada para atender otros procesos o incluso hilos de nuestra aplicación. Vamos, que no es fácil ni de lejos.

¿Cómo se produce el salto entre el anillo 3 y el 0, que hemos descrito más arriba? Pues depende del procesador que estemos usando. En la época de Windows 9x (y de la parte en modo protegido de Windows 3.x cuando la había), y para micros antiguos, NtWriteFile(), después de verificar que los parámetros recibidos son correctos, coloca en varios registros del procesador lo necesario, y ejecuta la instrucción int 0x2e, que genera una excepción si se hace desde el anillo 3. Esta excepción es recogida por el Kernel, que mediante los parámetros que hay en los registros determina si es una petición válida (y si no lo es protestará) y la procesará mediante la ejecución de la función correspondiente situada en un array de punteros a función que se llama System Service Dispatch Table, de las que creo que hay varias. Básicamente, lo que está haciendo es recibir un índice que se corresponde a una posición dentro del array de punteros, y como nos equivoquemos con esto la hemos cagado a base de bien, y es por eso por lo que antes del salto entre anillos se verifican los parámetros. El retorno al anillo 3 se produce con la ejecución de la instrucción iretd.

En micros Intel más modernos, el salto se hace mediante la instrucción sysenter y la vuelta mediante sysexit (o iret si estamos en modo depuración). En un AMD las instrucciones son syscall y sysret.

Y finalmente, en micros de 64 bits con la arquitectura x64 las instrucciones son las mismas que en el AMD (por que fueron los primeros en implementarla) y en la I64, epc.

Si os dais cuenta, dependiendo del microprocesador se hace de una u otra forma, lo que puede ser un serio quebradero de cabeza. Lo que hace Windows al arrancar un sistema de 32 bits es instalar la instrucción correcta en una posición de memoria y juego ejecutar sobre ella, con lo que a lo anterior añadimos un nuevo nivel de indirección.

La secuencia completa de paso del anillo 3 al 0 consiste, más o menos, en lo siguiente: primero se verifican los parámetros recibidos de la forma más completa posible, luego se ejecuta la instrucción que hay en cierta posición de memoria, que a su vez generará una excepción, que será controlada por el sistema operativo, que mirará si los parámetros son correctos, y si lo son volverá a saltar sobre un puntero a puntero a función, y finalmente lo que haya allí hará el trabajo.

Eso para un solo salto. Imaginaros cuántos son necesarios para que nuestro programa, y el sistema operativo funcione. Y no hemos hablado de que en cada una de esos pasos es necesario que la pila se guarde o se recupere, y que los datos deben ser copiados desde la pila de modo user a la de modo kernel para evitar que la aplicación pueda modificarlos en medio de una operación interna…

En un sistema x64 la operación es algo más sencilla porque la instrucción de salto es siempre la misma y no es necesaria la indirección extra sobre la instrucción ya que da igual que el microprocesador sea un Intel o un AMD.

Esto quizás te presente una duda en el caso de equipos de 32 bits: ¿por qué no está cableada dicha instrucción y simplemente a la hora de instalar Windows o de arrancarlo, el cargador pone en memoria el juego de DLLs correcto? Pues realmente no tengo ni idea, lo que sí tengo claro es que en ese caso Windows debería contar con al menos 4 juegos completos de DLLs y o bien elegir el necesario durante la instalación o casi cuadriplicar el espacio ocupado en disco. Lo que sí es cierto es que si se hubiera hecho así, el Windows de 32 bits funcionaría sensiblemente más rápido… o no.

Sólo nos queda ver, por mor de completitud, cómo funciona internamente el kernel sobre sí mismo. Supongamos por un momento que el kernel necesita acceder a la funcionalidad que hay en WriteFile(), pero en lugar de llamar a esta función directamente, lo que hace es llamar directamente a la rutina a la que se está apuntando en la tabla SSDT y santas pascuas, ya que en principio no se necesita verificar los parámetros que se suponen son correctos, y aparte de eso ya estamos en el anillo 0. No obstante, un driver no puede hacerlo así porque Microsoft no se fía de ellos, y es por ello que existen unas funciones que tiene como prefijo Zw y que son las que llamarán a su homónimo apuntado por la SSDT después de realizar las verificaciones –menos que si se llamara desde el anillo 3- oportunas.

Eligiendo qué hacer cuando pete nuestra aplicación

Rafael Ontivero — Thu, 19 Nov 2009 17:53:00 GMT

En la entrada anterior expliqué qué ocurre cuando una aplicación peta y se genera una excepción no controlada (o controlada pero relanzada), y en esta voy a explicar cómo podemos, desde nuestro propio programa, configurar el modo en que eso ocurre. Pero antes una introducción.

En algunos lados he dicho que las excepciones son caras. Con eso no me refiero a que cuesten dinero, sino a que es un tipo de característica que resulta muy complicada de procesar y que a veces requiere de bastante tiempo de proceso. Cuando se dispara una interrupción en una aplicación, sobre todo si ocurre en el lado del kernel, éste tiene que entrar y salir varias veces entre su modo y el de usuario, operaciones que no son baratas (de nuevo no en dinero, aunque lo mismo en su servidor en producción sí) ya que significan saltar entre los anillos 0 y 3 del procesador. Aparte de eso, se debe recorrer la pila (a ambos lados de los anillos) para ir buscando el controlador adecuado, ejecutarlo y en la mayoría de casos continuar con la búsqueda.

Cuando ponemos un bloque try/catch, o __try/__except ó __try/__finally, el compilador deja “marcas” en la pila, “marcas” que serán leídas por el controlador de excepciones. Dependiendo de cómo lo hayamos hecho, y el número de bloques y de controladores, el sistema tendrá que salvar y restaurar el estado de la pila y de la aplicación para ir ejecutando los diferentes bloques de captura, y a veces incluso se necesita de cierta “inteligencia” para que la ejecución sea la correcta. El tema queda bastante claro una vez que se han leído los capítulos de los dos libros que mencioné, con una excepción: que esos recorridos requieren tiempo, sobre todo si hay saltos entre anillo 0 y 3, por lo que en general el uso de excepciones está para eso: para ser usadas cuando realmente se produzca una, y no alegremente como una mera característica de nuestro lenguaje.

Dicho esto, considero que el ejemplo que Jeffrey Ritcher pone al final del capítulo 25 no es muy correcto, no porque esté mal, sino porque realizar gestión de memoria mediante excepciones me parece que es matar moscas a cañonazos… aparte del desperdicio de la misma. Ritcher crea una hoja de cálculo de un tamaño predefinido pero sin asignar ningún tipo de memoria. Luego, ante cada requerimiento de que una celda sea llenada con algo, intenta escribir en la posición. Si ya hay memoria asignada todo irá bien, pero si no, se disparará una excepción que asignará un bloque a dicha celda. La barbaridad está en que cada asignación, aunque sea de un solo byte, asignará 4KB (que es el tamaño de página de RAM), y en que el gasto de la excepción y su control es enormemente más caro que simplemente comprobar si la memoria está asignada o no. A no ser que se me escape algo, como ejemplo sobre el funcionamiento de las excepciones, vale, pero como ejemplo de algoritmo genérico, no.

De todos modos, el sistema de excepciones es my potente y versátil, y con la combinación del registro, podemos configurar a base de bien el comportamiento de las no controladas. Windows Internals lista 25 claves para cambiar el comportamiento, alguna de ellas tan radicales como hacer que ni siquiera se ejecute WerFault.exe y nuestra aplicación desaparezca de forma silenciosa.

Pero como diría el personaje de los dibujos animados, no se vayan todavía, que hay más. Aparte de poder instalar y controlar ciertas funciones de control de excepciones, podemos configurar el modo con que nuestra aplicación se comunica con el gestor de las mismas. Es decir, mediante ciertas llamadas a funciones de Win32, podemos decirle al sistema WER cómo debe comportarse, qué ficheros adjuntar, etc.

La mayoría de las funciones que voy a citar aquí de pasada, se encuentran dentro de kernel32.dll y para usarlas debemos incluir werapi.h.

WerSetFlags()/WerGetFlags(). Cambiamos o leemos si queremos que se incluya el heap (montículo) en el informe, si se suspenderán todos los hilos o sólo el que falló, si se añadirá el informe a la lista de errores, y si se enviará o no a Microsoft.
WerAddExcludedApplication()/WerRemoveExcludedApplication(). Añadir o eliminar una aplicación a la lista de aplicaciones excluidas de la generación de informes.
WerRegisterFile()/WerUnregisterFile(). Añadir o quitar el fichero indicado al informe.
WerRegisterMemoryBlock()/WerUnregisterMemoryBlock(). Añadir/Qutar un volcado de un área de la memoria de nuestro programa.

También podemos crear un informe desde nuestro programa cuando queramos. Los pasos a seguir son:

Llamar a WerReportCreate(), que inicia el informe.
Llamar tantas veces a WerReportSetParameter() como parámetros queramos cambiar.
Llamar tantas veces a WerReportAddDump() como bloques de memoria queramos incluir.
Llamar tantas veces a WerReportAddFile() como ficheros del tipo que sean queramos incluir.
Llamar a WerReportSetUIString() para añadir opciones a la pantalla de WerFault.exe.
Llamar a WerReportSubmit(), que dependiendo de la configuración para el programa y/o genéricas que se tengan, enviará o no, preguntará o no, etc. qué hacer con el informe.
Llamar a WerReportCloseHandle() para terminar con el tema.

Como podéis ver, la cosa es muy potente, y puede ser enormemente útil en determinadas situaciones. Imaginemos que nuestra aplicación esté petando en casa del cliente y no haya modo de ver qué puñetas pasa. La generación de informes a demanda podría ser la solución. Lo que no he visto es cómo recibir e interpretar esos informes.

También podemos usar estas funciones cuando sea nuestra aplicación la que esté controlando la excepción, pero debemos ser cuidadosos ya que ésta podría estar tan estropeada que el uso de todo esto volviera a genera nuevas excepciones que terminaran en el mismo código, que a su vez generara otras que…

Se supone que Windows es lo suficientemente inteligente como para detener la cadena, pero como yo ya he visto más de una vez petar de forma continua a una aplicación en Windows Vista hasta que la he matado desde el administrador de tareas, debemos ser cuidadosos con su uso.

De excepciones, del depurador, de Windows y de Visual Studio

Rafael Ontivero — Wed, 18 Nov 2009 16:54:09 GMT

Esto leyendo la quinta edición de Windows Internals, que cubre Windows Vista y Windows Server 2008 y es la última versión disponible del libro. Allá por los años del Windows 95 y del NT 4.0, un poco antes, un poco después, estaba yo muy interesado en las tripillas de los sistemas operativos, y aparte de empacharme con algún que otro mamotreto genérico sobre el tema, le di caña a los equivalentes, como Windows 95, al descubierto, o el Windows NT de Helen Custer, así como otros de similar temática. Vamos, que prácticamente me leí todo lo que pude conseguir sobre las interioridades de esos sistemas operativos.

Pero desde hace un tiempo me veo en la tesitura de que, conversando aquí y allí, me he dado cuenta de que me he quedado bastante obsoleto en el tema, con cosas que no sólo han sido mejoradas, sino que ahora funcionan de forma completamente diferente, así que me he puesto las pilas y le estoy dando un buen repaso al libro…

Bueno, pues como iba diciendo, el capítulo 3 del citado no es que sea nada del otro mundo. Bueno, sí, lo cierto es que como no sepas de programación de hardware y hayas hecho algo, te vas a quedar poco menos que a dos velas con muchas de las cosas que aparecen, ya que tienen que ver con la gestión de interrupciones, tanto de software como de hardware, así como las excepciones y demás intríngulis que todo sistema operativo ha de cumplir.

Personalmente yo he hecho un par de proyectos basados en un microprocesador, aunque generalmente, cuando lo hago, suelo trastear con microcontroladores más o menos potentes, y la verdad es que muchas de las cosas que aparecen ahí explicadas, con la evidente diferencia entre un sistema operativo como es Windows y lo que un mindundi como yo haya podido hacer, me las he encontrado en mis desarrollos. Tener en cuenta las prioridades y los niveles de las interrupciones, programarlos y cambiarlos en tiempo real, instalar y quitar vectores de interrupción, etc.

Por lo menos eso es de lo que trata la parte del capítulo 3 que he leído, que ciertamente me parece demasiado detallista en cosas que, la verdad, a no ser que vayas a meterte de lleno en la creación de drivers primarios para Windows, de poco te sirve. Y si sabes de sistemas operativos, lo único llamativo es que te enteras de que Windows no es mucho más diferente que otros sistemas.

Volviendo al tema (lo que me mola irme por las ramas), sobre la página ciento y pico (je je, me quedan todavía más de mil cien por leer, ¡qué emoción!) se pone a hablar del control de las excepciones del sistema operativo, y cómo son controladas en conjunción con el software de aplicación (ese que tu y yo hacemos) y el propio sistema. Y entonces te dice que si no tienes claro cómo funciona a nivel de programador, que mires los capítulos finales de Windows via C/C++. Y como resulta que tengo ese libro en la lista de pendientes (hace unos años leí y estudié la misma versión pero mucho más antigua, y encima en castellano), pues dejé uno y me puse con el otro, máxime recordando que fueron precisamente esos capítulos los que no leí en la edición anterior.

El sistema de excepciones de Windows es muy potente y versátil, y todos deberíamos saber lo básico sobre él. Pero no, no voy a entrar en detalles sobre el mismo, simplemente os diré que funciona muy parecido a las excepciones de un lenguaje de programación, con la salvedad de que es el sistema operativo el que las lanza y las gestiona si no lo has hecho tu.

En Windows Vista y siguientes existe una aplicación que se llama WerFault.exe y que seguro que habéis visto en ejecución. De hecho, cada vez que os peta un programa, es esa aplicación la que toma el control y saca la barra de progreso moviéndose y te permite unas u otras acciones una vez que ha hecho sus deberes.

Es decir, cuando una aplicación genera una excepción, o el sistema operativo dispara una causada por la aplicación (por ejemplo, una división entre cero o una escritura fuera de rango), se trastea con la pila de tu programa y se busca un controlador de excepción adecuado. Ojo, no estamos hablando de bloques try/catch, sino de bloques __try/__except… aunque a veces el control termina también en un catch, sobre todo si usamos C++ y hemos habilitado la compatibilidad de control de excepciones del sistema operativo (y esto no viene explicado así en el libro, que asume la compatibildad). En .NET no sé qué ocurrirá, pero no creo que haya mucha diferencia.

Si nuestro programa tiene un manejador para esa excepción, se ejecutará, y dependiendo de lo que devuelva, se reintentará la instrucción (de código máquina, así que ojo) que generó la excepción, se continuará como si nada hubiera pasado (y en este caso podríamos liarla todavía más gorda), o se seguirá buscando otro nuevo manejador. Es decir, independientemente de lo que quiera que hagamos en nuestro controlador, podemos decirle al sistema operativo que reintente, que ignore o que busque otro controlador más.

Una vez que se han recorrido todos los controladores adecuados, además de dos más extra que podemos instalar mediante AddVectoredExceptionHandler() y SetUnhandledExceptionFilter(), y siempre que se haya llegado al final de toda la cadena de excepciones (que es algo más larga y compleja de lo que aquí he expuesto) sin haber sido detenida, Windows lanzará el citado programa, y le pasará un manejador al proceso que está fallando, aparte de detener por completo la ejecución de todos sus hilos (en XP sólo se detenía el que fallaba) mediante unas APIs ALPC no documentadas.

Este programa, en base a algunas claves del registro, hará una cosa u otra. Como ha recibido los manejadores en modo heredado, tendrá control sobre el programa que está fallando. Aparte de añadir el evento correspondiente, podrá enviar el informe a Microsoft, o añadirlo a la lista de pendientes. Incluso existe la posibilidad de que ni siquiera aparezca, haciendo todas sus tareas de forma oculta, o incluso que no haga ninguna. Podemos incluso filtrar el comportamiento según qué aplicación haya fallado.

Después de que ha hecho sus tareas internas, si existe algún depurador registrado y si la configuración (o lo que hayamos elegido) lo permite, abrirá el programa vsjitdebugger.exe que mostrará los depuradores registrados. De nuevo este programa recibe los manejadores de forma heredada, y mientras, nuestra aplicación está completamente muerta, esperando. Una vez que hemos elegido un depurador, éste será ejecutado pasando, otra vez, la información necesaria para que sea capaz de buscar y localizar la aplicación que ha fallado.

Es entonces cuando ésta se abrirá dentro del depurador, y si están disponibles los símbolos y demás, podremos ver qué ha fallado y por qué.

Si os fijáis, el tema no es sencillo ni de lejos. En primer lugar, el programa fallante no puede hacer nada porque podría estar en un estado indeterminado, con la memoria o la pila completamente corruptas, así que es el sistema operativo el que debe tomar el control y lanzar una nueva aplicación que se encargue de todo el paripé, que a su vez lanzará un depurador que no es tal, sino un concentrador de depuradores, que al final sí, lanzará el depurador elegido, que tomará bajo su ala a nuestro programa petado.

¿Os dais cuenta lo complejo que es algo que asumimos de forma inconsciente como trivial? Pues no todo termina ahí, sino que es ahora el depurador el que debe meter las garras dentro de la aplicación defectuosa, insertándose en su espacio de direcciones de alguna manera.

Para finalizar, comentaros que esto no es más que un resumen de los capítulos 23, 24 y 25 de Windows via C/C++, quinta edición.

Instalar QT en Visual Studio

Rafael Ontivero — Mon, 31 Aug 2009 16:17:00 GMT

Si has intentando instalar las últimas versiones de QT en Visual Studio habrás visto que la cosa no funciona como debe ya que la biblioteca no compila, fallando en la parte de la construcción de WebKit, que viene a ser el componente para navegación Web de QT (Algo así como el control OCX del IE, pero válido para cualquier plataforma soportada).

Pese a ello, puede resultar muy interesante tener disponible esta plataforma en Visual C++, ya que, aunque la podemos instalar con su IDE nativo, las funcionalidades de éste apenas le llegan a la suela de los zapatos a las del de Microsoft, y no digamos ya las diferencias en cuanto a rendimiento del compilador de Visual C++ frente al de GNU.

Para quien no lo sepa, QT es un Framework escrito en C++ que es capaz de generar ejecutables para Windows, MAC y Linux a partir de un mismo código fuente. Es algo que todavía no he probado a hacer, pero seguro que dentro de poco publico algo por aquí. En un principio QT era un producto de TrollTech, y su licencia era propietaria. Con el tiempo la empresa fue bajando los requisitos y, gracias sobre todo a KDE –un escritorio Linux-, al final salió con licencia doble. Es decir, podías usarlo para hacer programas propietarios pagando una licencia a TrollTech o hacer programas libres sin tener que pagar nada.

Luego TrollTech fue comprada por Nokia, y con la versión 4.4 de la biblioteca, ésta pasó a ser LGPL, lo que quiere decir que se puede hacer cualquier tipo de desarrollo con ella, paguemos o no. En cierta medida es algo lógico ya que Nokia no se dedica a vender QT, sino que usa QT para sus móviles, y una forma de fomentar el desarrollo con esta biblioteca es la de ofrecerla completamente gratuita. De todos modos hay un requisito que pone Nokia, y es que sólo se puede usar la versión de enlace dinámico (con QT metido en varias DLLs) en lugar de enlace estático. Esto no está muy claro en la licencia en sí, pero pregunté y fue la respuesta que me dieron. Además, tampoco es que sea muy viable un ejecutable de 20 megas, por poner un ejemplo.

Obtener QT. El primer paso es bajarnos el SDK de QT, lo que podemos hacer desde aquí: http://qt.nokia.com/downloads. Debemos elegir la versión LGPL/Free y dentro de ella bajarnos el Qt SDK for Open Source C++ development on Windows. Al hacer clic sobre el enlace citado se iniciará automáticamente la descarga de la última versión del SDK.

Integración con Visual Studio. También debemos bajarnos el Visual Studio Add-in, que se integrará en Visual Studio versión estándar o superior (no creo que funcione en la versión Express).

Una vez instalados ambos elementos, tendremos en la carpeta C:\QT una nueva subcarpeta con la versión instalada, que en mi caso es la 2009.03. Esa instalación está completa, es decir, podremos usar el QtCreator para construir nuestros proyectos, y de hecho no hay que hacer nada más si nos conformamos con las herramientas de que nos provee Nokia.

Cuando instalemos una nueva versión, esta quedará en una nueva carpeta también colgando de C:\QT, y parece ser que la idea de Nokia es sacar cuatro versiones al año. Aparte de la fecha, también se lleva un control de versiones. En el caso que nos ocupa, la versión es la 4.5.2.

De este modo podemos mantener diferentes versiones del producto sin problemas, y de hecho incluso el Add-in de Visual Studio entiende eso y podremos compilar para una o para otra según queramos.

Una cosa a tener en cuenta es que la ruta de instalación no puede tener espacios en blanco, si no luego nos fallarán las herramientas, ya sean de Visual Studio como del propio QtCreator.

El siguiente paso es copiar la carpeta C:\QT\2009.03 en C:\QT\2009.03-vc. Yo he adoptado esa filosofía: la carpeta con la coletilla “-vc” es la versión de Visual Studio. Evidementemente podemos hacer esto directamente sobre la carpeta de instalación original, pero si metemos la pata sólo nos quedará desinstalar, borrar la carpeta, y volver a instalar (que tampoco es mala opción).

Si no fuera por los bugs que cito más abajo, sería buena cosa borrar el contenido de las carpetas bin y lib de lo que hemos copiado, aligerando así el espacio ocupado, pero debido a ello si lo hacemos no seremos capaces de compilar QT para Visual Studio.

Este paso que viene ahora es opcional pero recomendable. Yo me he creado un fichero .bat en C:\QT que he llamado “configure.bat” y que contiene lo siguiente:

cd %1\qt
configure –shared –debug-and-release
nmake

El proceso normal para recompilar QT es ir a la carpeta C:\QT\<versión>\qt y ejecutar el programa configure (en Windows, en Linux configure es un script) con las opciones de comandos adecuadas. En general no es necesaria ninguna excepto la última si queremos que nos construya las versiones debug y release en lugar de sólo la debug.

Con el fichero .bat lo que hago es automatizar este proceso, de modo que sólo tengo que irme a C:\QT y picar “configure <carpeta>” para reconstruir la versión que me interese.

Nos hayamos creado o no el fichero .bat, ahora tenemos que abrir una ventana de comandos de Visual Studio, situada generalmente en Inicio -> All programs -> Visual Studio 2008 -> Visual Studio Tools -> Visual Studio 2008 Command Prompt.

Pero hay truco. Si queremos construir una versión de 64 bits, debemos elegir la consola de 64 bits, y si queremos un sistema de 32, la normal. Deciros que yo todavía no he construido nunca una versión x64, pero por lo que dicen funciona igual de bien que la otra. Sólo con el tipo de ventana el script de QT sabrá qué versión compilar.

Una vez que hemos abierto la ventana de comandos, nos vamos a C:\QT si tenemos el fichero .bat o a C:\QT\<versión>\qt si no lo tenemos.

En el primer caso picamos “configure 2009.03-vc”. En el segundo, “configure –shared –debug-and-release”. En ambos casos nos preguntará qué versión queremos. Tecleamos ‘o’ de OpenSource, y luego ‘y’ para aceptar la licencia correspondiente. A partir de ahí podemos irnos a comer, cenar o echar la siesta.

Si no hubiera bugs en el proceso de compilación, en el primer caso el proceso se realizaría por completo, pero como los hay nuestra compilación se interrumpirá miserablemente. En el segundo caso, una vez que configure haya terminado, debemos teclear “nmake”, cosa que podemos hacer sin que el proceso de configurar haya acabado, y así casi mimetizamos ambos procesos.

Cuando se interrumpa la compilación, tendremos un error del enlazador diciéndonos que faltan una serie de símbolos. Tenemos entonces que irnos a la carpeta C:\QT\<versión>\qt\src\3rdparty\webkit\WebCore\tmp\moc. Ahí veremos dos carpetas, release_shared y debug_shared. Entramos en la primera y borramos el fichero “mocinclude.tmp”. Copiamos el fichero “moc_QnetworkReplyHandler.cpp” y nos vamos a la otra carpeta, debug_shared, en donde volveremos a borrar “mocinclude.tmp” y pegaremos el fichero. Si nos fijamos en esta carpeta hay ya un fichero con ese nombre pero de tamaño cero.

Es conveniente, aunque no obligatorio, “tocar” el fichero “moc_QnetworkReplyHandler.cpp” de debug_shared para que sea posterior a la fecha de creación (yo lo que hago es abrirlo con el bloc de notas, añado y quito un espacio en blanco y lo guardo, así se cambian las fechas.

Ahora volvemos a nuestra consola y volvemos a picar “nmake”. El proceso de compilación seguirá hasta el final, por lo que de nuevo podemos volver a echarnos otra siesta, irnos de parranda o leernos un par de libros. Compilar QT es una tarea larga, incluso en un Quad con 8 GB de memoria.

Borrar “mocinclude.tmp” es necesario para eliminar una caché que impide que el compilador vea los cambios que hemos hecho, por lo que si sólo copiamos el fichero y seguimos con la ejecución del proceso de compilación seguiremos teniendo el error.

El motivo de por qué el otro fichero tiene tamaño cero es harina de otro costal. QT utiliza un metacompilador llamado “moc” para unir los slots con las signals, por lo que el fichero fuente que hemos creado y que contiene elementos de acceso a la UI no vale directamente, primero hay que pasarlo por el programa “moc”, que creará un nuevo fichero ya válido.

En el caso que nos ocupa, el fichero original es “QnetworkReplyHandler.h”, pero por el motivo que sea (todo indica que es un bug del programa “moc”), éste es incapaz de generar el equivalente .cpp procesado para una build debug. Si se mocquea a mano con todas las opciones adecuadas, dice que no encuentra una clase válida y genera un fichero vacío. Hasta ahí he llegado yo.

Lo más curioso de todo es que si borramos los ficheros .a (que son de linux), los lib, los exe y las dll, el proceso de compilación se produce de forma diferente y no se nos crean los ficheros adecuados en la carpeta tmp\moc, de modo que no tenemos forma de copiar de la parte release a la parte debug… Ciertamente resulta algo extraño y mosqueante, y quizás cuando tenga tiempo y ganas lo investigue más a fondo.

Ya hemos compilado QT. Ahora abrimos Visual Studio y abrimos en la barra de menús QT -> QT Options, con lo que obtendremos un cuadro de diálogo en el que añadiremos nuestra nueva versión. Aquí la primera vez debe aparecer vacío, así que hacemos clic en el botón “Add”. Se nos vuelve a abrir otro diálogo y hacemos clic en los puntos suspensivos que hay a la derecha del campo “Path”. Ahora navegamos hasta C:\QT\2009.03-vc\qt y aceptamos. Ahora podemos darle un nombre a esta versión en el campo “Version Name”, por ejemplo “qt-2009.03”. Aceptamos todo y listo, ya tenemos lista la integración.

Si os habéis dado cuenta en el diálogo de opciones, es posible mantener varias versiones de QT y seleccionar la que nos interese por defecto. En principio puede parecer una chorrada, pero cuando tienes aplicaciones legadas con versiones antiguas que no compilan en versiones nuevas de QT es una gran cosa.

Con la integración con Visual Studio tenemos hasta un asistente de proyecto. Si elegimos crear un proyecto nuevo desde la página de inicio o desde el menú normal, veremos que ahora disponemos de un nuevo tipo de proyecto llamado “QT4 Projects” y que nos permite elegir entre diferentes opciones. La normal será “QT Application”, y dentro del asistente podremos elegir qué modulos vamos a usar. Una vez creado un proyecto, si hacemos doble clic sobre un fichero .ui, se nos abrirá el QT Creator, que es un editor visual de formularios y con el que podremos crear nuestras interfaces gráficas igual que se hace en C++Builder, C# o VB.

Sobre C++ Builder 2010 y su historia

Rafael Ontivero — Mon, 10 Aug 2009 12:25:00 GMT

Tenemos una nueva versión de C++ Builder a la vuelta de la esquina, para el 24 de agosto si no me he equivocado en los cálculos. Ciertamente es una gran cosa que Embarcadero, los nuevos propietarios y quiero creer que definitivos, hayan devuelto este magnífico producto a la vida, como vamos a ver. [Si no te molan mis pajas mentales históricas y autobiográficas, salta hasta C++ Builder 2010].

Un poco de historia

Yo fui un furioso borlander, hasta quizás el nivel del fanatismo. El que haya leído mi serie histórica (aquí y aquí) sabrá que, en la academia en donde aprendí C, nos pasaron el entorno de desarrollo Turbo C 2.0, que le daba como mil patadas al Microsoft C (y no es cosas de fundamentalismos, por aquella época el Turbo C era la maravilla de las maravillas tecnológicas en cuanto a compiladores de C). Por supuesto era pirata, como era pirata todo lo que usamos en aquella academia (por cierto, financiada con los primeros fondos de la UE para desempleados, de hecho nos pagaron una pasta gansa por ir a estudiar)...

La academia. De la academia aquella recuerdo una anécdota (por llamarla de alguna manera) que quizás no debería contar pero que voy a hacer. No recuerdo la fecha exacta en que estudiamos, pero era cerca del verano, y allí dentro hacía un calor más que sofocante, lo que, junto a calor generado por los ordenadores hacía que apenas pudiéramos concentrarnos en lo que estábamos haciendo. También teníamos otro problema, y es que los ordenadores eran, por decirlo suavemente, una mierda. A la par que antiguos, ninguno funcionaba bien, como tampoco los profesores eran muy buenos que digamos.

Vamos, que éramos el culo del mundo, una tapadera para que el dueño de la academia se forrara con los fondos aquellos. Nuestras quejas caían en saco roto, ya fuéramos a hablar con el dueño de la empresa como al INEM de nuestra ciudad. Prometían pero no cumplían, y algunos de nosotros estábamos allí para aprender, no para cobrar. Así que ni cortos ni perezosos, tres de nosotros cogimos el autobús y nos fuimos a la oficina del INEM en Alicante y expusimos el tema: que teníamos ordenadores que no funcionaban, que nos moríamos de calor, que los profesores sabían menos que nosotros (que no era poco), que nos habíamos quejado al dueño de la academia y al INEM de Elda y que no nos habían hecho caso, que cuando venía el propietario se iba a comer con el encargado de los cursos del paro y aquí haya paz y allí gloria, y que si no nos hacían caso no tendríamos inconveniente en irnos a quejar a Valencia o a Madrid...

Buenooooooooo, la que se armó. Nosotros, callados como putas, al día siguiente volvimos a clase como si nada hubiera pasado, y ese mismo día cayó el Armagedón. Vinieron dos señores muy trajeados, echaron un vistazo, llamaron por teléfono al dueño, el profe estaba blanco como la cera, nos mandaron a todos a casa hasta nuevo aviso y... en cosa de tres días teníamos profesores competentes, aire acondicionado y lo último de lo último en ordenadores. A partir de ese momento, aprendimos.

***

Ya lo he comentado con anterioridad, para mi aprender C fue lo más, la revelación del maravilloso mundo del desarrollo. Y más todavía con el Turbo C, primer concepto de lo que ahora nos es tan consustancial y sin el cual muchos de nosotros no sabríamos vivir. Luego vinieron otras cosas, como Visual Basic y Delphi, elementos que no podían coexistir sin un IDE. Y con ellos también nació lo que yo llamo la generación de los pseudoprogramadores. Y que nadie se me mosquee. Para un buen programador que pueda haber en VB o Delphi, hay 10 pésimos. En C (y C++) también los hay, pero esos se paran y cambian a otro lenguaje cuando están haciendo un programa de 10.000 líneas y ya no saben cómo meterle mano (ni ellos ni nadie más). Así que en esos otros lenguajes están, también, los de C que no saben.

Del Turbo C pasé al Turbo C++, no recuerdo qué versión, creo que también la 2.0, aunque mi memoria se vuelve como agua con el tema de las versiones aquellas. Sé que de las versiones "Turbo" se pasó las "Borland", que cambiaban -y mejoraban- el concepto del IDE. Aquella (cuando la tienda y algo después) fue mi época, más que de programar en C, de hacerlo en Clipper. Y las cosas están confusas en mis meninges. Sé que manejé varias versiones de ambos productos, todas ellas ejecutando en MS-DOS, aunque con algunas ya se podía desarrollar para Windows.

Bueno, el tema es que en su momento compré el Borland C++ 3.0, que fue mi primera herramienta seria (y tomada en serio) de desarrollo. Si no recuerdo mal, aquello tenía un IDE para DOS y otro para Windows. Ya os podéis imaginar cómo funcionaría la versión Windows, arrastrándose como una tortuga reumática. Lo que no recuerdo eran pantallas azules ni caídas extrañas, que no era poco. Además, yo usaba la versión de MS-DOS, mucho más estable y funcional.

Al poco de comprar (sí, he dicho comprar) la versión 3.0, salió la 3.1, que soportaba Windows 3.1 y que apenas tenía otras mejoras que usar el SDK (o como quiera que se llamara en aquella época) de la susodicha versión de Windows. Aquello me tocó un poco los cojones porque hacía nada que había pasado por caja, así que la conseguí pirata. En aquellos tiempos no hacía nada útil con aquellas herramientas más que usar los manuales para aprender C++ y programación bajo Windows.

De esos años recuerdo haber comprado el libro Aplique C++ de Bruce Eckel, que acabo de recuperar de mi biblioteca. Si bien dije en una entrada anterior que cubría el CFRONT 2.1, ahora veo que no es cierto, que sólo llega al 2.0, y encima en un capítulo aparte. Añadamos los diez o doce manuales que traía el Borland C++ 3.0 y ahí tenéis mi aprendizaje de C++, que tenía que tomarme con bastante calma, ya que aprender un lenguaje estudiando su sintaxis en formato backus-nair tiene su mérito (por eso me compré el libro citado).

Después vino Borland C++ 4.0, que ya hacía enfoque en Windows y dejaba las herramientas de MS-DOS como secundarias, y ahí fue cuando yo empecé a usar el IDE de Windows como mi editor de desarrollo, usara Clipper o el propio Borland. En aquellos años una unidad de CD valía una pasta gansa, aunque en algún momento Creative (o como se llamara entonces), sacó la Sound Blaster 16 con unidad de CD, que yo compré, más que nada por el lector, porque la música no me hacía ni fu ni fa, y encima hacer funcionar aquello era toda una odisea y se comía buena parte del procesador cuando estaba sonando.

Pues bien, yo tenía unidad de CD, pero me equivoqué al pedir la versión 4.0 y la recibí en disquetes, o más bien ignoraba que hubiera versión en CD. Reíros un rato, creo que eran 40 disquetes de 3.5" y alguno más de 5 y 1/4. Y, por supuesto, otros diez o doce manuales en papel. Lo que más me tocó las narices fue que el disquete 1 se me rompió al poco de tener aquello, y me tocó conseguirlo pirata porque el distribuidor en España se negaba a creerse eso de que se me había roto.

Incidentalmente, esa fue la primera vez que me plantee seriamente el motivo de comprar software original, si las pegas eran superiores a las ventajas. Lo único que me decidió a seguir siendo legal en ese aspecto era que los juegos conseguidos pirata terminaban haciendo cosas raras -como colgarse o no funcionar bien-, y se suponía que el software comprado, al venir de una fuente fiable, no traería errores en el soporte. Más tarde descubrí que a los legales también les pasaba. En fin.

Luego vino la versión 4.5, que tampoco compré porque la vi como una simple mejora. Más tarde sacaron Borland C++ 4.5 and Database Tools, que conseguí, de nuevo, pirata, porque aquello de hacer bases de datos con C++ me llamó mucho la atención. Era como mezclar churras con merinas, o al menos así lo pensaba yo, que vivía muy conforme con mi Clipper y mi MS-DOS, aunque estaba profundizando, a nivel diletante, en Win16. Pero lo de database tools era como una falacia, manejar bases de datos con C++ era algo como los Trabajos de Hércules, con lo que ahora sé eran los recién nacidos interfaces COM (aunque se llamaran OLE y OLE2). Inmediatamente después salió la versión 4.52 como bug fix de la anterior.

Cuando salió Borland C++ 5.0 pasé por caja, y volví a recibir una nueva espuerta de manuales, aunque ya pedí expresamente la versión en CD. O venía en CD y si querías disquetes tenías que pagarlos (y pedirlos) aparte, no recuerdo exactamente. Esta versión me la tomé muy en serio y me puse a estudiarla a fondo, sobre todo el IDE y lo que podía hacer, con aquellas plantillas de metaproyectos, y el acceso a sus interioridades del mismo mediante un lenguaje de script orientado a objetos. Aparte el compilador era bastante bueno y generaba el mejor código posible. Poco después recibí, gratis, la versión 5.02, otro bug fix.

Más o menos entonces también descubrí algo que me llenó de gozo: los parches. Sí, los fabricantes sacaban pequeños programas más o menos gratuitos que solucionaban algunos problemas de sus productos. Ciertamente el uso que yo hacía del Borand C++ no traía a la palestra ningún fallo si no era que tenías que tener cuidado con el orden de declaración de las variables y que a veces no se llamaban a los destructores. Casi nada, pero en mi caso no tenía importancia, lo veía como algo normal. Claro, era lo único que había -y tenía. No obstante, para la versión 5.02 conseguí, con mucho sudor, dos parches que apliqué con más satisfacción que utilidad, porque no vi diferencia entre antes y después.

***

Visual C++. No os penséis que sólo vivía de Borland. No recuerdo la sincronía entre versiones, pero en su momento conseguí Visual C++ 4 y luego la versión 5, y ciertamente no tenían nada que hacer frente a Borland. Con Visual C++ 6.0 la cosa cambió un poco, porque al parecer el mercado se había volcado hacia MFC en lugar de OWL (que también estudié, como estudié el poco valorado Turbo Vision, una biblioteca de clases potentísima para hacer lo mismo que con OWL pero para DOS). Sin embargo, en comparación, MFC era (y sigue siendo, al menos hasta la versión de Visual C++ 2008) una mierda, comparada con OWL. Esta última encapsulaba y abstraía mediante orientación a objetos real el api de Win32, mientras que MFC no es más que un envoltorio pseudo orientado a objetos de Win32. No obstante, se ve una tendencia a cambiar con Visual C++ 2008 Service Pack 1, en la que MFC, tras haber permanecido prácticamente estática desde la versión 6.0, parece estar evolucionando hacia algo más decente. Y es que la competencia de QT le anda a la zaga... con muchas ventajas frente a MFC.

Las versiones de Visual C++ las he conseguido por canales un tanto tortuosos. La 4 creo que me la regalaron por algo, simplemente me dieron el CD en una caja precintada. No puedo recordar por qué ni quién, pero sé que fue gratis. La 5 la compré con una licencia de estudiante, y la 6 también fue regalada. Por más que pienso, no consigo recordar cómo las conseguí, de hecho la 6 fue Visual Studio 6.0, que también traía Visual Basic y Visual InterDev o algo así, que jamás he sabido para qué servía. Y también sólo la caja, sin manuales.

Luego vino Visual Studio 2003 como elemento al comprar una suscripción a la MSDN, y luego me hicieron MVP y pude acceder a todas las versiones sin problemas, pero esa es otra historia.

***

C++ Builder. Bueno, el tema es que, una vez que me decidí a aprender en serio lo que traía Borland C++ 5.02, el fabricante sacó algo nuevo llamado C++ Builder. Como ya era cliente fijo de Database DM, me enviaron la publicidad del producto, que leí pero no entendí. Así que llamé a la empresa, y una amable chica me estuvo contando que eso era "lo nuevo de Borland, era programar como en Visual Basic o Delphi pero en C++. Había unos componentes que tu soltabas sobre la ventana y ya tenías hecha la parte visual de la aplicación". Si no me dijo exactamente eso, lo que me contó no se alejaba mucho de lo citado.

Y menos mal que lo compré. Aquello supuso una revolución personal, abandoné definitivamente Clipper (de hecho le di a todos mis clientes el código fuente de sus respectivas aplicaciones junto a propio Clipper) y me puse a estudiar aquello. No es que viviera de programar, que no lo hacía, pero algún que otro cliente sí tenía, y tampoco era dejarlos en la estacada, de hecho siempre les he mantenido los programas hasta que los han abandonado, aunque sé de uno que todavía tiene y usa la agenda doble que le hice. Bueno, ya no, porque hace cosa de un par de años el hombre murió, pero si siguiera vivo seguro que la estaría usando.

Con C++ Builder y una oportunidad que tuve pude dedicarme definitivamente al desarrollo y no a ir a salto de mata haciendo programas aquí y allí (mi trabajo diario y normal no era más que un modo de supervivencia). Una cosa que no he dicho es que de vez en cuando hacía algo embebido sin sistema operativo, incluso desde un PC "a pelo" (evidentemente en modo real x86 y sin muchas zarandajas). Sin embargo, esta oportunidad me puso en el camino que yo quería, y gracias a mi doble vertiente de programador de PC y no-PC he sobrevivido más que bien, y espero hacerlo en un futuro.

La siguiente versión fue C++ Builder 3 (no hubo 2 por un tema de sincronización con Delphi), que también compré. Y luego la 4. Y entonces se me hincharon las pelotas y decidí dejar de hacer el tonto comprando siempre lo mismo y me planté con C++ Builder 4, sus parches y sus bugs, que no eran pocos.

Más o menos entonces Borland entró en su fase "Inprise, me cambio el nombre porque no tengo ni *** idea de qué estoy haciendo" (Parece ser que las empresas también sufren crisis existenciales, y también parece ser que para ellas no vale eso de subirse a una montaña y preguntarse por el sentido de la vida). Y dejó de cuidar sus herramientas de desarrollo. Y empezó a dar bandazos. Sacaron el Kylix, un producto adelantado a su tiempo que ellos mismos mataron. Y otra herramienta de desarrollo en C++ multiplataforma que ahora no recuerdo cómo se llama, que también mataron. Compraron CodeWright y mataron sus productos. En fin, que de tontos está lleno el mundo.

En el tema del C++ sacaron las versiones 5 y 6 del C++ Builder, que no eran otra cosa que la 4 con la cara lavada. Y con cada versión, más bugs sin solucionar, hasta que mataron el producto. Supongo que con Delphi fue más o menos lo mismo. Yo usé la 5 y la 6 pero pirateadas, aunque mi herramienta principal siempre fue, durante muchos años, la 4.

Parece ser que algo estaba ocurriendo entre bambalinas, porque a partir de la 6 el entorno fue completamente remodelado intentando imitar las versiones de Visual Studio, con nuevas características y nuevas potencialidades. Cuando fueron saliendo las sucesivas versiones X, 2006, 2007 y 2009 yo estaba desarrollando con C# (no muy convencido, la verdad) y Visual C++ en mi trabajo actual (de hecho aproveché el cambio entre el anterior y el actual para cambiar por completo de herramientas). Yo pensaba que ambos funcionarían mejor que el C++ Builder, pero no es cierto. En el caso de .NET y C#, como te salgas de lo que Microsoft ha determinado como estándar, la mayoría de cosas no funcionan, aunque poco a poco lo van solucionando. Por otro lado, el compilador de C++ de Microsoft es muy bueno, bastante mejor que el de Borland, pero Visual Studio es otra cosa. En relación a C++ no anda muy fino, más que nada porque la implementación básica es para C#, y C++ anda metido con calzador. Esperemos que Visual C++ 2010 solucione el tema (y personalmente creo que, si no lo soluciona, al menos lo mejora sensiblemente).

Otra cosa es MFC, que son difíciles de aprender y retorcidas a más no poder. Técnicamente hablando no entiendo por qué ganó a OWL, pero la vida es así. Y ahora que más o menos me defiendo con MFC, añoro con bastante intensidad el C++ Builder y he abandonado desarrollar con C# y .NET mientras pueda evitarlo.

***

Pero con C++ Builder 2009 estoy viendo un agradable cambio. Cuando salió la versión 2007 o 2006, no recuerdo bien, fui invitado a una presentación y, como coincidía con el SIMO e iba a ir con mi jefe, pues asistí. Allí fue donde vi por primera vez a Octavio Hernández, y allí fue donde dejé caer mi pregunta bomba: "¿Va Borland a seguir publicando versión tras versión de este nuevo C++ Builder sin corregir los cientos y cientos de bugs que hay pendientes?", de hecho creo que asistí sólo por preguntar eso. Ciertamente cuando tradujeron aquello al inglés todos quedaron bastante incomodados, pero las muestras de adhesión a mi pregunta entre el público eran evidentes. Así que creo que fue David Dean el que dijo que sí, que él prometía que los errores se solucionarían.

Yo hice como que me lo creía pero interiormente lo tenía claro: esa es la respuesta que tienen que dar, de hecho seguí ignorando el producto. La 2006 fue una versión puente, la 2007 estabilizó muchas cosas y la 2009 significa el paso de ANSI a Unicode en la VCL, ciertos avances en C++ como la inclusión de la biblioteca boost y algunos avances sobre C++0x.

Y resulta que sí, que sí se están preocupando de los bugs. Por ejemplo, la versión 2007 tiene doce parches, y la 2009 cuatro que son seis, porque los sacan de dos en dos (uno para el compilador y el IDE y otro para el soporte de bases de datos). Y eso me hace querer volver, aunque reconozco que me he perdido muchos pasos en relación a la evolución de la VCL (desde la versión 4), y es difícil de recuperar.

C++ Builder 2010

Cuando escribo esto faltan 14 días para la salida del producto. Podemos ver aquí un reloj de cuenta atrás y un vídeo con las novedades, en inglés.

Básicamente mejoran el IDE con nuevos elementos:

· IDE Insight: Es una ventana de búsqueda que muestra las interioridades del IDE. Es decir, si uno quiere compilar pero no encuentra la opción por ningún lado, abre esta ventana, busca "compile" y le aparecen todas las cosas que tiene el IDE con esa funcionalidad y según el contexto actual. A simple vista parece una tontería, pero es una herramienta fantásticamente poderosa.

· Formateador de código, algo que ya trae Visual Studio desde al menos la versión 2003: seleccionas un bloque de código y formatea correctamente los indentados.

· Explorador de clases. Parece ser que es bastante potente y no sólo está limitado a nuestro proyecto, sino que puedes echar un vistazo por cualquier biblioteca instalada. A efectos comparativos, es una mezcla de la ventana de "Class View" y de "Object Browser" del Visual Studio con proyectos .NET.

· Más visualizadores de datos en el depurador. Ciertamente en esto siempre ha flojeado un poco el IDE. Esperemos que ahora esté solucionado.

· Control de Hilos en Depuración: una ventana de depuración especial que permite trastear con los hilos de nuestra aplicación, como ejecutar sólo uno de ellos, ejecutar con según qué hilos dormidos, etc. Según dice el vídeo es capaz de detectar deadlocks y similares.

· Compilación en background. A estas alturas suena algo risible que se presente eso como una novedad, cuando era algo que ya tenía el Turbo C, tuvo el Borland C y el Borland C++, y ha tenido de siempre Visual C++...

· Traerá integrado el SDK de Windows 7, por lo que se adelanta en cierta medida a Microsoft.

Por desgracia parece ser que el compilador de C++ de Borland (perdón, Embarcadero) sigue siendo el mismo pobrecito de siempre, sobrepasado por los estándares y bastante faltón al respeto.

Embarcadero está continuamente poniendo información sobre las novedades de la nueva versión en el canal de Twitter llamado EmbarcaderoTech, y hay vídeos en casi castellano y en portugués (que se medio entiende) aquí.

Todo lo que quisiste saber sobre las DLL y no te atreviste a preguntar (I)

Rafael Ontivero — Mon, 29 Jun 2009 11:56:27 GMT

Las DLL tuvieron su origen cuando se quiso compartir código común entre diferentes aplicaciones para así ahorrar algo de espacio en disco (posiblemente espacio en disquetes). Esto requirió que Windows implementara ciertos modelos de memoria bastante complicados para la época (de la historia de Unix/Linux poco sé, si la idea de compartir bibliotecas en tiempo de ejecución fue anterior o posterior –supongo que anterior, aunque vaya usté a saber-), pero era hacerlo así o limitar gravemente a Windows.

Ese modelo de memoria permitió otras cosas, como que las DLL solo pudieran tener un juego de datos para todos los programas que las usaran (con la posibilidad también de contener datos únicos para cada aplicación), ahorrando todavía más memoria. Una desventaja es que un programa maleducado podía tirar al suelo no sólo a otros que usaran una misma DLL, sino al propio Windows, y eso teniendo en cuenta que la DLL estuviera bien construida y no fuera la propia DLL la que tumbara al sistema.

Ahora las cosas son bastante diferentes, cada DLL se ejecuta en el mismo espacio de direcciones que la aplicación que la llama, de manera que ya no comparten memoria ni datos: cada aplicación tiene una instancia independiente que no afecta a otras en ejecución, por lo que el motivo principal se ha perdido y ahora cumplen otros roles no menos importantes.

Tipos de DLL

Hasta la entrada del .NET Framework, existían cuatro tipos de DLL que, dependiendo de su rol, podían contener una u otra cosa.

· DLL normal de código. Es un conjunto de funciones y funcionalidad más o menos destinada a ser utilizada por otros programas. El propio Windows está construido en base a esta característica: Las DLL kernel32.dll, gdi32.dll y user32.dll forman el núcleo del sistema operativo, al menos del subsistema de Win32/Win64.

· DLL de recursos. Como su nombre indica, sólo contienen recursos y nada de código (o el menos posible). Un recurso puede ser un bitmap, una cadena de texto o la definición de un cuadro de diálogo. Este tipo de DLL es muy útil para construir aplicaciones internacionales en las que las cadenas en cada idioma están almacenadas en una DLL diferente, de modo que cuando se carga el programa podemos indicar qué DLL de recursos cargar, teniendo así nuestra aplicación, de forma casi automática, disponible en todos los idiomas que queramos. El propio Windows lo hace así con las versiones MUI, que incluyen todos los textos y otros elementos en DLL normales pero renombradas con la extensión MUI. Usando este mismo paradigma, podemos tener soporte de temas y resulta mucho más fácil cambiar o actualizar los recursos de una aplicación.

· Contenedores COM, DCOM o ActiveX. Este tipo de DLL apareció relativamente tardíamente, aunque su utilidad es más que destacable, y más que un formato de DLL se trata de un subsistema de Windows que se apoya fuertemente en la DLL para funcionar: en general la mayoría de objetos COM se encuentran almacenados en este tipo de ficheros, si bien muchas veces se les cambia la extensión por OCX, aunque no es imprescindible.

· DLL de extensión. Aunque a primera vista podrían estar incluidas en el primer tipo, la construcción de estas necesita de ciertos cuidados especiales o nos encontraremos con serios problemas en su uso y su creación. Una DLL de extensión extiende la funcionalidad de alguna aplicación o marco de trabajo o del propio Windows.

Tras la entrada en escena del .NET Framework, los tipos de DLL se han extendido, o más bien los tipos anteriores han aumentado sus roles así como sus nombres y la división clara entre una clase y otra se ha perdido en cierta manera. En general una DLL .NET ya no se llama así, sino que se llama ensamblado y puede cumplir uno o varios roles anteriores. Los ensamblados normales ahora contienen una buena cantidad de metadatos que los convierten en un paso más allá de los contenedores COM, no suelen incluir código ensamblador sino que en su interior sólo hay instrucciones MSIL y Windows es incapaz de entenderlas sin el soporte del motor en tiempo de ejecución (runtime) de .NET.

Evidentemente, la división anterior es solo conceptual, ya que nadie nos impide tener una DLL que contenga código, recursos y extienda un marco de trabajo existente o se inserte como un servidor COM dentro de Windows. No obstante, y en general, los programadores suelen respetar la división.

Usos modernos de una DLL

Ya hemos visto algunos en el punto anterior, aunque podemos indicarlos para mayor claridad.

· Interfaz con un Driver. Muchas veces cuando tenemos que acceder a un dispositivo más o menos exótico el fabricante nos suministra una DLL que nosotros usaremos para comunicar nuestra aplicación con el dispositivo.

· Soporte de alguna funcionalidad suministrada por un tercero. Si bien también nos podría dar una biblioteca estática para enlazar con nuestra aplicación, el disponer de una DLL significa que ésta también podrá ser usada en otros lenguajes.

· Soporte de temas. Ponemos todos los recursos de una aplicación en una DLL y el hecho de cambiar de tema supone usar otra DLL con los mismos nombres y tipos de recursos pero diferentes en aspecto.

· Soporte de idiomas. Ponemos todas las cadenas de nuestra aplicación en una DLL y la cargamos en consonancia al idioma seleccionado. Aquí tenemos la desventaja de tener que cargar a mano con LoadString() todas las cadenas antes de usarlas. Por ejemplo, MFC ayuda en cierta manera a disponer de este sistema de internacionalización, y otras herramientas como C++Builder o el propio .NET las implementan de forma automática, generando y cargando la DLL adecuada en cada caso sin nuestra intervención.

· Ofrecer servicios actualizables. Esta es una gran ventaja, que utiliza el propio Windows y Visual C++ para insertar actualizaciones. Si ponemos cierta funcionalidad en una DLL, cuando queramos actualizarla sólo tendremos que cambiar dicha DLL por otra nueva que conserve el mismo interfaz público (o al menos la parte usada). Es lo que hace Microsoft con el runtime de Visual C++ cuando se produce alguna actualización de seguridad o corrección de bugs: en Windows Update nos aparece la correspondiente actualización, que sustituirá (más bien añadirá) la nueva versión al repositorio SXS.

· Modificar el comportamiento del sistema añadiendo ganchos (hooks) a Windows. Un ejemplo a esto es insertar una DLL para que actúe de filtro de teclado, dando funcionalidad a las teclas multimedia de nuestro teclado, y una variante es insertar una DLL en otro proceso para tomar el control (o permitir más funcionalidad), que es lo que hace, por ejemplo, Skype (Y no sé para qué).

· Compartir código entre aplicaciones. Aunque a fecha de hoy el ahorro de disco puede ser insignificante, disponer de DLLs con funcionalidad común puede suponer solucionar un bug o realizar algún tipo de mejora de forma simultánea en todas las aplicaciones instaladas que usen dicha DLL. Y por supuesto también está su contrapartida: estropear algo en todas.

De todos modos, esta lista sólo es una aproximación. Seguro que el lector conoce otros usos o se los puede imaginar.

Requisitos para ser una DLL "estándar"

Con esto nos referimos a los requisitos para que una DLL pueda ser utilizada por prácticamente cualquier otro lenguaje de programación, como puede ser el Visual Basic clásico, los lenguajes .NET, Cobol, Dephi, Fortran, etc., e incluso aplicaciones con soporte para ellas como Mathlab y otras.

· El interfaz de programación ha de consistir en funciones globales con el protocolo de llamada __stdcall de paso de parámetros. Cuando uno hace una llamada a función, el punto de retorno y los parámetros que vamos a usar se guardan en la pila. Dependiendo del protocolo de llamada, la limpieza de la misma corresponderá a quien llama o al llamado, así como el orden en el que los parámetros se guardan en ella también depende del protocolo. Como su nombre indica, __stdcall especifica un formato que todos los lenguajes deberían entender si quieren comunicarse con el mundo exterior. Hasta donde yo sé no existe ningún lenguaje moderno que pretenda soporte de extensiones y que no entienda el protocolo __stdcall.

· Si hay variables globales, éstas deben ser de los tipos más estándar posibles, como enteros con un tamaño prefijado. Nada de punteros ni estructuras complejas ni otros elementos dependientes de un compilador en concreto, aunque lo mejor es que no haya ningún tipo de elemento global aparte de las funciones.

· Los parámetros pasados y devueltos han der ser tipos estándar y perfectamente definidos, y debemos huir como de la peste de punteros a void y burradas similares (aunque a veces son inevitables).

· Nada de clases, ni objetos, ni funciones con extensiones no estándar (por ejemplo, paso variable de parámetros o parámetros por defecto).

· Disponer de un punto de entrada con la firma y la funcionalidad siguiente (Sacado de la MSDN, luego explicaremos esto, cualquiera de las dos firmas nos vale):

BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpReserved ); // reserved

int __stdcall DllMain(
HINSTANCE hinstDLL, // handle to DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpReserved ); // reserved

No obstante, muchas de estas reglas son relajables. La mayoría de lenguajes pueden lidiar con punteros y con estructuras de datos, otros no necesitan para nada el punto de entrada, y otros también trabajan bien con el protocolo de llamada __cdecl, que es el estándar de C y C++.

Con lo que sí que no suelen poder es con las extensiones de C++ como las clases, los parámetros por defecto o variables, el protocolo de llamada __fastcall y otras extensiones que muchos compiladores de C++ suministran, como gestión de excepciones y punteros relativos.

Esto no quiere decir que no podamos usar esas cosas en nuestra DLL, que sí podemos, lo que quiere decir es que el interfaz público con el que se debe comunicar la DLL no debe tenerlos. Luego, en nuestro código, podremos usar lo que queramos siempre que no salga fuera. Si usamos excepciones deberemos capturarlas dentro de nuestra DLL y no lanzarlas fuera a no ser que sean del tipo del sistema operativo (y en ese caso tampoco es recomendable).

Aunque pueda parecer extraño, ya que la mayoría de lenguajes modernos implementan clases, las de C++ están prohibidas en la parte pública de una DLL. Eso se debe a la forma en que C++ genera el código. Cuando C++ compila una clase, genera una lista de funciones globales del tipo "MiClase@MiMetodo@&D%&", que es la forma que tiene el compilador de empaquetar toda la información sobre el tipo de la función o de la variable. Él sabe cómo se llama el método, y lo llamará de la forma adecuada dentro del código fuente, pero externamente todos esos añadidos no son estándar y suelen variar de compilador a compilador (e incluso entre versiones del mismo), por lo que si exportamos una clase para que sea vista públicamente en nuestra DLL, la DLL exportará dicho listado de funciones.

Realmente se puede hacer, pero luego tenemos que figurarnos a qué método se corresponde cada función y simular el funcionamiento del objeto desde la aplicación que esté usando la DLL a no ser que nuestra aplicación esté escrita en C++ y compilada con el mismo compilador. En ese caso podemos exportar y usar una clase (o cualquier otro tipo de elemento), pero el consumo ha de ser interno.

Y a veces nos encontramos con esta misma situación cuando usamos una DLL de un tercero: éste la ha generado y comprobado con su compilador y en su sistema, y luego el usuario final se encuentra con un batiburrillo de estructuras, punteros, punteros a void y demás zarandajas que le hacen muy difícil usarla en su sistema.

Por eso lo de las reglas.

En una próxima entrada veremos los aspectos prácticos de todo esto.

¿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.