覆盖 CRT 的 _purecall 实现
我目前正在开发一个 DLL，它是一个封闭的工作项目的扩展。
我想捕获每个纯调用错误，所以我用谷歌搜索并找到了 _purecall 处理程序。我的问题是关于它的实施。幕后发生了什么？编译器本身获取我的处理函数地址（如果我定义了一个），并在它被类函数地址本身覆盖（初始化之后）之前将其写入 v 表中的每一行，或者是更复杂的东西，包括CRT 和全局指针？
当然，我问这个问题是因为我不希望我的插件 DLL 覆盖整个应用程序 _purecall 处理程序。我能否确定我的 purecall 处理程序将仅处理我的模块中的 purecall？
谢谢！
I'm currently working on a DLL that is an extension to a closed, working project.
I want to catch every pure-call bug, so I googled it up and found out about the _purecall handler. My question is about it's implementation. What's happening behind the scenes? The compiler itself takes my handler function address(if I defined one) and writes it a default value to each row in the v-table before it gets overridden by the class function address itself(after initialization), or it something more complex, involving the CRT and global pointers?
I'm asking this because I don't want my plugin DLL to overwrite the whole application _purecall handlers, of course. Can I be sure that my purecall handler will handle only purecalls in my module?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
答案在很大程度上取决于编译器如何实现 purecall 处理程序。如果编译器只是替换虚拟函数表中的“纯”函数指针，那么您就可以安全地修改父进程的行为。
但是一些编译器通过从 CRT 的处理程序调用您的处理程序来实现自定义的 purecall 处理程序。在这种情况下，行为将取决于您构建 DLL 的方式。如果您静态链接到 CRT，那么您的 DLL 将拥有其自己的所有 CRT 状态的实例。在这种情况下，编译器实现是无关紧要的。您的 purecall 处理程序不会干扰父进程。
另一方面，如果您动态链接到 CRT，则行为将取决于主机进程的构建方式。如果它动态链接到与您的 DLL 相同版本的 CRT，那么您的 purecall 处理程序确实可能会干扰。但同样，这取决于编译器的实现。即使它从 CRT 调用您的钩子，如果 CRT 为每个模块维护不同的钩子，您也可能是安全的。
无论如何，如果您想确保安全，那么您必须将 DLL 静态链接到 CRT，或者避免使用 purecall 处理程序（另一种选择是使用具体基类而不是抽象基类）。
The answer depends heavily on how your compiler implements the purecall handler. If the compiler simply replaces the "pure" function pointers in your virtual function tables, then you're safe from modifying the parent process behaviour.
But some compilers implement custom purecall handlers by calling your handler from the CRT's handler. In this case, the behaviour will depend on how you've built your DLL. If you've statically linked to the CRT, then your DLL will have its own instance of all CRT state. In this case, the compiler implementation is irrelevant. Your purecall handler will not interfere with the parent process.
On the other hand, if you've dynamically linked to the CRT, the behaviour will depend on how the host process was built. If it was dynamically linked to the same version of the CRT as your DLL, then your purecall handler could indeed interfere. But once again, this depends on the compiler implementation. Even if it's calling your hook from the CRT, you could be safe if the CRT maintains different hooks for each module.
In any case, if you want to be safe for sure then you must either statically link your DLL to the CRT or avoid using the purecall handler (an alternative would be to use concrete base classes instead of abstract ones).