其实这种所谓遗传的限制又何止在Windows上存在。

====================================================================================

一个由虚拟设备文件而造成的限制，竟然能跨越三十多年，跨越CP/M、MS-DOS、Windows、OS/2和Windows NT五个架构而以相同的形式存在，这最后也许真是微软的一场悲剧。
1973年，一个名为CP/M的操作系统诞生了。CP/M的文件系统是单层目录结构，文件名限制为8.3字符。为了支持用户程序的输入输出，CP/M提供了虚拟文件 COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL。
1980年，西雅图电脑产品（Seattle Computer Product）山寨了一个CP/M，称为86-DOS。因此，它同样具有CP/M具有的那些虚拟文件，同样是单层目录结构和8.3字符。由于许多程序总是将文件带扩展名保存，所有以那些虚拟文件名为主文件名的文件，都被视为和那些虚拟文件等价。

1973年，一个名为CP/M的操作系统诞生了。CP/M的文件系统是单层目录结构，文件名限制为8.3字符。为了支持用户程序的输入输出，CP/M提供了虚拟文件 COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL。
1980年，西雅图电脑产品（Seattle Computer Product）山寨了一个CP/M，称为86-DOS。因此，它同样具有CP/M具有的那些虚拟文件，同样是单层目录结构和8.3字符。由于许多程序总是将文件带扩展名保存，所有以那些虚拟文件名为主文件名的文件，都被视为和那些虚拟文件等价。

1981年，微软买下了86-DOS，并将其以MS-DOS 1.0的名字发布给用户。

1983年，MS-DOS 2.0发布了，它加入了树形目录结构。为了保持向下兼容性，所有的虚拟文件，COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL，在所有磁盘的所有目录下，不管扩展名是什么，都存在并且实现相同的功能。

1985年，微软终于做出了他们自己的图形用户界面，Windows 1.0。Windows 1.0的所有文件API，都是在DOS中断的基础上实现的，因此那些虚拟文件，在Windows下仍然是你看不到，却永远是存在的，它们的文件名，也就成为了保留文件名。

1987年，微软和IBM合作，推出了一个旨在实现“比DOS更好的DOS，比Windows更好的Windows”的新操作系统OS/2。OS/2虽然已经不再基于DOS，甚至文件系统也换成了新的HPFS；但是，为了与MS-DOS程序相兼容，这些始于CP/M的虚拟文件，其实现被几乎原封不动地带到了OS/2中，它们的文件名，也成为了Windows的保留文件名。

1988年，微软挖来了前VMS工程师Dave Cutler。在他的带领下，一个将成为OS/2的继任者的多用户、抢占式多任务操作系统投入了开发。由于微软和IBM合作关系的破裂，这个系统并没有被作为OS/2的继任者发展起来，而是在1993年以Windows的超集与继任者身份发布——Windows NT。它引入了全新的、当时可谓强大的NTFS文件系统，使得文件名没有必要再被8.3字符限制；但是，因为需要通过NTVDM保持与DOS和Windows（16位）的兼容，以及和旧Windows程序的源码级兼容，DOS（也是Windows）的那些虚拟设备文件，COM1, COM2, COM3, COM4, LPT1, LPT2, CON, AUX, PRN, 和 NUL，又顺理成章地在Windows NT最重要的Win32子系统中实现（虽然由于系统对资源的保护，它们可能无法实现原有的功能），它们的主文件名继续成为保留文件名。

由于Windows NT在当时对系统要求过高（16MB内存在1993年仍然需要一笔较大的投入），而且其运行速度也不够快，微软仍然在继续并行发展旧的Windows架构。

1995年，第一个不需要MS-DOS就能工作的旧系列Windows——Windows 95在万众瞩目中诞生。它不仅拥有连Windows NT都羡慕的即插即用功能，并且正式将Win32的一个功能比较完整的子集引入了旧Windows，同时引入了前两年Windows NT在DOS传统的文件系统——FAT中加入的扩展VFAT，文件名不再受8.3字符限制。然而，一方面由于Windows 95仍然有来自DOS和以前的Windows的“根”，加上Win32子集同样保留了这条“根”，DOS的虚拟设备文件的文件名，继续作为保留文件名在Windows 95，以及后来的Windows 95 OSR2（加入了FAT的新实现FAT32）、Windows 98和Windows Me中存在。

