Desarrollo de un paquete de programación del MC68000 para un entorno Windows mediante C++ Builder.

Transcripción

1 Desarrollo de un paquete de programación del MC68000 para un entorno Windows mediante C++ Builder. Creación de un editor de código y un macroensamblador AUTOR: Eloy Vilella Guiu DIRECTOR: Enrique Cantó Navarro FECHA: Abril 2004

2 ÍNDICE GENERAL: 1 INTRODUCCIÓN OBJETO DEL PROYECTO TITULAR ANTECEDENTES POSIBLES SOLUCIONES Y SOLUCIÓN ADOPTADA MEMORIA DESCRIPTIVA INTRODUCCIÓN AL C++ BUILDER DESCRIPCIÓN GENERAL CORRECCIÓN DE BUGS DEL PROGRAMA ORIGINAL Introducción: Bugs corregidos: ESTRUCTURA EN DLL s Introducción: Definición de una DLL: Comunicación con la DLL: Creación de una aplicación con una estructura con DLL: CREACIÓN DEL INTERFACE DE USUARIO Introducción: Estructura principal: Creación del editor de texto Creación de la página ensamblador Creación de la página linkador Creación de la página proyecto Adaptación de tamaños: MACROS Introducción: Concepto general: Diseño estructural: Definicion: Calling Method: Argumentos: Labels inside: USO DEL REGISTRO DE WINDOWS Introducción:

3 Estructura: Acceso al registro: Aplicación del registro en el macroensamblador: DESCRIPCIÓN INTERNA DEL PROYECTO Esquema del proyecto: Detallado de los ficheros: Descripción de las clases: Descripción de las funciones: CONCLUSIONES PLIEGO DE CONDICIONES CONDICIONES GENERALES CONDICIONES ECONÓMICAS CONDICIONES FACULTATIVAS CONDICIONES TÉCNICAS ANEXOS CÓDIGO DEL PROGRAMA

4 1 INTRODUCCIÓN 1.1 OBJETO DEL PROYECTO El objeto del presente proyecto es el desarrollo de un paquete de programación del MC68000 de Motorola. Esto consiste en el diseño de un interface gráfico de usuario que debe integrar un editor de texto, un ensamblador y un linkador, además de tener acceso a los programas de simulación y de comunicaciones (ambos proyectos ajenos al presente). El interface, además, debe ser soportado por una plataforma Windows 9X, El programa ensamblador debe admitir el uso de macros. 1.2 TITULAR El titular del presente proyecto es: -Nombre: Escola Tècnica Superior d Enginyeria (E.T.S.E.) Universitat Rovira i Virgili -Dirección: Av. Països Catalans, 26 Campus Sescelades Tarragona Telf: ANTECEDENTES Hasta el momento en los laboratorios docentes del DEEEA se disponía de un Ensamblador y un Linkador (además de un simulador y un software de interface del PC con el módulo docente) que tan sólo eran soportados por el sistema operativo DOS. En proyectos anteriores se adaptaron los programas de simulación y de comunicaciones con éxito a la plataforma de Windows. En un último proyecto se trató de adaptar los programas ensamblador y linkador pero resultó un fracaso. Algunos de los problemas importantes que se encontraron fueron la falta de portabilidad del código, la multitud de bugs contenidos en el programa, la excesiva simplicidad del interface de usuario (operabilidad insuficiente), el caotismo y la falta de limpieza en la programación... Las funciones de entrada y salida fueron adaptadas a la plataforma de Windows, aunque el código no fue reciclado de la forma necesaria. 4

