I believe the idea behind SQLITE_STDCALL and SQLITE_CDECL is that those macro's can be defined to how the specific compiler annotates those calling conventions, and then those define's in turn may be used in by the SQLITE_APICALL, SQLITE_CALLBACK, etc., defines. The whole point being to allow the complete definition of non-standard calling sequences as might be used by some Operating Systems (such as Windows) that use the Pascal calling sequence rather than the default cdecl calling sequences. If you do not use --apicall when running mksqlite3c.tcl and mksqlite3h.tcl then the sqlite3.c and sqlite3.h files are output with minimal annotations designed for use where you **do not** need to override the default calling conventions used by the compiler. Using --apicall when running mksqlite3c.tcl and mksqlite3h.tcl however litters the generated code with these classifiers so that you can, if you choose to do so, cohesively control the calling conventions used in the generation of the object and load modules -- so for example you can make the sqlite3 module use Windows calling conventions and look just like any old standard Windows API (which would presumably also allow you to create 32 to 64 bit trampolines if you chose to do so to allow "sqlite3" to be a "system component".)