2001年，微软正式发布了完全针对个人用户的Windows NT家族最新成员Windows XP，终结了旧系列Windows的15年历史。从那一时刻开始，Windows NT就是Windows。

2009年，微软发布了第一个不再具备兼容DOS和旧16位Windows程序的能力的Windows——Windows Server 2008 R2。虽然为了兼容DOS和Win16的子系统NTVDM已经消失，但是它又加入了一个能兼容32位的Windows程序的新NTVDM，就算是64位原生程序，其仍然最终实现在64位的Win32子系统（经常被称作Win64，但微软官方并不如此称呼）中。同样为了最大限度实现源码级向下兼容，CP/M、MS-DOS、Win16和32位Win32下的虚拟设备文件，虽然大部分已经失去原来的作用，但仍然如幽灵一般，在64位Win32子系统眼中的任何一个磁盘目录下隐藏着，虽然它们其实并不存在，但是你仍然无法直接建立和打开任何主文件名和它们中的任何一个相同的文件。

一个由虚拟设备文件而造成的限制，竟然能跨越三十多年，跨越CP/M、MS-DOS、Windows、OS/2和Windows NT五个架构而以相同的形式存在，如果从向下兼容角度看，这是个奇迹；但是从发展的角度来看，一个已经放弃与这个限制的来源——MS-DOS的兼容性的全 新64位系统，竟然还要被它所继续限制。反观类Unix系统，虽然存在着更多的虚拟设备文件，甚至存在着stdin/stdout/stderr这样和文 件系统无关的虚拟文件，但它们都是独立的，位置固定的文件，而不像现在我们谈到的的这些，不管在哪个目录，它们都像幽灵一样存在。

LPTx、COMx、PRN、AUX等等虚拟设备的功能，都是在当时为当年的PC而设定的。这些虚拟设备在现代Windows中的存在，在打印驱动程序设置的画面、拨号网络设置中都能清晰地看到。但是，Windows早已具备完善的、与底层无关的对串并口进行操作的API，开发者根本没有必要，甚至是不能通过读写这些虚拟文件来访问串口和并口。

CON、NUL，某种意义上可以说类似C语言的stdin、stdout和Unix的/dev/null，但是，在cmd环境下运行批处理文件，对console输入和输出都有比较完整的处理手段，而基本没有直接对CON进行处理的必要。当然，copy con 文件名 这样DOS下的东西，在CMD下仍然完全有效。

这些无处不在的虚拟文件的存在，也反映了DOS的“磁盘操作系统”的本性，文件系统就是磁盘的卷，里面的结构可以千变万化，而不像类Unix系统那样，整个文件系统是逻辑概念，不需要和磁盘等存储设备形成对应关系。Unix中的设备文件都放在/dev下，子文件系统可以被“mount”在根文件系统的任何目录下，然而DOS下由于文件系统没有统一的结构，每一个“盘符”下面就是一个独立王国，不可能拿出一个固定的地方来映射设备，也许微软当时也没有做长远考虑，就让这些幽灵般的设备文件在文件系统的任何地方都有效，然而他们显然没有想到，后来Windows NT的Native层已经有了一个和Unix有些类似的根文件系统，符号链接、挂载点等文件系统概念也在慢慢实现。但是，他们实现Win32有一个很重要的目的就是让为基于DOS的16位Windows系统开发者能够很快移植到NT为首的新平台上来，因此他们把DOS的这个显著特性也完全给移植了过来。后来，NT就算移植到非x86架构，移植到x86-64架构，仍然要对最初的Win32兼容，这样下来，DOS的这些特性一直保留到了DOS已经完全在系统中消失的今天。

