FSO和ASO都可以访问文件，他们有什么区别呢？其实，ASO除了在访问字节（非文本）数据有用外，就没有存在的必要了。如果想把例子中的ASO用FSO来实现，那么写入http.responsebody的时候会出错。反之也不行，ASO无法判断文件是否存在。如果文件不存在，loadfromfile就直接出错，没有改正的机会。当然，可以用on error resume next语句让脚本宿主忽略非致命错误，自己捕捉并处理。但有现成的fileexists()为什么不用呢？
另外，由于FSO经常被脚本病毒和ASP木马利用，所以管理员可能会在注册表中修改该控件的信息，使脚本无法创建FSO。其实执行一个命令regsvr32 /s scrrun.dll就恢复了。即使scrrun.dll被删除，自己复制一个过去就行。
热身完之后，下面我们来看一个功能强大的对象——WBEM（由WMI提供）。
【WMI服务】
先看看MSDN里是怎么描述WMI的——Windows 管理规范 (WMI) 是可伸缩的系统管理结构，它采用一个统一的、基于标准的、可扩展的面向对象接口。我在刚开始理解WMI的时候，总以为WMI是"Windows管理接口"(Interface)，呵呵。
再看什么是WMI服务——提供共同的界面和对象模式以便访问有关操作系统、设备、应用程序和服务的管理信息。如果此服务被终止，多数基于Windows的软件将无法正常运行。如果此服务被禁用，任何依赖它的服务将无法启动。
看上去似乎是个很重要的服务。不过，默认情况下并没有服务依赖它，反而是它要依赖RPC和EventLog服务。但它又是时常用到的。我把WMI服务设置为手动启动并停止，使用电脑一段时间，发现WMI服务又启动了。被需要就启动，这是服务设置为“手动”的特点。当我知道WMI提供的管理信息有多庞大后，对WMI服务的自启动就不感到奇怪了。
想直观了解WMI的复杂，可以使用WMITools.exe[2]这个工具。这是一个工具集。使用其中的WMI Object Browser可以看到很多WMI提供的对象，其复杂程度不亚于注册表。更重要的是，WMI还提供动态信息，比如当前进程、服务、用户等。
WMI的逻辑结构是这样的：
首先是WMI使用者，比如脚本（确切的说是脚本宿主）和其他用到WMI接口的应用程序。由WMI使用者访问CIM对象管理器WinMgmt（即WMI服务），后者再访问CIM(公共信息模型Common Information Model)储存库。静态或动态的信息（对象的属性）就保存在CIM库中，同时还存有对象的方法。一些操作，比如启动一个服务，通过执行对象的方法实现。这实际上是通过COM技术调用了各种dll。最后由dll中封装的API完成请求。
WMI是事件驱动的，操作系统、服务、应用程序、设备驱动程序等都可作为事件源，通过COM接口生成事件通知。WinMgmt捕捉到事件，然后刷新CIM库中的动态信息。这也是为什么WMI服务依赖EventLog的原因。
