winapi - 当您可以使用RET时，为什么在Win32下需要ExitProcess？

Question

我注意到，许多使用直接Win32调用(无C运行时相关性)构建的汇编语言示例都说明了对ExitProcess()的显式调用的使用，以在入口点代码的末尾结束程序。我不是在谈论使用ExitProcess()在程序中的某些嵌套位置退出。出乎意料的是，只有很少的示例使用RET指令退出入口点代码。我想到的一个例子是著名的TinyPE，其中程序变体以RET指令退出，因为RET指令是一个字节。使用ExitProcess()或RET似乎都可以完成这项工作。

来自可执行文件入口点的RET将EAX的值返回给KERNEL32中的Windows加载程序，该加载程序最终将退出代码传播回NtTerminateProcess()，至少在Windows 7上如此。在Windows XP上，我想我记得看到过ExitProcess ()甚至在线程清理链的末尾直接调用。

由于在汇编语言中有许多受人尊敬的优化纯粹是在生成较小的代码时选择的，我想知道为什么更多的 float 代码更喜欢对ExitProcess()的显式调用，而不是RET。这是习惯还是其他原因？

从最纯粹的意义上讲，RET指令比直接调用ExitProcess()更好吗？直接调用ExitProcess()似乎类似于通过从任务管理器中杀死程序来退出程序，因为这会短路返回Windows加载器调用入口点的正常流程，从而跳过各种线程清理操作？

我似乎找不到特定于此问题的任何信息，因此我希望有人可以对此主题有所了解。

Answer 1

如果您的主要功能是从C运行时库中调用的，则退出将导致对ExitProcess()的调用，并且该过程将退出。

如果您的主要功能是直接由Windows调用的(如汇编代码一样)，则退出只会导致线程退出。当且仅当没有其他线程时，该过程才会退出。如今，这是一个问题，因为即使您没有创建任何线程，Windows可能也已经代表您创建了一个或多个线程。

据我所知，这种行为没有得到适当的记录，但是在Raymond Chen的博客文章"If you return from the main thread, does the process exit?"中进行了描述。

(我也已经在Windows 7和Windows 10上对此进行了测试，并确认它们的行为符合Raymond的描述。)

附录:在Windows 10的最新版本中，进程加载器本身是多线程的，因此，在进程首次启动时始终会存在其他线程。