Como automatizar el llamado de Funciones en ASM

–Esto es mas util de lo que parece a primera vista–

Esto del juego me está haciendo reconsiderar mis métodos tradicionales de programación. Cuando comencé a programar en ASM para Windows los programas de los que aprendí usaban demasiadas macros y tan solo me limité a programar el mismo código a mano para evitar usarlas, pero ahora me doy cuenta de que hay mejores métodos para hacer este tipo de programción sin meterme para nada con las macros. Una de ellas es la llamada básica de las API.

La manera de llamar a la API de Windows es introducir por el stack en orden inverso los argumentos y luego llamar a la función con un CALL indirecto del tipo CALL [proceso].  La verdad es que aunque hacer esto es la manera mas eficiente tiene muchos inconvenientes. El primero es que es un lio recordar el orden y tipo de los argumentos y que muchos de estos argumentos a su vez pueden ser llamadas a otras funciones. Algunas de ellas tienen tantos argumentos que una simple inicialización puede tomar mas de cien lineas. La idea que tengo para estandarizar este proceso es el siguiente wrapper.

Pero antes de continuar es bueno que sepan lo que es una función wrapper: Un wrapper es una función que a su vez llama a otra. La función que es llamada puede cambiar pero la que llama permanece siempre con el mismo formato. Esto permite hacer modificaciones a nivel interacción con el sistema operativo sin necesidad de cambiar el source code de la aplicación y en este caso para llamar a todas las funciones con tan solo una llamada a función con un solo parámetro, la función se vería mas o menos así:

                          push     [message_box]
                          call       win32api

Por supuesto esta enorme simplificacion no es gratis, pues lo que haría esta función es lo siguiente:

1.- Usaría el único parámetro de entrada como un índice a una table que contiene las entradas de una tabla mas grande que contiene espacios para todos los argumentos de entrada y salida y un entero que indica la cantidad de argumentos de entrada que esa función puede recibir, siendo este el primero de los números.

2.- La función usaría ese número de argumentos para encontrar la posición del último de estos valores y los introduciría al stack desde el último al primero, en caso de que la función no recibiera argumentos el valor de la estructura sería cero y se pasaría directamente al punto tres.

3.- Se llamaría a la función en cuestión, de la manera acostumbrada, aunque es buena idea mejorar la estructura para incluir la identificación de la función dentro de esta.

4.- Al retornar de la función el valor de retorno (normalmente retornado en el acumulador) va en la posición correspondiente de la estructura. Normalmente es un solo valor pero pueden darse casos en los que pueda haber mas de un valor de retorno.

5.- La función wrapper termina de la manera habitual. Regresa el control al llamador.

Por ahora solo me hacen falta resolver el como identificar cada una de las entradas de la estructura índice. Se me ocurre que bastará con definir una lista de constantes del tipo función_uno = dword 1 y pasarle este valor como único argumento a la función. Por otro lado, me quedan dudas sobre como va a hacer el programa para recuperar los datos de manera individual.

Lo interesante de este enfoque es que bien aplicado volvería las llamadas a objetos COM y COM+ tan sencillas desde el punto de vista del ensamblador como cualquer llamada a una función propia del programa. Pues algunas de estas llamadas pueden contener múltiples argumentos tanto de entrada como de salida.

Ahora la única pregunta que me hago es como tener acceso a esos datos de manera sencilla. Puede que si hago una función que reciba el identificador de función y una posición de memoria como argumentos y que descarge en esa posición los valores recibidos. Lo mismo podría hacerse para mandar de un golpe todos los argumentos de entrada de una función cuando la estructura creciera de modo que no se pudiera manejar directamente.

Saben, ahora que lo veo escrito me doy cuenta de que toda la ventaja que se logra al no tener que introducir los argumentos manualmente al stack se pierde tratando de tener acceso a ellos de maneras tan indirectas. De cualquier modo voy a dejar esta entrada por si acaso a alguien se le ocurre hacer algo util con este tipo de estructura. De momente se me ocurre que puede usarse para que un procedimiento pueda determinar una secuencia de procesos y ejecutarlos en un orden determinado de manera automática sin necesidad de hacer códigos llenos de bloques condicionales.

Creo que el que una simple llamada a una función tome casi una pantalla completa de instrucciones puede servir para identificarla mejor a distancia. Por ahora lo que se me ocurre que puede ser la mejor opción es tomar la documentación oficial del Windows y convertir las llamadas de C (o lo que sea que se oculte bajo esa horrorosa notación húngara) a ensamblador en un documento sencillo de leer. Se me ocurre hacer un PDF con el Draw de OpenOffice. De momento solo sacaré las funciones que vaya necesitando y ocasionalmente publicaré información sobre alguna de ellas. Puede que un dia junte suficientes para crear una guia completa que pueda compartir con todos ustedes.

Este asunto fue un giro de 360 grados. Volví a quedar en la misma posición pero pude ver todo lo que tenía alrededor mio y sobre todo ubicar donde estaba parado. Y hablando de ciclos, en las próximas notas voy a hablar de algo muy importante sobre como todo eso que llaman interactividad y eventos se resume a un maldito ciclo infinito con unos cuantos saltos condicionales en el centro. Y en el caso del Windows se estudiará el caso de las funciones GetMessage y PeekMessage y la enorme diferencia que hay entre ellas que es tan grande como la de un juego de mesa basado en turnos y un juego de acción arcade en tiempo real.