实际的计算机代码可以执行Win API在OS内核内存空间中停留或作为应用程序的一部分一起编译？

Question

如果这个问题涉及过于基本的问题，请原谅我。

作为一个有点接近的人级程序员，我真的很想知道这一点 - 是否在编写应用程序时完全汇总了每个WIN API函数的基本代码，还是执行Win APIS停留的机器代码在内存中，由于PC被启动，并且只有该应用程序使用它们，因此在内存中是操作系统的一部分？

许多应用程序通过功能调用使用了所有操作系统的所有API。因此，我认为，并没有单独使用每个应用程序包含API机器代码，而只包含标题或签名来调用API，并且在启动应用程序时将映射API机器代码地址。

很抱歉，由于我的英语不好，我未能简洁地将这个问题简洁。我真的很想获得您的见解。谢谢。

Answer 1

系统的实现由系统通过编译模块提供（图像）。应用程序代码仅包含足够的信息，以便系统可以识别和加载所需的模块，并解决相应的导入。

例如，请考虑显示消息框的以下代码，等待其关闭，然后退出程序：

#include <Windows.h>

int main()
{
    ::MessageBoxW(nullptr, L"Foo", L"Bar", MB_OK);
}

给定函数签名（在 hinuser.h 中声明，从 Windows.h ）编译器可以几乎生成呼叫指令。它知道Callee期望它们的参数数量，预期类型以及订单和位置。缺少的是 user32.dll 内部的实际目标地址，仅在一个过程完全初始化后才知道，并将 user32.dll 模块映射到其地址空间中。

显然，编译器直到加载时间后才能推迟代码生成。它需要生成呼叫指令现在。由于我们知道 “计算机科学中的所有问题都可以通过另一个层次来解决” em> 这也是编译器所做的：而不是发出直接呼叫指令，而是生成间接呼叫。不同之处在于，尽管直接呼叫需要立即提供目标地址，但间接呼叫可以指定存储目标地址的地址。

In x86 assembly, instead of having to say

    call _MessageBoxW@16   ; uh-oh, not yet known

the compiler can conveniently delegate the call to the

    call dword ptr [__imp__MessageBoxW@16]

避免了灾难，我们已经为我们购买了足够的时间来修复代码，然后才能实际执行。

创建过程对象后，系统将控制控制到其主要线程以完成初始化。该初始化的一部分是加载依赖项（例如 user32.dll 此处）。完成后，系统最终知道加载地址（以及最终导入的符号的地址，例如 _MessageBoxw@16 ），并且可以在地址 __ imp_emessageboxw@16 __ imp__messageboxw@16 <覆盖IAT条目。 /代码>带有导入的功能地址。

这就是系统如何为系统服务提供实现的方式，而无需客户应用程序知道（物理上）他们会在哪里找到它们。

我说“大约” ，因为事情在现实中更加参与。如果那是您想了解的东西，我将把它留给Raymond Chen。他已经发表了a seriper更多详细信息：

• dll函数如何在16位Windows中导出？ >
• 如何在16位Windows中导入DLL函数？
• < < a href =“ https://devblogs.microsoft.com/oldnewthing/20060718-32/？p = 30483” rel =“ nofollow noreferrer”>如何在32-bit Windows中导出DLL函数？
• =“ https://devblogs.microsoft.com/oldnewthing/20060719-24/？p = 30473” rel =“ nofollow noreferrer”>真正是逆转功能，这些函数确实是远期的
• 重新思考32位Windows dll Exports的32位Windows
• 调用导入的函数，幼稚的方式
• 较少天真的编译器如何称呼导入的函数
• 与强迫为导入函数创建的存根有关的问题
• 当您弄错了dllimport时会发生什么？
• 名称是由于某个原因
• 为什么我不能添加一个函数我dllexport'Ed？