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

Question

如何为Windows进行程序与Windows NT的内核交互或向其发出命令？

内核如何返回任何数据？

Answer 1

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

如果你确实想要承受这一点，我推荐书Windows Internals By Mark Russinovich et ag。另一本好书是经典的Operating Systems by Deitel et al。

开始然而，随着Inside Windows NT by Helen Custer（版1） - 这是一个非常基本的书（注意，最后一个环节有coverof版2的PIC - 这是方式方法更为详细的）。

好吧，简而言之。

Windows组件之间有多种通信协议。他们中的大多数会在一天结束时通过一些共享内存（如缓冲区，堆栈等）使用传递数据。但协议可能会涉及很多，并且对于不同的通信而言是不同的。

我给你的建议是在上面的书中找到一些东西，并确定Windows操作系统的体系结构是如何挂在一起的。从这里你将看到各种组件如何通信。

（应用书呆子的脸） - 相信我这些都是学习Windows和操作系统的绝佳书籍，如果这是浮在你的船上。

Answer 2

试试看：Chapter 5 - Windows NT 4.0 Workstation Architecture。它应该足以开始。

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

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

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

应用程序通过使用本地 过程调用（LPC）与受保护的子系统进行通信，该过程调用是同一台计算机上组件之间的应用程序无关方法 。在 线程切换到内核模式后，微内核安排LPC 进行传送。

使用Fast LPC（一种优化的通信方法），Microkernel 认识到来自应用程序的调用涉及 环境子系统中的线程。它认为调用应用程序线程和 接收子系统线程要配对。接收线程 现在可以使用发送线程的未过期时间。

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

该子系统完成其任务，然后通过相同的方法将控制返回到应用程序中的等待调用线程的 。

将控制返回给应用程序之前，调用线程（从DLL）切换回用户模式。

微软操作系统工程师也使用共享内存窗口的概念来加速通信。数据放置在 执行程序中由进程管理器管理的临时 共享内存窗口中。这让应用程序可以看到子系统的内存 并共享数据而不使用LPC。但是，因为应用程序 线程仍然必须在执行体中运行，所以内核/用户模式转换为 ，并且仍然需要线程切换。

在这里有上exactly是如何完成的调用（是做什么用的ASM命令）的一些注意事项：The system call dispatcher on x86如果你需要它。

Answer 3

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

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

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

所有这些听起来都很复杂，而且这就是为什么Windows从程序员那里隐藏这些细节的原因。内核不需要直接与内核进行通信，Windows为程序员提供了几个DLL，这些DLL可以为他们做到这一点。

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

你可能会问为什么这样做。为什么不直接让kernel32.dll直接调用内核函数呢？原因是为了允许不同的多用户模式API。 Windows NT旨在支持多种API，不仅包括Win32，还包括POSIX和OS/2。每个用户模式API调用ntdll.dll来实现它们自己的API，从而防止它们自己直接调用内核服务。