5 1.4 POSIBLES SOLUCIONES Y SOLUCIÓN ADOPTADA Inicialmente se optó por buscar programas robustos para iniciar el trabajo sobre una base sólida. Se visitaron infinidad de websites de empresas importantes del sector y otras de recursos informáticos en la red, pero resultó imposible encontrar la versión freeware de algún cross assembler comercial y/o de calidad con los códigos fuente disponibles. No hubo otra elección que basarse en el ensamblador y linkador usados en los laboratorios del DEEEA adaptados a la plataforma de Windows en proyectos anteriores. La primera tarea fue realizar las adaptaciones necesarias a la versión y compilador utilizados (C++ Builder 5): la manera de pasar los argumentos a las funciones y la omisión del uso de variables long debido a que el sistema operativo sobre el que trabajaba el programa original era de 16 bits (DOS) cuando Windows es un SO de 32 bits. El problema se resume en: DOS: int = 16bits WIN: int = 32bits long int = 32bits long int = 64bits (no lo usamos) Una segunda adaptación consistió en la eliminación de las directivas del lenguaje C obsoletas. Muchas han sido modificadas por otras directivas más potentes en el lenguaje C++. La palabra clave malloc se utilizaba en C para reservar zonas de memoria de una forma dinámica, pero que podía causar graves problemas de colisiones en caso de un uso demasiado liviano con estructuras complejas. Toda estructura reservada en memoria con la palabra malloc debe ser eliminada mediante el uso de la directiva free y la inicialización del puntero utilizado. El C++ ha introducido las nuevas directivas new y delete que tienen una funcionalidad similar a las anteriormente mencionadas pero con una robustez y una potencia muy superior. Se ha tenido que sustituir las palabras malloc y free, además de adaptar el código relacionado, en los trozos de código donde se usan listas complejas o árboles binarios. Se pudo reciclar poco del proyecto anteriormente mencionado. El interface de usuario original fue desechado por su excesiva simplicidad y su falta de operabilidad, además hubo que trabajar la portabilidad de las funciones principales de los programas ensamblador y linkador. El proceso seguido para optimizar el paquete de programación fue el siguiente: 1. Realizar adaptaciones necesarias a la versión y compilador utilizados (C++ Builder 5): sintaxis de las cabeceras de las funciones y omisión del uso de variables long. 2. Eliminar interface original. 5

6 3. Eliminar los ficheros inútiles para la aplicación y limpiar el directorio de archivos de la antigua versión. 4. Tratar la portabilidad de las funciones principales del ensamblador y el linkador. 5. Estructurar, ordenar y limpiar el código original. 6. Tratar de entender el complejo funcionamiento del ensamblador y linkador. 7. Crear un interface temporal. 8. Corregir una infinidad de bugs del programa. 9. Diseñar el programa en una estructura con DLL (subdivisión de los ficheros en carpetas). 10. Crear el interface definitivo. 11. Diseñar el editor de código. 12. Ampliar el programa a macroensamblador. 13. Adaptar aplicación al uso del Registro de Windows. 14. Creación de la herramienta de procesado de proyectos. 15. Redacción de la memoria definitiva del proyecto. El programa se ha diseñado, como se ha mencionado en la lista anterior, en una estructura con DLL. El esqueleto de la aplicación es el siguiente: Interface (Editor+Plataforma) Simulador (exe) Comunicaciones (exe) Ensamblador (dll) Linkador (dll) 6

7 Figura 1 Esqueleto de la aplicación El paquete de programación debe ser capaz de procesar un fichero fuente de la forma siguiente: Figura 2 Proceso general Se podría haber realizado el proyecto con cualquier tipo de los diversos lenguajes visuales para Windows existentes en el mercado, como por ejemplo el Visual C, Visual Basic... pero finalmente se ha optado por el C++ Builder de Borland por diversas razones, entre las que podemos destacar su gran potencia heredada del C, la posibilidad de programar en modo orientado a objetos (POO) como en C++ y, la última y más importante, debido a que facilita y ahorra mucho tiempo a la hora de programar, ya incluye clases creadas con lo cual se agiliza en gran medida la generación de código nuevo y complejo. En resumen, mediante C++ Builder se consigue una programación orientada a componentes (POC). Un componente es similar a una clase, pero además consta de propiedades y eventos. Cada componente nuevo de una clase existente en las librerías del compilador, genera una serie de expansiones de código que integran en el documento un componente plantilla. Con este proceso de standarización ahorra tiempo y esfuerzos para programar dichos objetos, lo cual suele ser bastante engorroso y complejo en lenguajes como C++. 7

