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.

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

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.

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?

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

Stephen Posey
slpo...@concentric.net

Yes, I've tried that as well.

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....

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

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)

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

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

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.....