Bug with AGS plugin API on MinGW

[void]

Hi fellow AGS users,

today I discovered a possible bug in the AGS api interface. When using MinGW (32 bit) together with the new C++11 standard, something's wrong with managed objects. As soon as one instance should be deleted it's corresponding Dispose() method is invoked. However, the instance address it passes always refers to zero, no matter what.

I tested this multiple times using different approaches and everytime it failed. I also tested the string array plugin on google code (http://code.google.com/p/ags-plugin-stringarray) with bad results.

Is this a known problem? I haven't been able to find any information about it (or the Managed object interface in general). I cannot guarantee that it has something to do with C++11, it is just the only setting in my project that might be slightly deviating.

[Wyz]

Do you have any prior success using MinGW compiled plugins in AGS that also use managed objects? There are some serious issues when using MinGW or any other compiler then MSVCPP.

The plugin interface passes pointers to objects that have virtual members and them uses them; that is something that is very likely to break when the plugin and the host application were not compiled with the same compiler. This is because the way the vtable is implemented may differ among compilers. The best way to solve it is to compile with MSVCPP. I installed it just for compiling AGS plugins and it has since been burning a 8GB big hole in my hard-drive

Something to keep in mind in case the plugin API is redesigned in the future. For now I can only point you to this solution if you're using managed objects in your plugins. If you only have functions in your plugins using MinGW should be fine.

[void]

Ah, i see. Of course it is because of the virtual interface. I was so into gcc recently that I totally forgot about such things. Thank you very much for pointing me towards the right direction, wyz!

[Wyz]

I've been looking into this issue again yesterday and have interesting results.
Apparently it was not the vtable that caused the problem but the difference in calling conventions among MSVS and MinGW (MSVCPP puts the this pointer in the registry while GCC puts it on the stack; more info here). I was already trying an assembly hack but no need for that since I just found out that starting from version 4.7 MinGW now uses MS' calling convention! I tried it and it works!!

We can now also build plugins with MinGW.