8 2 MEMORIA DESCRIPTIVA 2.1 INTRODUCCIÓN AL C++ BUILDER A continuación se hace una breve introducción al lenguaje seleccionado finalmente para realizar el proyecto. El C++ es una extensión o ampliación del lenguaje C y a diferencia de éste último, permite programar en modo orientado a objetos. Anteriormente, la gran mayoría de las aplicaciones desarrolladas para Windows eran realizadas en lenguaje C, del mismo modo que las librerías de las funciones de las API. Sin embargo estas aplicaciones fueron construidas pensando en objetos, de forma que lo más conveniente era usar un interface basado en objetos, que realizara las llamadas a las API de Windows. Con la finalidad de facilitar la programación orientada a objetos se crearon las frameworks. Las framework son librerías que encapsulan las técnicas de programación más empleadas. Una aplicación basada en framework en comparación con otra que se basa directamente en llamadas a las API contiene menos código, con lo cual es más óptima desde un punto de vista temporal y es mucho más fácil de crear. Además el uso de MFC permite el uso de funciones de los lenguajes C o C++ y el uso directo de API. Los frameworks para Windows que más se han extendido en la actualidad son el MFC (Microsoft), OWL (Borland) y VCL (Borland). Las librerías VCL (Visual Component Library) son las que se han utilizado en este proyecto. Fueron desarrolladas originalmente para el compilador de Pascal de Borland, el Delphi. El nuevo compilador Borland C++ Builder incluye las VCL (además de poder compilar programas basados en OWL, MFC y Delphi). Este framework es el más avanzado ya que permite una auténtica programación visual C++ basada en componentes y formularios que pueden funcionar sin ficheros.dll adicionales. Además, permite la creación de aplicaciones de mediana complejidad para Windows en un tiempo relativamente corto. A continuación se explicarán algunos de los nuevos conceptos (y otros no tan nuevos) introducidos con la programación orientada a objetos. Se tratarán conceptos como clases, constructores y destructores entre otros. Éste es un tema bastante complejo pero se tratará de resumir y simplificar los conceptos (consúltese libro de programación C++ para más información): a) Class ( clase): Se trata de una de las extensiones más importantes que se han introducido con la programación orientada a objetos (POO). Es una wordkey con efectos muy similares a la palabra struct, pero con las siguientes diferencias: 8

9 o En una estructura, los campos de datos y las funciones son públicos de modo predeterminado, lo que significa que se podrá acceder a los campos de datos sin restricciones. o En una clase, son privados de modo predeterminado, lo que significa que sólo se pude acceder a los distintos campos por medio de ciertas funciones. En definitiva, struct no asegura la protección de los campos. Pero la búsqueda de esta protección es una de las bases de la programación orientada a objetos. class CLS1 private: int x; float y; void g(); public: void f(); Código 1 En el código anterior, los campos y funciones contenidos en la sección private no son accesibles directamente por el usuario de la clase. La función pública f puede ser llamada desde cualquier función del programa. Ésta es la única función que tiene acceso a la función privada g. Y sólo las funciones f y g pueden manipular los campos privados x e y. b) Constructor: Un constructor permite que se ejecute automáticamente una función de inicialización, llamada constructor, en la creación de un objeto perteneciente a una clase. El constructor también es llamado en la creación de un objeto con new. c) Destructor: Una función destructor permite liberar zonas de memoria que se han asignado dinámicamente (a menudo en el constructor) o bien cerrar un archivo abierto en el constructor. El destructor se llama también en la destrucción de un objeto con delete. d) Puntero this: En una función miembro, this (palabra reservada del C++) designa un puntero al objeto que se está tratando. This contiene la dirección de dicho objeto. 9

10 e) La herencia: La técnica de la herencia constituye sin duda la aportación más interesante de la POO. Permite crear una clase a partir de otra, heredando propiedades de esta última. Class A protected: int x; void f(); public: void g(); private: void h(); class B::public A private: int y; public: void j(); Código 2 Se ha creado en primer lugar una clase A que sirve de base para crear otras clases (clase de base). La clase B se construye a partir de A (clase derivada). En este caso, los campos y funciones x, f, g y h de la clase A pasan a ser campos de la clase B. o Los campos protected pueden ser accedidos desde B y sus derivadas. o Los campos public pueden ser accedidos desde todo el programa. o Los campos private no pueden ser accedidos. En caso de que la clase B se defina private de A, las palabras clave pasan a significar lo mismo pero anulando el acceso de las clases derivadas de B en todos los casos. 10

