DLL Calling conventions:
DLL functions have several calling conventions, with the two most common being <CODE lang=mc++>__cdecl and <CODE lang=mc++>__stdcall. Most Windows API functions are written with the <CODE lang=mc++>__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 <CODE lang=mc++>__stdcall calling convention is usually the most appropriate.
Calling DLLs dynamically in VB:
In VB, loading a DLL requires the use of a <CODE lang=mc++>__stdcall calling convention DLL function.
Calling DLLs dynamically in C++:
In C++, both calling conventions of <CODE lang=mc++>__stdcall and <CODE lang=mc++>__cdecl can be used (but not interchanged!). When prototyping the DLL function, <CODE lang=mc++>__cdecl is assumed and need not be explicitly typed into the <CODE lang=mc++>typedef statement. However, when dynamically calling a <CODE lang=mc++>__stdcall DLL function, it must be explicitly written into the <CODE lang=mc++>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 <CODE lang=mc++>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 <CODE lang=mc++>__stdcall for VB portability, and declared default in C++, thus <CODE lang=mc++>__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 <CODE lang=mc++>__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.