GNAT and a very foreign DLL

GNAT and a very foreign DLL

[Alexandre E. Kopilovitch]

  A winter evening, GNAT 3.13p on Windows, and some apparently exotic foreign
DLL, which was written in C or C++ and now should be called from an Ada program.
  The problem appears to be with the combination of the call convention and
the names of the DLL's entry points: the call convention is surely Stdcall,
but the entry point names do not contain usual suffixes "@nn" - they look as
common C identifiers.
  I looked into GNAT docs, and saw that although the review of the call conventions
and the entry point naming strategies is quite comprehensive, not all possible
combinations are supported with the pragmas. In particular, it seems that the
combination of the Stdcall convention and the entry point name without "@nn"
isn't supported - nether External_Name nor Link_Name nor other (linker's)
options can help.
  As the Stdcall convention is unavoidable anyway, I was forced to create some
"post-linker", which post-processes my executable, replacing "@" in the DLL's
entry point names by zero bytes. After that post-processing all works fine,
but I surely don't want to distribute such a "technology".
  So my question is: did I missing something in GNAT docs? Is there some
regular way to specify within an Ada program _any_ name for a DLL's entry
point, regardless of a call convention?

  By the way, the DLL in the case has an additional strange feature: the *.lib
for it, which is built with the Microsoft tool (according to the instructions
in the GNAT docs) doesn't work (linker doesn't resolve the external references
to the DLL's entry points). But the lib*.a created with the gnatdll using the
same *.def file works fine.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: GNAT and a very foreign DLL

[Ted Dennison]

In article <mailman.1010181542.30574.comp.lang.ada@ada.eu.org>, Alexandre E.
Kopilovitch says...
>  The problem appears to be with the combination of the call convention and
>the names of the DLL's entry points: the call convention is surely Stdcall,
>but the entry point names do not contain usual suffixes "@nn" - they look as
>common C identifiers.
..
>  As the Stdcall convention is unavoidable anyway, I was forced to create some
>"post-linker", which post-processes my executable, replacing "@" in the DLL's
>entry point names by zero bytes. After that post-processing all works fine,

If the problem is just the name, why don't you just use the "Link_Name"
parameter to "pragm Import" to specify the name they actually used?

However, you may want to check the C header files for that routine to make sure
the calling convention is what you think it is. I have seen DLL's with routines
with different conventions in them before.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: GNAT and a very foreign DLL

[Alexandre E. Kopilovitch]

Ted Dennison<dennison@telepath.com> wrote:
>>  The problem appears to be with the combination of the call convention and
>>the names of the DLL's entry points: the call convention is surely Stdcall,
>>but the entry point names do not contain usual suffixes "@nn" - they look as
>>common C identifiers.
>..
>>  As the Stdcall convention is unavoidable anyway, I was forced to create some
>>"post-linker", which post-processes my executable, replacing "@" in the DLL's
>>entry point names by zero bytes. After that post-processing all works fine,
>
>If the problem is just the name, why don't you just use the "Link_Name"
>parameter to "pragm Import" to specify the name they actually used?

Because with that Link_Name the suffix "@nn" is still appended. As the GNAT
User's Guide honestly says (at the end of Microsoft Windows Topics/Windows
Calling Conventions/Stdcall Calling Convention section):
"... there is no trailing underscore but the appropriate @nn is always added
at the end of the Link_Name by the compiler. "

>However, you may want to check the C header files for that routine to make sure
>the calling convention is what you think it is. I have seen DLL's with routines
>with different conventions in them before.
I checked that, and there are the Stdcall directives indeed. And moreover, all
that stuff works properly with the Stdcall calls.


Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: GNAT and a very foreign DLL

[Ted Dennison]

In article <mailman.1010276762.30835.comp.lang.ada@ada.eu.org>, Alexandre E.
Kopilovitch says...
>Because with that Link_Name the suffix "@nn" is still appended. As the GNAT
>User's Guide honestly says (at the end of Microsoft Windows Topics/Windows
>Calling Conventions/Stdcall Calling Convention section):
>"... there is no trailing underscore but the appropriate @nn is always added
>at the end of the Link_Name by the compiler. "

Yuck. I can see where they'd want to make it work this way, so that things are
easier on the average Windoze developer. But it really hoses you now when you
need that parameter to do exactly what it was put in the spec for.

OTOH, If you feed "External_Name" the exact same name and convention that the C
header file uses, then you ought to be receiving the same thing that the C
header file receives. I don't understand why that isn't working for you,
assuming you are linking in the same library files.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.