11 2.2 DESCRIPCIÓN GENERAL CORRECCIÓN DE BUGS DEL PROGRAMA ORIGINAL Introducción: Los programas ensamblador y linkador originales contenían múltiples errores de programación. Tras solucionar los problemas de portabilidad del código y adaptar el programa original al lenguaje y versión utilizados, se hizo un trabajo importante para comprender el código y entender el método de trabajo de los programas. Cabe resaltar que un ensamblador y un linkador son programas muy complejos. En apartados anteriores se han añadido esquemas que han sido elaborados para simplificar este trabajo de comprensión. En el apartado siguiente se procede a explicar algunos de los bugs corregidos del programa original. Muchos han sido omitidos por su parecido o poco interés para el proyecto, y otros no han sido descubiertos todavía. Para su corrección se ha tenido que realizar un trabajo de localización (mucho código y muy complejo), entendimiento perfecto del código, comprensión del lenguaje ensamblador y posterior corrección del error. El bug aparentemente más simple puede ocasionar serios problemas en su corrección Bugs corregidos: (DDD: destino, FFF:fuente) a) MOVEQ #0,D1 El nemónico moveq mueve un byte en modo direccionamiento inmediato a un registro de datos de 32 bits. El valor de 8 bits es extendido en signo en el registro de datos una vez transferido. Ensamblado general: 0111 DDD0 BBBB BBBB B:dato Ensamblado de la línea (anterior): = 0x7280 Ensamblado de la línea (correcto): = 0x7200 El problema estaba en que ensamblaba el dato #0 como 80 (cero negativo) 11

12 b) CMPM.B (A0)+,(A1)+ El nemónico cmpm resta el operando origen del operando destino y actualiza los flags según el resultado. Los operandos se introducen siempre en modo de direccionamiento con postincremento. Ensamblado general: 1011 DDD1 AA00 1FFF A:size Ensamblado de la línea (anterior): = 0xB388 Ensamblado de la línea (correcto): = 0xB308 El problema estaba en que ensamblaba el size=10 (tamaño long), es decir, ensambla cmpm.l (a0)+,(a1)+ La función que codifica la size (mete los 1 s y 0 s) es: cmpm ( ) if (size==2) valor+=64; //tratamiento.w else if (size==1) valor+=128; //tratamiento.l if (aa!=6 bb!=6) RETURN (DIR_INCORR); return sp(valor+opp1.op<<9)+8+op1.op); La codificación interna del ensamblador es:.b >>> size=1.w >>> size=2.l >>> size=4.s >>> size=8 nada >>> size=32 El error se encuentra en el else if (linea 2), debe entrar si size==4 (LONG) c) DIVS.W D0,D2 y DIVS.L D0,D2 El nemónico divs divide el operando con signo destino por el operando con signo origen y almacena el resultado en el destino. La operación tiene 4 modos de trabajo según la sintaxis usada. Ensamblado general: 1000 DDD1 11MM MFFF M:modo direccionamiento de fuente Ensamblado de la línea (anterior): = 0x85C0 Ensamblado de la línea (correcto): = 0x85C0 12

13 El error que nos muestra el ensamblador es Error de tamaño incorrecto. En realidad en la familia 68K no existe la opción.w/l en la operación DIVS. Se trata de un error de concepto del programador del código original. d) CMPA.L A0,A1 y CMPA.W A0,A1 El nemónico cmpa resta el operando fuente del registro de direcciones destino y actualiza los flags según el resultado. Ensamblado general: 1011 DDDM MMFF FFFF M:modo direccionamiento de fuente El problema está en que la familia 68K no distingue entre W/L Solución: dependiendo de la variable size, codificará el modo de una forma u otra. e) JMP L1 El ensamblador trataba este nemónico haciendo un salto relativo respecto al Program Counter (PC): 4EFA XXXX Existían problemas cuando la instrucción anterior era del tipo DC y ocupaba un número de bytes impares Solución: existe un bug posterior en el que luego resolveremos los problemas de la directiva DC y la paridad del PC. Sin haberlo resuelto todavía, usaremos uno de los recursos de la instrucción JMP. Podemos codificarla para que haga el salto a una dirección absoluta (en lugar de relativa al PC): 4EF9 XXXX XXXX 13

