• Añadir la macro _CRTDBG_MAP_ALLOC del preprocesador, ya sea definiéndola en algún archivo del proyecto o en las opciones de compilación del proyecto.
• Incluir en el siguiente orden stdlib.h y crtdbg.h en los archivos dónde se busquen las fugas de memoria. El archivo crtdgb.h sustituye las funciones malloc y free por unas propias que registran la memoria reservada y liberada.
• Añadir la función _CrtDumpMemoryLeaks () al final del programa en el que se buscan las fugas de memoria. Esta función muestra por la salida de depuración las fugas de memoria detectadas.

Todo esto sólo funcionará cuando el proyecto se compile con la macro _DEBUG definida, es decir, en lo que debería ser para todos la versión de depuración del programa.

La macro _CRTDBG_MAP_ALLOC sirve para que la función _CrtDumpMemoryLeaks () muestre información sobre el archivo y la línea en la que se produjo la fuga de memoria.

Un pequeño ejemplo de cómo quedaría todo:

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

int
main (int argc, char *argv[])
{
    /* Código del programa */

    _CrtDumpMemoryLeaks ();

    return 0;
}

Si este programa tuviera alguna fuga de memoria, al compilarlo en modo depuración y ejecutar el depurador de Visual Studio, se obtendría en la salida de éste un listado con las fugas de memoria del programa.

Para más información, leed el artículo Enabling Memory Leak Detection de la MSDN.

;Archivo INI

[sección]
clave1=valor1
clave2=valor2

En estos casos lo mejor es no reinventar la rueda, así que hice un par de búsquedas por internet, pero lo que encontré no me gustó, así que ni corto ni perezoso realicé mi propio cutre-parser que funcionaba bien para lo que quería, archivos INI creados a mano, pero no para todos los casos que podría tener un archivo INI.

Así que gracias a un poco de tiempo libre me he puesto las pilas un poco y he ido modificando aquel cutre-parser hasta algo más decente, aunque todavía le quiero dar un par de vueltas para dejarlo bien. De todos modos, el código que hay ahora mismo funciona bastante bien, así que he creado un repositorio para mini en github (por cierto, git mola mil), así no tenéis excusa para probarlo.

¿Qué son las autotools?

Las autotools, son programas que se usan para crear un paquete de código fuente que se pueda distribuir y compilar de una manera sencilla (configure, make y make install). Los programas que forman las autotools son los siguientes:

• aclocal
• autoconf
• automake

Estos programas son la base para crear el paquete de código fuente, para ello se tendrán que generar unos archivos concretos.

Estructura del código fuente a distribuir

Las autotools se usan para generar el paquete «tar.gz» que contiene el código fuente del programa que se va a distribuir, normalmente estos paquetes siguen una estructura estándar. La estructura básica es:

• src: Directorio del código fuente.
• AUTHORS: Indica los autores del programa.
• ChangeLog: Indica los cambios que se han ido produciendo.
• COPYING: Indica la licencia de distribución que tiene el programa. (Autogenerado)
• INSTALL: Explica cómo instalar el programa. (Autogenerado)
• NEWS: Indica las noticias relacionadas con el programa.
• README: Un pequeño documento en el que se describe el programa y se explican temas concretos de éste.
• THANKS: Indica los agradecimientos que tenga el autor/es.
• TODO: Indica una pequeña lista de cosas por hacer.

De este modo, si se van a utilizar las autotools sería aconsejable seguir la estructura anterior, y crear todos los archivos menos los como «autogenerado» que, obviamente, se generarán automáticamente, aunque siempre se pueden crear a mano ya que puede que no se quiera tener el contenido autogenerado.

El archivo «configure.ac»

Sobre este archivo gira toda la generación del programa para su distribución. En él se escriben las macros para los diferentes programas que se ejecutarán: aclocal, autoconf y automake.

AC_PREREQ(2.52)
AC_INIT([hola mundo], [0.1])
AM_INIT_AUTOMAKE([])

AC_PROG_CC
AC_CONFIG_FILES([Makefile src/Makefile])
AC_OUTPUT

