Kernel 命令和程序如何与Windows操作系统通信

为windows制作的程序如何与windows NT内核交互或向其发出命令

---

内核如何返回数据呢？

伙计，这是一个非常广泛的问题

如果你真的想了解这一点，我推荐这本书。另一本好书是经典

然而，从（第1版）开始——这是一本非常基础的书（注意，最后一个链接有第2版封面的图片——这更详细）

简言之，好的

windows组件之间有多种通信协议。他们中的大多数人会在一天结束时通过一些共享内存（如缓冲区、堆栈等）传递数据。但是协议可能非常复杂，并且对于不同的通信是不同的

我给你的建议是仔细阅读上面的书，确定Windows操作系统的体系结构是如何结合在一起的。从这里您将看到各种组件是如何通信的

（运用书呆子的面孔）-相信我，如果你的船能浮起来的话，这些书是学习Windows和操作系统的好书。

试着读一下：。应该足够开始了

最后，一些API直接构建在一些userland DLL中。这些都是直接执行的。其他需要内核模式帮助/服务

对于这些（我从上面的链接中引用）

应用程序使用API对用户模式进行图形调用 动态链接库。实现该调用的组件生成一个 内核模式陷阱调用执行器以切换其线程和复制 从用户模式堆栈到内核模式堆栈的调用参数。 然后，处理器的堆栈寄存器被切换为指向内核 模式现在线程可以在执行器中运行

应用程序通过使用本地端口与受保护的子系统通信 过程调用（LPC），一种独立于应用程序的 同一台计算机上的组件之间的通信。之后 线程切换到内核模式，微内核调度LPC 交货

使用快速LPC，一种优化的通信方法，微内核 识别来自应用程序的调用涉及 环境子系统。它考虑调用应用程序线程和 要配对的接收子系统线程。接收线程可以 现在使用发送线程的未过期时间

图形调用参数被传递给接收子系统 线接收线程切换回用户模式以完成 图形请求

子系统完成其任务，然后将控制权返回给 使用相同的方法在应用程序中等待调用线程

调用线程（从DLL）切换回用户模式 将控件返回到应用程序

微软操作系统工程师也使用了共享的概念 内存窗口，以加快通信速度。数据被放置在一个临时文件中 由中的进程管理器管理的共享内存窗口 总经理这使应用程序可以查看子系统的内存 并在不使用LPCs的情况下共享数据。但是，由于应用程序 线程必须仍然在执行、内核/用户模式转换中运行 仍然需要线程开关

---

这里有一些关于调用是如何完成的（使用了什么ASM命令）：如果需要的话。

为了回答这个问题，理解用户模式和内核模式之间的区别很重要。内核模式是最特权的CPU模式，在这种模式下，执行代码可以完全访问硬件。它用于最低级的操作系统功能。用户模式是一种更受限制的CPU模式。它防止代码直接访问硬件。应用程序以用户模式运行。当然，他们仍然需要以某种方式访问硬件，因此他们需要调用内核

这就是你的问题的出发点。为了允许用户模式代码调用内核，Windows内核设置了一个入口点。在基于x86的系统上，此入口点是软件中断（int 2e）或sysenter/syscall指令。执行这些指令会导致CPU模式切换，将CPU从用户模式转换为内核模式。一旦CPU切换了模式，它就会调用内核指定的函数。在Windows中，此函数是系统服务调度程序

系统服务调度器负责调用用户模式代码所需的内核服务。它获取由用户模式代码指定的函数号，并在系统服务描述符表（SSDT）中查找它。SSDT基本上是指向每个内核服务的函数指针列表。一旦识别出正确的内核服务，它就会使用用户模式应用程序也指定的参数调用它。内核服务完成后，CPU通过iret指令（如果来自软件中断）或sysexit/sysret（如果来自sysenter/syscall）返回应用程序

所有这些听起来都很复杂，事实确实如此，这就是为什么Windows对程序员隐藏这些细节的原因。Windows没有要求程序员通过内核设置的入口点直接与内核通信，而是为程序员提供了几个DLL，它们可以为他们实现这一点

现在又一次变得复杂了。从用户模式调用内核服务的过程在ntdll.dll中实现，但大多数程序员并不直接使用ntdll.dll。相反，它导出一组通用的内核服务，称为本机API。在此之上，Win32 API在kernel32.dll中实现。kernel32.dll中的大多数函数只是ntdll.dll中函数的包装器

你可能会问为什么要这样做。为什么不直接使用内核呢