对 API 发展的简单认识
lu_yi_ming(_at_)sina.com 2004.11.5
一、Windows 用户端
微软对 Windows 的若干部分进行了升级（Longhorn 中会看到），之后只提供 CLR 类库 API ，并且 Intel 又把 CPU 的速度提高若干倍后，我们只能写托管应用了。
C 语言大概只能用来写底层驱动，C++ 只能用来写 CLR，忘了 COM 吧，IL 一统江湖，x86 汇编彻底退出程序员的视野，IL 之上衍生出各种新语言... IE 开始支持 IL（比 ASP 支持 IL 可怕多了），互联网上的应用程序会爆炸性出现（不是现在的 DHtml + JavaScript 或 ActiveX 那些），n 多现在的应用程序将来会从 IE 中启动（每天都是最新版、没有病毒、及时修复Bug），微软干脆把 IE 作为桌面...
开始想象：当托管应用成为主流，并且互联网传输速度达到硬盘访问速度的时候，在本地安装应用程序就毫无意义了。当互联网私有数据存储安全性与本地存储相当的时候，在本地保存个人文件就无意义了。这之后本地文件系统就会被人们遗忘，只要那里有个 Windows 就行了。微软开始设计 IL CPU，Intel 低三下四向微软申请此 CPU 的设计许可。
二、Windows 服务器端
C/C++ 还是要保留的，那些运行效率要求高的服务器端平台程序（ASP、数据库）用 IL 来写、在 CLR 中运行可能会有问题，所以基本 C/C++ 语言 API 还是会保留的。
服务器端平台之上的应用程序还是各自的语言，数据库用SQL，JVM 用 Java，ASP 用 IL 。
三、开源的应对
开源社区也开发 IL 的虚拟机，运行在Linux、BSD、Hurd，以及 FireFox 之上；也可以嵌入 Apache，就像当初 Java 的道路。
开源 IL 虚拟机的类库中，关于内存、进程、设备、文件、用户、网络等方面的 API，可以封装 Linux 等操作系统的 API 来实现；关于窗口、消息、绘图等方面的 API，可以封装 XWindow 的 API 来实现；其余类似。
如果微软确实实现了更好更强的 API，那么开源社区也将跟随升级 API。
对于开源社区，只是针对 IL 托管多了一个新项目而已，原来的所有项目都将继续进行，现有的 API 都将继续支持。集市对大教堂的模式竞争将继续。开源社区的 IL 虚拟机长大后，SUN 的 Java/JVM 也会感到巨大的压力。
四、API 发展的限制
内存 API ：虽然托管代码自己管理内存，但也只是对操作系统内存 API 的调用。内存 API 的发展受限于 CPU/MMU 或操作系统的升级。
进程 API ：托管应用被作为普通进程调度。进程 API 的发展受限于操作系统的升级。
设备 API ：标准接口受限于操作系统的升级。特殊调用受限于设备的发展。托管只是这二者的封装。
文件 API ：受限于文件系统的升级。托管 API 只是文件系统 C API （或系统调用）的封装。
用户 API ：受限于操作系统用户管理的升级。托管 API 也只是封装。
网络 API ：受限于网络协议与应用的发展。IPv4 到 IPv6 的升级与托管没有直接关系。托管应用可能导致新高级协议的出现。
图形 API ：托管是对窗口、消息、绘图等 API 的封装，绘图 API 受限于显卡的升级，这几年这方面进步较大。
组件 API ：组件的寻找、通讯会因为托管应用发展而发生很大变化。
综合起来看，基本 API 还在各自的轨道上发展。托管可以视为基本 API 的另一种调用方式，好处是加强安全控制，为代码流动作准备。
五、API 发展带来的变化及竞争
1. 传统个人应用程序
微软虽然新 API 只提供 IL 类库，但不会马上停止老 API 的支持，所以应用开发商可以在适当的时候迁移到 IL 上来。应用程序的核心算法不会有太大变化，但用户界面可能需要尽快升级，带来的问题是升级的成本、风险与竞争、收益之间的权衡与把握。开源社区会在自己的平台上快速仿制。
2. 服务器端应用程序
变化不大，无论是技术还是竞争，现有的 J2EE / .Net 模式可以继续下去，即使开源社区的 IL 虚拟机真正成熟了也只是多了一个同类的选择。
3. 托管代码流动带来的新应用
高风险与大机遇并存，现在还看不清楚。
4. 微软、开源社区与 IBM
托管会让微软取得几年的领先时间。开源社区依然蓬勃发展，追赶超越微软的脚步时刻不停。IBM 会以商人的做法告诉最终用户开源的软件非常好，特别是运行在自己的服务器上，并提供可靠周到的，随需应变的服务保证。
六、附图
Linux 平台技术结构
Window 平台技术结构
