Redistributable compiler - DLLs for MS Visual Studio

Question

I'm making a programming learning game for my senior project and I'm looking for a compiler that can compile a DLL that can then be dynamically loaded into a Visual Studio 2008 C++ application.

The important idea here is that the compiler is redistributable. If VS was redistributable I'd be using that.

So far I'm had some success using MinGW, but that success is limited. Currently I'm only able to get one DLL loaded and working at a time. The moment I try to load a second one the VS C++ app crashes with a Access Violation error.

I've been able to load two DLLs compiled in VS itself without problem so it leads me to believe that it's something specific to MinGW, it's DLL's, and how they interact with LoadLibrary() and whatnot.

I've been working at this problem for quite some time and I'm frusterated. If anyone knows of a different compiler that you know would work instead of MinGW, or if you'd seen this problem perhaps you know why the second DLL crashes it. I'm sure it's related to each DLL stepping on the other in some way but I have no idea what that would be or how to find out.

It could be the way I'm compiling the DLL or how I'm loading it; I have no idea.

I would really appreciate the feedback, thanks!

Edit: These are the simple calls to g++ and dlltool for creating the DLL http://pastebin.com/f675df4b0

This is the source from one of my DLLs. http://pastebin.com/f5c062611

This is the code in my C++ app for loading the DLL. http://pastebin.com/f52f94a18

-Michael

Answer 1

Would just using Visual Studio Express be good enough? The compiler is freely downloadable and it will save you a lot of pain trying to get the DLLs to be compatible.

I don't know how strict your requirements are, but odds are that if you check the licensing info on the Visual Studio Express it will be loose enough for your project.

Answer 2

You are returning 0 from DllMain. According to the specifications you should return TRUE unless something goes wrong. However I can't see why this should give different behavior on MSVC or MinGW. It also says that LoadLibrary should return 0 if DllMain returns FALSE so this may not be the actual explanation.

Does DllMain actually get called in both the MSVC and the MinGW version, does something happen if you remove the comment on the messagebox call in it?

For more info on DllMain, check out http://msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx

Another thing that may be of interest if you actually call the AiFunction from the first dll before loading the second. If you do, can you try loading both dll's without calling any dll function inbetween and see if it works better?

My suspicion is that MinGW and MSVC packs the Input or Output structs differently and that somehow this size mismatch causes the some memory to be corrupted when you call AiFunction. You can sanity check this by comparing sizeof() results for Output and Input inside and outside the dll and see if it matches. This doesn't guarantee that it is correct, but if it doesn't match you can be pretty sure something is going to go wrong.

Finally I'm worried that returning Output can potentially be a problem in the long term if you start introducing virtual calls and such things since that may not be implemented in exactly the same way inside MSVC and MinGW. If you keep it without virtual functions and such things it should be fine as long as the structure packing matches.