Jump to content

  • Log In with Google      Sign In   
  • Create Account


DLLs, classes and VS versions


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Endurion   Crossbones+   -  Reputation: 3332

Like
0Likes
Like

Posted 19 January 2011 - 12:59 PM

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)?
Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

Sponsor:

#2 Endurion   Crossbones+   -  Reputation: 3332

Like
0Likes
Like

Posted 21 January 2011 - 01:21 PM

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

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?
Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#3 SiS-Shadowman   Members   -  Reputation: 359

Like
1Likes
Like

Posted 24 January 2011 - 07:01 AM

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.

#4 Endurion   Crossbones+   -  Reputation: 3332

Like
0Likes
Like

Posted 25 January 2011 - 01:02 AM

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.
Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>

#5 Zoner   Members   -  Reputation: 232

Like
0Likes
Like

Posted 25 January 2011 - 06:22 PM

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.

#6 SiCrane   Moderators   -  Reputation: 9392

Like
0Likes
Like

Posted 25 January 2011 - 08:24 PM

Actually, the MSVC ABI is pretty stable. If you go through their bug tracker you can find numerous bugs that Microsoft has declined to fix because they'll screw up the ABI. However, while the ABI is stable, the standard library implementation isn't, and details can and will change just from having different compiler settings.

#7 Endurion   Crossbones+   -  Reputation: 3332

Like
0Likes
Like

Posted 25 January 2011 - 11:32 PM

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.
Fruny: Ftagn! Ia! Ia! std::time_put_byname! Mglui naflftagn std::codecvt eY'ha-nthlei!,char,mbstate_t>




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS