Subject: RE: Problems building DLLs with cygwin
From: [email-masked] (Colin Peters)

5 Dec 1996 21:30:04 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Original-To: "'David Essex'" <[email-masked]>
Original-Cc: "'GNU-Win32'" <[email-masked]>,
        "[email-masked]'"
	 <[email-masked]>
Original-Sender: [email-masked]

David Essex[SMTP:[email-masked]] wrote:
>At 07:52 PM 04/12/96 +0100, you wrote:
>>Once more I whould like to report that I have big trouble building dlls
>with b16.
>>I first tried to build the dll using the dlltool from cygnus and I was not
>able to get things working.
>>....
>>Does someone have an idea what is wrong with as, ld or dlltool.
>It was working in b14 if both DLL and calling program was written using the
>gnu-win32 compiler. 
>
>>Has someone build dlls successfully and used them from another application.
>I doubt it. I ran into the same problem trying to call DLL's written using
>gnu-win32(b14) compiler from Delphi. They would compile but Delphi was
>unable to load it. 
>The problem relates to the standard or maybe lack of, for win32 DLL's.
>Apparently DLL's compiled with say MS C/C++ will not work if they are called
>by an application written using say Borland C/C++, and visa versa(1).

Actually, I know from personal experience that this is not necessarily true,
which is not to say that it will always work. I wrote a DLL for a program
produced by another vendor. They used Borland, and we used Visual C++. There
were not particular problems between the two except with what might be expected:
I had to get the packing and alignment right for some structures they were passing
around. My MSVC DLL was called by a Borland DLL and called other Borland DLLs.

Now, mind you, this was a completely dynamic loading situation, where layers would
use LoadLibrary and GetProcInstance (?) to get the appropriate function calls from
the layer below. However, I would be surprised if the OS was not capable of doing
the same thing with ordinary DLL references.

One place which it's fairly certain this will not work is with C++, since every
compiler does different name mangling.

>Work-arounds and issues relating to this problem are much to long to be
>expanded on here but can be found in a magazine article(2) I recently read.
>So what standard is the gnu-win32 ot the minimalist gnu-win32 using? Perhaps
>I am showing my ignorance on this subject, but I think these are issues that
>should be resolved, or at least expanded on.

>(2) Windows Developer's Journal, August 1996, "Building Win32 DLL's the
>right way".

I wish I'd seen that article, and I really hope the people at Cygnus are aware
of these issues (actually I'm sure they are).

That raises another point though. Perhaps some of these problems are worse under
Win32 than on win16? The DLLs I wrote and used were win16. On the other hand,
anyone who has written programs that use GUI calls (or the Minimalist C run time
library calls) knows that it is possible to call MS-ish DLLs from GNU code. This
suggests that the reverse should also be possible.

As for the model/system/defaults that the Minimalist system works on, they are
the same as anything else produced by GNU-Win32. I didn't do anything to change
them (as far as DLLs go). Actually, up until now there has been no explicit
information on building DLLs for mingw32 (beyond what comes from the Cygnus
docs), however I recently got a package from Gunther which does this, and I'm
in the process of integrating it. I'll probably wait until b17 comes out before
making a new release though. Gunther also managed to do some stuff with C++ and
DLL support, but I still haven't taken a good look at it.

Good luck,
Colin.

-- Colin Peters - [email-masked]
-- Saga University Dept. of Information Science
-- Fundamentals of Information Science
-- http://www.fu.is.saga-u.ac.jp/~colin/home.html

-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".