C ++：加载EXE作为一个DLL，本地的vftable问题 [英] C++: Loading an EXE as a DLL, local vftable problem
问题描述
好的，所以这一个很长时间来解释一下我这么裸露。
我有一个名为test.exe的exe，通常用作独立的应用。我想在另一个应用程序app.exe中使用这个exe作为一个模块（一个dll）。
test.exe中的代码做了一些非常简单的例子： p>
void doTest（）
{
MyClass * inst = new MyClass（）;
inst-> someMethod（）;
}
其中 someMethod（）是虚拟的，MyClass有一个虚拟的。
doTest（）从test.exe导出，因此一个名为test.lib的lib是创建
app.exe与此lib相关联，以便在启动时静态加载test.exe。
当我运行test.exe stand - 它运行很好，但是当我运行它从app.exe中加载它崩溃。
使用调试器进入代码，显示崩溃是在调用虚拟方法。事实证明，vftable以某种方式变得不好。
经过一些调查，事实证明，当MyClass的构造函数中的代码正在运行时，vftable是一回事，但是当调用新的返回它被替换为其他称为local vftable的东西。我发现这个模糊的讨论，为什么这是。
在大概一天的调试之后，我发现这两个例子中的local vftable指针是相同的，当test.exe是独立的，作为模块加载。这不能正确，因为test.exe加载到不同的地址...
为了测试这个理论，我将链接器选项中的加载地址更改为加载test.exe的地址在app.exe中，现在，所有的一切都有效。
显然，这不是永久的解决方案，因为下一次这个随机选择的地址可能被占用，所以我的问题是：为什么这个本地vftable绑定到exe的静态加载地址？正在加载一个exe作为模块的坏事？为什么exe假定它被加载到其静态地址？
只适用于上下文：这一切都是用MSVC 2008，Windows XP x64完成的。
我最终使用的解决方法是简单地添加一个编译配置，并将exe编译为一个真正的DLL，而不是强制它像一个。 / p>
使用 / fixed：no 由于某种原因没有解决问题。
exes和DLL之间的另一个区别是入口点是不同的。一个DLL的入口点是DllMain，其中exe在CRT中的入口点，最终调用main（）或WinMain（）。
Ok, so this one is abit long to explain so bare with me..
I have an exe named test.exe which is usually used as a stand alone application. I want to use this exe as a module (a dll) inside another application, app.exe.
The code in test.exe does something really simple like:
void doTest()
{
MyClass *inst = new MyClass();
inst->someMethod();
}
Where someMethod() is virtual and MyClass has a virtual d'tor.
doTest() is exported from test.exe and thus a lib called test.lib is created
app.exe is linked with this lib to statically load test.exe when it starts.
When I'm running test.exe stand-alone it runs just fine but when I'm running it loaded from within app.exe it crashes.
Stepping into the code with the debugger revealed that the crash is in the call to the virtual method. It turns out that the vftable somehow goes bad.
After some investigations it turns out that when the code inside the constructor of MyClass is running , the vftable is one thing but when the call to new returns it is replace with something else called a "local vftable". I found this obscure discussion about why this is.
After about a day of debugging it occurred to me that the pointers in this "local vftable" are the same in both cases, when test.exe is stand alone and whenit is loaded as a module. This can't be right because test.exe is loaded into a different address...
To test this theory I changed the loading address in the linker options to the one where test.exe is loaded when it is in app.exe and now, lo and behold, everything works.
Obviously, this is not a permanent solution because next time this randomly selected address may be occupied and the same problem will occur again.
So my question: Why is this "local vftable" tied to the static loading address of the exe? is loading an exe as a module a bad thing? why does the exe assume it is loaded to its static address?
Just for context: this is all done with MSVC 2008, Windows XP x64.
The workaround I ended up using is to simply add a compile configuration and compile the exe as a real dll instead of forcing it to act like one.
using /fixed:no didn't solve the problem for some reason.
Another difference I between exes and DLLs is that the entry point is different. a DLL's entry point is DllMain where as an exe has its entry point in the CRT which eventually calls main() or WinMain().
这篇关于C ++：加载EXE作为一个DLL，本地的vftable问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
