I've been using VS 2003 C++ for quite some time and built an engine framework via plugin Dlls. This lets me exchange DX8, DX9 fixed function, DX9 shaders, OpenGL renderer without the main game noticing.
This worked very nice. I export one function returning an instance of the class. I did use non POD types in the exported classes methods. Since I have control over both Dll and main app I never had problems with that.

Now I've got Windows 7 and VS 2003 doesn't work cleanly anymore. I'm trying to move to VS 2008 but have real problems getting the framework to run as smooth as it did before. I had the automatic upgrade convert both projects (engine and game) to VS 2008 and I get crashes during startup. The crashes seem to be related to the interfaces not matching, but they should.

My question:
Does anyone have any experience with this scenario?
If I compile both engine and game Dlls with the same settings I should be able to use non POD types without problems as far as I know. Also mixing Debug and Release should not pose any problem (mixing that worked fine with VS 2003).

What's recommended? Rebuild the projects from scratch with VS 2008? Or try to refine all the interfaces to pure interfaces (which is frankly a lot of work and also adds a lot of unneeded conversions)?

No idea anyone? I'm still struggling as I get strange effects. With the debugger I get things like these:

[attachment=1115:debug-off.png]

Note the values of m_pVertexBuffer. They are the same variable. Any idea why the debugger shows the correct AND the wrong value?

Also mixing Debug and Release should not pose any problem (mixing that worked fine with VS 2003).

That totally depends. If you have dlls that link against different runtimes then those will maintain different heaps: You must call delete in the same dll you have called new to obtain that address (which is really annoying when you cannot control which runtime a 3rd party library uses). I would suggest not mixing different runtimes, unless you really know what you are doing. For example, templated containers will most likely cause problems when they're passed accross dll boundaries.



About solving your problem, you most likely need to find a test case that displays the same problem: Either by reducing the original code (doing a binary search through your code probably helps) or by rewriting a test from scratch until it crashes. For example, do you have that problem with every mesh instance? Does it happen sporadically? If the former is the case, then you could post your code: Maybe we can detect a problem.

Thanks for the feedback

Yeah, I'm aware of the heap part and always kept those two apart.

I've mostly solved the problem. I had interfaces that were not strict interfaces. The abstract interfaces derived from some base interfaces which had some code (with STL containers) in them. This seems to be the cause for getting messed up v-tables. I've now reduced the interfaces to pure interfaces which seems to have done the trick.
For reference, the interface being in the DLL is derived from three other interfaces. I now resorted to the IMPL idiom to keep that up and also still have common code outside the main class.

Also in the DLL I sometimes didn't tread the interfaces as such, but instead cast to their base and accessed (STL) members directly. Obviously it exploded in my face.

Still irks me to have way more const char* now instead of the nice std::strings. Oh well

At least now it works in both VS 2003 and VS 2008.

C++ doesnt have an ABI, and Microsoft changes the one they made up pretty much every version. Which means you need to decide to either protect the interface from exposing anything STL related, or plan on rebuilding and linking the whole codebase against the new compiler and c/c++ runtime dlls or libs.

Yeah, that's why i was wondering. I did port both DLL and game to VS 2008 (auto-converted the project) and made sure to use the same STL preprocessor defines for both projects. But still had those problems.

Moving to pure interfaces without STL parameters did the trick.