SoloCodigo

Crear nuestra propia Run Time Library (Tercera Parte)

En la MSDN encontré algo interesante sobre la opción /ENTRY del linker:


"Type a function name in the Entry-Point Symbol text box (or in the function argument on the command line). The function must be defined with the __stdcall calling convention. The parameters and return value must be defined as documented in the Win32 API for WinMain (for an .EXE file) or DllEntryPoint (for a DLL). It is recommended that you let the linker set the entry point so that the C run-time library is initialized correctly, and C++ constructors for static objects are executed."

Vamos a probar un poco de código con objetos estáticos:

ESTATICOS.CPP

Compilando y linkeando este código con la Run Time Library por defecto conseguimos cuatro MessageBox, dos con 66 (el constructor) y dos con 99 (el destructor).
Ahora tratamos de compilar y linkear con nuestra Run Time Library y nos encontramos con lo siguiente:
estaticos.obj : error LNK2001: unresolved external symbol _atexit
estaticos.exe : fatal error LNK1120: 1 unresolved externals

Si vamos a la MSDN podemos ver que lo que hace esta función es ejecutar la función que le es pasada como parametro al final del programa. Usando una estructura de pila (LIFO).
Entonces que nos detiene? Que nos imposibilita crear una función simple como esa? Nada, manos a la obra señores.

C_ATEXIT.CPP

Hermoso el código verdad? Cada vez que se llama a la función atexit() se comprueba si ya tiene valor la estructura donde vamos a guardar los punteros a las funciones. Se realloca la memoria necesaria y se le asigna al elemento actual el parametro func. Siempre devolvemos cero que indica que no hubo ningún error.

Pero este código hermoso que hace exactamente hasta ahora? Ir llenando una lista de punteros a funciones, perfecto pero nos falta algo muy importante, recordemos que atexit() crea una lista de funciones que van a ser llamadas al final del programa. El principio del programa es la función de ENTRADA (solo nos interesan main, WinMain y DllMain ya que si fuera otra no usaría la Run Time Library, ni la nuestra ni la de VC++) que sabemos como se ejecuta, la llamamos nosotros desde nuestra Run Time Library por lo tanto sabemos perfectamente cuando termina de ejecutarse; en la siguiente instrucción a la llamada a main() el programa debe ejecutar la lista de funciones de atexit() y limpiar el buffer utilizado. Estas dos cosas las hace la función destructores() que está también en C_ATEXIT.CPP.

Ahora mismo podríamos compilar el programa ESTATICOS.CPP pero no pasaría nada, la compilación y el linkeo serían satisfactorios pero nuestro programa no haría absolutamente nada.
La pregunta del millón, quien llama a la función atexit(): la propia Run Time Library la llama. Acertaron? No me mientan eh.
Y cuando y porque la llama? Porque el compilador le pasa el puntero del destructor al ejecutar el constructor, por lo tanto, al no tener implementado nuestro código para manejar los constructores estáticos no recibimos ninguna llamada a atexit() y destructores() se ejecuta sin ningún puntero al que llamar.

Que hace el compilador para decirnos que existen constructores de objetos estáticos? El compilador crea un función diferente para cada uno de los objetos estáticos (esto lo podemos comprobar viendo las direcciones que le pasa por cada objeto a atexit) y nos pasa dentro del ejecutable las 'etiquetas' (posición en el archivo) de esas funciones a ejecutarse.


data_seg
#pragma data_seg( ["section-name"[, "section-class"] ] )

Specifies the default section for data. For example:

#pragma data_seg( "MY_DATA" )

causes data allocated following the #pragma statement to be placed in a section called MY_DATA.

Data allocated using the data_seg pragma does not retain any information about its location.


Estas secciones que se definen con #pragma data_seg son escritas por el linker dentro del ejecutable y tienen punteros, a inicializadores de C, constructores de C++, pre-terminadores de C y terminadores de C que forman tablas, estas se guardan en variables que tienen el comienzo y el fin de la tabla y son pasadas a una función llamada _initterm() que se encarga de llamar a todos esos punteros ejecutando su código. Esta es la forma en la que se llama a al constructor de de un objeto estático.

Nuestro nuevo C_MAIN.CPP:

Este nuevo main define las diferentes secciones donde se encontraran las benditas tablas, llama a las tablas de inicio justo antes que a main() y a las de terminaciones justo después, además de llamar a nuestra función destructores(). Las tablas son procesadas por la función initterm() que recorre la tablae de punteros a funciones, ejecutando cada uno de ellas, hasta encontrar un puntero nulo.

Creamos nuestra libreria y ESTATICOS.EXE:

cl /c *.cpp
lib *.obj /out:clib.lib
cl /c ESTATICOS.CPP
link ESTATICOS.OBJ /NODEFAULTLIB USER32.LIB KERNEL32.LIB CLIBCLIB.LIB


Ahora si, tenemos el mismo comportamiento que con la Run Time Library de VC++ para los objetos estáticos.

Un regalito en esta parte, vamos a ver como manejar las variables de entorno:

C_MAIN.CPP

Esta nueva versión del C_MAIN.CPP incorpora la función _envinit, que cre la lista de variables de entorno y le pasa la variable _environ a la función main() de nuestro programa.

Ahora vamos a implementar getenv y putenv:

C_PUTENV.CPP

C_GETENV.CPP

Podemos probar su correcto funcionamiento con cualquier programa que use el parametro envp o simplemente cambiando variables del entorno como TMP (el path de los archivos temporales).

En la cuarta parte veremos como implementar las funciones de entrada y salida por consola.

Saludos,
Mariano.

Autor: Mariano Ventaja

http://www.c0d3rz.com.ar

Descarga: http://c0d3rz.com.ar/foro/viewtopic.php?t=104