TGCD DLL for Visual Basic (CDECL vs. STDCALL)

What follows is an explanation of why the zlib library uses the CDECL calling convention as opposed to the STDCALL convention (copied from the zlib DLL_FAQ). The explanation applies to the TGCD DLL as well.

6. I see that the ZLIB1.DLL functions use the "C" (CDECL) calling
convention.  Why not use the STDCALL convention?
STDCALL is the standard convention in Win32, and I need it in
my Visual Basic project!

(For readability, we use CDECL to refer to the convention
 triggered by the "__cdecl" keyword, STDCALL to refer to
 the convention triggered by "__stdcall", and FASTCALL to
 refer to the convention triggered by "__fastcall".)

Most of the native Windows API functions (without varargs) use
indeed the WINAPI convention (which translates to STDCALL in
Win32), but the standard C functions use CDECL.  If a user
application is intrinsically tied to the Windows API (e.g.
it calls native Windows API functions such as CreateFile()),
sometimes it makes sense to decorate its own functions with
WINAPI.  But if ANSI C or POSIX portability is a goal (e.g.
it calls standard C functions such as fopen()), it is not a
sound decision to request the inclusion of <windows.h>, or to
use non-ANSI constructs, for the sole purpose to make the user
functions STDCALL-able.

The functionality offered by zlib is not in the category of
"Windows functionality", but is more like "C functionality".

Technically, STDCALL is not bad; in fact, it is slightly
faster than CDECL, and it works with variable-argument
functions, just like CDECL.  It is unfortunate that, in spite
of using STDCALL in the Windows API, it is not the default
convention used by the C compilers that run under Windows.
The roots of the problem reside deep inside the unsafety of
the K&R-style function prototypes, where the argument types
are not specified; but that is another story for another day.

The remaining fact is that CDECL is the default convention.
Even if an explicit convention is hard-coded into the function
prototypes inside C headers, problems may appear.  The
necessity to expose the convention in users' callbacks is one
of these problems.

The calling convention issues are also important when using
zlib in other programming languages.  Some of them, like Ada
(GNAT) and Fortran (GNU G77), have C bindings implemented
initially on Unix, and relying on the C calling convention.
On the other hand, the pre- .NET versions of Microsoft Visual
Basic require STDCALL, while Borland Delphi prefers, although
it does not require, FASTCALL.

In fairness to all possible uses of zlib outside the C
programming language, we choose the default "C" convention.
Anyone interested in different bindings or conventions is
encouraged to maintain specialized projects.  The "contrib/"
directory from the zlib distribution already holds a couple
of foreign bindings, such as Ada, C++, and Delphi.

With all that said, it is possible to write a very thin wrapper around the CDECL DLL that exposes a STDCALL convention instead. At least one NeuroSky customer has already done so.