Re: linking problem in DPAPI

[Stephen Leake <stephen_leake@acm.org>]

"bubble" <bubble@riskm.com.tw> writes:

> <copy from 
> http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html>
>
> direct linking to a dll
> The cygwin/mingw ports of ld support the direct linking, including data 
> symbols, to a dll without the usage of any import libraries. 

Interesting. 

> after some error.
> I have a solution.
>
> I copy crypt32.dll from c:\windows\system32 to project home.
> and change pragma  (not use Stdcall Calling Convention ).
> pragma Import (C, CryptProtectData, "CryptProtectData");
> then it work..

As you discover below, "linking" is not the same as "working".

> I have new question..
> in windows SDK document ,the WINAPI declare should mapping to Stdcall.
> It's mean who's responsibility to clean stack frame.
> http://www.unixwiz.net/techtips/win32-callconv.html
> if I use "C" calling conventions in a "WINAPI" funciton , colud system clean 
> stack twice and cause some problems?

Yes, you will eventually get a stack error; either overflow or underflow.

The problem is that the 'Convention' parameter in 'pragma Import'
speficies two things; the 'calling convention' (who pops the stack),
and the 'naming convention' (how the name is mangled in the DLL).

Microsoft has two naming conventions for the StdCall calling
convention; the 'old' one (pre Windows NT) that appends '@nn' where
'nn' is the number of bytes on the stack, and the 'new' one without
the @nn.

Ada has no way to distinguish between the two. A while ago (May 2004)
I had a similar problem, and tried to get AdaCore to provide a
Convention identifier for the 'new' StdCall naming convention; they
didn't believe it was necessary.

On the other hand, the "Link_Name" parameter to 'pragma Import' should
allow you to specify the correct name. In 2004 (GNAT 3.15?) the
compiler added '@nn' even to the Link_Name; AdaCore promised to fix
that.

So you should try using:

    pragma Import (StdCall, CryptProtectData, 
         External_Name => "CryptProtectData", 
         Link_Name => "CryptProtectData");

If that doesn't work, you'll have to build an import library that uses
the StdCall calling convention with the new naming convention. That is
done via the following steps (as recommended by AdaCore):

dll2def crypt32.dll > crypt32.def

_manually_ edit cyrpt32.def to add the appropriate @nn. 
(this step is just ridiculous, but it is required by the GNAT tools).

gnatdll -k -e cryp32.def -d crypt32.dll

The -k strips the @nn that you so laboriously added in the previous
step. Hmm. I guess that means the 'nn' in the .def doesn't have to be
correct; it just has to be there.

Hmm. I've just re-read the GNAT user's guide for 5.03a. It says GNAT
can use the .lib library files (Microsoft format). It also gives the
procedure I outlined above. 

However, my GNAT distribution doesn't contain dll2def. I found a
version (via Google) at
http://users.ncrvnet.nl/gmvdijk/packages.html#DLL2DEF
Hmm. That has source code; maybe we could fix it to add an option to
add the @nn.

In any case, send a bug report to AdaCore. Let them know how hard it
is to use their tools to do what should be a simple task. Maybe
they'll fix it eventually! Mention my bug report D525-020; that will
let them know it's not an isolated case.

Also ask how they build libcrypt32.a; I can't believe they manually
edit a .def file!

-- 
-- Stephe