[回溯本源] Unix Fork和Windows CreateProcess可以比较吗？

进程是现代操作系统的一个最基本的概念。书本上说：进程是一个具有独立功能的程序关于某个数据集合的一次运行活动。它可以申请和拥有系统资源，是一个动态的概念，是一个活动的实体。它不只是程序的代码，还包括当前的活动，通过程序计数器的值和处理寄存器的内容来表示。

详细点说：进程的概念主要有两点：

第一，进程是一个实体。每一个进程都有它自己的地址空间，一般情况下，包括文本区域（text region）、数据区域（data region）和堆栈（stack region）。文本区域存储处理器执行的代码；数据区域存储变量和进程执行期间使用的动态分配的内存；堆栈区域存储着活动过程调用的指令和本地变量。

第二，进程是一个“执行中的程序”。程序是一个没有生命的实体，只有处理器赋予程序生命时，它才能成为一个活动的实体，我们称其为进程。

在Unix系统中，我们通常用fork来创建一个进程，相应的，在Windows操作系统里，我们用的是CreateProcess，一些对两个平台不熟悉的程序员，常常误以为二者是等同的，并得出了诸如在Windows创建进程比在Unix慢许多等错误结论。

fork时发生了什么？
当fork()系统调用发生时，子进程会拷贝其父进程的所有页面，并将其加载入操作系统为它分配的一片独立内存中。这些拷贝的动作很消耗时间，而且在某些情况下并不需要这么做。如果子进程马上执行了"exec"系统调用（用来执行任何可执行文件）或者Fork()之后就退出进程，拷贝父进程的页面就很不划算，因为exec后包括代码段，数据段和堆栈等都已经被新的内容取代，只留下进程ID等一些表面上的信息仍保持原样，而如果fork完之后我们马上就调用exec，这些辛辛苦苦拷贝来的东西又会被立刻抹掉。

在这种情况下，一种叫copy-on-write （随拷随写）(COW)的技术被采用了，当fork发生时，父进程的页面并没有被拷贝到子进程中，相反，这些页面被父进程和子进程所共享。无论父子进程中谁要去修改页面，系统就为该进程拷贝一个独立的特定页面，然后再对其进行修改。该进程以后就只使用这个新拷贝的页面而不再是共享的那个，而别的进程则继续使用共享的页面。这项技术就叫随拷随写，因为当有进程要写页面的时候，就需要先拷贝页面。

采用了COW技术，Fork时，子进程只需要拷贝父进程的页面表就可以了。产生这种设计是因为有时兼容POSIX的操作系统在Fork之后，并不需要执行Exec，比如apache Web Server就因此而受益，这时候的fork让你想起点什么？恩，有点接近Windows的CreateThread。

socket_accept()
fork()
if (child)
    handleRequest()
else
    goOnBeeingParent()

COW技术使得创建子进程的代价小了许多，但是现实情况下，很多时候Fork会紧跟着一个EXEC，因为Exec必须装载所有的映像，unix还是得花很大的代价来创建一个进程。

阐述到这里，比较公平的比较是 Fork近似于NtCreateThread 而CreateProcess 近似于 fork + execve.

这里为什么说比较公平而已，因为还有别的因素我们还未涉及。

相对于Unix，Windows的设计更有弹性，它是一个多层次的而且更加组件化的操作系统，Windows拥有许多子系统，我们通常说的Windows，只是它的子系统之一，称为WoW(Windows On Windows),其他子系统还包括Wow64,Posix和OS2。 Windows NT内核也支持COW fork,但是只为SFU（Microsoft's UNIX environment for Windows）所使用，SFU进程和Win32进程是不同的东西。

回到Win32的进程创建上来，你会发现Windows为Win32进程创建的过程添加了许多枝节。首先，它需要通知CSRSS进程被创建，CSRSS又调用了LPC，而它要求至少kernel32(NTDll.dll)等动态库要被加载，然后它又要处理许多预保留的工作项目,之后该进程才能被认为是一个Win32进程，之后还有许多枝节要去处理比如解析manifests,程序兼容性检查，程序的限制策略等等等等，这些附加在原始进程创建过程之后枝节，无疑拖累了进程创建速度。

这些巴拉巴拉的事情，让我想起了struts，一个又一个filter被插入一次http request之后。

MS提供了一个组策略可以禁用兼容性检查，这样可以大大提高进程的创建速度。此外Win32的运行库(kernel32.dll等等)还带来了大量注册表读操作和初始化。这些东西对 UNIX, SFU或者原生进程都是不存在的。

不带任何子系统的原生进程的创建速度是很快的，而创建SFU进程要比Win32进程简单得多，也快得多，尽管Win32花了许多力气在加载这些枝节之上，但是一方面，它提高了对客户的友好，另一方面，运行库的预加载使得图形界面的处理速度更快,或者Win32进程天生就是为图形处理做准备的。

运行在Windows里Unix Subsystem之上的XClock.



SFU不是unix仿真系统：

现在我就算在win32下作server的开发，也是优先考虑使用 multi-process。提高健壮性和负载能力。

1、WOW提供的是16位Windows的兼容层，可以把它看成是一个16位的模拟器，类似于NTVDM模拟16位DOS一样

2、很多所谓的“子系统”，例如Posix，其实只是一个或几个DLL，按照Posix的标准把底层的API包装了一下而已，甚至大名鼎鼎的OpenGL也是对DirectX的简单包装

3、Windows的设计其实是很拙劣的，文中最后所讲的“Windows的设计更有弹性，它是一个多层次的而且更加组件化的操作系统”等等其实正是Windows的缺点，没办法，商业化带来的后果就是设计思想的匮乏和越积越多的历史包袱

