Board index » delphi » Help: calling procs in a C++ DLL

Help: calling procs in a C++ DLL

I'm trying to access from a Delphi 4 application an exported routine in
a DLL created under Borland C++. When I try to run it however, I get the
error message
'The pparprog.exe file is linked to missing export params.dll:boring'
then complains
'Unable to create process'

Just under the interface keyword, I've added
procedure boring; cdecl; external 'params.dll';
(I've tried leaving out the 'cdecl;' and '.dll' having read a previous
thread on this group, but the result is the same)
and in the C++ the routine is defined as
void _export boring(void)

I've seen examples with keywords like 'far' and '_pascal' scattered
round the C++ routine header, but rather than try random combinations I
thought I'd look for help here.
In addition, the Sams Delphi 4 Developer's Guide reference manual p237
says 'In this case [when you have a C/C++ import library], you have to
translate the library to a Pascal equivalent interface unit.' which
makes me think I'm missing out a step. However, their help seems to end
at this point, which is more than a bit frustrating.
So what do I do?

Any help gratefully received.

 

Re:Help: calling procs in a C++ DLL


On Wed, 25 Oct 2000 12:35:51 +0100, David Tracey

Quote
<David.Tra...@cambridge.simoco.com> wrote:
>I'm trying to access from a Delphi 4 application an exported routine in
>a DLL created under Borland C++. When I try to run it however, I get the
>error message
>'The pparprog.exe file is linked to missing export params.dll:boring'
>then complains
>'Unable to create process'

>Just under the interface keyword, I've added
>procedure boring; cdecl; external 'params.dll';
>(I've tried leaving out the 'cdecl;' and '.dll' having read a previous
>thread on this group, but the result is the same)
>and in the C++ the routine is defined as
>void _export boring(void)

Actually the external directive usually goes in the implementation
section.

I'm presuming your example is "simplified" as a void function taking
no parameters would seem to be somewhat useless.

Quote
>I've seen examples with keywords like 'far' and '_pascal' scattered
>round the C++ routine header, but rather than try random combinations I
>thought I'd look for help here.

It might help to have the genuine C declaration to look at.
Particularly if there are any #defines or other preprocessor
directives nearby.  I'm wondering if we're having an Ansi vs.
Widestring problem.  

One thing to try is running TDUMP on the .DLL to make sure the routine
IS in there, perhaps you have a different version.

The "far" and "_pascal" stuff is pretty much only of concern in 16-bit
code, and you're using D4.  Which brings up the question: are you sure
it's a 32-bit DLL?

Quote
>In addition, the Sams Delphi 4 Developer's Guide reference manual p237
>says 'In this case [when you have a C/C++ import library], you have to
>translate the library to a Pascal equivalent interface unit.' which
>makes me think I'm missing out a step. However, their help seems to end
>at this point, which is more than a bit frustrating.
>So what do I do?

Typically an "interface unit" consists of external routine
declarations such as you're attempting, no other steps involved.

Stephen Posey
slpo...@concentric.net

Re:Help: calling procs in a C++ DLL


Quote
Stephn Posey wrote:
>Actually the external directive usually goes in the
>implementation section.

Yes, I've tried that as well.

Quote
>I'm presuming your example is "simplified" as a void function
>taking no parameters would seem to be somewhat useless.

True; I stripped it down to that to be sure it wasn't just a problem
with type translation - I know C++ in particular refuses to recognise a
procedure name if you get one of the parameter types even slightly
wrong.
Having also seen Allessandro Allasio's earlier thread, I tried to mimic
his function as far as possible by adding to the C++[1]:
 int FAR PASCAL _export intproc(int param)
 {
   return(param);
 }

and in the Delphi form I have :

implementation
function intproc(param: integer) : integer; external 'params.dll';

plus an invocation of it lower down as follows:
   Val := intproc(1);

No better; it still reports it can't find intproc.

I did wonder if it was finding another params.dll elsewhere, but
renaming the actuall .dll caused it to complain that it wasn't there, so
it can't be that.
The DLL in question is definitely 32 bit, but in turn uses another which
is 16bit. I don't see why this should be a problem though - at least not
at the stage of trying to find the exported routines.
I'd like to have a look at what's in the DLL, but at the moment all
I can think of is passing it through a 'strings' utility, which at least
demonstrates that the 'intproc' is there in some form. Are there any
tools which tell you what is in a DLL?

Anyway, at the moment I'm stuck - there are probably other ways round it
(such as doing the whole thing in C++), but I'm not that happy about
leaving it without at least an idea of what I'm doing wrong - these
unresolved questions have a habit of  reappearing at even less
favourable times.

So - any ideas?

[1] The '++' is irrelevant here, but there is a class in there which
I was hoping to use later - probbaly that will bring its own
problems....

Re:Help: calling procs in a C++ DLL


"David Tracey" <David.Tra...@cambridge.simoco.com> skrev i melding
news:39F813FC.798DBF0E@cambridge.simoco.com...

Quote
> I'd like to have a look at what's in the DLL, but at the moment all
> I can think of is passing it through a 'strings' utility, which at
least
> demonstrates that the 'intproc' is there in some form. Are there any
> tools which tell you what is in a DLL?

QuickView.exe in Windows directory shows the exported functions of a
.dll

--
Bjoerge Saether
Consultant / Developer
Asker, Norway
bsaether.removet...@online.no (remove the obvious)

Re:Help: calling procs in a C++ DLL


Quote
David Tracey <David.Tra...@cambridge.simoco.com> wrote in message

news:39F6C597.CFD914FD@cambridge.simoco.com...

Quote
> I'm trying to access from a Delphi 4 application an exported routine in
> a DLL created under Borland C++. When I try to run it however, I get the
> error message
> 'The pparprog.exe file is linked to missing export params.dll:boring'
> then complains
> 'Unable to create process'

It sounds like you have everything right but the name of the routine. Have a
look with QuickView and I reckon you'll find its called _boring@7cfr() or
some such gibbereish. If you have compiled in C++ without the name mangling
disabled, then I would guess thats the root of your problem. A quick look at
VC6 help (since my memory can't be trusted ) shows....

If you have functions in a DLL written in C++ that you want to access from a
C-language module, you should declare these functions with C linkage instead
of C++ linkage. Unless otherwise specified, the C++ compiler uses C++
type-safe naming (also known as name decoration) and C++ calling
conventions, which can be difficult to call from C.

To specify C linkage, specify extern "C" for your function declarations. For
example:

extern "C" __declspec( dllexport ) int MyFunc(long parm1);

regards,

Dave

Re:Help: calling procs in a C++ DLL


Quote
David Reeve wrote:
>It sounds like you have everything right but the name of the routine.
>Have a look with QuickView and I reckon you'll find its called
>_boring@7cfr() or some such gibbereish. If you have compiled in
>C++ without the name mangling disabled, then I would guess thats
>the root of your problem.

YEESSSS.... a result at last!
Quick View did indeed show the routine as @times2$qi (instead of
times2), and Delphi obviously wouldn't let me use that name. I couldn't
find the relevant switch in the Borland C++ 4.5 IDE to disable mangling,
but I managed to get hold of the function in two separate ways - by
specifying the index, and by using the 'name' directive in the
'external' declaration.

A further hurdle was a spectacular crash when it did eventually run, but
I got round that by using the 'stdcall' qualifier (arrived at that by
trial and error - 'pascal' and 'cdecl' didn't work but 'stdcall' did).
My thirst for knowledge isn't such as to make me desperate to know
exactly why that's necessary yet.

Thanks very much for all the help. Now I just have to try and remember
what I was actually trying to do on Monday.....

Other Threads