Calling Conventions to "Foreign" DLL Calls

Post by a***@aol.com
I am using "foreign" DLLs (written by someone else) and there is no
calling convention recommendation, although the "help" files recommend
the use of C++.
Is there any sure-fire way of establishing the correct calling
convention to use in Delphi calls to the DLL. For one DLL in a simple
use I get AVs with cdecl but none with stdcall (I have not tried
safecall). Are "suction & vision" methods the only way to go, or is
there something better ?
I have three DLLs all written by a major company who knows nothing
except VBasic or C++.

Short of reading the disassembly, there's no way of knowing if they
don't tell you.

Yes, it's stupid.

Groetjes,
Maarten Wiltink

Rudy Velthuis

2010-11-19 21:17:13 UTC

Post by Maarten Wiltink
Short of reading the disassembly, there's no way of knowing if they
don't tell you.

They more or less do. The name mangling differs.

--
Rudy Velthuis http://rvelthuis.de

"The way to find what the mainstream will do tomorrow is to
associate with the lunatic fringe today."
-- Jean-Louis Gassee

Ali Svensson

2010-11-18 23:22:18 UTC

Post by a***@aol.com
I have three DLLs all written by a major company who knows nothing
except VBasic or C++.

Then they sure have some methods how they call those functions from VB.
And VB is kind of a dummy step brother to us.

So, what interfaces do those Chinese++ folks have to offer for our
brother? -as

a***@aol.com

2010-11-19 07:41:18 UTC

Post by Ali Svensson
So, what interfaces do those Chinese++ folks have to offer for our
brother?

They provide a '.h file which includes a declaration of 'extern "C"'.
Does this imply a 'cdecl' ? But suction & vision tests require it to
be 'stdcall'.

Alan Lloyd

Maarten Wiltink

2010-11-19 08:35:14 UTC

Post by a***@aol.com
They provide a '.h file which includes a declaration of 'extern "C"'.
Does this imply a 'cdecl' ?

No, it implies names aren't mangled/decorated to indicate function
prototypes, but are simply left as-is. It says nothing whatsoever
about calling convention.

Post by a***@aol.com
But suction & vision tests require it to be 'stdcall'.

That is the industry standard. With all the arbitrariness and lack
of dependability implied in those words.

It's _not_ the default, though. Something in that header file should
be specifying it.

Groetjes,
Maarten Wiltink

Ali Svensson

2010-11-19 10:10:07 UTC

Post by a***@aol.com
They provide a '.h file which includes a declaration of 'extern "C"'.

When you have that Header file it usually lists all the exported
functions. Then the DLL is no more completely "foreign". Your problem
more or less may just be a plain Header Conversion problem, how to get
that Chinese++ header converted to a .pas Unit.

I have been succesful in about 70% of the cases when I have tried to
convert some C headers earlier.

Then the rest 30% of them... Even if the .h file size is only something
like 40 kB, the automated Delphi and Lazarus converting tools fail right
at the beginning, creating total uncompilable garbage. And with my
Chinese knowledge the rest of it will not get converted, no chance.
Good luck. -as

Hans-Peter Diettrich

2010-11-19 10:27:03 UTC

Post by a***@aol.com
They provide a '.h file which includes a declaration of 'extern "C"'.

The calling convention often is hidden in a macro, like _DLLFUNC...

Check the header file for such macros in the function declarations.

DoDi

a***@aol.com

2010-11-19 14:08:19 UTC

Post by a***@aol.com
They provide a '.h file which includes a declaration of 'extern "C"'.

The calling convention often is hidden in a macro, like _DLLFUNC...
Check the header file for such macros in the function declarations.

I have three DLLs, call them H, U & C, the H is for a later product
than the others - the entries which are not constant integers in
the .h files are :

// H - found to be stdcall
#ifndef _FOOTSWITCHAPI_H_INC_
#define _FOOTSWITCHAPI_H_INC_

// S - found to be cdecl
#ifndef __DSSFSUSR_H__
#define __DSSFSUSR_H__

// U - found to be cdecl
#ifndef __DSSUSBFUSR__
#define __DSSUSBFUSR__

#ifdef __cplusplus
extern "C" {
#endif
#define FSWUSB_WDM

By "found to be" means that the convention I quote did not cause an
AV.

Anything meaningful ?

Alan Lloyd

Hans-Peter Diettrich

2010-11-19 16:53:04 UTC

Post by a***@aol.com
They provide a '.h file which includes a declaration of 'extern "C"'.

The calling convention often is hidden in a macro, like _DLLFUNC...
Check the header file for such macros in the function declarations.

I have three DLLs, call them H, U & C, the H is for a later product
than the others - the entries which are not constant integers in

[...]

Sorry, you didn't post any function declaration.

DoDi

a***@aol.com

2010-11-19 17:12:48 UTC

Post by a***@aol.com
They provide a '.h file which includes a declaration of 'extern "C"'.

The calling convention often is hidden in a macro, like _DLLFUNC...
Check the header file for such macros in the function declarations.

I have three DLLs, call them H, U & C, the H is for a later product
than the others - the entries which are not constant integers in

[...]
Sorry, you didn't post any function declaration.

I have no problems with the C > Delphi function declaration
translations, they are typically...

DWORD
OpenUSBFootSW(
HWND hWhandle,
DWORD qNumber);

... in the .h file, Which I translate typically as ...

OpenUSBFootSW_dll : function(hWhandle : HWND; qNumber : DWord) :
DWord safecall{or cdecl or stdcall};

There are no other elements of the function definitions in the .h file
which could possibly be calling convention modifiers. The DLL
_functions_ appear to work OK, they just leave AVs behind after
returning, when I use what is apparently the wrong calling convention
keyword.

I am loath to post much more text verbatim from the .h file because of
commercial confidentiality.

Doing further tests it seems the safecall keyword produces more stable
returns from the DLL. Would there be any oddities in using that (which
I understand is usually used & required for interfaces but not used
otherwise). The DLLs do not use interfaces.

Thanks for all the comments.

Alan Lloyd

Hans-Peter Diettrich

2010-11-20 03:48:53 UTC

Post by Hans-Peter Diettrich
Sorry, you didn't post any function declaration.

I have no problems with the C > Delphi function declaration
translations, they are typically...
DWORD
OpenUSBFootSW(
HWND hWhandle,
DWORD qNumber);

Okay, then there exist no further modifiers, that might affect the
calling convention. This IMO is a flaw, introduced by people that are
not aware of the existence of multiple compilers, which have their own
definitions for the default calling convention :-(

Post by a***@aol.com
.... in the .h file, Which I translate typically as ...
DWord safecall{or cdecl or stdcall};

When the default calling convention is specific to the compiler, one of
the above choices should apply to *all* functions. Your OP indicates
that it should be stdcall. Safecall is a COM/ActiveX thing, but may be
used in VB code as well. IMO a lot depends on the tool (or coder), that
provided the header files...

Post by a***@aol.com
I am loath to post much more text verbatim from the .h file because of
commercial confidentiality.

The above example says it all :-(

DoDi

Rudy Velthuis

2010-11-19 21:19:23 UTC

Post by Ali Svensson
So, what interfaces do those Chinese++ folks have to offer for our
brother?

They provide a '.h file which includes a declaration of 'extern "C"'.
Does this imply a 'cdecl' ?

No. It only means that the names are not mangled according to their C++
name mangling rules, but are simply exported as the names given,
possibly with an underscore as prefix (probably cdecl), or an @xx as
postfix (probably stdcall).

--
Rudy Velthuis http://rvelthuis.de

"Room service? Send up a larger room."
-- Groucho Marx

Rudy Velthuis

2010-11-19 21:15:31 UTC

Take a look at the mangling of names. It may give you a hint about the
calling convention.

http://cplus.about.com/od/introductiontoprogramming/a/conventions_2.htm

Otherwise, try the trick I mention in:

http://rvelthuis.de/articles/articles-convert.html#cconvs

But I would just try cdecl and see if that works. If it fails, I'd try
stdcall. You may get a crash when trying, but hey, that is what
programmers do. <g>

FWIW, if some of the functions are in fact methods, you may have to
mimic __thiscall
(http://msdn.microsoft.com/en-us/library/ek8tkfbw%28VS.80%29.aspx)
using built-in assembler.

--
Rudy Velthuis http://rvelthuis.de

"But in our enthusiasm, we could not resist a radical overhaul
of the system, in which all of its major weaknesses have been
exposed, analyzed, and replaced with new weaknesses."
-- Bruce Leverett, Register Allocation in Optimizing Compilers

Rudy Velthuis

2010-11-19 21:20:55 UTC