14 f) DC.B... El nemónico DC es una directiva del ensamblador usada para mapear datos en memoria. Ensamblado general: XXXX XXXX XXXX XXXX X:carácter de la cadena Este nemónico tenía dos bugs diferentes: a) Cuando el número de caracteres de la cadena es impar, entonces el ensamblador reserva un número impar de bytes (siguiente instrucción en zona impar). El ensamblador entonces llenaba los huecos libres con espacios y añadía otra línea en el fichero de listado con el formato: xxxxxx : 00 :. La solución adoptada es la de incrementar el Program Counter para que la siguiente instrucción se encuentre en posición par. b) En las mismas condiciones del punto anterior, el ensamblador asigna a las 2 siguientes instrucciones al DC la misma posición de memoria. El problema viene por la línea añadida para tener un número de bytes par. La solución adoptada esta vez se basa en concatenar (cuando el número de caracteres es impar) la línea ensamblada con 00 y rellenarla entonces los huecos libres con espacios. De esta manera, no hay necesidad de añadir una línea auxiliar al fichero listado. g) Direccionamientos (d16,an) y (d8,an,xn) MOVE.B normalmente ensambla: 00SS DDDd ddff ffff S: size (.B=01,.W=11,.L=10) D: reg d: modo direccionamiento F: reg f: modo direccionamiento Según el direccionamiento, a veces se añade una palabra más (2 bytes = 4 hexa): a) (d16,an) XXXX XXXX XXXX XXXX (desplazamiento) b) (d8,an,xn) ARRR S000 XXXX XXXX A:!A/D (An) R: reg (Xn) S: size 14

15 h) MOVE.B 3(A0),D1 (-3 se codifica en hexadecimal con FFFD) Ensamblado de la línea (anterior): = 0x = 0xFFFF = 0xFFFD >>> 1228 FFFF FFFD Ensamblado de la línea (correcto): = 0x = 0xFFFD >>> 1228 FFFD Problema: Solución: Cuando el desplazamiento es negativo, el programa extiende el signo a 32 bits (4 bytes). Por ello nos ensambla las dos palabras: la primera con el valor de 16 bits y la segunda con el signo extendido. Cuando el desplazamiento sea negativo, recortamos una palabra del valor del desplazamiento ensamblado antes de concatenarlo con la instrucción move ensamblada. Para corregirlo, accederemos a la función de la directiva DC y buscaremos el caso de direccionamiento aa=10 (línea 520 de Func.cpp) 15

16 i) MOVE.B 3(A0,D3),D1 (-3 se codifica hexadecimal con FD) Ensamblado de la línea (anterior): = 0x = 0xFFFF = 0x3FFD >>> 1230 FFFF 3FFD Ensamblado de la línea (correcto): = 0x = 0x30FD >>> FD Problema 1: Solución: Problema 2: Solución: Mismo que en el caso anterior Se accede a la función de la directiva DC y se busca el caso de direccionamiento aa=2 (línea 533 de Func.cpp) Si nos fijamos en el formato de la palabra añadida con este tipo de direccionamiento, vemos que los 2 primeros bytes no deben extender el signo tampoco, ya que se usan para otros fines. En un principio, simplemente preparaba la palabra (para escribirla en el fichero listado) concatenando los carácteres 00 con los 2 bytes útiles del desplazamiento (FFFF FFXX). Pero surgió un problema: simplemente superponía los carácteres 00 a la información necesaria. La solución que se adoptó finalmente fue restarle al desplazamiento FFXX el valor equivalente a FF00 j) GLOBAL etiqueta Supongamos un código con la estructura siguiente: global... valor JMP valor... valor... 16

17 El programa contenía un error en la función int valor(char *) del fichero parser.cpp que erraba en el tratamiento de la etiqueta de tipo global. El código de dicha función queda de la forma siguiente tras ser modificado: static int valor (char *puntero) struct arbol *r; r=buscar_rama(raiz,puntero); if (r!= NULL) reub=reub2; switch (r->tipodevariable) case 0 : reub2=0; break; case 1 : reub2=1; break; case 2 : reub2=0; segpasadaparser=1; break; case 3 : if(segunda_pasada==2) longjmp(ebuf,16); break; case 4 : reub2=0; break; case 5 : reub2=1; break; return r->valor; if (segunda_pasada==2) longjmp(ebuf,16); reub2=0; if (codigoreub) reub2=1; return 0; Código 3 17

