• Advertisement
Sign in to follow this  

Dlls and Win 7

This topic is 3146 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Trying to move some of my code out to dlls for easier reuse. I am setting up the dlls in code like this:
#ifdef DLL_EXPORT
    #define DLL_API __declspec(dllexport)
#else
    #define DLL_API __declspec(dllimport)
#endif

extern "C" DLL_API void Test(int x)
And of course the define is set for the dll code and not for the other code. This works fine in XP but in Win 7 the error "...has stopped working, searching intenet for fix..." is given. If I go back to static link it works in Win 7. I really have no clue if there are coding standards for Win 7 so I might be missing something obvious. But are there any suggestions to this problem?

Share this post


Link to post
Share on other sites
Advertisement
The program using a dll works fine on multiple XP computers. Got a user with the Win 7 beta and the program crashes on start up with the Windows error message I posted in the first message. If I static link the dll code then it works on all computers. So the problem has to be something with my dll creation.

I've even tried exporting it as a class using:


class DLL_API Test
{
public:
...

private:
std::string teststring;
}


And in release mode I'll get warning 'C4251 - class needs to have dll-interface' on the std::string with it crashing in Win 7.

Share this post


Link to post
Share on other sites
You shouldn't include templates in your DLL interface (so that std::string is a no-no).

Also, if you're compiling against the static runtime library, you're going to run into problems with memory allocated between the main program and the DLL - you should compile against the DLL runtime library (that is, your "Runtime Library" under "C++ / Code Generation" should be set to "Multithreaded DLL" or "Multithreaded Debug DLL").

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
The program using a dll works fine on multiple XP computers. Got a user with the Win 7 beta and the program crashes on start up with the Windows error message I posted in the first message. If I static link the dll code then it works on all computers. So the problem has to be something with my dll creation.


You should install some debugging tools on that machine. Maybe the visual c runtimes are missing on his computer, or you forgot to include a dll. But we cannot extract more information from that error. A debugger will tell.

*Edit* Don't forget to check the executable with the dependency walker. It can tell you if there are any dlls missing.

Share this post


Link to post
Share on other sites
I had forgot that I was static linking the VSC++ runtimes in the main exe. And then the dll was set to the default of using the runtime dll. I do not believe the user has the VSC++ runtime installed on his Win 7 computer. Not sure I can get him to install any kind of debugging stuff on his computer. So probably setting the dll to static link the runtime should fix the problem? I know there are other issues of two runtimes being loaded in to memory using this approach. But I really doubt anybody would ever supply dll with a different runtime.

For the std::string issue, do I need to convert my strings to something like a char * to get that warning to go away?

Share this post


Link to post
Share on other sites
You can simply tell him to install the visual studio release runtimes that you're using (2005, 2008, whatever). Then you can switch to dynamic linking again.
And yes, you will need to only export classes that either don't use std::string at all, or use the pimpl idiom to protect your members from being exported.

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
I had forgot that I was static linking the VSC++ runtimes in the main exe. And then the dll was set to the default of using the runtime dll. I do not believe the user has the VSC++ runtime installed on his Win 7 computer. Not sure I can get him to install any kind of debugging stuff on his computer. So probably setting the dll to static link the runtime should fix the problem? I know there are other issues of two runtimes being loaded in to memory using this approach. But I really doubt anybody would ever supply dll with a different runtime.
There are other problems with static linking the runtime library, though. In particular, you exectuable and DLLs will all have their own separate heap. That means that you won't be able delete memory that was newed in a different module.

In general - especially if you're using DLLs - you should be linking to the DLL runtime library.

Share this post


Link to post
Share on other sites
Forgot about the heap issue with static linking.

I don't really need the dll as it works if I static link that code. And I doubt anybody would would really ever need to replace the dll. I think until I can get a Win 7 box myself I am just going to defer the problem.

Thanks for all the suggestions. Ratings for everybody.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement