[Zlib-devel] RE: [png-implement] Binary-incompatible change in the DLL interface of zlib

[Cosmin Truta]

On Mon, 28 Jul 2003, John Bowler wrote:

> __stdcall is, I believe, the Pascal calling convention.  Arguments are
> pushed in the order they occur in the source, therefore the last is at the
> top of the stack.  It's the natural way to do it but it doesn't work with C.
> Why would the author of a Pascal compiler care about this, everyone should
> be writing in Pascal...

No.

WINAPI was __pascal in WIN16, and it is __stdcall in WIN32, but __pascal
and __stdcall are different. __stdcall has the same (inverse) argument
order like __cdecl, but it cleans the stack like __pascal. Still,
__stdcall is not capable of handling vararg functions.

I think __pascal is not supported by the Microsoft compilers, but only
by the Borland compilers nowadays.

Why in the world did we need __stdcall besides __pascal, I have no clue.

__fastcall is the fastest, but that has its own quirks.


> The primary advantage of using __stdcall now that it is possible with ANSI-C
> is that the functions are *natively* callable from other languages.
> __stdcall C just looks like a Modula-3, or Pascal, or whatever function.
> Otherwise either a specific *non-standard* declaration is required or a
> wrapper function (as in the VB case.)

__stdcall is not ANSI-C, but it is an extension. An ANSI-compliant
compiler that does not allow non-standard extensions will reject it.

Different calling conventions exist only under DOS and Windows. In Unix,
it's CDECL all the way. Even when Delphi was ported to Kylix under
Linux, the calling convention keywords lost their meaning, and they are
just blank placeholders with no effect. Everyone uses CDECL.

Also, there is no particular reason to use __stdcall from foreign
programming languages. VB and JNI/Java use __stdcall (but it's a whole
different business with JNI), Delphi (in Windows) uses __fastcall,
Fortran and Ada use __cdecl. The old Fortran and Turbo Pascal under DOS
used to use __pascal, but there was no __stdcall in DOS. Want some more?
Oh, C++ uses __cdecl.


> That said, it doesn't matter very much - just so long as the C header file
> *always* decorates the function declarations with the procedure call
> standard!  Even a mixed __cdecl for static lib and __stdcall for DLL would
> work fine - the (C) application writers would just have to remember to
> define ZLIB_DLL or not according to what they linked with.  The error
> happens at build (link) time and is an obvious set of missing symbols.

__cdecl and __stdcall work fine only when the function does not have
arguments. Otherwise, there are crashes, caused by inconsistent stack
cleanup (callee in CDECL, caller in STDCALL).

Mixing __cdecl with __stdcall can be done by circumventing or otherwise
avoiding the internal name mangling, but that would mean replacing
link-time errors with run-time errors.


__stdcall doesn't work with varargs, it is not part of the C standard,
it is only used in Windows (not in Linux, BSD or whatever). The only
reason I see is that it is demanded in the older Visual Basic, but this
sole reason is something that I already knew.