可以调用.exe的DllMain吗？

Question

我的问题与this one不完全相同(这不是理论上的，只有一个没有消息循环的主线程，InitInstance和ExitInstance不是合适的调用)。

我正在使用一个没有消息循环的控制台应用程序；这个应用程序加载一个带有LoadLibrary函数的exe，以便它可以使用它导出的函数。坏消息: exe的DllMain函数没有被调用(我用一个def文件验证了符号表，DllMain显示正确)；the doc says如果加载的模块是DLL，它就会被调用(太糟糕了)。

在调用LoadLibrary时(可能在调用FreeLibrary时再次执行)，有哪些条件(如果存在)会导致执行exe的DllMain函数？

诚挚的问候

Answer 1

最明显的情况是调用LoadLibrary()的进程显式地获取GetProcAddress("DllMain")，然后调用它。

Answer 2

这些条件包括：

1)将加载的二进制文件编译为DLL (当使用gcc/ld时，表示使用--shared选项；如果使用--shared，则结果文件将是dll，不会运行，如下所示)

2)在要加载的二进制文件的PE文件头中设置IMAGE_FILE_DLL。如果它被设置了，那么文件就是一个动态链接库，当Windows链接器将这个文件链接到你的程序时，它将为你调用它的DllMain()函数(不管它是如何链接的--运行时的LoadLibrary()或者编译时的-llibraryname )。为此，文件还必须满足(1)。但是有了这个标志，正在加载的二进制文件将不能运行。如果未设置IMAGE_FILE_DLL，则在将文件加载到程序中时不会调用DllMain()。

使用--shared编译dll，然后手动从其头文件中删除IMAGE_FILE_DLL (即使用十六进制编辑器)将不起作用-当您运行它时，将只执行DllMain()，并且fdwReason将是一个未定义的数字(在我的机器上为0x28ffd4)。

更新

Windows上的所有DLL和EXE文件都是PE文件，不同之处在于它们的链接方式，以及在它们的标头中设置哪些标志。这就是为什么我写file being loaded而不是dll being loaded的原因。

最后一段还描述了这样的场景:将文件编译为dll，然后通过处理其头文件将其转换为exe。它不起作用。

命名与此无关(您可以选择任何名称，通过一些pexports+dlltool修补程序，您可以为.exe文件创建一个导入库，并能够将其链接为-lexenamewithoutextension

澄清一下：

• 如果不使用--shared进行编译，则不会在其中设置
• ，它将是可运行的，但在您链接--shared时将不会调用DllMain()

​

当您链接it.时，将不能运行

• 如果您使用--shared编译它:将在其中设置DllMain

​

• 如果您不使用--shared编译它，然后手动打开其中的IMAGE_FILE_DLL标志：
  • 它将不再可运行，并且在您链接it.

时不会调用任何DllMain()

​

• 如果您使用--shared编译它，然后手动关闭其中的IMAGE_FILE_DLL标志：
  • 它将是可运行的，但将执行DllMain()而不是()，并且在您链接main时将不会调用DllMain()

​

Answer 3

实际上，Windows完全忽略了函数的名称"DllMain“( Windows NT 3.x的旧Windows API文档明确指出了这一点)。

加载DLL时，调用的不是DllMain()函数，而是位于文件入口点的函数。

当然，链接器将以DllMain()是此函数的方式创建DLL文件。

但是，对于EXE文件，entry函数(将调用WinMain())位于入口点。

因此，很明显，Windows在将EXE文件作为DLL加载时不能调用此函数。