GNAT and a very foreign DLL

["Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru>]

  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