Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive:	<http://sourceware.cygnus.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help:	<mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id:	<200003161604.KAA05323@hp2.xraylith.wisc.edu>
To:	"Incubus " Inc gnita "" <icg_incubus AT yahoo DOT com>
cc:	cygwin AT sourceware DOT cygnus DOT com
Subject:	Re: cygwin DLLs and VC
In-reply-to:	Your message of "Thu, 16 Mar 2000 07:40:18 PST."
	<20000316154018 DOT 8752 DOT qmail AT web121 DOT yahoomail DOT com>
Date:	Thu, 16 Mar 2000 10:04:13 -0600
From:	Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>

Incubus "Inc gnita" <icg_incubus AT yahoo DOT com> writes:
>   I've tried compiling a working VC++ DLL project
> using the dllhelpers r2.4 provided with Cygwin B20,
> and found out that despite the result worked fine
> with Gygwin's GCC compiled exes, it didn't work at
> all with the same exes compiled with VC. 
>   In fact, it returns exactly the same adress for
> the dll imported function in both cases, but when
> calling it from VC it causes a GP fault. The exports
> are done using old-fashion .DEF style, so I'm
> forcing the calling convention to "C" using the extern
> "C" directive, that I think that should be supported
> by
> both compilers.
>   If any of you found this problem or have any idea
> about solving it, please let me know.

Let me see if I understand this.

1. VC++ compiled DLL loaded dynamically from VC++ compiled main app.
   - Works.
2. Cygwin compiled DLL loaded dynamically from VC++ compiled main app.
   - Does not work.

If this is the case, then it's expected. Cygwin v1.1 will have full
functionality to be loaded dynamically by non-cygwin application, but
b20.1 has only partial support.

To make it work with b20.1, and keeping in mind that you'll only have
partial support, use __cygwin_noncygwin_entry AT 12 as the entry point 
for your Cygwin DLL.

See my examples for Java JNI or Excel DLL etc on:
  http://www.xraylith.wisc.edu/~khan/software/gnu-win32/

Good news is that all this hackery will go away, at least in theory, 
in the upcoming Cygwin v1.1.

BTW, you may need to make loadable functions, such as Register, use
the __stdcall calling convention, or else you may run into stack
corruption. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -