From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8dd1b8da682c35ae X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news4.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!news2.wam.umd.edu!nntp.abs.net!news.abs.net!not-for-mail Newsgroups: comp.lang.ada Subject: Re: linking problem in DPAPI References: From: Stephen Leake Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:mk3sv8PZi7U/zpl69FniW274wd8= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 Dec 2005 07:56:27 -0500 NNTP-Posting-Host: 66.159.65.1 X-Complaints-To: abuse@toad.net X-Trace: news.abs.net 1136033789 66.159.65.1 (Sat, 31 Dec 2005 07:56:29 EST) NNTP-Posting-Date: Sat, 31 Dec 2005 07:56:29 EST Xref: g2news1.google.com comp.lang.ada:2404 Date: 2005-12-31T07:56:27-05:00 List-Id: "bubble" writes: > 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