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

评论

22 楼 ray_linn 2010-07-14  

seen 写道

mallon威武
大姨妈退散

我现在对javaeye已经连争论的兴趣都没有了。

21 楼 seen 2010-07-14  

mallon威武
大姨妈退散

20 楼 mathgl 2010-07-05  

rubynroll 写道

理论上“微内核”架构可以有更灵活的配置，系统可以更轻巧，更容易裁剪。

只是很不幸，臃肿的Windows设计糟蹋了“微内核”的声誉。

所谓过犹不及，过多的分层，过多的抽象，结果就是臃肿。

本应该是“笨重”的mono Linux内核，不仅运行效率高，而且借助Open Source的模式弥补了架构上的不足，反而博得“轻巧灵活”的好名声。

开发过Windows的驱动，也开发过Linux的驱动；感觉一个是地狱，一个是天堂。

体系结构自然有高低，但更重要的是看怎么实践。

windows驱动 早期的VxD确实是噩梦。。不过现在好上许多了...

19 楼 rubynroll 2010-07-04  

理论上“微内核”架构可以有更灵活的配置，系统可以更轻巧，更容易裁剪。

只是很不幸，臃肿的Windows设计糟蹋了“微内核”的声誉。

所谓过犹不及，过多的分层，过多的抽象，结果就是臃肿。

本应该是“笨重”的mono Linux内核，不仅运行效率高，而且借助Open Source的模式弥补了架构上的不足，反而博得“轻巧灵活”的好名声。

开发过Windows的驱动，也开发过Linux的驱动；感觉一个是地狱，一个是天堂。

体系结构自然有高低，但更重要的是看怎么实践。

18 楼 mallon 2010-06-19  

对了我说你这句话“我们通常说的Windows，只是它的子系统之一，称为WoW(Windows On Windows)”是错的。

完整地用三句话讲（应该没有把柄了吧...）

1、“WOW”专指32位Windows NT系统上的16位Windows兼容层，你在32位系统里跑个16位的Windows程序，会在任务管理器中看到“ntvdm.exe”和“wowexec.exe”两个东东，就是这玩意儿；

2、“WOW64”专指64位Windows NT系统上的3位2Windows兼容层。

3、总结地讲，“WOW..”指的是XX位Windows NT系统上的YY位Windows兼容层，XX =/= YY，根本不可能有所谓的XX位Windows NT系统上的XX位子系统一说，其实英文单词“on”已经很清楚了，怎么可能自己“on”自己呢？就好像说“我是我儿子”一样可笑。

17 楼 mallon 2010-06-19  

第三，可能有些不准确。准确讲，NT时代的Microsoft POSIX subsystem、XP/2000时代的Microsoft Windows Services for UNIX (SFU)以及2003 R2/Vista/2008时代的Subsystem for UNIX-based Applications (SUA)都工作在用户态，都是围绕内核吃饭的“应用程序”，和CygWin没什么两样，不准确讲就是“Win32API的包装”了，呵呵

参见：
http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX
http://en.wikipedia.org/wiki/Subsystem_for_UNIX-based_Applications
还有参见你自己贴出来的图。

可能你会说：NFS不是在内核里面吗？我反驳道：NFS是Windows自带的吗？还不是之后像装软件一样装上去的。可能你又会说，类似IIS一样虽然是之后装的，但也属于Windows的一部分啊，IIS的http.sys也工作在内核态呢...这我就说不清了，到底打上Microsoft商标的软件装上去就可以看作操作系统的一部分，还是不能这样看呢？运行在内核态的程序（NFS、http.sys、设备驱动...）算不算做内核的一部分呢？要选地球作为参照系的话，太阳都是绕着地球转的呢...

不谦虚地讲，我的能耐也只到这里为止了，让我再拿出更加深入的证据和你辩论确实无能为力，也不想自寻烦恼，呵呵。微软的东西早让我疲惫不堪了，那些广告似的体系结构图、花哨的命名和句子等也不足以让我意淫，所以你也得拿点更深入的东西才能让我信服。但是我估计很难，Windows内核源代码毕竟是不公开的，Hack再深入还是Hack，上不了正道的。