苹果当年从90年代末已经成为“活化石”（协作式多任务，没有内存保护）的旧Mac OS系统迁移到基于Nextstep和BSD的Mac OS X系统，也设计了一个和当年的Win32类似的Carbon API，它把旧Mac OS中大多数正规的系统管理器（旧Mac OS的各种系统调用都称之为各种各样的“Manager”）移植到了Mac OS X，以方便开发者迅速转到Mac OS X上来。当初，苹果和微软不同，他们明确声明了Carbon将只是一个过渡的API，最终苹果将放弃对它的支持，开发者必须最终过渡到Mac OS X原生的接口Cocoa上来。然而，以Adobe为首的某些大公司忽略了这一说法，虽然很快就使用Carbon开发了一系列经典大型软件的Mac OS X版本，但他们并没有认真考虑Cocoa化的时间表。2007年苹果突然宣布，Carbon在Leopard系统之后将不再被更新，Mac OS X移植到x86-64架构时将不包括原生版本的Carbon库，iPhone OS也不支持Carbon。Adobe等这时才傻了眼，回过来慢慢Cocoa化自己的那些大怪物们已经显得非常仓促。这样，Flash插件在OSX下慢、Photoshop CS4 Mac版不支持64位等等问题成了乔布斯严厉抨击他们“懒惰”的重要理由。对Adobe来说，直到CS5，其Creative Suite系列仍未能彻底转向Cocoa，未能保持与其Windows版本同步的功能，至于Flash插件，则是仓促做了Cocoa版，却仍然和以前一样能让Macbook变成火炉。至于苹果，其异常高调的对Adobe的抨击，是建立在Leopard到Snow Leopard的大量进步基础上的：支持了OpenCL，支持了新的多线程API Grand Central Dispatch （GCD），完全Cocoa化的新QuickTime框架，而整个系统的大小反而比Leopard小了1G以上。虽然抛弃了Carbon的发展，但是Snow Leopard对旧程序的兼容性，和Leopard相比并没有降低。

微软通过各种正当的或者无耻的甚至非法的手段达成的强大垄断优势，一个方面也拖慢了微软的发展。虽然他们竭尽全力想保持向下兼容性，但是从Windows 98到Windows 2000、XP，Windows XP到Vista，总是有一批软件最终无法兼容。有人说如果一件东西没有坏就不要修它，但是当今IT的发展已经达到微软靠传统垄断模式越来越力不从心的程度了。前有苹果iOS/AppStore平台的强大威胁（至少在美国是如此），后有Google的云计算概念，微软总是被动迎战，但Zune打不过iPod，Windows Live永远找不着北，进入Bing时代后虽然耗费了比苹果还多的宣传费，却完全无法在全球和Google，中国和百度、腾讯对抗。掣肘微软创新的，也许就是微软的垄断平台中那些他们没有勇气砍掉的东西，那些CON、LPTx、COMx，那个C:，那个越来越难以实现的“向下兼容”……Windows 7中干脆搞了个在虚拟机上实现的“Windows XP 模式”，这证明他们已经开始意识到他们的那些“向下兼容”已经和他们的创新发生冲突了。也许有一天，当一个全新的、强大的、简洁的Windows系统出现的时候，所有的旧应用程序都能在一个几乎完美的虚拟旧系统的环境中运行，这时候，CON、LPTx、COMx终将从系统的保留文件名中彻底消失，而他们实现的新的“向下兼容性”将比以往任何时候都强大。

生物的进化达到人类这种水平，人类依然保持着灵长类的一切特征、哺乳类的一切特征和动物的一切特征，人类的身体成为人类发展的最后障碍；微软为了保持向下兼容性，折腾了20多年，.net这样的革新提出了10年，Windows仍然还没摆脱这样一个小小的限制。这最后也许真是微软的悲剧吧。

作者注：这篇文章在一位朋友发给我开头那张图之后顺手写成，几句气话而已。尽管把口水喷过来，无论你拿着美分、角票、日元，或者只是为了图一时之快。