[Zlib-devel] zlib 1.2.5

[Török Edwin]

On 05/25/2010 09:19 PM, Rolf Kalbermatter wrote:
> "John Bowler" <jbowler at frontiernet.net> wrote:
>> From: Cosmin Truta
>>> That one won't work. It's ABI-incompatible, mainly because it uses a 
>>> different, non-default calling convention (stdcall).
>>
>> IRC MS seem to have fixed this - linking something with "C" calls to a DLL
> that provides
>> "WINAPI" entries seemed to work. I didn't investigate in detail but it
> seemed likely that
>> the linker was inserting a compatibility layer.
> 
> To my knowledge such an automatic translation layer between cdecl callers
> and stdcall library
> doesn't exist. If you use the import library that was created together with
> the DLL you won't
> see any problems of course but if you link to a cdecl import library but
> have a stdcall shared
> library things do go bad.
> And I don't see any use in such a translation layer. If someone has this
> problem he messed up
> Somewhere and should fix that instead of MS doing such a useless behind the
> scene patch up.
> 
> Also there is no 100% reliable way to detect if an API is stdcall or cdecl
> since the @stack
> name decoration does not need to be present for stdcall exports if one
> chooses so when
> creating the DLL. And going to analyze the assembly code of the export by
> such an automatic
> translator would be an even worse idea. 

How about a simple test EXE program for the official zlib DLL?
It would load the DLL, and do some simple things like call APIs
(including the gz APIs).
If you built the DLL wrong / linked to the wrong CRT it will
crash/report wrong results.

Best regards,
--Edwin