Otra de librerias dll.

[Instru]

Todavia ando por aqui... Y ya veo que regresaron los grandes genios de programacion....jajajaja.

Tengo una duda parecida a la de blackwind.

Estuve leyendo un libro donde uno de los temas era crear dlls, pero como plugins. Lo que entendi es que creabas un archivo lib que era como generico. Y despues dependiendo de lo que tu le indiques al programa ya compilado, elegir una dll. Es decir varias dlls para un lib.
Esto se hacia usando clases y bueno haciendo la analogia de objetos como se hace en C++.

El problema es que pusieron un ejemplo muy especifico, uno para crear una engine. Pero si yo quiero que sea para otra cosa. Copmo se haria?

Tengo entendido, que hay que crear una clase que cargue la dll y luego busque una funcion que nos devuelva una puntero al objeto dentro de la dll, pero como se hace esto? y que mas hay que hacer? Aparte, no se si este en lo correcto con lo que digo, ya que eso fue lo que yo entendi, igual y esta mal interpretado.

Saludos

[MaxExtreme]

Es mucho más fácil de lo que parece, Instru. Creas un "estándar" para tu aplicación. Por ejemplo, una DLL deberá llevar las funciones Iniciar(), Destruir(), CrearGUI(HWND * hwnd), DatosRecibidos(void * p)... que serán llamadas por el programa principal cuando sea necesario. A su vez, la DLL deberá llamar al programa cuando haya hecho determinadas tareas.

Sobre lo de mezclar libs y dlls no veo la necesidad, siempre lo he hecho con DLLs.

[Instru]

Ok si, de hecho esas funciones que me pusiste como ejemplo son las mismas que las del ejemplo que lei.
Ahora. No entendi muy bien tu idea. Pero lo que quiero hacer es que el programa ya compilado pueda cambiar la dll. Como un sistema de plug ins. Que si yo decido usar una usar esa y sino la otra. Esta opcion esta en el programa.

Ahora la gran pregunta, como se hace?

Saludos

[Eternal Idol]

Se hace justamente sin usar el .LIB que implica enlazado estatico y usando las funciones de enlazado dinamico (LoadLibrary y GetProcAddress, miralas en la MSDN).

[Instru]

Y por ejemplo, si quiero hacer una nueva dll, pero sin tener que volver a compilar mi aplicacion, es decir, que luego luego me reconosca que hay otra dll compatible... Muy parecido al sistema de plugins de winamp.

Saludos

[MaxExtreme]

Iniciado por Instru

Y por ejemplo, si quiero hacer una nueva dll, pero sin tener que volver a compilar mi aplicacion, es decir, que luego luego me reconosca que hay otra dll compatible... Muy parecido al sistema de plugins de winamp.

Saludos

No... Ya te hemos explicado que las DLLs se cargan en ejecución. Al compilar no tienes que saber nada.

[Eternal Idol]

Iniciado por Instru

Y por ejemplo, si quiero hacer una nueva dll, pero sin tener que volver a compilar mi aplicacion, es decir, que luego luego me reconosca que hay otra dll compatible... Muy parecido al sistema de plugins de winamp.

Saludos

Creo recordar que, al menos en versiones antiguas, la "busqueda" de plugins del Winamp estaba basada simplemente en un directorio homonimo. Podrias hacer eso que es bastante simple, tener un directorio donde tengan que estar los plugins y hacer un FindFirstFile/FindNextFile para encontrarlos. Eso no implica ningun tipo de recompilacion y como bien dice MaxExtreme no tenes que saber nada en tiempo de compilacion.

[Instru]

Bueno, pero por ejemplo, si en el directorio pones un txt? Hay que hacer un filtro de de nombres de archivos, no? Pero... que pasa si a un txt le pones extension de dll. Digo es un caso un poco fuera de lo comun, pero me gustan hacer los programas a prueba de errores.... Que sucederia?
Saludos

[MaxExtreme]

