Hola a todos!
Me he vuelto a encontrar con un problemilla al utilizar DLLs.
Tengo mi DLL que es una implementacion de una clase interface ( motor grafico, por ejemplo ) y esta hace un new del objeto mediante una funcion. Bueno, hasta aqui todo bien. Ahora me he querido hacer una aplicacion con MFCs utilizando este objeto, pero me he encontrado con el problema de que la aplicacion no me quiere cargar la DLL ( utilizo LoadLibrary ).
Alguien sabe porque es esto? He dejado todos los settings del proyecto igual que el resto, pero no consigo solucionarlo... si alguien me pudiese ayudar, le estaria muy agradecido. Este problemilla me saca de quicio.... (nooo)
En fin, muchisimas gracias por adelantado!
Un saludote!!
EDIT: La funcion GetLastError( ) de Windows me devuelve el error numero 126 ( The specified module could not be found. ERROR_MOD_NOT_FOUND ) y juro y perjuro que el archivo esta ahi, y con otras aplicaciones no MFCs me funciona a la perfeccion... (grrr)
El único consejo que te puedo dar es que hagas un GetCurrentDirectory antes del LoadLibrary para asegurarte de que el directorio actual es el correcto.
Saludos.
Ya lo habia probado, pero muchas gracias igualmente. No se que puede ser... : (
Me suena q me pasaba lo mismo y era porque en el dllmain de mi DLL no retornaba 1 en la carga de la misma. En la msdn dice q cuando se esta cargando si no retorna 1 la funcion LoadLibrary retorna un error. El parametro q especifica la carga esta en ul_reason_for_call (o algo asi XD) si usas el wizard del vc++.
No se si sera esto, me suena de haber tenido problemas con ello,lo mismo furrula.
saludos
Buenas:
Pues yo no tenia ningun DllMain; no lo necesitaba. Ahora se lo he puesto, pero parece que no pasa por ahi, pero con una aplicacion Win32 normal, si que pasa. Ciertamente el Windows no me cree cuando le digo que en la ruta X esta una DLL : ( No lo entiendo!!
Mi DllMain es esto:
BOOL WINAPI DllMain( HINSTANCE hInstance, DWORD dwReason, LPVOID lpvReserved ) {
return TRUE;
}
Gracias por el intento!!
Estoy desesperandome por momentos...
exportas el DllMain?
Lo unico que hago es poner, en los settings del proyecto, que el EntryPoint es DllMain. Y esto me funciona cuando es una aplicacion Win32 normal, pero no con MFC.
Desde la aplicacion MFC he hecho el LoadLibrary de unas pocas DLLs y la unica que me ha funcionado bien ha sido la OpenGL32.DLL...
Tambien he probado la AfxLoadLibrary, pero me da los mismos errores (nooo) (nooo) (nooo) (nooo)
como me alegro de no usar mfc :D
Bueno, al fin lo he conseguido arreglar!
Al final la culpa no era de las MFCs, si no mia ( Gracias igualmente, ethernet, por el link. Muchas gracias ). Lo que pasaba es que la DLL que estaba intentando linkar esta, a su vez, intentaba linkar con otra DLL ( implicitamente, creo que se llama ) y era esta la que Windows no encontraba. Fallo mio... :(
como me alegro de no usar mfc
Eso mismo pensaba yo, hasta que me han hecho ver la luz ^_^ Las MFC estan mejor de lo que parece.
Un saludote y gracias a todos!!
wxwindows rocks
Los comentarios de ethernet siempre son tan claros y concisos... -_-
sync
MFCs (shit)
wxwindows es una libreria para hacer ventanitas, botoncitos, comboboxs, barras de desplasamiento etc, lo mismo que las MFCs. La enorme ventaja es que es multiplataforma, tu programa hecho con wx tambien correra en linux.
Lo que se le puede criticar es que no esta 100% terminada, pero es tan buena que hay compañias que tienen planes de utilizarla en sus productos momerciales, por ejemplo Borland.
De las aplicaciones mas famosas que usan wxwindows esta XMule, un port multiplataforma de eMule.
Poco a poco las MFCs van a quedar relegadas, porque... ¿Para que hacer un programa que solo correra en Windows? Si puedo hacer unos que ademas correra en linux , mac, bsd, Etc.
Ademas Microsoft apuesta ahora por "FORMS" de .Net como substituto para las MFCs.
Ya hay .Net y C# para linux y ya pronto tendremos "FORMS" para linux. :D
Upss... ¿que no el tema era otro? :huh:
Zeru sale del modo linuxero.
:P
Querido zeru...
Citarwxwindows es una libreria para hacer ventanitas, botoncitos, comboboxs, barras de desplasamiento etc, lo mismo que las MFCs
... con MFCs puedes hacer threads, sockets, fpt, http, dao, odbc, files ,arquitectura documento/vista... con wxwindows ?¿? ...pues entonces hablamos de cosas diferentes.
CitarPoco a poco las MFCs van a quedar relegadas, porque... ¿Para que hacer un programa que solo correra en Windows? Si puedo hacer unos que ademas correra en linux , mac, bsd, Etc.
Pq hoy en dia mas del 90% ( no se si me quedo corto ) de los usuarios tiene windows. Ademas pq no se puede comparar la calidad y velocidad de un programa generado para una plataforma que el que debe de preveer todas las posibles alterativas de donde se debe ejecutar. ( es como los soldaditos de metal que te compras y pintas, o bien los que te compras ya pintados )
CitarAdemas Microsoft apuesta ahora por "FORMS" de .Net como substituto para las MFCs.
Cierto es que se apuesta por .NET. Pero es que culo veo culo quiero los de MS ( .NET == filosofia Java ). De todas formas en vc .net no han eliminado MFCs tradicional, ni las aplicacione win32, pq sera ? ... tal vez pq no puedan competir en prestaciones de velocidad ante las que se hacen valer de un interprete para ejecturase en un s.o o en orto... vease Java con la Virtual Java Machine ( VJM ) o el .NET con su super framework, que dicho sea de paso ( esto es para pegarles ostias hasta que se queden calvos ) no tiene en casi dos años de existencia ya un framework para otras plataformas que no sea Win. ¿ En tonces que se gana con .NET ?...
Bueno, ya no rallo más, solo decir que wxwinows tiene su sitio y MFC ocupa otro, escoger la más adecuada depende de las necesidades del proyecto.
Un saludo.
Zeru nos vemos en #war3d (ole) .
mfc sucks
re Hola
Citar
... con MFCs puedes hacer threads, sockets, fpt, http, dao, odbc, files ,arquitectura documento/vista... con wxwindows ?¿? ...pues entonces hablamos de cosas diferentes.
Ok cierto :) admito que las MFCs son mucho mas completas. Aun asi pienso que las MFCs apestan, son feas y confusas.
E insisto, lo pero de todo con las MFCs es que solo te sirven para hacer programas para Windows.
Citar
Pq hoy en dia mas del 90% ( no se si me quedo corto ) de los usuarios tiene windows.
Cierto, al igual que en su tiempo todos tubimos un Nintendo en lugar de Sega, aun cuando Sega era mejor.
Ahora todos usamos PCs aunque las MAC son mejores.
Pero aclaro que yo no estoy en contra de usar Windows, de hecho la mayoria de los programas que hago corren en Windows.
Y ademas corren en linux.
Es por eso que no me gustan las MFCs, ni me gusta Direct X, porque solo te permiten hacer programas para Windows.
Es decir mientras que con Direct X puedes hacer programas que correran en el 90% de las maquinas, con OpenGL puedes hacer que tu programa corra en el 99% de las maquinas.
Soy usuario de Windows y de Linux. War3D corre en windows y linux (en terioria deberia poder compilarse en Mac, BSD, etc, digo en teoria poque no tengo una Mac para hacer pruebas)
Citar
Cierto es que se apuesta por .NET. Pero es que culo veo culo quiero los de MS ( .NET == filosofia Java ). De todas formas en vc .net no han eliminado MFCs tradicional, ni las aplicacione win32, pq sera ?
Hay que dar soporte hacia atras. No se puede dar un salto tan brusco porque el 80% del sofware actual o mas dejaria de ser util.
Es por eso que los actuales procesadores de 32 bites pueden correr aplicaciones de 16 bites, y los nuevos procesadores de 64 bites podran corres aplicaciones de 32.
Citar
tal vez pq no puedan competir en prestaciones de velocidad ante las que se hacen valer de un interprete para ejecturase en un s.o o en orto... vease Java con la Virtual Java Machine ( VJM ) o el .NET con su super framework
Pues no esactamente, .Net tiene ciertas diferencias con JAVA, una de ellas es que, auqne si existe una maquina virtual, .Net tambien puede generar binarios nativos, es decir, ejecutables que usan las arquitectura del micrcoprocesador al maximo. (O al menos hasta donde los programadores de MS puedan llegar)
Hace ya mucho lei eso, pero la idea basica es que, nosotros los desarrolladores, al terminar nuestro programa vamos a distribuir el bytecode, es decir nuestro programa ya compilado. El usuario lo descarga o recibe en CD o como sea, lo ejecuta, y el framework compila nativamente las partes del bite code que se utilizan, es decir el programa corre lentamente la primera vez, pero las siguientes ya corre como si se tratase de un ejecutable nativo.
Lo hermoso de todo esto es que tu framework va a detectar que tienes un Pentium4, y compilara el bitecode para tu Pentium4, pero en mi caso detectara que tengo un AdlonXP y compilara el bytecode especialmente para mi AtlonXP.
Ya me estoy extendiendo mucho :P
Considerando que ambas son tecnologias de Microsoft. ¿ Porque defiendo .NET y porque en cambio pienso que las MFCs son mierda ?
Pues porque, ademas de Age Of Empieres, .NET es la unica buena idea que ha tenido Microsoft. Aunque hay que aclarar que tiene muchas cosas basadas en JAva y ademas los progrmadores de .Net son extrabajadores de Borland :P
No tiene caso resistirse a .NET, si es peor o mejor que Java, eso no importa. No solo Microsoft nos va a imponer la tecnologia de .NET a los usuarios de Windows, sino que hasta los linuxeros tendremos que aprender c#, o seguir usando c++ pero con un compilador de .Net para c++.
Ademas no hay porque resistirse, como ya dije .Net es una de las pocas cosas buenas que ha hecho MS, y aunque MS hiciera mal las cosas y nos entregara malos compiladores para .NEt, pronto tendremos compiladores libres para .NET. De hecho ya existen algunos, como MONO y GNUSharp o algo asi.
Aun si, Microsoft abandonara el proyecto, ya hay mucha gente detras que lo apoyara, incluyendo Linuxeros.
Citar
Un saludo.
Zeru nos vemos en #war3d .
Ya te puse un ban y level -1 en #war3d :P
Na no es cierto :D jejeje :*
Citar
no tiene en casi dos años de existencia ya un framework para otras plataformas que no sea Win. ¿ En tonces que se gana con .NET ?...
Es poco probable que Microsoft haga un su framework para otros sitemas operativos que no sean suyos, (Puros Windows), pero ya existen frameworks hechos por terceros, por ejemplo MONO www.go-mono.org el cual ya esta muy muy avanzado, DotGNU www.dotgnu.org y creo que hay un tercer proyecto que esta muy verde aun.
El mas interesante es MONO, porque no solo es para la arquitectura 386, sino que tambien corre en PowerPC, Y ademas no solo corre en Linux sino que por extraño que paresca hay una version para Windows. Es decir Mono Para Windows es una "implementacion de Libre de .NET" para Windows.
Bueno ya me pase.. escribi demaciado y lo peor es que no tiene nada que ver con el tema original :P
MA]Mestre :angry: Unete al lado oscuro de la fuerza y ven a programar con nosotros el War3D.
Ese esfecto de agua que esabas haciendo para tu terreno deberia estar en el War :)
Las MFCs hasta hace nada tenían memory leaks. Comprobado claramente con Rational Purify :)
De todas formas yo las sigo utilizando (nooo)
sync
Las MFCs hasta hace nada tenían memory leaksmmm no dudo de tus palabras, pero no conozco leaks de memoria, ¿ algun ejemplo ?
CitarMA]Mestre Unete al lado oscuro de la fuerza y ven a programar con nosotros el War3D
no hombre no, el lado oscuro es DX. :P
CitarEse esfecto de agua que esabas haciendo para tu terreno deberia estar en el War
ufff, esperate que lo acabe, pq se me jodio el disco duro y la copia de seguridad era de antes de empezarlo, asi que lo estoy rehaciendo ( no con muchas ganas pq me quede planchado :( , maldito discoduro arggghh )
Un saludo.
MFC soporta threads, sockets... y que? XD acaso wxwindows no lo soporta ? (http://www.wxwindows.org/supported.htm).
Ademas MFC SOLO se puede usar con c++ y vc++, wxwindows se puede usar con python, c++, c, etc. MFC solo se ejecuta en plataformas wintel, wxwindows en wintel y muchas mas.