[回溯本源] 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仿真系统：