Nada. LoadLibrary devolvería un error y simplemente no la uses. ¿Qué problema hay?

[Eternal Idol]

Iniciado por Instru

Bueno, pero por ejemplo, si en el directorio pones un txt? Hay que hacer un filtro de de nombres de archivos, no? Pero... que pasa si a un txt le pones extension de dll. Digo es un caso un poco fuera de lo comun, pero me gustan hacer los programas a prueba de errores.... Que sucederia?
Saludos

El FindFirstFile lo harias con *.DLL y de cualquier manera Windows te devolveria 0 cuando intentaras cargar un ejecutable que no fuera una libreria PE bien formada.

[Instru]

Ok, muchas gracias, lo voy a intentar asi.

[Instru]

Reviviendo el post......
Tengo una duda acerca de las funciones que menciono Eternal Idol. En linux, que uso? O mejor dicho, cual es la manera mas estandar o mas bien, portable de hacer un vinculo dinamico?

Saludos

[MaxExtreme]

En GNU/Linux se usan mayormente librerías estáticas, no se cargan al vuelo; pero aun así hay funciones para usar librerías dinámicas. Busca en Google.

[Instru]

Bueno, ok. Otra cosa mas. Si estoy programando para otra plataforma que no es ni windows ni linux, puedo hacer que el enlace dinamico se haga estatico o algo asi?
Es decir, que mi programa igualmente cargue las funciones pero de otro archivo.

Saludos

[MaxExtreme]

Iniciado por Instru

Bueno, ok. Otra cosa mas. Si estoy programando para otra plataforma que no es ni windows ni linux, puedo hacer que el enlace dinamico se haga estatico o algo asi?
Es decir, que mi programa igualmente cargue las funciones pero de otro archivo.

Saludos

No entiendo la pregunta :S

Cada sistema operativo / plataforma tiene sus propios estándares de ejecutable, normalmente. De igual manera funcionan las librerías.

No entiendo a que te refieres con "en otra plataforma". No hay ejecutables "estándar". Primero porque cada sistema operativo lo pone como quiere, segundo porque usan diferentes procesadores.

[Nivel7]

#ifdef WIN32
#define FXLOCAL
#define FXEXPORT __declspec(dllexport)
#define FXIMPORT __declspec(dllimport)
#else
#if defined(__GNUC__) && (__GNUC__ >= 4)
#define FXLOCAL __attribute__ ((visibility("hidden")))
#define FXEXPORT __attribute__ ((visibility("default")))
#define FXIMPORT
#endif

Esto es para definir macros de importacion ya sea Windows o Linux.

Como se hace en Linux, la verdad no lo sé, en windows hay diferentes formas.

Implicitamente o modo de carga estatica, es decir tu creas tu Dll, y ademas de crearse una Dll, se crea un fichero .a o .lib, este se usara como una libreria estatica a la hora de crear tu ejecutable que use esta libreria Dll.

explicitamente es usando la funcion LoadLibrary y GetProcAddress.
NO estoy del todo seguro si este metodo requiere de archivos .DEF

la verdad las pocas veces que he usado Dlls, lo he hecho implicitamente es decir con __declspec(dllimport) o __declspec(dllexport).
lo he intentado en otras ocasiones con LoadLibrey pero nunca me funciona.

La regla es que una vez que modificas la Dll, tienes que recompilar el ejecutable pero no siempre es asi. (SI compilas con el mismo compilador, puedes modificarla sin que eso implique recompilar tu ejecutable (Siempre y cuando las funciones que usa tu ejecutable mantengan su nombre, tipo y parametros igual)).


Se que no ayuda en mucho esta informacion pero queria comentarte eso.

Saludos.

[Nivel7]

Despues de ver la pregunta de Instru he estado probamdo esto de las Dlls, la ligadura temprana de Dlls, (o estatica como se llame), me funciona muy bien, pero al ligadura por LoadLibrary, no funciona para nada, me marca un acceso invalido a memoria.

