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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

其二，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调用底层的驱动实现，微软说“关我鸟事，我给你开个门，你厂商爱怎么折腾怎么折腾去”呵呵。

第三，可能有些不准确。准确讲，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里的“一切皆文件”如出一辙，可惜还是那句老话，历史包袱太重，往上层越包装越丑陋（举个例子：文件路径）

对了我说你这句话“我们通常说的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”自己呢？就好像说“我是我儿子”一样可笑。

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

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

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

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

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

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