Summary: GNAT and a very foreign DLL

Summary: GNAT and a very foreign DLL

[Alexandre E. Kopilovitch]

Several days ago I asked in this newsgroup for a help with building an import
library for some specific DLL. My statement of the problem was the following:

-----
  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.
[skip]
  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?
-----

  After that, Craig Carey wrote me (private message) about the gnatdll -k switch
(and the dlltool --kill-at switch). That solved the problem completely.
  Then I looked into "Using gnatdll" section of GNAT User's Guide and found
there a comprehensive description of those switches (including their purpose).
So, another question arises: why I failed to find that piece of documentation
when I needed it? The probable answer is that I was diverted from a further
search by the phrase at the end of the "Stdcall Calling Convention" section:
"...@nn is always added at the end of the Link_Name by the compiler." I didn't
realize at that moment that the exported name and the DLL's entry point name
generally need not be the same, and that the tool that creates an import library
may take care of it. The term "Link_Name" somehow hypnotizes me, and I gave up.
I think that a reference to the gnatdll at that point of documentation would
save from such a mistake. Therefore I just sent to report@gnat.com the following
suggestion:

==============================================================================
I suggest a minor addition to the GNAT User's Guide. Taking the GNAT User's Guide
for GNAT 3.13p as a base, I think that it may be useful to add the following
paragraph at the end of Stdcall Calling Convention section (that is, after the
words "@nn is always added at the end of the Link_Name by the compiler.") .

--- cut here ---

Note, that in some special cases a DLL's entry point name lacks a trailing @nn.
while the exported name generated for a call has it. The gnatdll tool, which
creates the import library for the DLL, is able to handle those cases (see the
description of the switches in Using gnatdll section).

--- cut here ---
==============================================================================


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

Re: Summary: GNAT and a very foreign DLL

[Craig Carey]

On Wed,  9 Jan 2002 23:19:53 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@vib.usr.pu.ru> 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.

When linking in Windows NT DLLs the gnatdll -k option could be needed.

>[A] way to specify within an Ada program _any_ name for a DLL's entry
>point, regardless of a call convention?

The definition file can contain something like this:
EXPORTS
  <entry_name_for_linker>=<entry_name_of_DLL>
  abc@4=abc
  def=_def@4

That could be useful if another compiler is used.

>Therefore I just sent to report@gnat.com the 


-

Here is a question. (I did not see answers to these questions in the
GNAT 3.13p documents.)

How can GNAT DLLs that are called from Delphi, be debugged ?. Apart
from use of TCP sockets there can be 2 options including these

* Win32 OutputDebugString(string) can be used. What is a good way to
  capture those strings?. Something from the free Microsoft SDK or
  something else?. What software is used.

* DOS console Window and CreateProcess. (There is an example of a
  call to that Win32 routine in Mr Obry's Posix library. Has
  anybody got an example where the thread owning the MSDOS console of
  a DLL, is an Ada task?.


Craig Carey