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

Cross Threading en MVVM y Windows Phone 8 (y también 7)

Rafael Ontivero — Wed, 05 Dec 2012 10:42:07 GMT

Os cuento una rápida que seguro os va a solucionar un montón de quebraderos de cabeza y que me ha traído loco un rato hasta que me he dado cuenta del pufo.

Todo viene cuando estás usando el patrón MVVM y varías algún dato que se está mostrando en algún componente visual. Todos los tutoriales te dicen que heredes de ObservableCollection y que implementes el método NotifyPropertyChanged(). Y te ponen el típico ejemplo:

public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
{
    var handler = PropertyChanged;
    if (null != handler)
    {
      handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

Hasta aquí nada extraño. Cuando una propiedad cambia su valor, quien quiera que esté observando tu colección se enterará del mismo y actuará en consecuencia. Eso si alguien está observando tu colección, que no siempre ocurre, sobre todo si hay algún converter de por medio (ya hablaré largo y tendido sobre esto).

Pero el problema viene cuando ese cambio se produce fuera del hilo principal de la aplicación, como suele pasar a poco que estés haciendo algo medianamente serio. No veo yo bloqueando tu aplicación mientras un servicio web o lo que sea se baja lo que se tenga que bajar, aparte de que en Windows Phone la mayoría de llamadas a todo eso son asíncronas.

Si haces un cambio en un hilo que no sea el de la UI, en Windows Phone 7.5 no pasa nada. Simplemente se ejecuta el código y en general tu colección cambia de valor y a veces, sólo a veces, la visualización cambiará. O no.

En Windows Phone 8 ocurre otra cosa no muy diferente. Recibes dos first chance de dos excepciones diferentes, el IDE no te captura nada a no ser que cambies la configuración de captura de excepciones y el hilo en el que se esté ejecutando el código se muere silenciosamente. Y por supuesto no se cambia nada en la parte visual de tu aplicación.

Vale. Tonto si no pones un bloque try/catch en cada hilo. Pero aquí estamos hablando de otro combate.

¿Cómo puñetas puedo actualizar eso de forma automática? Es decir, ¿tengo que hacer un BeginInvoke() cada vez que asigne algo? La respuesta corta es que sí. La larga es lo siguiente.

Primero tienes que crearte una propiedad nueva en la clase App que vas a llamar UiDispatcher (o como te salga de los OO):

internal static Dispatcher UiDispatcher=Current.RootVisual.Dispatcher;

Y luego cambia el código de arriba por el siguiente:

        public event PropertyChangedEventHandler PropertyChanged;
        private void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
        {
            var handler = PropertyChanged;
            if (null != handler)
            {
                if (App.UiDispatcher.CheckAccess())
                    handler(this, new PropertyChangedEventArgs(propertyName));
                else
                    App.UiDispatcher.BeginInvoke(() => handler(this, new PropertyChangedEventArgs(propertyName)));
            }
        }

Ahora, si os fijáis, si el cambio de vuestra propiedad se realiza dentro del hilo principal, se llamará directamente, y si lo hace desde otro lo hará dentro del Dispatcher de la UI.

¿Por qué una propiedad y no llamar siempre a Current.RootVisual.Dispatcher? Pues porque podría interesarnos tener diferentes dispatchers para otras cosas, pero esa es otra guerra que hay que combatir en otro momento.

QT: QFileSystemViewer a partir de una ruta

Rafael Ontivero — Tue, 10 Jul 2012 15:59:41 GMT

Esto es un “truco” que he encontrado de refilón y lo voy a anotar aquí para que no se me olvide y para goce y disfrute de quien me lea.

La idea es utilizar el modelo documento/vista de QT para navegar a través del sistema de ficheros, pero solo a partir de una ruta en concreto.

Si lo utilizamos conforme a la documentación, el árbol de ficheros se verá completo, con todas nuestras carpetas y ficheros. Nosotros queremos que la raíz del árbol sea una ruta cualquiera.

QFileSystemModel *model=new QFileSystemModel;

QModelIndex index=model->setRootPath(“ruta_a_limitar”);

ui->treeView->setModel(model);

ui->treeView->setRootIndex(index);

En donde treeView es un QTreeView.

Alfred: Cómo lanza aplicaciones dentro de vmWare

Rafael Ontivero — Tue, 26 Jun 2012 08:22:49 GMT

Escenario.

Quieres (o ya tienes) aplicaciones virtualizadas en el Dock. Es decir, tu tienes un programa dentro de una máquina virtual vmWare y quieres lanzarla desde el Dock sin más.

Para ello, una vez que la máquina virtual está en modo Unity, lanzas la aplicación desde el menú de vmWare y te aparecerá el icono de la misma en el Dock. Ahora sólo tienes que, con el botón derecho del mismo, elegir “Opciones -> Mantener en el Dock”.

La próxima vez que quieras lanzarla, con hacer clic sobre dicho icono es suficiente para que se abra la máquina virtual y tu programa de forma completamente transparente. Si la máquina está en modo Unity la aplicación se abrirá como una más del MAC. Si no, lo hará dentro de la ventana.

Vale.

Problema

Ahora queremos poder lanzar esa aplicación desde un atajo de teclado. Hace tiempo expliqué cómo hacer algo similar con Automator y una serie de pasos. No sé si funcionará en el caso que nos ocupa, ni me importa mucho ya que ahora tengo instalado Alfred y su Power Pack, que es lo que realmente debería traer OS X de serie…

Solución

Alfred con el Power Pack tiene la opción de lanzar cualquier aplicación con una combinación de teclas que, creo, se superpone a las del sistema operativo. Hacerlo para cualquier aplicación es completamente trivial, pero para las aplicaciones internas de una máquina virtual es harina de otro costal.

Mirando aquí y allí, he descubierto que el Dock guarda la configuración de los programas que tiene en su barra aquí: ~/Library/Preferences/com.apple.dock.plist

Si abres dicho fichero con xCode te encuentras una serie de items numerados. Hay que buscar el que nos ocupa, y en la rama “file-data -> _CFURLString” tenemos lo que nos interesa: la ruta al arhivo que el sistema usa para lanzar el programa que nos interesa.

Una breve inspección nos dice que, para cada máquina virtual, y dentro de su bumdle, existe una carpeta llamada “Applications” que contiene un fichero por cada aplicación “exportada” por la máquina virtual.

Ahora ya sólo nos queda añadir el fichero deseado al lanzador de aplicaciones de Alfred.

Supongo que los que usáis Parallels tendréis algo equivalente.

Win/MAC: arranque dual y jodimiento de particiones

Rafael Ontivero — Sat, 19 Nov 2011 12:14:42 GMT

Os lo juro. Estoy hasta los putísimos cojones de Windows, de MAC y de la madre que los parió a todos. El primero por pensarse que todo le pertenece, incluyendo las particiones HFS+, y el segundo por pensar que todos los usuarios son tontos del culo.

No tengo muchas ganas de escribir, así que voy a ser bastante escueto.

Escenario: Windows/MAC con Boot Camp y arranque dual. Como Windows asigna las unidades como le sale de los cojones, entro en el Administrador de Discos y las cambio a los valores que quiero.

Vale, todo bien en Windows. Inicio OS X y… una de las tres particiones no se carga. Es decir, habiendo cambiado la letra de unidad a dos particiones HFS+ desde Windows, una de ellas luego no se carga desde OS X porque Windows, en su maravilloso afán de poseerlo todo, ha decidido cambiar cierta cadena de las tablas internas del disco por “Microsoft Basic Data”. Hay que joderse con tomate. ¿No saben reconocer una partición ajena y no tocar nada? Pues parece ser que no, que tienen ganas de joder la marrana.

Bueno, la Utilidad de Discos de OS X se ve incapaz de recuperar la partición. Hala, nueva pérdida de datos. Cuatro máquinas virtuales y un montón de descargas.

***

Pues no, hay solución. Está aquí. Otro geek de la más alta alcurnia se ha encontrado con el mismo problema y ha creado una aplicación en Python para solucionar el problema. Lo único que hace es cambiar dicha cadena por su valor por defecto. Y entonces OS X reconoce la partición como suya y la monta.

Olé sus cojones.

Os cuento cómo hacerlo.

***

Desmonta el disco completo en donde esté la partición afectada. Luego graba el fichero gpt_surgeon.py en disco (ojo con grabar el html y no el contenido del mismo). Aquí viene cuando Apple piensa que somos imbéciles o así. Tu grabas un archivo, que te lo pone como texto de lectura escritura. Pero tu lo quieres de ejecución, porque si no ya puedes darle de sopapos porque se negará a correr.

Hay que añadir el bit de ejecución. ¿Cómo? Ahí está el problema. Desde la interfaz gráfica no se puede, porque CMD-I sólo te dejar cambiar entre lectura y escritura, pero no ejecución.

Quizás haya algún botón por algún lado para activarlo, pero no lo he encontrado, así que tienes que abrir una ventana de terminal y cambiarlo ala UNIX: “chmod u+x gpt_surgeon.py”. Claro, puede que algún imbécil siga la secuencia desde el Finder y sea capaz de cambiarle los permisos a un troyano. En fin, viva la ergonomía y usabilidad maqueras.

Luego sigues la secuencia explicada en el enlace de arriba:

./gpt_surgeon.py list /dev/disk<n>, en donde <n> es el disco malo.
Localiza la partición jodida, en la que debe aparecer el infame texto de “Microsoft Basic Data”.
sudo ./gpt_surgeon.py repair /dev/disk<n> <y>, en donde <y> es la partición rota.
Al poco, OS X (o el script) montará todas las unidades, habiendo reparado la estropeada.

Y ya está, esta ha sido la crónica del día de hoy. Cagontó…

OS X Lion: Activar la repetición de teclas

Rafael Ontivero — Sun, 31 Jul 2011 18:38:17 GMT

Sin muchas ganas de escribir una nueva entrada, voy a poner algo interesante que corrige una de las cagadas de OS X Lion: la repetición de las teclas que llevan caracteres especiales.

Como os comenté en la entrada anterior, Apple la había cagado a base de bien con el tema de la repetición de teclas. Supongo que para un usuario Ruso o Báltico, la cosa puede resultarle interesante, pero no para la mayoría del resto del mundo.

Si la opción fuera configurable no habría problema: se cambia y ya está, pero no lo es, o al menos no lo es de forma sencilla ya que no aparece por ningún lado en la configuración.

Sin embargo sí que existe una forma de volver la cosa a su estado original, y es mediante un comando tecleado en el terminal de OS.

Abrís la aplicación de terminal (tal y como se escribe), y pegáis el texto:

defaults write -g ApplePressAndHoldEnabled -bool false

Y pulsáis enter. Ya está cambiado. No sé si es necesario reiniciar o cerrar la sesión abierta porque simplemente lo piqué y seguí con el MAC encendido y no tuve oportunidad de comprobarlo hasta que reinicié al día siguiente.

Y es que, a veces, sólo a veces, esas webs sensacionalistas pro Apple sirven para algo, ya que de esto me enteré aquí.

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.

El RFOG se renueva, por dentro y por fuera

Rafael Ontivero — Thu, 02 Dec 2010 20:40:45 GMT

Sí, pese a lo que dijo sobre su MAC, al final se ha comprado un PC que sin ser lo último de lo último, tiene su cosa. El MAC está bien, pero le echa a faltar muchas cosas, muchos programas y otros temas, así que, al final, en lugar de comprarse un MAC PRO, se ha decidido por un clónico.

Si os preguntáis qué le ha pasado con su ordenador viejo, no lo hagáis directamente a él, porque va a coger un cabreo de cojones y posiblemente os deje con la palabra en la boca… si no os suelta alguna fresca.

Básicamente su QUAD con 8 GB de RAM se ha quedado en la empresa. Para evitar jaleos y tener la fiesta en paz, ha decidido que no vale la pena batallar por cosa tan nimia (Si no lo sabíais, el RFOG ha pasado, por ordeno y mando, de trabajar en su casa a tener que ir, todos los días, a una empresa, gastando por ello al menos hora u hora y media más de su vida por las mismas prestaciones económicas, y de hecho sigue preguntándose por qué no se ha ido sin más... Corramos un estúpido velo sobre el tema y dejemos la cosa como está.

Bueno, el nuevo ordenador del RFOG está compuesto por una placa Gigabyte (Modelo P55A-UD4) que tiene hasta tres chipsets para discos. Uno para el eSata, otro para los SATA II normales y un tercero para dos discos SATA III. Aparte la placa tiene FireWire 400. Ahí es nada, y también ahí es nada el tiempo que tarda toda la rutina del POST, de hecho más tiempo que el necesario para arrancar su Windows.

Esa placa ejecuta un Core i7 870 a 2.93 GHz que tiene cuatro núcleos dobles con HyperThreading, lo que suman 8. Y bien bonitos que se ven en el Administrador de Tareas. Y también, de momento, no les ha visto el culo, porque no suben del 40% total de tiempo de proceso.

La idea original era ponerle 16GB de RAM, pero al final sólo pudo disponer de 4 porque no le pudieron encontrar módulos de 4GB, aunque le han dicho que en cuanto los consigan lo avisan y se los cambian. De todos modos, 8GB ya son gigas para lo que el RFOG quiere.

La tarjeta de vídeo es una ATI HD6850. El rendimiento es tal que ni el StarCraft II ni el Civilization V a plena resolución hacen que la el ventilador de la misma se revolucione. Ahí es nada. De hecho, apenas nota que tiene algunas cosas con vmWare en modo Unity (que ya es decir).

Luego están los discos. Un SATA II de 1 TB normalito como disco de datos y de seguridad. Y cuatro discos SSD de 64GB en dos RAID 0. Sí, lo que oís, los discos valen más que el resto del ordenador.

Pero ¡chico!, cómo van. Y eso que no son de los más rapiditos que hay, que si no… El arranque de Windows hasta mostrar el escritorio es unos 10 segundos. La tasa de transferencia en copia entre las dos agrupaciones RAID es de unos 220-230 MB/s sostenida (unos 40 GB de una tacada).

A todo eso ha añadido a su ya existente monitor de 24”… otro más. Y como el primero tiene resolución de 1920x1200, el nuevo también la tiene (los modernos traen una de 1920x1080, quizás para poder bajar precios). Y el RFOG se pierde entre tanta pantalla.

***

Eso en cuanto al hardware. Respecto al software la cosa es algo más normal. El SATA II tiene dos particiones, en una de ellas está su trabajo y en la otra se mantienen las copias de seguridad de los otros dos conjuntos RAID, que el RFOG no se fía mucho ni de los SSD ni de los RAID. Relativamente amargas experiencias ha tenido con los últimos.

En uno de los RAID está Windows 7 x64 al completo con algunos programas más, entre ellos vmWare y Office. En el otro hay almacenadas varias máquinas virtuales, en donde se han instalado diferentes programas. En una de ellas está Visual Studio 2010, y en otra, Visual Studio 2008SP1 con los SDKs embebidos. Y así. Esas dos son Windows 7 Ultimate x86 con 3GB de RAMy 2 procesadores con 2 cores, y se pueden tener ambas abiertas sin mucha penalización de rendimiento (en su i7, claro, y más cuando tenga 16GB de RAM).

Y la idea es mantener limpio su HOST e ir intercambiando las máquinas virtuales según necesidad. Su nueva máquina lo da, y de momento la cosa está funcionando bien, con algunos detalles que está puliendo a ratos. Puede poner accesos directos a los programas en su barra de tareas como si una aplicación no virtualizada se tratara, y cuando la lanza primero se abre la máquina virtual en modo Unity y luego se lanza la aplicación.

El único problema es que Visual Studio no se lleva bien con los proyectos situados en carpetas de red, aunque sean compartidas a nivel de vmWare, así que ha metido todos sus proyectos en un disco duro virtual de Windows (VHD) y lo ha añadido a la configuración de la máquina virtual.

Un detalle del que se ha dado cuenta es que la máquina virtual, salvo el acceso a video, es sensiblemente más rápida que la real. Ignora si eso se debe a que es de 32 bits en lugar de 64, o a que al estar el disco comprimido sobre un SSD la rapidez es impresionante…

Evidentemente todo esto es a nivel particular. A nivel de curro la cosa sigue como antes. (Bueno, mucho peor, pero sigue haciendo proyectos interesantes, que quizás sea lo único que lo mantenga apegado a él).

***

Bueno, ya para finalizar, la idea original era hackintoshear la placa base (que se puede, es una de las que tienen el parche de la BIOS) para instalarse un Snow Leopard en nativo y virtualizar todos sus Windows, pero una vez que tuvo delante de sí el PC… se le quitaron las ganas de hacerlo. Es muy posible que en un arranque de aburrimiento lo intente, o que se instale una VM pirateada.

Ya veremos.

¡Los diccionarios personalizados de Visual Assist no funcionan con Visual Studio 2010!

Rafael Ontivero — Thu, 16 Sep 2010 16:42:00 GMT

Si tenéis esta estupenda herramienta de Whole Tomato seguro que os puede pasar lo que a mí. En su WEB tienen bien explicado, y clarito, cómo instalar otros diccionarios aparte del inglés que viene de serie.

Los diccionarios sirven para que el programa encuentre errores ortográficos en los comentarios y otras partes. Yo suelo escribirlo todo en inglés cuando pico código (en mi macarrónico, inigualable e increíblemente culto inglés – ¡ejem!), pero hay proyectos que los pongo en castellano por el destino de los mismos.

Lo más curioso es que, una vez instalados, los diccionarios funcionan en Visual Studio 2008 y anteriores pero no en la versión 2010.

Podemos encontrar en la WEB de Whole Tomato la forma de instalarlos, aquí. Pero está en inglés, así que voy a explicarlo en castellano.

La instalación de un diccionario requiere que nos bajemos el mismo del proyecto Open Office y nos quedemos con el archivo .aff y el .dic. Para castellano son “es_ES.aff” y “es_ES.dic”. Ahora tenemos que poner estos archivos en la carpeta “C:\Program Files (x86)\Visual Assist X\Dict” si nuestro Windows es de 64 bits o en la carpeta “C:\Program Files\Visual Assist X\Dict” si es de 32. Como mis Windows están en inglés, si los vuestros están en castellano, tenéis que sustitur “Program Files” por “Archivos de programa”.

Una vez que tengáis ahí los dos ficheros y reiniciemos Visual Studio, ya podremos usar palabras en el idioma instalado sin que Visual Assist proteste poniéndonos la rayita roja por debajo de la palabra faltona. No hace falta decir que si no queremos un idioma, con borrar sus correspondientes ficheros .aff y .dic todo resuelto.

En Visual Studio 2010 no funcionan. Esa es la forma estándar de hacerlo, pero si tenemos la última versión de Visual Studio nos encontramos con que los diccionarios añadidos no funcionan. No, no es un bug del programa, es que han cambiado la localización de los mismos. Si queremos tenerlos disponibles también para la versión 2010, debemos colocarlos en nuestro profile:

· C:\Users\<usuario>\AppData\Roaming\VisualAssist\Dict

Fijaros que tenéis que cambiar <usuario> por el nombre de vuestro usuario, y que la carpeta “AppData” es oculta.

Detectando fugas de memoria en Visual C++

Rafael Ontivero — Thu, 01 Jul 2010 11:21:00 GMT

A veces nos encontramos con que nuestro programa “chorrea” memoria, y hasta hace poco tiempo no había nada tan terrible para un programador como encontrar dónde se producía el problema, máxime cuando se trataba de aplicaciones con múltiples hilos.

Hubo una época en la que incluso había herramientas de terceros y analizadores de código para encontrar este tipo de problemas. Pero recientemente (creo que a partir de la versión 2005 de Visual C++), Microsoft añadió una serie de utilidades a la compilación Debug para detectar estos errores de forma casi inmediata.

Visual C++ 2005 creó la técnica, y Visual C++ 2008 la perfeccionó. Y por supuesto Visual C++ la mantiene.

Veamos un ejemplo. ¿Qué tiene de malo este código fuente tan sencillo?

class Elemento
{
    public:
    char A,B,C,D;

};

int _tmain(int argc, _TCHAR* argv[])
{
    Elemento *e=new Elemento();

    return 0;
}

Es evidente más allá de toda duda que no hemos liberado e. Este es un caso trivial, porque cuando salgamos del programa el espacio de direcciones se limpiará y no pasará nada. Pero imaginaros esa asignación en un bucle dentro de un programa destinado a estar horas y horas en ejecución.

Llega un momento en que ocupa toda la memoria disponible y revienta. Y lo peor es que el error que nos dé será tan críptico y tan extraño que, si no miramos el programa corriendo en el administrador de tareas no nos daremos cuenta. Y a veces ni así si el crecimiento del uso de la memoria es lento.

Además, en cada máquina el error será diferente, e incluso en la misma máquina dará diferentes errores dependiendo del uso del programa y del propio sistema (hablamos de excepciones extrañas con mensajes extraños e incluso mostrando texto corrupto).

Imaginaros ahora que os dan un programa de cien mil líneas que haya pasado por cinco o seis programadores, algunos de ellos malos y otros peores, que el programa tenga fugas de memoria y que te lo asignen a ti para solucionarlos.

No, no vale pegarse un tiro ni prenderle fuego al ordenador o a la empresa.

***

Es muchísimo más fácil que todo eso. Si nuestro programa está hecho en MFC tan sólo tendremos que recompilarlo con Visual Studio 2008 o siguiente, ejecutarlo un rato desde el IDE y cerrarlo.

Si no usa MFC y sólo usa Win32 u otras librerías, debemos añadir varias cosas al mismo. Abajo el nuevo código.

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

class Elemento
{
    public:
    char A,B,C,D;

};

int _tmain(int argc, _TCHAR* argv[])
{
    Elemento *e=new Elemento();

    _CrtDumpMemoryLeaks();
    return 0;
}

Hemos incluido unos ficheros cabecera y en el punto de salida hemos hecho una llamada a la función _CrtDumpMemoryLeaks(). La salida de la ventana Output (from Debug) tras una ejecución es la siguiente:

[… texto omitido …]
'fugas_memoria.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
Detected memory leaks!
Dumping objects –>
{107} normal block at 0x00695E30, 4 bytes long.
Data: < > 00 00 00 00
Object dump complete.
The program '[716] fugas_memoria.exe: Native' has exited with code 0 (0x0).

Nos fijamos en algunas líneas que nos dicen que ha habido fugas de memoria en un bloque de 4 bytes (que se corresponden a los cuatro char que hemos indicado en la clase). Mola, ¿no?

Bueno, ya sabemos que tenemos una fuga de memoria, pero no sabemos quién la está generando. Vamos a averiguarlo.

Lo primero es fijarnos en la línea

{107} normal block at 0x00695E30, 4 bytes long

y en el número que hay entre corchetes: 107. Ese es el número de bloque de memoria que no está siendo liberado. Una vez que sabemos qué bloque es, debemos relanzar la aplicación pero esta vez en lugar de ejecutarla con F5 o con Debug -> Run, ejecutamos un solo paso para que se nos quede en el punto de entrada inicial pulsando F11 o Debug -> Step Into. También podemos poner un punto de interrupción.

Una vez hecho esto, abrimos una ventana de Watch (Inspección) y añadimos la variable

{,,msvcr100d.dll}_crtBreakAlloc

a inspeccionar. La parte “msvcr100d.dll” dependerá de la versión del compilador que estemos usando. En general será “msvcr71d.dll” para 2003, “msvcr80d.dll” para 2005 y “msvcr80d.dll” para 2008 , aparte de la expuesta para 2010.

Ahora ponemos 107 como valor, ejecutamos el programa y… ¡Nos saltará una excepción! Le damos a “break” y se nos abre un fichero de código fuente de las tripas del runtime de C/C++. Para ir a donde nos interesa, abrimos la ventana de “Call Stack” y buscamos nuestro código fuente entre la pila de llamadas.

¡Y allí estará el new o el malloc() que nunca se libera! ¡Hemos encontrado la fuga!

***

A simple vista parece algo lioso, pero os puedo asegurar que cada vez que explico esto en alguna de las empresas por las que voy se notan los suspiros de alivio de todo el departamento de desarrollo y vuelven las sonrisas.

Si nuestra aplicación está hecha en MFC todavía es más fácil porque la mitad de cosas ya vienen predefinidas (de ahí esa extraña definición de “DEBUG_NEW” que hay por los ficheros de código fuente).

Las apuestas pueden subir cuando el error es aleatorio, pero siempre será más fácil así que sin ayuda. Además, existen trucos como poner periódicamente llamadas al volcado de las fugas, aparte de que hay más opciones para la detección, algunas de ellas no documentadas porque vienen de la propia experiencia personal.

Todo esto que he explicado aquí está contado en varios lugares de la MSDN, y hay más opciones y variación, de hecho una búsqueda de “memory leak” arroja bastantes resultados.

Qué hacer cuando a Visual C++ se le va la pinza en el editor de diálogos

Rafael Ontivero — Wed, 17 Feb 2010 12:25:00 GMT

Supongo que le habrá pasado a más de uno, que está haciendo cosas en el editor de diálogos de Visual C++ y de repente se le va la pinza y deja de funcionar como debe, a veces dando un error que no es un error.

Esto normalmente se debe a que hay algo mal en el código fuente que impide al parser actuar debidamente. Quizás hemos añadido una entrada mal en el mapa de mensajes, o en el DDX o simplemente el fichero de recursos esté mal.

Pero otras veces simplemente pasa, como ahora mismo. En este caso concreto ha sido añadiendo una variable para un control: he introducido el nombre (un nombre correcto) y me ha dicho que la sintaxis estaba mal (ejem) y a partir de ese momento la opción de añadir variable se ha ido de vacaciones…

La solución habitual es llamar a “Build -> Clean Solution”, pero eso tampoco termina de funcionar, así que a veces tenemos que pasar por hacerlo todo a mano…

Pues bien, en este caso concreto, cerramos Visual Studio, nos vamos a la carpeta del proyecto insultante y borramos el fichero de proyecto con la extensión del nombre de red de nuestra máquina (no el .vcproj, si borramos ese la cagamos a base de bien, sino el .vcproj.<host>), y el fichero .aps. A partir de ese momento todo debería volver a funcionar bien. También podríamos, ya de paso, borrar la carpeta DEBUG tanto de la del proyecto como de la solución, así como el .NCB y el .SUO de la solución, pero no es necesario.

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.

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.

Vídeo de introducción al MFC Feature Pack de Microsoft en Microsoft

Rafael Ontivero — Wed, 17 Jun 2009 13:47:00 GMT

Bueno, como podéis ver, aunque me queden un par de entradas sobre el Kindle, el RFOG sigue en la brecha de sus cosas de C++ y demás zarandajas, que fue el origen de este Blog. El que haya escrito poco sobre mis temas últimamente se debe a que he tenido mucho trabajo y he estado enormemente ocupado... ¿Qué? ¿No te lo crees? Pues yo tampoco, para serte sincero.

Esto de las ganas de escribir en el blog va y viene, y unas veces hay más y otras menos, y las más una perrería de tumbarme a leer novelicas de ciencia ficción que no os lo creeríais (o a lo mejor sí, vaya usté a saber).

Bueno, dejémonos de rollos patateros y vayamos al asunto:

Ayer Microsoft publicó en Channel 9 España un video muy chulo que he hecho sobre el Feature Pack. Es una introduccion rápida por las características del mismo, y la verdad es que me hubiera gustado profundizar más. No prometo que lo haga, pero tampoco que no... ya que por fin hay algo en MFC moderno, últil y funcional (y que encima no le he encontrado ningún bug, y eso que llevo ya dos aplicaciones hechas con él).

Bueno, pues nada, aquí está el vídeo. Que lo disfrutéis.

http://channel9.msdn.com/posts/Daniel+Garzon/C-MFC-Feature-Pack/

Cómo abrir máquinas virtuales vmWare en ventanas independientes

Rafael Ontivero — Wed, 25 Feb 2009 15:00:00 GMT

Esta es una tarea pendiente que llevaba bastante tiempo detrás de conseguir. Quizás lo que cuente aquí sea evidente para todos menos para mi, pero por si acaso -y para que no se me olvide-, voy a dejar constancia de ello.

¿Qué desarrollador moderno no tiene varias máquinas virtuales para hacer sus experimentos y pruebas? Yo al menos tengo una buena espuerta de ellas, y si bien antes usaba Virtual PC, que no es un mal producto ni de lejos, al carecer de soporte para USB terminó haciendo que cada vez menos máquinas virtuales estuvieran en Virtual PC y más en vmWare, y en la última instalación de Windows decidí prescindir de Virtual PC ya que muchas veces lanzaba máquinas de ambos productos sin darme cuenta y terminaba con una bonita pantalla azul debida al bit de virtualización...

Virtual PC mantiene una lista de máquinas virtuales y cuando abres una la lanza en una ventana independiente. vmWare tiene similares opciones pero quedan encastradas en la misma ventana virtual, de modo que, aparte de estar siempre visibles, reducen la cantidad de máquina virtual que pueden mostrar. No obstante, todas esas cosas se pueden ocultar sin problema, pero entonces estamos un poco ciegos en cuanto qué tenemos abierto...

Una solución es lanzar las máquinas virtuales y luego entrar en ellas mediante escritorio remoto... pero si estás haciendo por ejemplo una aplicación que usa gráficos de forma intensiva el resultado no es muy bueno, no en relación a tener la pantalla directamente...

Así que yo empecé por tener una carpeta en el escritorio conteniendo un acceso directo a cada una de las máquinas virtuales que tengo, al abrir la primera todo va bien, pero al abrir la segunda ésta oculta la anterior de modo que luego tienes que estar saltando entre una y otra desde el menú Window, o, lo que es peor, si estás en pantalla completa tienes que quitarla, cambiar y volver (evidentemente, quien tenga un solo monitor no está afectado por ese problema, pero quien use dos como yo, se pueden mostrar dos máquinas virtuales a pantalla completa en vmWare, una en cada monitor).

Evidentemente, no hay ningún switch ni ninguna opción para hacer esto. Es decir, no hay ningún sitio ni en las opciones del programa ni en las de la línea de comandos que diga "abre cada máquina virtual en una ventana independiente". La forma más directa es ir al menú inicio, abrir una nueva sesión de vmWare, y desde el programa cargar la nueva máquina virtual (y eso si no está cargada ya en otra ventana) y lanzarla.

Pues bien, la solución es tan evidente que... bueno, mejor la digo y no se hable más:

Abrir cada máquina virtual wmWare en una ventana independiente a partir de un acceso directo.

Bueno, lo primero es añadir la ruta de vmWare a tu path. En mi caso es "C:\Program Files (x86)\VMware". Luego, cambiar el acceso directo de, por ejemplo "C:\MisVM\VM tonta\VM tonta.vmx" a 'vmware "C:\MisVM\VM tonta\VM tonta.vmx"'. Así se abrirá cada una en una ventana independiente.

Sí, ya lo sé, es una tontería.

Hemos leído: John Lakos: Large-Scale C++ Software Design

Rafael Ontivero — Thu, 19 Feb 2009 16:10:00 GMT

Bueno, realmente no lo hemos leído del todo, ya que nos quedan cien de las ochocientas páginas que componen este mamotreto, pero que si no pasa nada caerán esta noche de forma rápida, ya que son varios apéndices.

¿Por dónde empezar? Uf. Es un libro difícil de leer, no por la prosa, sino por el contenido, altamente –muy altamente- técnico. El autor parte de que ya sabes C++, pero no el C++ que puedas aprender en la escuela, sino C++ de verdad. No se entretiene en explicarte esto o aquello, sino que parte a saco, suponiendo que eres un programador profesional.

Como el título indica, el libro está destinado a los desarrolladores de grandes proyectos en C++, aunque ciertamente si eres uno que trabaja en solitario o con poco acompañamiento como yo el libro también te va a servir, y no poco, aunque haya partes que en principio no estén dedicadas a ti, pero siempre se pueden sacar buenas ideas y conceptos.

John comienza con el hecho de que la mayoría de libros sobre diseño de C++ se centran en la parte lógica en lugar de la física, es decir, mucha clase, mucho encapsulamiento, mucha jerarquía de objetos, pero sin tener en cuenta el coste de compilación que supone usar tales abstracciones en un lenguaje como C++. Y nos da ejemplos prácticos y nos muestra cómo un cambio trivial en una línea de un fichero puede suponer la compilación completa de un sistema que puede tardar horas o incluso días.

Después de estudiar métricas sobre el tema, el nivel de acoplamiento entre componentes, etc., comienza lo bueno: técnicas, sesudamente razonadas, para mejorar el diseño, no lógico, sino físico, de forma que los tiempos de compilación y la estabilidad de los interfaces públicos mejoren en gran medida.

Algunos conceptos son triviales y reducen drásticamente el tiempo de compilación, otros son más complejos y requieren una refactorización completa (o casi) del diseño. Lo bueno del libro es que siempre, siempre, vamos guiados por razonamientos formales y por ejemplos completamente válidos, de modo que la conclusión es obvia: el autor tiene toda la razón.

El núcleo del libro son los capítulos 5, 6 y 7, en los que nos habla de los tres niveles a considerar: el de los componentes (entendidos como una unidad física), el de los paquetes y el de los grupos de paquetes. Ciertamente en los tres capítulos se repiten casi las mismas las técnicas aplicadas a cada nivel, pero vienen destinadas a diferentes roles dentro de un teórico grupo de desarrollo. De hecho, he estado prácticamente como un mes y medio dedicado a leer, anotar y releer parte de estos capítulos, aunque el 7 se me quede un poco grande.

La tercera parte del libro trata sobre conceptos lógicos, y es más un compendio de reglas sueltas relativamente razonadas que un todo coherente. No obstante, resulta un buen complemento a lo anterior. Por ejemplo, nos explica la mejor forma de sobrecargar los operadores y por qué otras sobrecargas son generalmente incorrectas aunque formalmente válidas, el uso de tipos y de parámetros, por qué no sobrecargar el operador new de forma global y un largo etcétera.

Se nota que el libro es algo viejo. Nos habla de los espacios de nombres como novedad, y de las plantillas como algo ineficaz y peligroso y que de momento los compiladores no saben tratar adecuadamente, pero sin embargo, nos da razonadas ideas sobre su uso.

Aunque no es un libro para tener sobre la mesa de trabajo, sí que puede resultar útil su lectura periódica y su consulta cuando nuestro proyecto se vuelva un poco inmanejable. Además, al final de cada capítulo y del propio libro, viene un interesante resumen de todos los temas tratados en cada uno de ellos.

En fin, que se trata de un libro muy recomendable para aquellos profesionales de C++ o amateurs que quieran serlo.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

La solución

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

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

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

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

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

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

*(&FixedElementField+i)

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

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

El uso de esta construcción es bien sencilla:

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

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

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

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

C++: Insertar un ejecutable dentro de otro… y luego ejecutarlo

Rafael Ontivero — Thu, 11 Sep 2008 15:10:00 GMT

Vamos a explicar cómo tomar un ejecutable (o cualquier otro fichero binario), insertarlo dentro de un ejecutable y posteriormente cómo recuperar ese ejecutable embebido, soltarlo a disco y ejecutarlo. El escenario típico es borrar el propio ejecutable que actúa como hospedante, pero seguro que a las mentes calenturientas de mis lectores se les ocurren más aplicaciones.

El problema no existía en Windows 95 y siguientes: un programa podía borrar su propio ejecutable y terminar sin ningún problema (o casi). Pero en los núcleos NT hacer eso es harina de otro costal. Teóricamente se puede hacer mientras que el ejecutable a borrar no abra ningún handle… pero evidentemente cualquier ejecutable suele abrir no uno, sino infinidad de ellos.

La solución consiste entonces en disponer de dos ejecutables en disco. El primero hará su tarea y llamará al segundo antes de terminar, que tras unos instantes procederá a borrar el primero, quedando éste último en disco. Pero entonces tenemos que distribuir dos ficheros y colocarlos en el mismo sitio, por lo que la mejor solución es que el primero contenga al segundo en sus entrañas y lo use a voluntad. Incidentalmente el segundo podría decir a Windows que lo borre en el siguiente reinicio, pero no vamos a entrar en detalles sobre esto.

Primer paso: Insertar el ejecutable

Suponiendo que tengamos ya construido nuestro ejecutable (que vamos a llamar “borra.exe”), insertar un recurso del tipo RCDATA en un fichero ejecutable es una tarea trivial. Basta con abrir el fichero de recursos del ejecutable (el .rc) como texto e insertar la línea:

ELEXE RCDATA "..\\final\\Win32\\Release\\borra.exe"

Recompilamos y ya tenemos el ejecutable como recurso binario embebido en nuestro propio ejecutable. Evidentemente no estamos limitados a ningún tipo de archivo en concreto. Podríamos hacerlo incluso con recursos normales (mapas de bits, iconos, cadenas, etc.). La única diferencia es la forma de recuperar un recurso binario de uno almacenado como estándar.

Segundo paso: Sacar el ejecutable y ponerlo en disco

Cuando queramos volcar nuestro ejecutable a disco, debemos ejecutar algo parecido a lo siguiente:

HRSRC res=FindResource(NULL,_T("ELEXE"),RT_RCDATA);
if(res==NULL)
     return GetLastError();

int size=SizeofResource(NULL,res);
HGLOBAL hRes=LoadResource(NULL,res);
unsigned char *pRes=(unsigned char *)LockResource(hRes);

HANDLE hFile=CreateFile(szT2Path,GENERIC_WRITE,0,NULL,CREATE_ALWAYS,0,NULL);
if(hFile==INVALID_HANDLE_VALUE)
     return GetLastError();

WriteFile(hFile,pRes,size,&bytesWritten,NULL);
CloseHandle(hFile);

ShellExecute(HWND_DESKTOP,NULL,szT2Path,NULL,NULL,SW_SHOWNORMAL);

El primer paso consiste en llamar a FindResource con el nombre y el tipo de recurso. Si nuestro fichero hubiera estado almacenado en otro lugar que no fuera nuestro propio ejecutable, el primer parámetro a pasar es la instancia del fichero externo.

Tras tener un handle válido, tenemos que mirar el tamaño que ocupa el recurso almacenado, lo que hacemos con SizeofResource.

Ahora viene cargar el recurso en memoria y obtener un handle de memoria (LoadResource). Pero todavía no podemos acceder a los bytes de nuestro fichero, debemos bloquear el acceso a los mismos mediante LockResource, lo que nos devolverá un área de memoria accesible.

Aquí el autor lo ha asignado a un buffer de caracteres sin signo, pero realmente cualquier tipo de dato es perfectamente válido, aunque tenemos que tener en cuenta de no guardar ningún byte de más en el fichero final. Haciéndolo con un buffer de caracteres nos aseguramos de guardar el tamaño correcto.

Ya solo nos queda guardar el buffer a disco y hacer la llamada para ejecutar el fichero extraído.

Quizás nos preguntemos por qué no hemos liberado la memoria apuntada por pRes: está expresamente descrito en la documentación de la MSDN: no debemos hacerlo nosotros, ya lo hará el sistema cuando corresponda.

Consideraciones finales

Evidentemente una solución más sencilla sería marcar el propio ejecutable para ser borrado en el siguiente reinicio en lugar de hacer toda esta parafernalia, pero a veces puede no interesarnos que dicho fichero esté en disco hasta ese momento.

De todos modos aplicaciones para esto las hay a montones. Soltar un ejecutable que haga algo, termine y luego sea borrado por el programa principal, forzar un reinicio del programa principal, distribuir un solo exe que luego suelte todos los ficheros que necesite…

Singleton con y sin Singleton

Rafael Ontivero — Mon, 03 Mar 2008 18:20:28 GMT

Ahora que están de moda los antipatrones, voy a explicar un patrón que es muy famoso pero que no me gusta absolutamente nada, no por el diseño del mismo, sino por los efectos laterales no deseados que genera. Por ello también voy a explicar otra forma de construirlo que me gusta más, aunque adolece de otras limitaciones.

Singleton es un patrón que nos obliga a tener una sola instancia de una clase, es decir, globalmente sólo podremos disponer de un objeto de ese tipo. El truco está en conseguir que, hagamos lo que hagamos, no podamos crear más de una instancia.

En lenguajes como C++ este patrón tiene menos utilidad que en C++/CLI, C# o VB.NET, ya que la forma clásica de hacer algo similar es tener una variable global accesible por todos los módulos, cosa de la que suele encargarse el enlazador de hacer.

Pero los lenguajes .NET adolecen de falta de variables globales; es decir, no puedes tener un objeto global y visible en toda la aplicación. Personalmente no entiendo este purismo tan quisquilloso, ya que los lenguajes .NET no son precisamente orientados a objetos puros, y menos aún con la especificación 3.0 de C#. Y si encima este hecho complica bastante ciertos desarrollos, el absurdo sube de nivel.

Pero es lo que hay.

La solución para tener un objeto global es disponer de una clase estática. Si bien a priori resulta una buena idea, en la práctica no lo es tanto. Independientemente del hecho de que los constructores estáticos en .NET no funcionan muy bien o, en otras palabras, tienen bastante bugs (al menos en la versión 2.0, aunque dudo mucho que lo hayan solucionado en los SP1), tenemos ciertas limitaciones, como la imposibilidad de que se llame a otro constructor estático de forma encadenada…

¿Y por qué comento esto? Pues porque el patrón Singleton utiliza una variable y un constructor estático. Veámoslo en C#:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Text;

4:

   5: class Singleton

   6: {

   7:     public static Singleton Instancia=new Singleton();

8:

   9:     private Singleton() {}

10:

  11:     public int Numero;

  12:     public void DiNumero()

  13:     {

  14:         Console.WriteLine(Numero++.ToString());

  15:     }

  16: }

17:

  18: class Program

  19: {

  20:     static void Main(string[] args)

  21:     {

  22:         Singleton.Instancia.Numero = 33;

  23:         for (int i = 0; i < 10;i++)

  24:             Singleton.Instancia.DiNumero();

  25:     }

  26: }

Observamos que el truco está en definir un constructor privado. Al hacerlo, ya no podremos equivocarnos y crear varias instancias de esta clase, y la única forma de acceder al único objeto que pueda haber en toda la aplicación es mediante

   1: Singleton.Instancia

Si intentamos crearnos un objeto del tipo Singleton, el compilador protestará y nos dirá que el constructor no está accesible.

Si alguien quiere una explicación más en detalle, se puede pasar por la MSDN o por aquí.

¿Nadie ve el problema?

Pues hay dos. El primero ya lo hemos dicho: tenemos un objeto global al sistema, que es estático y por tanto sigue unas reglas algo diferentes, como la imposibilidad de hacer una llamada a otra variable estática que implemente su propio constructor estático dentro del constructor de nuestro Singleton… O en otras palabras: no podemos tener Singletones anidados, no al menos bajo .NET.

Pero el mayor problema es otro. Cuando se habla de Singleton, se pone un ejemplo con dos líneas de código y listo. Pero una clase de la Vida Real™ no es sencilla. Tendremos varios métodos miembro, así como variables. ¿Cómo las inicializamos? ¿En el constructor? ¡Pero si no tiene constructor al que podamos pasarle valores! ¿Las ponemos públicas? ¿Propiedades?

Una solución es la mostrada aquí:

   1: Singleton.Instancia.Numero = 33;

   2: for (int i = 0; i < 10;i++)

   3:     Singleton.Instancia.DiNumero();

Pero a mí al menos eso me parece una guarrería mayor, y más cuando haya varios datos miembro, como suele ser habitual en clases no triviales… La única cosa que podemos hacer es especificar valores por defecto en el constructor estático:

   1: private Singleton() { Numero = 50; }

Pero eso sólo alivia el problema, no lo soluciona.

Qué bonito sería que pudiéramos indicar algo como

   1: [Pattern(Singleton)]

   2: class Singleton

   3: {…

Y disponer de la clase como si tal cosa… Pero esa es otra guerra.

Otra aproximación

Veamos ahora una variante, que es la que yo implemento en mis propios programas. Primero el código:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Text;

4:

   5: class MiSingleton

   6: {

   7:     private static int m_cuenta=0;

8:

   9:     private int m_numero;

  10:     public MiSingleton(int num)

  11:     {

  12:         m_cuenta++;

  13:         if (m_cuenta > 1)

  14:             throw new Exception("RFOG Singleton Exception");

15:

  16:         m_numero = num;

  17:     }

  18:     public void DiNumero()

  19:     {

  20:         Console.WriteLine(m_numero++.ToString());

  21:     }

  22: }

  23: class Program

  24: {

  25:     static void Main(string[] args)

  26:     {

  27:         MiSingleton m = new MiSingleton(33);

  28:         for (int i = 0; i < 10;i++)

  29:             m.DiNumero();

30:

  31:         MiSingleton n=new MiSingleton(88);

  32:     }

  33: }

Aquí encontramos otros problemas y otras limitaciones, pero personalmente me gusta más así. Definimos una variable estática, un entero que nos servirá para contar cuántas instancias de esta clase tenemos.

Definimos un constructor público al que podremos pasarle cualquier número de parámetros que queramos, de hecho se trata de una clase normal y corriente que tiene un bloque de código concreto en el constructor:

   1: m_cuenta++;

   2: if (m_cuenta > 1)

   3:     throw new Exception("RFOG Singleton Exception");

La segunda vez que intentemos instanciar esta clase obtendremos una excepción. Aquí la limitación está en que nos daremos cuenta de nuestro error en tiempo de ejecución, no de compilación, lo que ciertamente es una desventaja seria pero que pierde fuerza cuando nos enfrentamos a las limitaciones y bugs de los constructores estáticos.

La segunda instanciación dentro del bloque de main() lanzará la excepción. La otra limitación a esto viene de la imposibilidad de tener variables globales y de que tengamos que pasar m siempre que queramos usarlo.

Lo ideal sería tener ambas opciones juntas, pero ciertamente dentro de .NET es imposible.

La que os espera... (ji ji)

Rafael Ontivero — Fri, 01 Feb 2008 10:37:00 GMT

Hará como una hora que he recibido de Amazon mis últimas adquisiciones, que son los seis libros situados en la parte inferior que se pueden contemplar en la foto que acompaña esta entrada... casi 200 euros en libros, sumados a otros doscientos y pico de varios pedidos anteriores...

A los de la foto hay que añadir el "Reverse Engineering" sobre el que he comentado y otro sobre patrones, en los que creo poco, por lo menos tal y como se presentan habitualmente (quizás se deba a que en las aplicaciones que yo desarrollo no hay sitio para ellos, y me refiero a sitio físico, ya que a veces con límites de 8 K para el código pocas florituras puedes hacer)...

También hay que añadir un par de libros sobre C++/CLI que ya he comentado por estos lares y dos más sobre C# de los que hablé tiempo ha...

Esto es como un vicio, una vez que compras en Amazon y te sale bien, ya no te puedes contener, tal ha sido el cambio de costumbres que mi librero habitual me dice que ya no me paso por la sección de informática... Y se lo he contado... Y me ha preguntado qué libros son los buenos... Lo mismo en unos meses veo libros en inglés en su escaparate, je je.

Quiero aprovechar para contar un problema que tuve en Amazon y su satisfactoria solución. El pedido anterior a éste traía "Win32 Programming" (el que está arriba a la izquierda del todo), que son dos tomos, pero me vino uno solo... Puesto en contacto con Amazon, me pidieron que retornara el defectuoso y que les dijera cuánto me había costado. Así lo hice, y antes siquiera de terminar de leer el correo, ellos ya me habían enviado, cargándomelo, un nuevo paquete. Una vez que les informé del envío, de su tracking y de lo que me costó hacerlo, me ingresaron ese coste más el que me habían cargado por el nuevo envío... Y cuando recibieron el paquete me enviaron un correo con que todo había sido solucionado.

Efectivamente, haciendo cuentas al final no tuve que pagar ningún dinero por SU problema, si bien es cierto que son un tanto barrocos a la hora de procesar las órdenes.

¿Qué? Ah, sí, el título de la entrada... Pues eso, que ya sabéis lo que voy a leer y estudiar... Así que andad preparados.

Se me olvidaba, la foto:

C++/CLI y C# VII: GetLastError en escenarios de interop

Rafael Ontivero — Sun, 25 Nov 2007 19:59:00 GMT

Introducción

Hay un tema que ha aparecido indirectamente en algunos mensajes del grupo de C# relativo al tema de Interop mediante atributos (que es el único que puede hacer C# y VB.NET), y que desde que estoy leyendo dicho grupo nadie ha advertido o ha tenido algún problema con él, o al menos yo no me he dado cuenta de ello.

Cuando uno hace una llamada al API de Win32, muchas funciones devuelven un estado de error a través de un handle inválido o simplemente devolviendo FALSE. Es una consecuencia de los tiempos en que ni el compilador ni Windows soportaban ningún modelo de excepción. Era tarea del programador comprobar dicho valor de retorno y luego realizar una llamada a GetLastError(), que devolvía un número y que se podía convertir a una cadena más o menos inteligible mediante una nueva llamada a otra función: FormatMessage.

Si ahora volvemos al entorno manejado, cuando queramos realizar una llamada a través de interop a cualquier función de Win32 que utiliza ese formato para retornar un error, nos encontramos con la duda de qué ocurre entre las dos llamadas, es decir, nuestra llamada al método y una segunda para obtener el error.

El Interop por atributos funciona de la siguiente forma: cuando nosotros hacemos una llamada a través de este sistema, el compilador inserta una cosa llamada thunk, que consiste en una llamada a ejecutar cierto código especial. Entre muchas otras cosas, este código se encarga de traer la DLL de Win32 a nuestro espacio de direcciones (es un decir, porque realmente no trae nada, sino que prepara el contexto para realizar la llamada), realizar la conversión de los parámetros en parámetros compatibles para Win32, ejecutar dicha función y volver a convertir todo el tema en valores que el .NET sea capaz de entender. Lento, muy lento.

Cuando volvamos a llamar a otra función, la operación se repite, por lo que una vez que se ha realizado la llamada a la función que queríamos, cuando hagamos la nueva llamada a GetLastError() repetiremos todo lo de arriba, de forma que hemos perdido el valor, ya que estamos en un nuevo contexto que nada tiene que ver con el anterior.

Si seguimos las reglas tal y como las hemos planteado, el tema tendría un fallo garrafal en cuanto a funcionalidad hacia el API Win32… Pero lo cierto es que los chicos de MS no son tontos, y han solucionado el problema de forma bastante elegante, aunque ineficaz desde un punto de vista del rendimiento, pero creo que excepto permitiendo el Interop al estilo en que se permite en C++/CLI, es la única forma posible de hacerlo.

Cómo funciona por defecto

Cuando hacemos una llamada al API Win32, el sistema de Interop hace por nosotros la llamada a GetLastError() en cada llamada, de forma que dicho resultado se guarda en el contexto. Y podemos accederlo mediante el método Marshal.GetLastWin32Error().

Es decir, cada vez que hagamos una llamada mediante Interop a una función del API de Win32, tendremos disponible el valor devuelto por el GetLastError() de Win32, ya que dicha llamada se ha hecho automáticamente.

Activarlo y desactivarlo

Este funcionamiento viene activado por defecto, y lo cierto es que añade más sobrecarga a un sistema ya sobrecargado de por sí ya que, ante cada llamada a una función de Windows, el sistema hace dos, además de guardar un valor en el TLS (Thread Local Storage) del contexto de ejecución en el que se haya realizado. Y nosotros tendremos que realizar también una nueva consulta a Marshal.GetLastWin32Error(), y si queremos enseñar un mensaje bonito, a FormatMessage() de nuevo, que no es una función sencilla de utilizar y que requiere también un buen trabajo de atributos y de interop.

Una llamada a un método de USER32.DLL podría tener esta firma:

[System.Runtime.InteropServices.DllImport("user32.dll")]
extern static void SampleMethod();

De esta forma, estamos indicando el funcionamiento por defecto, es decir, poder obtener el valor del error de Win32.

Pero si especificamos esta forma:

[System.Runtime.InteropServices.DllImport("user32.dll")], SetLastError=false]
extern static void SampleMethod();

Estamos indicando al sistema de Interop que no realice la llamada a GetLastError(), de forma que optimizamos en cierta medida los accesos a Win32 siempre y cuando no nos interese determinar si hubo error o no.

Un ejemplo podría ser una llamada a MessageBeep(). Si falla poco podemos hacer, ya que el usuario no oirá nada y punto.

Como siempre, la versión en PDF está aquí.