我有一个使用Visual Studio 6在1997年最后编译的共享DLL。我们现在在MS Server 2008上使用此应用程序和共享DLL,它似乎不太稳定。
我假设如果我使用VS 2005或更新版本重新编译,它还会包含对所包含的Microsoft库的改进,对吧?这是常见的必须重新编译MS错误修复?
在新环境中使用旧编译代码时是否有一般性做法?
编辑:
答案 0 :(得分:2)
我无法从MS / VS特定的有利位置发言,但我对其他编译器的经验如下:
ABI(即调用约定或类信息的布局)可能在编译器甚至编译器版本之间发生变化。因此,如果您使用不同的编译器版本编译应用程序和库,您可能会遇到奇怪的崩溃。 (这就是为什么有像COM或NSObject这样的东西 - 它们为不同的模块定义了一种稳定的方式来相互交流)
某些操作系统会根据生成二进制文件的编译器版本或与之关联的系统库来更改其行为。这样他们就可以修复错误而不会破坏变通方法。如果您使用较新的编译器或使用较新的库再次构建,则假定您再次测试,因此他们希望您注意不再需要您的解决方法并将其删除。 (这通常适用于整个应用程序,因此较新的应用程序中较旧的库通常会获得新的行为,并且其解决方法已经已损坏。
新编译器可能更好。它可能有更好的优化器并生成更快的代码,它可能有错误修复,它可能支持新的CPU。
新的编译器/新库可能有更新版本的模板和其他存根,粘合剂和库代码,这些代码将被编译到您的应用程序中(例如C ++模板类)。这可能是#3或上述#1的变体。例如。如果你有一个较旧的std :: vector实现,你传递给较新的应用程序,它可能会崩溃尝试使用已更改的部分。或者它可能效率较低或功能较少。
所以一般来说使用新的编译器是个好主意,但这也意味着你应该小心并彻底测试它,以确保你不会错过任何更改。
答案 1 :(得分:1)
您使用“C ++”和“MFC”对其进行了标记。如果你实际上有一个C ++接口,你真的应该使用你用它构建客户端的相同编译器来编译DLL。 MS不会使C ++ ABI在编译器版本(特别是标准库)中保持完全稳定,因此不兼容可能会导致细微的错误。
此外,较新的编译器通常更擅长优化。
答案 2 :(得分:0)
如果旧的dll看起来更稳定,根据我的经验,这只是因为使用VC6可以更好地掩盖错误。 (对新版本使用广泛的运行时检查?!)
主要的好处是,您可以在与主应用程序交互时无缝地调试dll。还有其他一些你不想错过的改进,例如: CTime能够在2037年之后保留日期。