Hello,

I have found something in a online assambler book available for download from http://www.drpaulcarter.com/pcasm/index.php. On page 167 of the pdf version I found this:

"The attentive reader will be wondering why the class methods in Figure 7.14 are explicitly declared to use the C calling convention by using the _cdecl keyword. By default, Microsoft uses a different calling convention for C++ class methods than the standard C convention. It passes the pointer to the object acted on by the method in the ECX register instead of using the stack. The stack is still used for the other explicit parameters of the method. The _cdecl modifier tells it to use the standard C calling convention. Borland C++ uses the C calling convention by default."

Maybe the problem would be solved if all functions of the bot class and all functions used by the bot class are declared with _cdecl on dll and exe side.

quote: Original post by Anonymous Poster
Hello,

I have found something in a online assambler book available for download from http://www.drpaulcarter.com/pcasm/index.php. On page 167 of the pdf version I found this:

"The attentive reader will be wondering why the class methods in Figure 7.14 are explicitly declared to use the C calling convention by using the _cdecl keyword. By default, Microsoft uses a different calling convention for C++ class methods than the standard C convention. It passes the pointer to the object acted on by the method in the ECX register instead of using the stack. The stack is still used for the other explicit parameters of the method. The _cdecl modifier tells it to use the standard C calling convention. Borland C++ uses the C calling convention by default."

Maybe the problem would be solved if all functions of the bot class and all functions used by the bot class are declared with _cdecl on dll and exe side.

I can try that out.

I assume the minor 0.2 update fixes this problem with other compilers???

Tanx to the compiler-god, it doest :D