我有一个可执行文件（我使用Visual C ++ 10创build的），我需要使用我写的其他程序（相同环境）的function。 由于复杂的部署要求，我不会去，从所需的functionbuild立一个DLL，并加载到这两个程序是不是我能做的事情。
所以我以为我可以在EXE中使用__declspec(dllexport)函数，然后LoadLibrary()会让我GetProcAddress()它们。
显然这是不可能的，但是当我开始看时，这看起来是可行的。
特别是，当你在一个EXE项目中使用__declspec(dllexport)函数时，Visual C ++也会生成一个用于dynamic链接的lib文件 – 所以你甚至不需要使用LoadLibrary() – 只需要链接到结果库并调用函数。
不幸的是，主要的问题是，当你将结果文件声明为EXE时，Visual C ++将“CRTmain”入口点添加到生成的文件中，而不是DLL获取的“CRTDLLmain”。 当Windows（自动） LoadLibrary()从您的主程序的EXE，它不调用“CRTDLLmain”入口点（因为它不存在），该模块的C运行时不会被初始化，并作为结果所有有趣的工作（例如内存分配）失败，有趣的（*）运行时exception。
所以，如下所示，我的问题是：是否有一种方法可以使Visual C ++在生成的文件中构build“CRTmain”入口点和 “CRTDLLmain”入口点？
（*）像“中国古老的诅咒”中的“有趣”
对的，这是可能的。
http://www.codeproject.com/Articles/1045674/Load-EXE-as-DLL-Mission-Possible
这个想法是a）修补IAT和b）在调用你的出口之前调用CRT。
根本不！ 问题是CRT和你想加载的EXE使用一些全局变量。 你的主EXE是一样的。 那么内存分配应该如何工作呢？
如果你想使用这样的结构，你必须使用一个DLL意识到多线程，CRT初始化和所有这些其他的东西。 你需要这个！
但是COM自动化呢？ 这不是一个简单的解决方案，在另一个EXE中使用你的代码？
最简洁的答案是不”。 在远远地看了之后，没有办法让VC ++做我想做的事情，很可能没有其他的编译器。
主要的问题是大多数人都知道并且喜欢的main()入口点并不是C ++可执行文件的真正切入点：编译器需要做很多初始化工作才能使“C ++运行时库”进入可用状态，以及初始化全局变量，静态变量等。 这个初始化在共享库中使用不同的代码，而不是在可执行文件中，并且没有办法像另一个那样运行。
有一件事是可以做到的，就是将共享的功能建立到一个DLL中，并且主要的可执行文件将DLL作为资源嵌入，并从可执行文件的内存映射区域加载它（有几个代码示例如何用stackoverflow和网络上的其他地方的VC ++来做到这一点）。 现在另一个程序可以通过从捆绑可执行文件加载DLL来完成同样的事情。