The "This" pointer in a member function of a class is actually an 'invisible' first parameter passed to the function by the compiler. For example, when you write the function : void CDeleteMeDLLApp::Start2( unsigned long dwDummy1, unsigned long dwDummy2 ) The compiler actually generates this as if it was : void CDeleteMeDLLApp::Start2(CDeleteMsDllApp* this, unsigned long dwDummy1, unsigned long dwDummy2 ) The problem here is that inside the DLL you are saying that "start2" is a class member function (and therefore has this 'invisible' first parameter called "this"). However, in the App you are telling the compiler it is a normal 'C/C++' function (and therfore it does not have a "this"). When the compiler generated the call to "Start2" is does not add the "this" bexcause it is not aware that "Start2" is a class member (and even if it was aware, the compiler does not now the address of the class instance 'theApp' at this point - only the DLL knows that. So the compilter cannot pass the address even if it knew it should) To correct this you must resolve this inconsistent view of the function - either make it a member in both places, or a non member in both places. You have 3 choices : (a) Use non-member functions in the dll, rather than class members; (b) Make the member functions 'static', so they do not have a 'this' pointer; (c) export the class from the DLL, rather than the individual member functions. When I do this, I often export a function that returns a pointer to the class, like this : In the Dll : CDeleteMeApp* declspec( dellexport) getClass() { return &theApp; } In the app : typedef CDeleteMeDll* (CALLBACK* GETCLASS)(); GETCLASS getClass; HLIB lib = LoadLibrary("deleteMeDll"); getClass = (GETCLASS)GetProcAddress("getClass"); CDeleteMeDLL* theClass = getClass(); theClass->Start(pWnd); theClass->Start2(1, 2); You need to rework you interface between the DLL and the App - either make it 'c-style', and export 'normal' functions (you can of course make these exported functions into 'wrapper' functions that simply call the appropriate class member function !), or make it 'C++ style', and export the class, not the member functions. Either way, the bottom line is to avoid exporting class member functions!! The root of this is that DLLs were invented before C++ was in widespread use, and therefore the DLL architecture has no knowledge of the concept of 'class' - DLLs were designed to hold code (functions) and data as separate elements, not classes (a hybrid mix
