From: ismaelj AT hotmail DOT com ("Ismael Jurado") Subject: About DLLīs again 17 Apr 1997 13:42:12 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199704171444.HAA08566.cygnus.gnu-win32@f39.hotmail.com> Content-Type: text/plain X-Originating-IP: [194.179.125.73] Original-To: gnu-win32 AT cygnus DOT com Original-Sender: owner-gnu-win32 AT cygnus DOT com About the DLL's that don't work: Few days ago I posted a procedure to make DLL. This procedure was based on my own experience, experience that I want to share with the group, because for me work great, it will do so for others. In the other hand , Iīm not a Windows 'guru', I only try to do my best. Anyway, here are some answers to your questions. Matt Calder wrote > I find that I can load the dll during the WinMain procedure, and > in some parts of the WinProc (Main window procedure). The library > will load if I am in the message handler for WM_CREATE or WM_PAINT, > but not in the message handler for WM_COMMAND! When I say message ... > In this configuration the dll is loaded, if the LoadLibraryEx() > call is moved into the WM_COMMAND portion it will not load. I > don't understand why, if I use a dll built with MSVC it works > fine. Any help would be very much appreciated. I've tested myself this and Iīve found the same problem that you, that the program failed to load the DLL, but itīs a problem of the program generated by the compiler. To prove this, I compiled the DLL folowing the procedure I posted (using the cygnus tools), and then I make 3 compilings of the test program (similar to the one you posted) one with the cygnus package, other with the Minimalist (Mingw32) package, and other with Borland C++ 5.0. The programs generated by gcc failed to load the DLL, but the one compiled with Borland did it's work independently of where in the program I put the LoadLibrary() call (that it's well-formed as long as I know). For me, that testing shows that the procedure to generate the DLLīs work, but something fails within gcc, or maybe itīs only a lack of the right option in the command line... I donīt know what it is. HARBAUGH AT FCRFV1 DOT NCIFCRF DOT GOV wrote: > Ismael, your example worked great, but I still have a problem because > I need to pass arguments. Whenever I try to write a function that > passes arguments, the linker complains as follows: > > (d:\CYGNUS\H-I386~1\BIN\ld.exe 1304) In cygwin_except_handler > (d:\CYGNUS\H-I386~1\BIN\ld.exe 1304) Exception trapped! > (d:\CYGNUS\H-I386~1\BIN\ld.exe 1304) exception C0000005 at 438238 HARBAUGH AT FCRFV1 DOT NCIFCRF DOT GOV wrote in other message: > I figured out one way to stop the errors I wrote about in my > last message; I added a MessageBox call in the DllMain > function, just as you did. THEN THE DLL WORKED. > Unfortunately, I really must get rid of that MessageBox call. I donīt know what is wrong here. Again, I made a modification on my example for a function passing values, and make 3 compilations and got this: it works when I call the funcion linking with the Dll, and donīt works when I call the function via LoadLibrary(), no matter if DLLMain() have or not a MessageBox() call. Here are the test results: Mydll.dll : Always build with gcc using cygnus tools and folowing the procedure posted App A : Test example loading the DLL via LoadLibrary and calling foof with GetProcAddress() App B : Test example linking with mydll.a and calling directly foof Envoriment | cygnus | mingw32 | borland | ------------------------|--------|---------|---------| void foof() & App A | Y | Y | Y | int foof(LPSTR) & App A | N | Y | Y | void foof() & App B | Y | Y | Y | int foof(LPSTR) & App B | Y | Y | Y | ------------------------------------------------------ HARBAUGH AT FCRFV1 DOT NCIFCRF DOT GOV wrote in other message: > I realize I must be doing something wrong, but I have no idea what it could be. > Ultimately I want to be able to pass values back to a Visual Basic calling > procedure. If you can help me, please let me know. About this, I have heard something like cygnus-produced DLL's canīt be loaded by other DLL, and as far as I know, the VB code is a DLL... So, I trust on may procedure: the DLLs work OK, but not the programs that must load them. Any clue about this ? Ismael Jurado Ismaelj AT hotmail DOT com --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".