如何在另一个 CRT 库中重新路由 std::clog？
我有一个使用 VS2008 构建的 Win32 程序，因此我的代码与 MSVCR90.DLL 和 MSVCP90.DLL 链接。但是，它也在使用 VS2005 构建的 DLL（我无法修改）中运行代码，并且当该 DLL 中的代码打印到 clog 流时，它是通过 MSVCR80.DLL 和 MSVCP80.DLL 执行的。问题是：如果我在代码中重新路由 std::clog，我只会影响针对 crt 9.0 库构建的代码，使用旧版 crt 8.0 的代码不会重新路由其输出。那么有没有办法在针对旧 CRT 构建的 DLL 中重新路由阻塞流呢？
我研究了在较旧的 CRT DLL 上调用 GetModuleHandle() 和 GetProcAddress() 并设法重新路由 C stderr 流（通过 _open_osfhandle 和 _dup2），但是 C++ 阻塞流似乎仍然不受影响。我想我还需要在旧的 CRT 库中调用 ios_base::sync_with_stdio() ，但我无法获得该函数的有效地址。任何帮助将不胜感激。
谢谢。
I have a Win32 program that's built with VS2008, so my code is linked with MSVCR90.DLL and MSVCP90.DLL. However, it's also running code in a DLL (which I can't modify) that's been built with VS2005 and when code in that DLL prints to the clog stream it does it via MSVCR80.DLL and MSVCP80.DLL. Here's the problem: if I re-route std::clog in my code, I only affect code built against crt 9.0 libs, code using the older crt 8.0 wont have its output re-routed. So is there a way to re-route the clog stream in a DLL built against an older CRT?
I've investigated calling GetModuleHandle() and GetProcAddress() on the older CRT DLLs and have managed to re-route the C stderr stream (via _open_osfhandle and _dup2), however the C++ clog stream still seems to be unaffected. I think I also need to call ios_base::sync_with_stdio() in the older CRT lib but I couldn't get a valid address to that function. Any help would be greatly appreciated.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 VS2005 构建一个辅助 DLL - 该 DLL 应该简单地导出一些函数来完成 VS8 运行时所需的设置。
Build a helper DLL using VS2005 - This DLL should simply export some functions to do the setup you need for VS8 runtime.
还可以尝试
freopen...但这也可能需要在较旧的 CRT 中调用。不过，Eric 关于辅助 DLL 的建议实在是太过分了，只需使用 GetProcAddress 即可获取指向 VC8 版本的指针。最有效的选择是在首先启动流程时重定向标准流。
另一种可能性是延迟加载辅助 DLL，并在加载之前执行流重定向。这样，当 MSVCRT80 加载时，它将附加到重定向流。
Try also
freopen... but this too might need to be called in the older CRT. Eric's suggestion of a helper DLL is massive overkill though, just useGetProcAddressto get a pointer to the VC8 version.The most effective option is to redirect the standard streams when launching the process in the first place.
Another possibility is to delay-load the helper DLL, and perform the stream redirection before loading it. That way when MSVCRT80 loads, it will attach to the redirected stream.