Linux兼容Win32程序,“一个框架、两个界面”

Linux兼容Win32程序,"一个框架、两个界面"

[日期：2007-07-19]

来源：Linux公社

作者：Linuxidc

[字体：大 中 小]

看看Windows内核怎样来满足这两个条件，就知道我们要做些什么了。

首先是怎样使.sys模块跟有关的系统调用和中断响应挂上钩、接上口。换言之，怎样将.sys模块纳入内核中的设备驱动框架，包括把具体的模块放在 框架中的什么位置上，跟上下左右相邻的模块或部件怎么交互。在Windows内核中，这主要是I/O子系统的事，具体主要体现在两个方面：一方面是模块装 入以后首先要向I/O子系统登记，或向上一层的设备驱动登记，那也就是间接地向I/O子系统登记。另一方面，当有关的系统调用发生时，正是通过I/O子系 统转化成对于具体设备驱动的逐层调用和返回。所以，I/O子系统代表着一个设备驱动框架的主体。不过，I/O子系统并不是设备驱动框架的全部，.sys模 块可能还要跟中断响应挂上钩。例如，一个.sys模块中的一部分可能是作为中断服务程序运行的，另一部分可能是作为bh函数(在Windows中称为 DPC)运行的，还有一部分则受I/O子系统的驱动。Windows的.sys模块都是针对Windows的设备驱动框架开发的，既然我们要把这些. sys模块装入 Linux内核运行，就必须在Linux内核中构建起这么一个框架。具体地，就是要在Linux内核中实现Windows的I/O子系统，Windows 的中断响应/服务机制，以及有关的一些辅助性的成分。

Windows设备驱动框架解决了对.sys模块的装入和使用。如果每个模块都是封闭、独立的，不需要环境的支持，那就够了。但是，事实上几乎不存 在这种封闭、独立的设备驱动模块，几乎每个模块的运行都需要得倒环境的支持。举例来说，一个设备驱动模块在运行中可能需要分配缓冲区。可是设备驱动模块本 身是不具备这个能力的，因为它并不掌握任何可动态分配的内存资源。于是，就只好请求内核予以分配，这就是对环境的依赖。为此，操作系统内核要“引出 (export)”大量的内核函数供动态安装模块调用。这个函数集合的大小、以及每个具体函数的调用条件、参数、作用、返回值、副作用，就构成了具体内核 的设备驱动支撑界面。显然，不同的内核有不同的设备驱动支撑界面，就好像不同的内核有不同的系统调用界面。要让Windows的.sys模块在Linux 内核中正常运行，就必须在Linux内核中提供Windows的设备驱动支撑界面。与系统调用界面不同，Windows设备驱动支撑界面的定义是公开的 (否则第三方就无法为其开发设备驱动模块了)，定义于Win2k或WinXP的DDK、即“设备驱动开发包”。Win2k的DDK中定义了2000来个支 撑函数，但是常用的也就是几百个、甚至更少。当然，微软公开的只是这个界面的定义，而不包括它的实现。

那么，怎样实现这些支撑函数呢？还是老办法，把它们转化成、或者嫁接到相应的Linux设备驱动支撑函数上去。

值得一提的是，Windows对网络设备的驱动另外定义了一个框架，称为NDIS；并专门提供了一个NDIS设备驱动支撑界面，使NDIS设备驱动 模块只需要(并且只应该)调用NDIS界面上的支撑函数。这样，网络设备的驱动就自成体系，有了一个大框架中的小框架。不过，无论是NDIS的框架还是支撑界面都比较小，只能算是Windows设备驱动框架和界面的附庸和扩充，而且许多NDIS支撑函数实际上就是一些Windows设备驱动函数的简单包 装，所以我们将NDIS归入Windows设备驱动的框架和界面。

综上所述，我们开发Linux兼容内核，主要就是在Linux内核中实现这一个框架和两个界面，就是：Windows设备驱动框架、Windows 系统调用界面、以及Windows设备驱动支撑界面。这就是Linux兼容内核开发工作的主体。当然，还有不少零碎的、辅助性的开发工作要做，但相比之下 工作量就比较小了。

不过，说“一个框架、两个界面”是开发工作的主体，这是就兼容内核本身而言，而不是就整个操作系统而言。要让Windows应用软件正常运行，在内 核外面还需要有一些DLL、即动态连接库的支持，以及一些配套服务进程的支持。如果单纯从技术的角度看问题，那么确实只要有了兼容内核就行了，因为我们可 以把 Windows上的DLL和配套服务程序都拷贝过来。可是这不仅是个技术问题，更是个法律问题，我们不能去侵犯微软的版权。所以，这些DLL和配套服务程 序也都需要开发，幸好Wine已经为我们做了许多这方面的工作，只是需要对其中的四个DLL、即所谓“四大件”作些修改。须知把Windows系统调用嫁 接到Linux系统调用的正是这四大件：kernel32.dll、gdi32.dll、user32.dll、还有ntdll.dll，现在则又要使它 们回归本来面目，把扭曲了的东西再扭曲回去。

　　还应看到，Windows的技术和应用本身也在发展，这些发展更多地体现在DLL和服务进程中，例如OLE、COM/DCOM、.NET这些技术大 多是通过DLL和服务进程实现的。Wine虽然已经做了很多这样的DLL和服务程序，但是这方面的开发也许永远不会完，不过那是细水长流的事了。