From: mlx AT san DOT rr DOT com (Steve Biskis)
Subject: Re: Delphi problem with DLL
13 May 1998 01:16:35 -0700
Message-ID: <199805121323.GAA16549.cygnus.gnu-win32@proxyb1-atm.san.rr.com>
Reply-To: <mlx AT san DOT rr DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
To: "Laurent Merckx" <Laurent DOT merckx AT eurodb DOT be>
Cc: <gnu-win32 AT cygnus 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 AT cygnus DOT com" with one line of text: "help".