Subject: About DLL�s again
From: [email-masked] ("Ismael Jurado")

17 Apr 1997 13:42:12 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Content-Type: text/plain
X-Originating-IP: [194.179.125.73]
Original-To: [email-masked]
Original-Sender: [email-masked]

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 <[email-masked]> 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.

[email-masked] 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

[email-masked] 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    |
------------------------------------------------------

[email-masked] 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
	[email-masked]

---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".