18 j) Árboles binarios: En el apartado referente a las macros se explica el procedimiento que sigue el programa cuando encuentra una etiqueta de definición de macro del tipo macro. Se informa de que el programa crea una estructura del tipo árbol binario llamada arbolm para almacenar los objetos macro y rellenar los campos necesarios.... Figura 3 Árboles binarios Otro caso de utilización de una estructura compleja como la anterior es en la definición de etiquetas en el código fuente. Cuando el ensamblador encuentra la palabra clave ETI u otro sistema de definición de una etiqueta en el fichero asm, el programa crea un objeto del tipo arbol que corresponde al componente de un árbol binario. La definición del objeto arbol y el objeto arbolm es : struct arbol struct arbol *arbol_der; struct arbol *arbol_izq; char label[16]; int valor; int tipodevariable; ; struct arbolm struct arbolm *arbol_der; struct arbolm *arbol_izq; char label[16]; AnsiString text; int llamadas; int argumentos; ; Código 5 Código 4 Para el manejo de una estructura del tipo árbol binario compuesta por objetos de la clase arbol se utilizan punteros a objetos de dicha clase. Mediante una serie de funciones recursivos (funciones que son llamadas desde el interior de su propio código) el puntero recorre el árbol con un sistema inteligente para localizar el objeto buscado. La declaración de estas funciones pueden ser localizadas en el fichero ens.h: struct arbol *buscar_rama (...); struct arbol *insarbol(...); void listar_arbol (...); void eliminar_rama(...); void eliminar_arbol (...); Código 6 18

19 Las funciones siguientes son referentes a la estructura de árbol binario utilizada en el caso de la definición de macros. La declaración se puede encontrar en el fichero macros.h: struct arbolm *buscar_rama (...); struct arbolm *insarbol(...); void listar_arbol (...); void eliminar_rama(...); void eliminar_arbol (...); Código 7 Todas las funciones referentes a los objetos tipo arbol (excepto eliminar_arbol) fueron desarrolladas por el programador del ensamblador original. Sin embargo, el programa original procedía de forma incorrecta: fin: //cerrar ficheros fclose(ff); fclose(fs); remove("..\\usuario\\xxx.xxx"); fclose(fd); if (flistado!=null) flwrite(); fclose(fl); //Falta recorrer los arboles de macros y etiquetas y borrarlos punteros if (errores) remove(fdestino); throw "ENS1"; throw "ENS0"; Código 8 El código anterior son las últimas instrucciones ejecutadas para cualquier fichero fuente en la DLL ensamblador. Una vez compilado el código fuente, se procede a cerrar los ficheros utilizados y se lanza una excepción. Podemos comprobar que no se libera la memoria reservada para los objetos de los árboles binarios ni se inicializan las variables globales puntero creadas en la cabecera del fichero ens68k.cpp. Las carencias anteriores nos provocan errores de ejecución del programa ensamblador en compilaciones posteriores y nos puede provocar problemas de memoria. 19

20 La solución adoptada fue desarrollar las funciones eliminar_arbol(arbol *) y eliminar_arbol(arbolm *). Estas funciones son algorismos recursivos que recorren el árbol hasta sus extremos y eliminan los componentes desde las ramas hasta la raiz de la estructura. El código en ambos casos sigue el siguiente esquema: void eliminar_arbol (struct arbol *a) if (!a) return; eliminar_arbol (a->arbol_izq); eliminar_arbol (a->arbol_der); delete(a); a=null; Código 9 Las cinco funciones referentes a los objetos tipo arbolm han sido recicladas y modificadas de sus respectivas referentes a arbol. El código puede ser consultado en el anexo de Código del Programa en el fichero arboles.cpp. 20

21 2.2.2 ESTRUCTURA EN DLL s Introducción: El principal objetivo del proyecto ha sido crear una plataforma de trabajo donde se integren el editor, el ensamblador y el linkador. Una consecuencia directa ha sido la aparición de problemas en el orden y en la legibilidad del código. Puede resultar caótico tener varios programas complejos en una misma aplicación. La solución adoptada para resolver los problemas ha sido la estructuración de la plataforma en un diseño de programa principal y DLL s. Figura 4 Estructura en DLL Definición de una DLL: DLL es una acrónimo de Dynamic Link Library (o librería de acceso dinámico). Se trata de un archivo que contiene funciones que se pueden llamar desde aplicaciones u otras DLL en tiempo de ejecución. Los desarrolladores utilizan las DLL para poder reciclar el código y aislar las diferentes tareas. Las DLL no pueden ejecutarse directamente, es necesario llamarlas desde un código externo. Ventajas principales de las DLL: Las DLL nos ahorran espacio en disco. Si tenemos 501 aplicaciones y utlidades que utilizan la xxx.dll, montando ésta estáticamente en cada aplicación se incrementa el espacio utilizado en 500 veces el tamaño de la xxx.dll Las DLL ahorran memoria al utilizar un técnica de memoria compartida llamada "mapeo de memoria". Windows carga las DLL en la zona común global de memoria y mapea el rango de direcciones de la DLL en el espacio de direcciones de cada aplicación que hace la carga de dicha DLL. Por tanto, 21

22 procesos diferentes que utilizan por ejemplo la xxx.dll, pueden compartir la misma instancia de la DLL en memoria sin necesidad de cargar copias de ella La localización de errores (bugs) es más sencilla debido a que un bug está típicamente localizado en una única DLL. Por tanto no necesitamos redistribuir toda nuestra aplicación, sino únicamente la DLL errónea para solucionar un problema Diferentes usos de las DLL: Enlace estático significa que se accede con una librería que contiene todos los OBJs necesarios. No es una DLL, sino una librería estática. La extensión suele ser.lib Enlace estático con una DLL significa que se accede con una librería import que contiene referencias a la DLL (nuestro caso) Cargar dinámicamente la DLL significa que debemos utilizar la función del API de Windows LoadLibrary Comunicación con la DLL: Como se ha definido anteriormente, las DLL representan paquetes ejecutables (EXE s complejos), así que no se pueden pasar argumentos tan fácilmente como en el caso de las funciones. La comunicación más importante entre el interface y las DLL son el paso de argumentos en las llamadas a las funciones principales de las DLL y los mensajes que devuelven las DLL mientras analizan el código y que deben ser mostrados al usuario mediante el interface. La parte de las llamadas se resolvió mediante la declaración de las funciones Ens68K(...) y Lnk68K(...) como IMPORT/EXPORT en el fichero.h de las DLL. No se puede interactuar con los objetos del formulario principal directamente desde un archivo de la DLL (informa de un linker error). Simplemente, debo tratar los datos puestos en el formulario antes de ejecutar la DLL correspondiente, pasando los datos necesarios a la DLL como argumentos: a) DLL ensamblador: se pasan el nombre de los archivos asm, obj y lst y la ruta de usuario b) DLL linkador: se pasa el nombre de cada archivo obj, si éste es absoluto o reubicable, el origen/fin (caso absoluto), y el nombre de los s28 y map y la ruta de usuario La parte de los mensajes es algo más compleja. Los mensajes no se pueden enviar en tiempo real, ya que se debería cortar la ejecución de la DLL cada vez, cosa dificil y poco práctica. La solución adoptada al problema ha sido crear una variable del tipo 22

23 AnsiString (este tipo se encarga de reservar zonas de memoria según el tamaño de la variable en tiempo de ejecución, además de proporcionar otra información como el tamaño...). Durante la ejecución de la DLL, cuando se debía enviar el mensaje pertinente, ahora se acumula en esta variable. Cuando se acaba la ejecución total de la DLL (ensamblado o linkado), entonces se llama desde el interface a una función creada previamente que imprime el contenido de la variable en el lugar adecuado. Pueden existir varias variables simultáneamente debido a que existen mensajes de salida y de errores Creación de una aplicación con una estructura con DLL: a) Creación de un proyecto normal (intefens.bpr) en la carpeta interface desde el que se llamará a las funciones principales de las DLL. El proyecto estará formado por interfens.bpr+cpp (proyecto) y Principal.cpp+dfm+h (ventana principal). En el archivo de llamada a las DLL s (Principal.cpp) se incluyen (#include) los archivos.h de las DLL (ensdll.h y lnkdll.h) Se deben adherir al proyecto interfens los archivos de librerías de las DLL (ensdll.lib y lnkdll.lib) b) Creación de otro proyecto con Dll Wizard (opción de creación) llamado ensdll.brp en la carpeta ensamblador (contiene todos los archivos importantes del ensamblador). Este proyecto contiene básicamente ensdll.brp+cpp+h (proyecto) y demás archivos importantes para ensamblador (*.cpp y *.h) contenidos en la carpeta c) Creación de la DLL del linkador de la misma forma que la anterior d) Edición especial de los archivos.h de la DLL (ejemplo ensamblador): #ifndef ensdllh #define ensdllh #ifdef DLL #define EXPORT_IMPORT declspec(dllexport) #define interfens "dllexport" #else #define EXPORT_IMPORT declspec(dllimport) #define interfens "dllimport" #endif EXPORT_IMPORT declaración de función/es principal/es de Dll (accesible desde el exterior) #endif Código 10 23