• Programa aclocal: Sirve para generar el archivo «aclocal.m4». ¡Sólo se generará si en el archivo «configure.ac» hay macros de automake!
• Macros de autoconf: Empiezan por AC_*, y se buscan en el archivo «configure.ac» y en el «aclocal.m4» si existe. Sirven para la configuración correcta del programa.
• AC_PREREQ(versión) indica la versión de autoconf necesaria.
• AC_INIT([aplicación], [versión]) inicializa autoconf, recibe como parámetros el nombre del programa y su versión.
• AC_PROG_CC indica que realizará una compilación de código escrito en C.
• AC_CONFIG_FILES([Makefile src/Makefile]) indica los archivos «Makefile» que se van a generar a partir de sus respectivos «Makefile.am».
• AC_OUTPUT indica los archivos que finalmente debe generar el script «configure».
• Macros de automake: Empiezan por AM_*, y sirven para la generación de los diferentes «Makefile».
• AM_INIT_AUTOMAKE([]) inicializa automake, se le puede pasar un parámetro que la verdad no sé lo que indica, para mi ejemplo no hace falta pasárselo.

Aviso: Las macros no pueden llevar un espacio entre su nombre y el paréntesis de inicio.

Los archivos «Makefile.am»

Los archivos «Makefile.am» contienen las reglas para generar los archivos «Makefile» correspondientes a los directorios dónde se encuentran, por lo que habrá un archivo por directorio en el que se tenga que realizar alguna operación con make.

De este modo, siempre se debe tener un archivo «Makefile.am» en el directorio raíz del proyecto, este archivo contendrá algo similar a lo siguiente:

SUBDIRS = src
EXTRA_DIST = AUTHORS ChangeLog NEWS README THANKS TODO

• SUBDIRS enumera los directorios que contienen otros archivos «Makefile.am».
• EXTRA_DIST enumera los distintos archivos que deberá tener el paquete, para distribuir el código fuente que se generará.

En este caso el directorio «src» es dónde, supuestamente, deberá estar el código fuente de nuestra aplicación y tendrá un archivo «Makefile.am», que indicará las reglas para compilar nuestro código fuente correctamente.

El archivo «Makefile.am» tendrá el siguiente contenido:

bin_PROGRAMS = hola−mundo
hola_mundo_SOURCES = hola−mundo.c

• bin_PROGRAMS indica el nombre del ejecutable final.
• hola_mundo_SOURCES indica los archivos con el código fuente de la aplicación.
• Si se necesitarán bibliotecas se debería añadir hola_mundo_LDADD con las macros necesarias para dichas bibliotecas en el archivo «configure.ac».

Nota: Para generar una biblioteca, se debería usar libexec_PROGRAMS en lugar de bin_PROGRAMS.

Generación del script «configure»

Una vez creados los archivos necesarios, se deben realizar los siguientes pasos:

1. Generación:

   $ aclocal
   $ autoconf
   $ automake --add-missing

2. Compilación y ejecución del programa:

   $ ./configure
   $ make
   $ src/hola−mundo

3. Distribución del programa:

   $ make distcheck

Para ampliar un poco más All you should really know about Autoconf and Automake

He de decir que este libro no me ha sorprendido mucho, ya que en cuanto llevas algo de tiempo programando sobre Win32 y visitando la MSDN a menudo, te acabas conociendo las partes más utilizadas. Además, este libro es bastante antiguo (del 2004).

En general, no me convence la forma de explicar los temas por parte del autor, casi todos los capítulos se limita a copiar las diferentes funciones que se utilizan para hacer lo que sea, y a explicar cada uno de sus parámetros. Por lo que el libro se transforma en una especie de resumen de la MSDN.

De todo el contenido del libro me quedaría con los capítulos sobre los servicios de Windows y las estructuras de seguridad (SIDs, ACLs, ACEs) de Windows.

Aún así, puede servir como punto de partida para empezar a programar sobre Windows utilizando Win32, si no fuera por las pegas que he comentado.

Recomendación: Baja.
Nivel: Medio.
Idioma: Inglés.

Windows emite estas señales a las aplicaciones correspondientes para que puedan manejarlas y terminar de una forma adecuada, por ejemplo: realizando las operaciones necesarias para no dejar archivos en algún estado catastrófico perdiendo la información de estos.

Manejando las señales

Para manejar estas señales las aplicaciones disponen de una lista de manejadores, en la que en principio sólo hay una función que termina la ejecución del proceso. Para añadir/borrar un manejador a la lista se dispone de la función SetConsoleCtrlHandler:

BOOL WINAPI SetConsoleCtrlHandler (PHANDLER_ROUTINE HandlerRoutine, BOOL Add);

Donde los parámetros son:

• HandlerRoutine: Es un puntero a la función que manejará las señales recibidas. Tendrá la forma:

  BOOL WINAPI CtrlHandler (DWORD CtrlType)

• Add: Si su valor es TRUE indica que la función se añadirá a la lista de manejadores de las señales, en cambio si es FALSE indica que la función se borrará de la lista de manejadores.

La función del manejador

Como se ha mencionado antes, la función del manejador tiene la forma:

BOOL CtrlHandler (DWORD CtrlType);

La función del manejador deberá tratar las señales que crea conveniente, utilizando el parámetro CtrlType que recibirá uno de los siguientes valores:

• CTRL_C_EVENT: Señal de Ctrl+C.
• CTRL_BREAK_EVENT: Señal de Ctrl+Break.
• CTRL_CLOSE_EVENT: Señal del cierre de la ventana de la consola.
• CTRL_LOGOFF_EVENT: Señal del cierre de la sesión.
• CTRL_SHUTDOWN_EVENT: Señal del apagado del sistema

Este manejador devolverá TRUE cuando haya tratado la señal, y FALSE cuando no la haya tratado, de modo que pasará a ejecutar el siguiente manejador.

Ejemplo

Como todo se entiende mejor con un ejemplo, aquí os dejo el ejemplo de la MSDN sobre registrar un manejador de señales de control de la consola:

#include <windows.h>
#include <stdio.h>

BOOL WINAPI CtrlHandler (DWORD CtrlType) {

    switch (CtrlType) {

        // Handle the CTRL-C signal.
        case CTRL_C_EVENT:
            printf ("Ctrl-C event\n\n");
            Beep (750, 300);
            return TRUE;

        // CTRL-CLOSE: confirm that the user wants to exit.
        case CTRL_CLOSE_EVENT:
            printf ("Ctrl-Close event\n\n");
            Beep (600, 200);
            return TRUE;

        // Pass other signals to the next handler.
        case CTRL_BREAK_EVENT:
            printf ("Ctrl-Break event\n\n");
            Beep (900, 200);
            return FALSE;

        case CTRL_LOGOFF_EVENT:
            printf ("Ctrl-Logoff event\n\n");
            Beep (1000, 200);
            return FALSE;

        case CTRL_SHUTDOWN_EVENT:
            printf ("Ctrl-Shutdown event\n\n");
            Beep (750, 500);
            return FALSE;

        default:
            return FALSE;
    }
}

int main (int argc, char *argv[]) {

    BOOL added;

    added = SetConsoleCtrlHandler ((PHANDLER_ROUTINE) CtrlHandler,
                                   TRUE);
    if (added) {
        printf ("\nThe Control Handler is installed.\n");
        printf ("\n -- Now try pressing Ctrl+C or Ctrl+Break, or");
        printf ("\n    try logging off or closing the console...\n");
        printf ("\n(...waiting in a loop for events...)\n\n");

        while (1) {
            Sleep (500);
        }

    } else
        printf ("\nERROR: Could not set control handler");

    return 0;
}

Pues si vuestra consola admite colores ANSI (casi todas lo hacen, incluso la de Windows), lo tenéis muy fácil ya que mediante unas cadenas de escape se pueden cambiar los colores. Estas cadenas siguen un patrón del tipo:

<ESC>[{attr1};...;{attrn}m

Donde attrX es un código numérico que determina una característica del texto (como subrayado), el color del texto y el color del fondo de éste. Estos código están definidos y se pueden consultar en esta web que contiene las cadenas de escape ANSI.

De este modo, si se quiere cambiar el color del texto, por ejemplo en un programa en C, se haría lo siguiente:

printf ("\e[32m Soy de color verde\n");
printf ("\e[0m Vuelvo a ser del color normal.\n");

Lo normal es que estas cadenas se guarden en algún tipo de constantes, para luego usarlas y no tener que escribir la cadena de escape cada vez que queramos cambiar el color.

(Sacado de zeros and ones)

La clase GtkWidget

Es la clase básica de la que parte cualquier otro widget de GTK+, esta clase en sí misma no hace nada específico (por ejemplo: un cuadro de texto, un botón, …) para ello existen clases específicas, como las ventanas o los contenedores. Estas clases más específicas heredan de la clase GtkWidget las funciones, atributos y señales básicas que les hacen ser clases válidas para poder usarse en GTK+.

Partes esenciales de un widget

Como cualquier clase de cualquier lenguaje de programación orientado a objetos, la clase de un widget se divide en:

• Funciones: Son las funciones que permiten trabajar con dicha clase. Aquí las llamo funciones porque estamos trabajando sobre C, si fuera sobre cualquier lenguaje de programación orientado a objetos las llamaría métodos.
• Atributos (o propiedades): Son variables asociadas a la clase que identifican propiedades de ésta, por ejemplo: el color, la altura, …
• Señales: Muchos lenguajes de programación orientada a objetos no usan señales, pero en GTK+ son necesarias para controlar los eventos.
  Las señales identifican el evento que se ha producido, y se deben asociar a alguna función para que GTK+ al interceptar la señal ejecute dicha función, por ejemplo: al pulsar un botón que se escriba un mensaje en un cuadro de texto, la señal sería la pulsación del botón y la función asociada a ella la escritura del mensaje en el cuadro de texto.

De este modo, en la documentación de la API de GTK+, se puede observar que cada widget se descompone en estas partes para que sepamos claramente qué se puede hacer y/o qué tareas realiza dicho widget.

Las ventanas

Las ventanas son los widgets raíces, ya que sin ellas no podría haber aplicación. Hereda las propiedades de GtkContainer, por lo que puede contener a otro widget (¡cuidado! sólo a uno), por lo que lo normal es que dentro de una ventana se introduzca un GtkBox de algún tipo, en el que se coloquen el resto de widgets de la aplicación.

Como veis en el título digo ventanas, y es que hay varios tipos de ventanas:

• GtkDialog: Crea una ventana emergente. Dentro de este tipo de ventanas existen varios tipos predefinidos como el dialogo de “Acerca de”, el de elección de archivo, el de elección de color, …
• GtkInvisible: Crea una ventana invisible.
• GtkMessageDialog: Crea una ventana con un mensaje personalizado, es uno de los tipos predefinidos del GtkDialog. Son las ventanas que muestran mensajes de error, advertencia, …
• GtkWindow: Crea una ventana normal y corriente. Será el widget que se use como base para cualquier aplicación.
• GtkAssistant: Crea un asistente para guiar al usuario en varios pasos.

Como he dicho, de todos estos tipos el más importante es GtkWindow, que es la ventana normal y corriente que tiene cualquier aplicación.

Como cualquier widget de GTK, GtkWindow es muy fácil de manejar con echar un ojo a la documentación de la API se aprende rápido como funciona todo. A continuación os pongo un trozo de código en el que creo una ventana vacía:

#include <gtk/gtk.h>

int main (int argc, char *argv[]) {

    GtkWindow *window;

    gtk_init (&argc, &argv);

    window = (GtkWindow *) gtk_window_new (GTK_WINDOW_TOPLEVEL);
    gtk_window_set_title (window, "Soy una ventana");

    g_signal_connect (G_OBJECT (window), "destroy",
                      G_CALLBACK (gtk_main_quit), NULL);

    gtk_widget_show_all (GTK_WIDGET (window));
    gtk_main ();

    return 0;
}

Este código muestra una ventana con el título Soy una ventana.

Por este motivo, se me ocurrió hacer un pequeño programa (en C) que genera contraseñas aleatorias (llamado passwdgen), con una serie de opciones:

• En base al conjunto alfanumérico (alfabeto en mayúsculas, minúsculas y/o números).
• Longitud mínima y/o máxima personalizable, si se le da una mínima y otra máxima se escogerá una longitud aleatoria entre los valores dados. (La longitud predeterminada es de ocho caracteres)

De este modo, se genera aleatoriamente una cadena de caracteres en base al conjunto de caracteres y la longitud que queramos. Lo he subido a Google Code para que todos podáis hacer uso de él y/o si queréis trastear con el código, está licenciado bajo GPL 2.

Si estáis interesados, visitad la web de passwdgen.

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>

/* Proceso hijo */
void
do_child (int data_pipe[])
{
    /* Cerramos la parte de la tubería que no usamos (lectura) */
    close (data_pipe[0]);

    /* Tubería de escritura a salida estándar */
    dup2 (data_pipe[1], STDOUT_FILENO);

    /* Ejecutamos el proceso que queramos (p. ej.: ls) */
    execvp ("ls", NULL);

    perror ("execvp");
}

/* Proceso padre */
void
do_parent (int data_pipe[])
{
    char salida[200];
    int nread;

    /* Cerramos la parte de escritura */
    close (data_pipe[1]);

    /* Leemos la salida */
    nread = read (data_pipe[0], salida, 200);
    while (nread > 0) {
        printf ("%s", salida);
        nread = read (data_pipe[0], salida, 200);
    }

    close (data_pipe[0]);
}

int
main (int argc, char* argv[])
{
    int data_pipe[2];
    int pid;
    int rc;       

    rc = pipe (data_pipe);
    if (rc == -1) {
        perror ("pipe");
        exit (1);
    }

    pid = fork ();
    switch (pid) {
        case -1:
            perror ("fork");
            break;

        /* Proceso hijo */
        case 0:
            do_child (data_pipe);
            break;

        /* Proceso padre */
        default:
            do_parent (data_pipe);
            break;
    }

    return 0;
}