1...WOW是16位兼容层。。。汗，那WOW64呢？

2...我说了半天，您一个字儿都不看？Wrap API那是CygWin做的事情，那是不折不扣在Win32 API上模拟POSIX。举个简单的东西, 你在Win32里模拟出COW给我看看？

3...您一句话就把业界公认的更先进的微内核设计打回老家去了？Windows是混合内核，但比起linux的单一内核，它更像微内核

1、opengl似乎不是directx的简单包装。
2、个人认为windows内核设计比linux内核设计要先进。不知道为什么多层次更加组件化其实正是缺点。

WOW是WOW（专指16位环境），WOW64是WOW64，呵呵不玩文字游戏，我说那些子系统和OpenGL是API Wrap是有根据的，看图






很显然opengl32.dll调用的是ddraw.dll（至于第三方的OpenGL实现，例如SGI的，那就不得而知了），而psxdll.dll最终依赖的是ntdll.dll，众所周知ntdll.dll是用户态的最底层，但是并不是内核态的，微软不是傻子，能够依赖现有实现的，怎么会重来一次呢？

所谓微内核巨内核纯粹炒的是概念，微内核好在哪里？结构清晰合理？那结构清晰合理又得到了什么好处？Who cares？大多数时候关心的是整体架构设计，单单一个内核决定不了什么。

Windows确实层次多，但从来没有实现过真正的组件化，组件之间的依赖性是非常大的，上午还有事就不深入讲了吧，反正真正深入研究过Windows底层的都知道的。

我从一开始写程序就接触的Windows，持续了很多年，也曾为搞懂一个诸如API Hook、Native API之类的问题而沾沾自喜，当时想的是Windows确实“博大精深”啊！但是现在已经厌倦了这一切。俗话讲由简入繁易，由繁入简难，“博大精深”并不能说明所谓的“先进”，“大道至简”才是最高境界

第一、WOW很显然是你在玩文字游戏了。莫非我的写上WOW16,WOW64好骗取稿费？

第二、子系统和API有截然的不同，不要顾左右而言它。至于结构图，我已经贴在上面。我想你根本没玩过子系统。胡乱猜测而已。你也可以去dump一下posix.exe,依赖的win32 api只有寥寥几个而已。

第三、你扯OpenGL32.dll wrap了ddraw.dll里，那么请问用了的哪些个API呢？还是让我们看看你砍到的那些图的余下部分，有图有真相



OpenGL32.dll提供了多少个API: 368个，1：368，果然是一叶障目啊，你还真奸猾，真能扯淡

至于ntdll.dll，那是WOW进入内核态的总入口，OpenGL不是子系统，只是WOW的一部分，不调用ntdll.dll才见鬼了。

晕了，我贴一段opengl的吧，也是从网上copy的。
OpenGL硬件加速

　　在Windows平台上，OpenGL驱动可能有三种模式：纯软件、MCD和ICD：

    *

      纯软件模式：微软提供一个OpenGL的软件实现，所有渲染操作均由CPU完成，速度很慢。如果安装系统时使用Windows自带的显卡驱动程序，那么 OpenGL程序就会运行在软件模式下。而且由于微软有自己的Direct3D，所以对OpenGL的支持很消极，它的OpenGL纯软件实现只支持 OpenGL1.1，而目前OpenGL的最新版本为1.4
    *

      MCD（Mini Client Driver）：MCD是早期微软在Windows NT上支持OpenGL时，为了简化驱动开发时使用的一个模型。在这个模型中，OpenGL渲染管线的变换、光照部分仍然由软件实现，而光栅化部分则由硬件厂商实现，因此只要硬件支持，MCD可以硬件加速光栅化部分。MCD虽然可以简化驱动开发，但是功能限制太大，现在市面上的3D加速卡均支持硬件变换和光照，MCD却不能利用这一特性，看上去MCD已经没有存在的价值
    *

      ICD（Installable Client Driver）：ICD是一个完整的OpenGL驱动模型，比MCD复杂得多。硬件厂商要实现完整的OpenGL渲染管线，如变换、光照、光栅化等，因此只要硬件支持，ICD可以硬件加速整个OpenGL渲染管线。我们通常说的OpenGL硬件加速就是指的通过ICD模型获得的硬件加速，而现在硬件厂商提供的OpenGL驱动程序也都是依照ICD模型开发的。主要硬件厂商的ICD已经可以支持OpenGL的最新版1.4

 

　　Windows怎么实现OpenGL硬件加速呢？OpenGL32.dll是微软的OpenGL 1.1纯软件实现，我们的程序都要动态链接到这个 dll。如果安装3D芯片厂商的驱动程序，会将一个不同名字的dll放到Windows系统目录下，比如在Windows 2000下安装 nVIDIA GeForce2 MX的驱动程序，会在系统目录下放一个nvoglnt.dll（这就是nVIDIA的OpenGL驱动），并在注册表中登记nvoglnt.dll，让Windows知道硬件加速OpenGL驱动的名字，以后运行OpenGL程序，OpenGL32.dll就会把 OpenGL调用直接转到nvoglnt.dll。

 

    Windows平台上，一个OpenGL程序是否使用硬件加速由三个因素决定，这三个因素缺一不可，否则程序都会运行于纯软件模式：

    *

      是否有一块3D加速卡
    *

      是否安装了显卡厂商提供的最新的驱动程序，Windows自带的显卡驱动程序并不会提供 OpenGL硬件加速能力
    *

      指定的像素格式是否被显卡硬件所支持

不要很显然的就：opengl是directx的封装了。

单单从导入库来猜测有时候并不一定正确。

我虽然不能说对windows内核很熟悉，但windows的组件即使依赖性很强，也比linux要好些。