为什么 Windows 制作 DLL 而不是直接内核访问 [关闭]答案

【问题标题】：Why Windows is making DLL's instead of direct Kernel Access [closed]为什么 Windows 制作 DLL 而不是直接内核访问 [关闭]
【发布时间】：2014-12-21 06:25:18
【问题描述】：

当开发者使用 Windows Libraries 时，大部分代码都是需要 DLL 的。

我们使用 User32.dll 、 Kernel32.dll 、 Gdi32.dll 等...

这些都开放给开发者使用。

所有这些 dll 都使用 SSDT 上定义的系统调用。

为什么我们不能直接访问 SSDT？为什么微软添加 dll 作为代理。 DLL 作为核心代理的优势是什么。

据我所知，当我们调用 LoadLibrary 函数时，我们为每个进程分配数据，这不是共享。

如果我们想将其标记为 shared ，我们将这个 pragma 称为 datas

#pragma data_seg (".myseg")

这可以减少我们在 DLL 上的内存使用量。因为没有进程会再次进行分配。

DLL 是否跨进程提供共享和非共享数据？ CPU 上的 CPL 0 和 CPL 3 安全性如何？ DLL 是否用作核心上的安全层？ DLL 用作调用门？

【问题讨论】：

这个问题似乎是题外话，因为它不是一个实际的问题。您编写程序的方式不会根据答案而改变。这更多是关于操作系统设计的问题。试试cs.stackexchange.com
Windows是强分层的，kernel32.dll等实现了winapi层。还有其他 api、OS/2 和 Posix。原生操作系统 api 非常不同，与 VMS 非常相似，并且多年来发生了变化。
对非常广泛的问题投票-1，显示出非常有问题的研究工作和有争议的可用性（对于任何人）。如果您想了解更多关于类似 Windows 的操作系统的内部结构并获得问题的实用答案，请在reactos.org/wiki/Welcome_to_the_ReactOS_Development_Wiki加入 ReactOS 内核开发团队，然后稍后再写一封 @987654323 @ ;)
并非所有 API 函数都直接调用到内核中，它们中的许多都具有用户模式组件。始终使用 DLL 使 Microsoft 能够灵活地在用户模式和内核模式之间移动代码，同时保持与现有二进制文件的向后兼容性。例如，NT 4 将整个窗口管理器和图形设备接口组件从用户模式移动到内核模式，如described here。如果应用程序直接调用内核，这是不可能的。

标签： windows winapi operating-system

【解决方案1】：

使用某种形式的异常或中断调用操作系统服务。这是允许处理器切换到内核模式所必需的。

这通常必须用汇编语言来实现。汇编代码将寄存器和堆栈设置为系统服务，然后执行类似的指令

将模式更改为内核 #100

其中 100（我的任意值）是对应于系统服务的系统中断向量的索引。该数字会因调用的系统服务而异。

在我的简化示例中，处理器命中更改模式指令、触发器和异常，调用地址为中断向量中第 100 个条目的中断例程。该例程是在内核模式下运行的实际系统服务。

在您的 C/C++/Pascal 程序中，这将是一个 PITA（如果不是不可能的话）。操作系统通常会提供包装函数（在 Windows 中的 DLL 中）为您完成所有这些工作。

换句话说，应用程序调用一个看起来像普通的旧 C/C++/Pascal 函数的包装函数，它是用汇编语言编写的，设置寄存器并触发异常以进入内核模式。相同的函数将解包寄存器以将系统服务中的任何数据返回给调用程序。

【讨论】：