DLL Calling conventions:
DLL functions have several calling conventions, with the two most common being __cdecl and __stdcall. Most Windows API functions are written with the __stdcall declaration, and it is the most commonly used in DLLs. These two declarations are very different, and though they can be interchanged in the calling routine in C++, doing so will wreak havoc on the program, creating serious memory leaks! The actual difference in these calling conventions is not really as important as making sure to not get them mixed up. One thing to remember: when using DLLs written in one language, and using them in another, the __stdcall calling convention is usually the most appropriate.
Calling DLLs dynamically in VB:
In VB, loading a DLL requires the use of a __stdcall calling convention DLL function.
Calling DLLs dynamically in C++:
In C++, both calling conventions of __stdcall and __cdecl can be used (but not interchanged!). When prototyping the DLL function, __cdecl is assumed and need not be explicitly typed into the typedef statement. However, when dynamically calling a __stdcall DLL function, it must be explicitly written into the typedef statement. There was some confusion on this, because the statically loaded Windows API functions do not require this anywhere when calling the DLL functions. However, this is because the typedefs already exist in the system-level files of the compiler.
If anyone has questions on this, don't hesitate to ask. As simple as this looks, I racked my brain trying to figure out why, when I was dynamically calling the DLL functions (which were written as __stdcall for VB portability, and declared default in C++, thus __cdecl), my program would run fine until sometime after the DLL call. At that point, all hell broke loose, with no warning. When I would recompile the DLLs using the __cdecl calling convention, everything was just fine. Now I know, and thought I'd save you all some grief at some point down the road, if you should also run into this.