当然了，Windows很多地方也是相当成功的，比如Win95之后焕然一新、引领潮流的桌面风格；还有NT内核里的对象结构，设计得非常精美，“一切皆对象”和Unix里的“一切皆文件”如出一辙，可惜还是那句老话，历史包袱太重，往上层越包装越丑陋（举个例子：文件路径）

16 楼 mallon 2010-06-19  

其二，Windows的OpenGL就是DirectX的Wrapper。你在Windows下面用OpenGL编程，肯定得链接opengl32.lib库，而opengl32.lib肯定是链到opengl32.dll上。

然后，引述：
http://www.opengl.org/wiki/Getting_started#Windows
http://bbs.games.sina.com.cn/thread-186836-1-1.html
Windows下的OpenGL默认实现（上面讲了，也就是opengl32.dll）在Win98、ME、2000下是纯粹软件实现的，支持到OpenGL 1.1，Windows XP下是Direct3D的包装，支持到OpenGL 1.1，Windows Vista以上也是Direct3D的包装，支持到OpenGL 1.4，如果安装了驱动，那么opengl32.dll会转到驱动提供的dll（前提是如果有的话），由驱动提供的dll调用底层的驱动实现，微软说“关我鸟事，我给你开个门，你厂商爱怎么折腾怎么折腾去”呵呵。

15 楼 mallon 2010-06-19  

我的语文确实很差劲，只能尽力把意思表达清楚吧。

微内核只提供最基本的系统服务，而把其他服务独立出去，指的是功能上的“微”而不是体积上的“微”，模块之间按理讲应该是结构清晰的，但是Windows确是藕断丝连，比如，你能用Windows微内核（这里咬文嚼字一下，Windows内核也并不是完全意义上的“微”，省得又被你抓住什么把柄）加上一些基本的服务，启动一个简单的字符模式的Shell吗？可能你会说可以，“故障恢复控制台”不是典型的例子吗？但是你能在“故障恢复控制台”下面启动系统服务、打开网络吗？藕断丝连的问题出来了吧。可能你会讲，要微软下点功夫改改肯定行的，问题是任何东西“改改”总能实现的，只是难度不同而已，呵呵。

所以第一个问题我的观点是：Windows从内核到上层应用，各个模块之间的耦合是紧凑而且错综复杂的，以至于很难（咬文嚼字一下，差点用了“不可能”这个词而留下把柄，呵呵）用单独一两个模块不拖泥带水地完成某些看似简单的功能。

14 楼 ray_linn 2010-06-19  

mallon 写道

再举个例子，Windows内核再“微”，用PE、Embedded裁减再小也得几十兆，图形界面是肯定得带的，而且随便加一个程序，比如“记事本”、“任务管理器”都得伤筋动骨的，依赖性太强了，记事本的“打开”对话框依赖的是Shell的一整套结构，看看Server 2008 Core里的记事本，“打开”对话框是不是很简陋？微软有源代码，所以他能够“巧妙地”解决一些问题，而我们不能。

你莫非认为微内核=微小的内核？Micro Kernel=Small Kernel? 哪些东西是内核的，那些不是内核的，麻烦回去翻翻书。

你想阐明个什么道理呢？除了带非所问的太极推手之外。能不能老老实实回到最初的地方

OpenGl不是简单Wrap了DirectX?
Posix子系统是不是简单Wrapp了Win32API?


这些观点是不是全是误导人民群众？

13 楼 ray_linn 2010-06-19  

mallon 写道

七猫说的还是很有道理的，我承认很多东西没有深入研究过，但是ray你说“OpenGL32.dll提供了多少个API: 368个，1：368，果然是一叶障目啊，你还真奸猾，真能扯淡”我真要笑了，提醒你一下吧，DirectX走的是COM架构，而COM里申请对象一个函数足矣...

反正Windows也就这样了，新的技术出啊出啊出啊...程序员学啊学啊学啊...活到老学到老，呵呵

申请对象一个函数足矣，但用了其中多少个函数呢？如此证据不足的东西能作为理论依据，我算服了。

12 楼 mallon 2010-06-19  

再继续举例子，看看微软的上层设计，从OLE到COM到DCOM到COM+，微软用C++搭建了一套完整的分布式体系结构的大厦，但是这座大厦确是建筑在C++的沙地上的，最后呢，和同时期同样建筑在C++之上的CORBA一样轰然倒塌。当然很多人会驳斥说C++是好的不是坏的，确实我以前也是这样想的，从哲学上讲任何东西只要不坏都是好的，但是有没有想过和更好的东西比较一下呢？用COM、CORBA编写大型软件，写得吐血，改得便血的时候，有没有想到解放一下自己呢？

没想到？微软倒是想到了，于是模仿Java的基于虚拟机架构的.NET出来了，微软很聪明，从来不讲自己这套东西是基于虚拟机的，而是用一个很学术化的名次“CLR”，说.NET程序是“托管”的，乍一听好像是一套很高明的函数库或者类库，看起来也像，所有.NET程序都链接到了mscoree.dll上，于是乎一大帮“半瓶子水”又开始样样自得起来，以为又学到了什么“博大精深”的东西了。

.NET架构确实做得不错，但是微软是一家商业公司，历史的包袱不得不背，“兼容”“兼容”“兼容”...越做越大，而且真正用起来，稀奇古怪的问题层出不穷，光看帮助没GOOGLE还真搞不定...

微软以前的程序员还是很厉害的，但是这些年新招的程序员貌似是越来越烂了，举个例子，安装SQL Server 2008，那个安装程序一个又一个不同风格不同款式对话框弹出来，有些大字体有些小字体，有些按钮文本款歪在一边，甚至C#图形程序默认的图标都没改，估计是临时工做的吧，笑死...

11 楼 mallon 2010-06-19  

可能有些地方大家都说得不精确，以至于看似观点截然相反，事实上讨论的完全不是一个东西。

确实Windows的分层很清晰，这个我承认，至少从框架图上看是如此，但是一到实用场合就傻眼了，我是个实用主义者，所谓“不看广告看疗效”。

举个例子，写个获取CPU占用的程序，可以直接使用API、或者WMI、或者PDH，厉害点的直接用Native API，选哪个技术呢？用WMI，那早期的NT4上就跑不了了（除非装了WMI）、而且效率也是问题。

再举个例子，Windows内核再“微”，用PE、Embedded裁减再小也得几十兆，图形界面是肯定得带的，而且随便加一个程序，比如“记事本”、“任务管理器”都得伤筋动骨的，依赖性太强了，记事本的“打开”对话框依赖的是Shell的一整套结构，看看Server 2008 Core里的记事本，“打开”对话框是不是很简陋？微软有源代码，所以他能够“巧妙地”解决一些问题，而我们不能。

10 楼 mallon 2010-06-19  

七猫说的还是很有道理的，我承认很多东西没有深入研究过，但是ray你说“OpenGL32.dll提供了多少个API: 368个，1：368，果然是一叶障目啊，你还真奸猾，真能扯淡”我真要笑了，提醒你一下吧，DirectX走的是COM架构，而COM里申请对象一个函数足矣...

反正Windows也就这样了，新的技术出啊出啊出啊...程序员学啊学啊学啊...活到老学到老，呵呵

9 楼 七猫 2010-06-19  

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

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

8 楼 七猫 2010-06-19  

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

7 楼 七猫 2010-06-19  

晕了，我贴一段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硬件加速能力
    *

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

6 楼 ray_linn 2010-06-19  

mallon 写道

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

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

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

Windows确实层次多，但从来没有实现过真正的组件化，组件之间的依赖性是非常大的，上午还有事就不深入讲了吧，反正真正深入研究过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才见鬼了。

5 楼 mallon 2010-06-19  

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确实“博大精深”啊！但是现在已经厌倦了这一切。俗话讲由简入繁易，由繁入简难，“博大精深”并不能说明所谓的“先进”，“大道至简”才是最高境界

4 楼 七猫 2010-06-18  

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

3 楼 ray_linn 2010-06-18  

mallon 写道

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的单一内核，它更像微内核