se me ocurrio que podia hacer algo para solucionar el problema planteado por Instru, pero si no logro hacer funcionar LoadLibrary y GetProcAddress sera dificil.

Mi planteamiento es este:

Hacer una Dll y su respectiva libreria estatica, en esta se declarara una clase abstracta, es decir una clase con funciones virtuales puras, a manera de interfaz.

esta libreria se incluira en el ejecutable para tener un puntero de la clase abstracta.
esta libreia tambien se usara para crear las Dlls, que en el futuro, se utilizaran para dar diferentes comportamientos al programa.

en estas otras Dlls, se declararan objetos deribados de la clase abstracta y a traves de una funcion se mandara un puntero de esta clase al programa.

esto se haria con las funciones LoadLibrary y GetProcAddresss.

El funcionamiento de esto se basa en el polimorfismo.
es decir a travez de un puntero a clase base se accedes a funciones mienbro de clases derivadas.

por tanto siempre y cuando las clases nuevas contenidas en las Dlls, implementen la interfas(Clase abstracta), se le podra dar diferentes comportamientos al programa que use esta clase.(a travez del puntero en la Dll base).

Alguien a trabajado con LoadLibrary y GetProcAddress??

por que me marcara error de acceso??

Este es un programa basico en el que intento llamar una simple funcion y no lo logro, que esta ra mal??:

#include <windows.h>

typedef void(*PF)();

int main()
{
HINSTANCE hDll = LoadLibrary("MiDll.dll");
PF Mensaje = (PF)GetProcAddress(hDll, "HelloWorld");
Mensaje();
FreeLibrary(hDll);
return 0;
}

esta es la funcion en la Dll:

DLLEXPORT void HelloWorld ()
{
MessageBox (0, "Hello World from DLL!\n", "Hi", MB_ICONINFORMATION);
}

Saludos.

[Instru]

Bueno, las funciones LoadLibrary y GetProcAddress me funcionan perfectamente. De hecho ya hice la primer prubea. hice una dll, y la use en mi ejecutable con las funciones dichas.

En windows, eso esta perfecto, namas pongo windows.h y listo, puedo usar esas funciones. En linux oi que hay archivos muy parecidos a los dlls, pero se llaman de otra manera. El problema es que estoy programando para una consola de videojuegos, y lo que quiero es que mi aplicacion use plug ins. Pero que estos plugins sean solo para windows y en el mejor de los casos para linux. Mas sin embargo, en la consola, solo quisiera usar una sola plugin.

El proposito de esto es la maxima portabilidad. Por ejemplo SDL es muy portable, pero en windows es algo ineficiente. Entonces doy a escojer entre SDL, allegro, DX y OGL. En linux igual, a excepcion de DX.
Pero en la consola solo quiero utilizar SDL. Pero para no tener que reprogramar la parte donde tengo que sustituir por SDL, quisiera hacerlo, como si fueran plugins. Aunque sea de manera estatica

Posiblemente con unos #ifdef, #ifndef, etc podria funcionar.
Que opinan de esto.

La pregunta se resumen en:

Como puedo llamar funciones que estan en otro "ejecutable" o archivo desde otro ejecutable? que no sea desde windows.

Saludos

[MaxExtreme]

Iniciado por Instru

La pregunta se resumen en:

Como puedo llamar funciones que estan en otro "ejecutable" o archivo desde otro ejecutable? que no sea desde windows.

Y yo te vuelvo a responder: Dependerá de la plataforma / sistema operativo.

[Instru]

Bueno, y diciendote que es un cpu SH4 y un ARM. Y que uso el compilador gcc.
Suficiente informacion? A el OS seria KOS.
Saludos

[MaxExtreme]

Si el OS permite el uso de librerías dinámicas, adelante.

Yo no conozco mejor que tú KOS ;)

[Instru]

Bueno. Me acabas de dar la gran idea....
Voy a checar la super escaza documentacion de KOS.
Saludos