Re: linking problem in DPAPI

[Stephen Leake <stephen_leake@acm.org>]

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

>> 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..
>
> I can invoke the CryptProtectData,CryptUnprotectData and get a output.
> then it will crash after executing some statement.

Right; that's typcial of stack corruption.

> and I have test
>     pragma Import (Stdcall, CryptProtectData, 
> "CryptProtectData","CryptProtectData");
> and still fail in linking.

Ah, too bad. Please send a bug report to 'report@gnat.com'.

> crypt functions loading by loadLibrary and GetProcAddress have some strange 
> behaviors ,I am still in testing.

Ok. You _really_ should not have to do that!

> a document from MS has explain calling convention more.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_Calling_Conventions_Topics.asp

Interesting. They don't document the "stripped" naming convention,
even though all the current DLLs use it.

Still, that's typical of Microsoft; the documentation is very poor.

> I don't the understand the reason why MS need 2 different " STDCALL
> " calling convention. (maybe MS's programers confused or they using
> special naked function call in security issuse)

With current tools, the "@nn" notation serves no purpose. I suspect
someone got tired of having to put them in by hand, and invented a new
convention that doesn't have them.

> If MS really want 2 stdcall, they should be name stdcall and
> stdcall2 or something. 

Yes. The fact that they have _not_ clearly documented the current
convention makes it harder to get the Ada compiler companies to suppor
it. 

> the problem should forward to MS news group. It's not ada compiler
> or linker problem... :(

Well, to the extent that we have to make our tools work with it, it
_is_ an Ada compiler problem.

A separate problem is getting MS to document what they are doing.

> if therer is no way to remove @xxx in function suffix,
> may be I can add "esp register adjust" patch code after  calling crypt 
> family functions.   :(

I doubt that will work.

Clearly there _is_ a way to produce the right library; AdaCore does it
for each release of GNAT.

The only way I'm aware of at the moment involves manually editing the
.def file produced by dll2def. But I'm pretty sure you don't need to
get the "nn" _correct_, since it will be stripped out by gnatdll
anyway. So just use an editor macro (or 'sed' script) to add @4 to
each function name; that should not be hard.

-- 
-- Stephe