This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: Delphi problem with DLL
- To: "Laurent Merckx" <Laurent dot merckx at eurodb dot be>
- Subject: Re: Delphi problem with DLL
- From: "Steve Biskis" <mlx at san dot rr dot com>
- Date: Tue, 12 May 1998 06:21:04 -0700
- Cc: <gnu-win32 at cygnus dot com>
- Reply-To: <mlx at san dot rr dot com>
I'm sorry Laurent, but that: "ONLY" difference of being C++ vs. standard C
is a biggie !!! (to me)
I swore off of C++ about 7 years ago in lieu of Objective-C and NEVER
looked back.
With Objective-C you concentrate most of your time designing the OO
solution, with C++
you spend most of your time tailoring your OO solution to the rules and
numerous exceptions
of the rigid syntax. Yea, I admit it, I'm an ObjC biggot ... ouch! - just
slipped off my soapbox.
But I'll venture one guess anyway.
Is the exported function that returns with a fault defined as __stdcall
?
eg.
const char * __stdcall _export someFunc( int anInt, char aChar )
{
// Bunch o' code ...
return <some char *>
}
I apologize if you already know this, but your C++ code (the DLL) is
using the C calling convention while your delphi code (the exe) is
using the pascal calling convention. The __stdcall directive should be
used where modules of dissimilar languages interact.
This is to get them on the same page as far as:
A> What order arguments are popped off the stack and
B> Which side (caller vs. callee) cleans up the stack after the function
returns.
From your description, its sounds as though your problem may involve item
B.
Now, since C++ (like ObjC) mangles function names, your gonna have to
make
use of the "extern" keyword or create plain C jumper functions or
"wrappers"
for the C++ member functions you wish to export and don't forget what the
1st
two arguments to every member function/method really are. (self,_cmd)
In general, ALWAYS define ALL functions that are exported as part of the
interface of a DLL as __stdcall. This ensures conformity for
inter-language
usage.
I've written systems where delphi .exe's call into C/ObjC DLL's and
systems
where C/ObjC .exe's call into delphi DLL's with out to much fanfare.
Hope this helps,
da bisk.
> It doesn't seem to work !
> Delphi can launch my functions. These functions use the 'new' operator
> of g++ and return a good value but when returning to caller, Delphi
> stops (like a breakpoint control).
> When we continue execution, it make a protection fault and Win95 crash !
>
> The only difference is that the entry module is written in g++ and
> #include <objc/runtime.h> is commented !
>
> Do you have an idea ? Is the threads the origin of this problem ?
> But thank you, it works better than before !
>
> Laurent.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".