Hola. La pregunta es simple: ¿Cómo puedo unir un programa hecho en visual basic con sus librerías, de forma que quede un solo ejecutable?
Un saludo.
P.D.:No busco un autoextraíble con winrar...
Versión para imprimir
Hola. La pregunta es simple: ¿Cómo puedo unir un programa hecho en visual basic con sus librerías, de forma que quede un solo ejecutable?
Un saludo.
P.D.:No busco un autoextraíble con winrar...
Pues compilando estáticamente. Vamos, con Visual Basic no sé si se puede hacer (¿pueden ir los assemblies dentro del ejecutable?), pero con lenguajes como C sí.
Solo una cosa,pasate a C ya.
Buenas, pues lo que pides no es trivial... tampoco sé si existe una aplicación o un programita que te haga esa unión que pides. Probablemente si, si no, mira tú por donde acabas de dar con un magnífico proyecto.
Las DLL contienen código ensamblado, como bien dice Fruit, (desde el punto de vista de un programador, una dll es un paquete de funciones, procedimientos y estructuras de datos que están ahí para usarse en una aplicación, y da igual en qué lenguaje haya sido realizada), de forma que ese código, o más habitualmente, parte de ese código (el programador rara vez usa el 100% del código de una DLL, salvo excepciones), suele cargarse en memoria cuando el proceso lo solicita.
Da igual que tu aplicación la estés haciendo en VB, C, Delphi, JBuilder o lo que te dé la gana... al fin y al cabo vas a compilar para Windows y generar un .exe, por lo que una DLL a nivel de código ensamblado siempre será compatible.
El mecanismo es muy simple... El proceso (.exe en ejcución), cuando quiere algo de una librería, hace que el SO llame explícita o implícitamente (el programador pudo haber hecho la tarea manualmente) a la función LoadLibrary(...) de la API WIN32, para cargar la DLL en memoria. Tras ese momento, nuevamente implícita o explícitamente se llama a otras dos funciones de la API, GetModuleHandle(...) y GetProcAddress(...) que obtienen la dirección de memoria de la función o procedimiento exportado de la DLL que quiere utilizar, y a partir de ahora, el proceso puede hacer uso del código de la DLL como si se tratase de código "suyo", aunque realmente lo que se hace es poner el registro EIP apuntando a la dirección obtenida de la reubicación asignada por el SO en el momento del enlazado (Dirección obtenida por la función GetProcAddress(...)).
Para este cometido, hay varias opciones:
Para ambas opciones debes saber bien como funcionan los .exe. A diferencia de un .com que simplemente es una copia de la imagen en memoria de un proceso, es que básicamente el .exe posee una estructura especial, basada en tres partes: cabecera, Tabla de secciones y secciones.Cita:
1º Inyectar el código de la DLL en una sección de tu .exe con espacio suficiente.
2º Enlazar el código nuevamente, si lo que quieres importar a tu .exe es gran cantidad de código. Esta opción es como yo lo haría.
La cabecera contiene a su vez 3 partes: cabecera DOS MZ, sección DOS y Cabecera PE. Para tu cometido (suponiendo que eliges la 1ª opción), tendrás que centrarte en esta 3ª parte (Cabecera PE), pues es la que te va a permitir jugar con las secciones de tu .exe. En dichas secciones será dónde "inyectes" el código de la DLL que necesitas. Has de saber que para hacer esto, debes tener espacio suficiente en alguna sección para que te "quepa" el código que vas a insertar, de lo contrario no funcionará y te cargarás el .exe entero :).
En este mecanismo se basan los famosos "packers" o "ciphers" para evitar la ingeniería inversa, o simplemente comprimir un ejecutable. Por lo que también te ayudará a tu cometido saber cómo funcionan estos programas.
La segunda opción, que es la que yo haría, se trata de hacer un linker, (lo que llevan los compiladores "hablando malamente", que utilizan los programadores de código compilado), con todas las de la ley.
Mi idea sería la siguiente:
Una vez escrito en disco, tendrás un .exe nuevo, con el código importado.Cita:
1º Cargar el .exe en memoria (ejecutarlo haciendo doble click).
2º Cargar la DLL en memoria mediante LoadLibrary().
3º Obtener una lista de direcciones de memoria (ya reubicada) de los métodos exportados por la DLL. Tarea que puedes hacer examinando la DLL en memoria y con ayuda de la función GetProcAddress().
4º De esa lista tu puedes seleccionar el 100% o sólo lo que te interese, eso ya es decision tuya, (sería buena opción dar a elegir al usuario lo que desea importar a su .exe).
5º Puesto que todo está en memoria, sólo te queda volcar la información a disco (Tarea que puedes hacer con las funciones ReadProcessMemory(...) y VirtualProcessEx(...) para la lectura de memoria, y las correspondientes para ficheros: CreateFile(...), WriteFile(...), etc...).
6º Deberás ir controlando lo que vuelcas y escribes, para saber luego cómo crear tu cabecera PE. Esta parte es quizás la mas complicada, y para ello deberás hacer uso de las correspondientes estructuras de datos: IMAGE_NT_HEADERS, IMAGE_FILE_HEADER, etc...
En fin, si te embarcas en ese proyecto, ya tienes algunas ideas con las que partir y horas que echar ;).
Un saludo.
Muchas gracias, hystd, y aprecio el tiempo que le has hechado a este "consejo". Voy a investigar lo del volcado de las dll y a ver si me resulta el proyecto. Pero lo mas facil en un programa es llevar los dll con el exe no? Me refiero aparte, en la carpeta. Y no existe la opción de que el exe tenga un sector que descomprima el dll en una carpeta temporal? Que en cuanto se cierre el programa, se borre el dll, pero que el exe contenga en sí el dll, o algo así xD
Gracias, y saludos. (Fruit, a tí tambien..)
ah, chewarrior, admiro y apoyo tu respuesta, es verdad, pero como la gente sigue usando windows y veo que como tienen taaaaaaaaaaaa(a*10^9)nto dinero, y puede invertirlo para no hundirse y comprar todas las empresas que se le pongan delante....(p.d.:apple puede que compre a Sony... :(...)
Echa un ojo al programa 'iexpress', viene con todos los Windows desde el XP. Quizás se acerque a lo que necesitas.
La idea de tener una DLL independiente del .exe no se debe a que sea más fácil o menos difícil... se basa simplemente en conceptos relacionados con el desarrollo y la ingeniería del software. Un buen programador, una vez tiene su código ya funcional, lo que hace es refactorizar y modularizar ese código. De esta forma garantiza: facilidad de mantenimiento, reutilización, legibilidad y tamaño del programa. Esta tarea es extremadamente necesaria cuando empieza a haber sobre todo líneas de código o fragmentos de código que se repiten. En tal caso, lo correcto es crear un procedimiento o una función, de forma que cada vez que sea necesario hacer uso de ese fragmento, sólo habrá que hacer la llamada a la función.Cita:
Pero lo mas facil en un programa es llevar los dll con el exe no? Me refiero aparte, en la carpeta.
Si además exportas esa función o procedimiento a una DLL, mirando en que en el futuro ese fragmento de código puede servirte para otras aplicaciones que desarrolles, tal vez ahorres tiempo en todos los aspectos, no teniendo que codificar ese fragmento nuevamente.
De hecho esto es uno de los pilares básicos de la POO, sólo que en vez de hablar de librerías, hablamos de clases y objetos (siendo muy generalistas xD). Una DLL lo que saca en ventaja a una clase es que el tamaño final del código de un ejecutable se reduce bastante, y como desventaja es que al ser código compilado, en principio nadie puede modificar su contenido (y nótese que digo en principio, pues si aplicas ingeniería inversa, puedes hacerlo, pero claro, ya sería algo ilegal para el caso de Windows... la ingenieria inversa normalmente está prohibida en casi cualquier ámbito, por ejemplo la F1).
Se llaman secciones, no sectores :).Cita:
Y no existe la opción de que el exe tenga un sector que descomprima el dll en una carpeta temporal? Que en cuanto se cierre el programa, se borre el dll, pero que el exe contenga en sí el dll, o algo así xD
Con respecto a lo que comentas, si tienes código importado en tu .exe, ya no será importado, sino que será código que está en una sección que has creado dentro del ejecutable y por tanto ya pertenece a él, (por lo menos, si lo haces como te he comentado), y en tal caso, ya no cabe decir "extraer una dll de un ejecutable", sino decir "extraer código de una sección y ubcarlo en una dll". Por tanto, si quieres ahora extraer ese código y meterlo en una DLL, pues ahora haces el proceso inverso, sólo que ahora debes adaptarte a la estructura de una DLL en vez de a la estructura de un .EXE. Pero sinceramente, no le veo sentido :), pero bueno, como poder, claro que se puede. En tal caso, cuando crees tu nuevo ejecutable con el código importado de la DLL en una sección, debes añadir otra que se encargue de hacer esta tarea de "extracción" de forma que el EntryPoint salte a esta sección nada mas iniciar.
Un saludo.
Saludos y espero no sea demasiado tarde mi intenvencion.
Hace tiempo utilizaba el siguiente metodo.
A mi proyecto le agregaba un modulo el cual contenia:
Asi que solo le indicaba la ruta donde se crearia el archivo, esa funcion la generaba un programa previamente realizado para no tener que capturar nada yo, solo agregar el modulo al proyecto y generar el archivo automaticamente.Código:Public Function Archivo_Saludo(Ruta As String)
Open Ruta + "Saludo.Txt" For Append As #1
Print #1, "486F6C61206D756E646F"
Close #1
End Function
Contras: de windows vista hacia arriba podria fallar si instalas o creas archivos en directorios restringidos :S
pd. el Print no te sirve para crear archivos DLL exe, etc porque genera un salto de linea al final de cada instruccion
Gracias por el aporte proteo1